Newest 'libx264' Questions - Stack Overflow

Les articles publiés sur le site

• How to port signal() to sigaction() ?

  28 septembre 2016, par Shark

  due to recent problems discovered with NDK12 and NDK13b2, i'm thinking of 'porting' libx264's use of signal() (and missing bsd_signal() in ndk12) to use sigaction() instead.

  The problem is, I'm not quite sure what's the simple&fastest way to replace signal() calls with sigaction() ones.

  For all i see, it's mainly used in x264-snapshot/common/cpu.c in the following manner:

  using the following signal handler:

  static void sigill_handler( int sig )
  {
      if( !canjump )
      {
          signal( sig, SIG_DFL );
          raise( sig );
      }
  
      canjump = 0;
      siglongjmp( jmpbuf, 1 );
  }
  

  This is the problematic x264_cpu_detect function... currently, i'm guessing i only need to tackle the ARM version, but i';; still have to replace all occurances of signal() with sigaction() so i might just cover both of them to get the thing building...

  FYI - the NDK13 beta2 still has "unstable" libc and the build doesn't fail on this part, but rather the first invocation of the rand() function somewhere else... So i'm out of luck and replacing the signal() calls might be better than just waiting for the official NDK13 release. I'm doing this to get rid of text-relocations so i can run the library (and doubango) on API 24 (Android N)

  the problematic part of function that invokes signal():

  #elif SYS_LINUX
  
  uint32_t x264_cpu_detect( void )
  {
      static void (*oldsig)( int );
  
      oldsig = signal( SIGILL, sigill_handler );
      if( sigsetjmp( jmpbuf, 1 ) )
      {
          signal( SIGILL, oldsig );
          return 0;
      }
  
      canjump = 1;
      asm volatile( "mtspr 256, %0\n\t"
                    "vand 0, 0, 0\n\t"
                    :
                    : "r"(-1) );
      canjump = 0;
  
      signal( SIGILL, oldsig );
  
      return X264_CPU_ALTIVEC;
  }
  #endif
  
  #elif ARCH_ARM
  
  void x264_cpu_neon_test( void );
  int x264_cpu_fast_neon_mrc_test( void );
  
  uint32_t x264_cpu_detect( void )
  {
      int flags = 0;
  #if HAVE_ARMV6
      flags |= X264_CPU_ARMV6;
  
      // don't do this hack if compiled with -mfpu=neon
  #if !HAVE_NEON
      static void (* oldsig)( int );
      oldsig = signal( SIGILL, sigill_handler );
      if( sigsetjmp( jmpbuf, 1 ) )
      {
          signal( SIGILL, oldsig );
          return flags;
      }
  
      canjump = 1;
      x264_cpu_neon_test();
      canjump = 0;
      signal( SIGILL, oldsig );
  #endif
  
      flags |= X264_CPU_NEON;
  
      // fast neon -> arm (Cortex-A9) detection relies on user access to the
      // cycle counter; this assumes ARMv7 performance counters.
      // NEON requires at least ARMv7, ARMv8 may require changes here, but
      // hopefully this hacky detection method will have been replaced by then.
      // Note that there is potential for a race condition if another program or
      // x264 instance disables or reinits the counters while x264 is using them,
      // which may result in incorrect detection and the counters stuck enabled.
      // right now Apple does not seem to support performance counters for this test
  #ifndef __MACH__
      flags |= x264_cpu_fast_neon_mrc_test() ? X264_CPU_FAST_NEON_MRC : 0;
  #endif
      // TODO: write dual issue test? currently it's A8 (dual issue) vs. A9 (fast      mrc)
  #endif
      return flags;
  }
  
  #else
  
  uint32_t x264_cpu_detect( void )
  {
      return 0;
  }
  

  So the question is really this: what would be the quickest/easiest//fastest way to replace the signal() calls with sigaction() ones while preserving the current functionality?

  EDIT: The reason i'm trying to get rid of signal() are these build errors:

  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function sigill_handler: error: undefined reference to 'bsd_signal'
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
  

  I already know that this is a known NDK12 problem, that might be solved by bringing bsd_signal back to the libc in NDK13. However, in it' beta state with it's unstable libc - it's currently missing the rand() function and simply waiting for it might not do the trick. But in the worst-case scenario, i guess i'll just have to wait for it and retry after it's release.

  But as it currently is, the prebuilt version of the library i want to use has text-relocations and is being rejected by phones running newer API / version of the android OS.

  EDIT2: I also know that signal() usually works by using sigaction() under the hood, but maybe i won't get bsd_signal related build-errors... since i'm suspecting that this one isn't using it. It's obviously using bsd_signal, which may or may not be the same underlying thing :/

• How to port signal() to sigaction() ?

  28 septembre 2016, par Shark

  due to recent problems discovered with NDK12 and NDK13b2, i'm thinking of 'porting' libx264's use of signal() (and missing bsd_signal() in ndk12) to use sigaction() instead.

  The problem is, I'm not quite sure what's the simple&fastest way to replace signal() calls with sigaction() ones.

  For all i see, it's mainly used in x264-snapshot/common/cpu.c in the following manner:

  using the following signal handler:

  static void sigill_handler( int sig )
  {
      if( !canjump )
      {
          signal( sig, SIG_DFL );
          raise( sig );
      }
  
      canjump = 0;
      siglongjmp( jmpbuf, 1 );
  }
  

  This is the problematic x264_cpu_detect function... currently, i'm guessing i only need to tackle the ARM version, but i';; still have to replace all occurances of signal() with sigaction() so i might just cover both of them to get the thing building...

  FYI - the NDK13 beta2 still has "unstable" libc and the build doesn't fail on this part, but rather the first invocation of the rand() function somewhere else... So i'm out of luck and replacing the signal() calls might be better than just waiting for the official NDK13 release. I'm doing this to get rid of text-relocations so i can run the library (and doubango) on API 24 (Android N)

  the problematic part of function that invokes signal():

  #elif SYS_LINUX
  
  uint32_t x264_cpu_detect( void )
  {
      static void (*oldsig)( int );
  
      oldsig = signal( SIGILL, sigill_handler );
      if( sigsetjmp( jmpbuf, 1 ) )
      {
          signal( SIGILL, oldsig );
          return 0;
      }
  
      canjump = 1;
      asm volatile( "mtspr 256, %0\n\t"
                    "vand 0, 0, 0\n\t"
                    :
                    : "r"(-1) );
      canjump = 0;
  
      signal( SIGILL, oldsig );
  
      return X264_CPU_ALTIVEC;
  }
  #endif
  
  #elif ARCH_ARM
  
  void x264_cpu_neon_test( void );
  int x264_cpu_fast_neon_mrc_test( void );
  
  uint32_t x264_cpu_detect( void )
  {
      int flags = 0;
  #if HAVE_ARMV6
      flags |= X264_CPU_ARMV6;
  
      // don't do this hack if compiled with -mfpu=neon
  #if !HAVE_NEON
      static void (* oldsig)( int );
      oldsig = signal( SIGILL, sigill_handler );
      if( sigsetjmp( jmpbuf, 1 ) )
      {
          signal( SIGILL, oldsig );
          return flags;
      }
  
      canjump = 1;
      x264_cpu_neon_test();
      canjump = 0;
      signal( SIGILL, oldsig );
  #endif
  
      flags |= X264_CPU_NEON;
  
      // fast neon -> arm (Cortex-A9) detection relies on user access to the
      // cycle counter; this assumes ARMv7 performance counters.
      // NEON requires at least ARMv7, ARMv8 may require changes here, but
      // hopefully this hacky detection method will have been replaced by then.
      // Note that there is potential for a race condition if another program or
      // x264 instance disables or reinits the counters while x264 is using them,
      // which may result in incorrect detection and the counters stuck enabled.
      // right now Apple does not seem to support performance counters for this test
  #ifndef __MACH__
      flags |= x264_cpu_fast_neon_mrc_test() ? X264_CPU_FAST_NEON_MRC : 0;
  #endif
      // TODO: write dual issue test? currently it's A8 (dual issue) vs. A9 (fast      mrc)
  #endif
      return flags;
  }
  
  #else
  
  uint32_t x264_cpu_detect( void )
  {
      return 0;
  }
  

  So the question is really this: what would be the quickest/easiest//fastest way to replace the signal() calls with sigaction() ones while preserving the current functionality?

  EDIT: The reason i'm trying to get rid of signal() are these build errors:

  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function sigill_handler: error: undefined reference to 'bsd_signal'
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
  

  I already know that this is a known NDK12 problem, that might be solved by bringing bsd_signal back to the libc in NDK13. However, in it' beta state with it's unstable libc - it's currently missing the rand() function and simply waiting for it might not do the trick. But in the worst-case scenario, i guess i'll just have to wait for it and retry after it's release.

  But as it currently is, the prebuilt version of the library i want to use has text-relocations and is being rejected by phones running newer API / version of the android OS.

  EDIT2: I also know that signal() usually works by using sigaction() under the hood, but maybe i won't get bsd_signal related build-errors... since i'm suspecting that this one isn't using it. It's obviously using bsd_signal, which may or may not be the same underlying thing :/

• OpenCV VideoWriter using ffmpeg with "Could not open codec 'libx264'" Error

  28 septembre 2016, par user2262504

  I am new to OpenCV, and I want write Mat images into video using VideoWriter on Ubuntu 12.04. But when constructing VideoWriter, errors came out.

  It seems that OpenCV invoke ffmpeg API using default parameters and ffmpeg invoke x264 using its default parameters. Then these setting is broken for libx264. Thus the "Could not open codec 'libx264'" error.

  Anyone has ideas to solve this problem?

  More specifically:

  1. anyone knows where and how OpenCV invoke ffmpeg API?
  2. how to change ffmpeg default settings using code, hopefull, can be easily embeded into OpenCV?
  3. will changes of default in ffmpeg be carried to libx264?

  Errors:

  1. Uising CV_FOURCC('H', '2', '6', '4')
  [libx264 @ 0x255de40] broken ffmpeg default settings detected
  [libx264 @ 0x255de40] use an encoding preset (e.g. -vpre medium)
  [libx264 @ 0x255de40] preset usage: -vpre  -vpre 
  [libx264 @ 0x255de40] speed presets are listed in x264 --help
  [libx264 @ 0x255de40] profile is optional; x264 defaults to high
  Could not open codec 'libx264': Unspecified error
  
  2. Using FOURCC = -1 to invoke user customized codec
  OpenCV Error: Unsupported format or combination of formats (Gstreamer Opencv 
  backend doesn't support this codec acutally.) in CvVideoWriter_GStreamer::open, 
  file /home/XXX/Downloads/opencv-2.4.8/modules/highgui/src/cap_gstreamer.cpp, 
  line 505 terminate called after throwing an instance of 'cv::Exception'
  what():  /home/XXX/Downloads/opencv-2.4.8/modules/highgui/src/cap_gstreamer.cpp:
  505: error: (-210) Gstreamer Opencv backend doesn't support this codec acutally.
  in function CvVideoWriter_GStreamer::open
  

  Codes:

  int main(int argc, char *argv[])
  {
      VideoWriter outputVideo;
      bool fourcc_on = true; //switch on / off different error
      if (fourcc_on)
          outputVideo.open("outVideo.avi", CV_FOURCC('H', '2', '6', '4'), 25, Size(100, 100), true);
      else
          outputVideo.open("outVideo.avi", -1, 25, Size(100, 100), true);
  
      if (!outputVideo.isOpened())
      {
          cout  << "Could not open the output video for write" << endl;
          return -1;
      }
      return 0;
  }
  

  OpenCV Configuration:

  -- Detected version of GNU GCC: 46 (406)
  -- Found OpenEXR: /usr/lib/libIlmImf.so
  -- Looking for linux/videodev.h
  -- Looking for linux/videodev.h - not found
  -- Looking for linux/videodev2.h
  -- Looking for linux/videodev2.h - found
  -- Looking for sys/videoio.h
  -- Looking for sys/videoio.h - not found
  -- Looking for libavformat/avformat.h
  -- Looking for libavformat/avformat.h - found
  -- Looking for ffmpeg/avformat.h
  -- Looking for ffmpeg/avformat.h - not found
  -- Could NOT find JNI (missing:  JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH) 
  -- 
  -- General configuration for OpenCV 2.4.8 =====================================
  --   Version control:               unknown
  -- 
  --   Platform:
  --     Host:                        Linux 3.8.0-38-generic x86_64
  --     CMake:                       2.8.7
  --     CMake generator:             Unix Makefiles
  --     CMake build tool:            /usr/bin/make
  --     Configuration:               RELEASE
  -- 
  --   C/C++:
  --     Built as dynamic libs?:      YES
  --     C++ Compiler:                /usr/bin/c++  (ver 4.6)
  --     C++ flags (Release):         -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -msse -msse2 -msse3 -ffunction-sections -O3 -DNDEBUG  -DNDEBUG
  --     C++ flags (Debug):           -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -msse -msse2 -msse3 -ffunction-sections -g  -O0 -DDEBUG -D_DEBUG
  --     C Compiler:                  /usr/bin/gcc
  --     C flags (Release):           -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -msse -msse2 -msse3 -ffunction-sections -O3 -DNDEBUG  -DNDEBUG
  --     C flags (Debug):             -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -msse -msse2 -msse3 -ffunction-sections -g  -O0 -DDEBUG -D_DEBUG
  --     Linker flags (Release):      
  --     Linker flags (Debug):        
  --     Precompiled headers:         YES
  -- 
  --   OpenCV modules:
  --     To be built:                 core flann imgproc highgui features2d calib3d ml video legacy objdetect photo gpu ocl nonfree contrib python stitching superres ts videostab
  --     Disabled:                    world
  --     Disabled by dependency:      -
  --     Unavailable:                 androidcamera dynamicuda java
  -- 
  --   GUI: 
  --     QT:                          NO
  --     GTK+ 2.x:                    YES (ver 2.24.10)
  --     GThread :                    YES (ver 2.32.4)
  --     GtkGlExt:                    NO
  --     OpenGL support:              NO
  -- 
  --   Media I/O: 
  --     ZLib:                        /usr/lib/x86_64-linux-gnu/libz.so (ver 1.2.3.4)
  --     JPEG:                        /usr/lib/x86_64-linux-gnu/libjpeg.so (ver )
  --     PNG:                         /usr/lib/x86_64-linux-gnu/libpng.so (ver 1.2.46)
  --     TIFF:                        /usr/lib/x86_64-linux-gnu/libtiff.so (ver 42 - 3.9.5)
  --     JPEG 2000:                   /usr/lib/x86_64-linux-gnu/libjasper.so (ver 1.900.1)
  --     OpenEXR:                     /usr/lib/libImath.so /usr/lib/libIlmImf.so /usr/lib/libIex.so /usr/lib/libHalf.so /usr/lib/libIlmThread.so (ver 1.6.1)
  -- 
  --   Video I/O:
  --     DC1394 1.x:                  NO
  --     DC1394 2.x:                  YES (ver 2.2.0)
  --     FFMPEG:                      YES
  --       codec:                     YES (ver 55.58.105)
  --       format:                    YES (ver 55.37.101)
  --       util:                      YES (ver 52.78.100)
  --       swscale:                   YES (ver 2.6.100)
  --       gentoo-style:              YES
  --     GStreamer:                   
  --       base:                      YES (ver 0.10.36)
  --       app:                       YES (ver 0.10.36)
  --       video:                     YES (ver 0.10.36)
  --     OpenNI:                      NO
  --     OpenNI PrimeSensor Modules:  NO
  --     PvAPI:                       NO
  --     GigEVisionSDK:               NO
  --     UniCap:                      NO
  --     UniCap ucil:                 NO
  --     V4L/V4L2:                    Using libv4l (ver 1.0.1)
  --     XIMEA:                       NO
  --     Xine:                        NO
  -- 
  --   Other third-party libraries:
  --     Use IPP:                     NO
  --     Use Eigen:                   NO
  --     Use TBB:                     NO
  --     Use OpenMP:                  NO
  --     Use GCD                      NO
  --     Use Concurrency              NO
  --     Use C=:                      NO
  --     Use Cuda:                    NO
  --     Use OpenCL:                  YES
  -- 
  --   OpenCL:
  --     Version:                     dynamic
  --     Include path:                /home/shixudongleo/Downloads/opencv-2.4.8/3rdparty/include/opencl/1.2
  --     Use AMD FFT:                 NO
  --     Use AMD BLAS:                NO
  -- 
  --   Python:
  --     Interpreter:                 /usr/bin/python (ver 2.7.3)
  --     Libraries:                   /usr/lib/libpython2.7.so
  --     numpy:                       /usr/lib/python2.7/dist-packages/numpy/core/include (ver 1.6.1)
  --     packages path:               lib/python2.7/dist-packages
  -- 
  --   Java:
  --     ant:                         NO
  --     JNI:                         NO
  --     Java tests:                  NO
  -- 
  --   Documentation:
  --     Build Documentation:         NO
  --     Sphinx:                      NO
  --     PdfLaTeX compiler:           /usr/bin/pdflatex
  -- 
  --   Tests and samples:
  --     Tests:                       YES
  --     Performance tests:           YES
  --     C/C++ Examples:              NO
  -- 
  --   Install path:                  /usr/local
  -- 
  --   cvconfig.h is in:              /home/shixudongleo/Downloads/opencv-2.4.8/build
  -- -----------------------------------------------------------------
  -- 
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /home/XXX/Downloads/opencv-2.4.8/build
  

  FFMPEG

  ffmpeg is enable to support OpenCV and libx264 is enabled when compiling ffmpeg. By using ffmpeg command line, libx264 is running normally.

  $ ffmpeg -i test.avi -vcodec libx264 test.mp4
  ffmpeg -i test.avi -vcodec libx264 test.mp4 > ~/Downloads/ffmpeg_log.txt
  ffmpeg version 2.2.git Copyright (c) 2000-2014 the FFmpeg developers
    built on Apr 24 2014 16:39:51 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
    configuration: --enable-gpl --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-nonfree --enable-postproc --enable-version3 --enable-x11grab --enable-shared --enable-pic
    libavutil      52. 78.100 / 52. 78.100
    libavcodec     55. 58.105 / 55. 58.105
    libavformat    55. 37.101 / 55. 37.101
    libavdevice    55. 13.100 / 55. 13.100
    libavfilter     4.  4.100 /  4.  4.100
    libswscale      2.  6.100 /  2.  6.100
    libswresample   0. 18.100 /  0. 18.100
    libpostproc    52.  3.100 / 52.  3.100
  Input #0, avi, from 'test.avi':
    Duration: 00:00:03.73, start: 0.000000, bitrate: 1757 kb/s
      Stream #0:0: Video: msvideo1 (CRAM / 0x4D415243), rgb555le, 320x240, 1781 kb/s, 15 tbr, 15 tbn, 15 tbc
      Metadata:
        title           : julius.avi Video #1
  File 'test.mp4' already exists. Overwrite ? [y/N] y
  No pixel format specified, yuv444p for H.264 encoding chosen.
  Use -pix_fmt yuv420p for compatibility with outdated media players.
  [libx264 @ 0x25d08e0] using cpu capabilities: none!
  [libx264 @ 0x25d08e0] profile High 4:4:4 Predictive, level 1.2, 4:4:4 8-bit
  [libx264 @ 0x25d08e0] 264 - core 142 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=12 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=15 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
  Output #0, mp4, to 'test.mp4':
    Metadata:
      encoder         : Lavf55.37.101
      Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv444p, 320x240, q=-1--1, 15360 tbn, 15 tbc
      Metadata:
        title           : julius.avi Video #1
  Stream mapping:
    Stream #0:0 -> #0:0 (msvideo1 -> libx264)
  Press [q] to stop, [?] for help
  frame=   56 fps=0.0 q=-1.0 Lsize=     321kB time=00:00:03.60 bitrate= 731.0kbits/s    
  video:320kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.409949%
  [libx264 @ 0x25d08e0] frame I:3     Avg QP:15.36  size:  7975
  [libx264 @ 0x25d08e0] frame P:38    Avg QP:26.05  size:  6230
  [libx264 @ 0x25d08e0] frame B:15    Avg QP:28.25  size:  4418
  [libx264 @ 0x25d08e0] consecutive B-frames: 46.4% 53.6%  0.0%  0.0%
  [libx264 @ 0x25d08e0] mb I  I16..4:  1.4% 72.8% 25.8%
  [libx264 @ 0x25d08e0] mb P  I16..4:  1.6%  5.7% 15.1%  P16..4:  7.6%  6.3%  7.4%  0.0%  0.0%    skip:56.3%
  [libx264 @ 0x25d08e0] mb B  I16..4:  0.2%  1.0%  2.0%  B16..8: 13.3%  7.8%  8.7%  direct: 8.3%  skip:58.8%  L0:34.9% L1:36.6% BI:28.5%
  [libx264 @ 0x25d08e0] 8x8 transform intra:37.7% inter:2.3%
  [libx264 @ 0x25d08e0] coded y,u,v intra: 52.1% 42.1% 30.1% inter: 19.6% 9.2% 5.2%
  [libx264 @ 0x25d08e0] i16 v,h,dc,p: 56% 17% 24%  2%
  [libx264 @ 0x25d08e0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 16% 68%  1%  1%  1%  1%  1%  1%
  [libx264 @ 0x25d08e0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 18% 28%  5%  6%  5%  7%  5%  6%
  [libx264 @ 0x25d08e0] Weighted P-Frames: Y:31.6% UV:21.1%
  [libx264 @ 0x25d08e0] ref P L0: 70.5%  9.0% 12.1%  6.5%  2.0%
  [libx264 @ 0x25d08e0] ref B L0: 91.3%  8.7%
  [libx264 @ 0x25d08e0] kb/s:700.56
  

• Add VUI parameters to h.264 post encode

  20 septembre 2016, par Dustin Kerstein

  Apparently ffmpeg/libx264 doesn't add these VUI parameters and this is causing issues with my decoder. Avidemux 2.5 does (2.6 does not) but I would very much like to avoid preparing/re-encoding the hundreds of files.

  The VUI parameters I am looking to add are:

  • max_num_reorder_frames=0
  • bitstream_restriction_flag=1

  Is anyone aware of any tools that could accomplish this without re-encoding? If this is something that would need to be custom written, where would be a good place to find the right person?

  Thanks, Dustin

• Add VUI parameters to h.264 post encode

  20 septembre 2016, par Dustin Kerstein

  Apparently ffmpeg/libx264 doesn't add these VUI parameters and this is causing issues with my decoder. Avidemux 2.5 does (2.6 does not) but I would very much like to avoid preparing/re-encoding the hundreds of files.

  The VUI parameters I am looking to add are:

  • max_num_reorder_frames=0
  • bitstream_restriction_flag=1

  Is anyone aware of any tools that could accomplish this without re-encoding? If this is something that would need to be custom written, where would be a good place to find the right person?

  Thanks, Dustin