New libx264/h264 library bug needs fix

[durack1]

@chaosphere2112 I've just tried to roadtest the new libx264/h264 defaults in the ffmpeg call and hit the following error:

So the call:

x.ffmpeg(outMP4,xList,rate=5,bitrate=2048)

returns:

** Processing:  /work/durack1/Shared/131118_PaperPlots_SaltyVariability/pngs/quarters.mp4                                            
ffmpeg version 2.7 Copyright (c) 2000-2015 the FFmpeg developers                                                                     
  built with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-16)                                                                             
  configuration: --prefix=/usr/local/uvcdat/2.4.0rc1/Externals --disable-yasm --enable-gpl --enable-libx264 --extra-cxxflags=/export/doutriaux1/build/build/FFMPEG --enable-shared --enable-zlib                                                                          
  libavutil      54. 27.100 / 54. 27.100                                                                                             
  libavcodec     56. 41.100 / 56. 41.100                                                                                             
  libavformat    56. 36.100 / 56. 36.100                                                                                             
  libavdevice    56.  4.100 / 56.  4.100                                                                                             
  libavfilter     5. 16.101 /  5. 16.101                                                                                             
  libswscale      3.  1.101 /  3.  1.101                                                                                             
  libswresample   1.  2.100 /  1.  2.100                                                                                             
  libpostproc    53.  3.100 / 53.  3.100                                                                                             
Input #0, image2, from '/export/durack1/.uvcdat/__uvcdat_309035998_%d.png':                                                          
  Duration: 00:00:20.00, start: 0.000000, bitrate: N/A                                                                               
    Stream #0:0: Video: png, rgb24(pc), 814x629, 5 fps, 5 tbr, 5 tbn, 5 tbc                                                          
[libx264 @ 0x1a1c9a0] height not divisible by 2 (814x629)                                                                            
Output #0, mp4, to '/work/durack1/Shared/131118_PaperPlots_SaltyVariability/pngs/quarters.mp4':                                      
    Stream #0:0: Video: h264, none, q=2-31, 128 kb/s, 5 fps                                                                          
    Metadata:                                                                                                                        
      encoder         : Lavc56.41.100 libx264                                                                                        
Stream mapping:                                                                                                                      
  Stream #0:0 -> #0:0 (png (native) -> h264 (libx264))                                                                               
Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

My call seems to have tripped over a bug? in libx264 described here. I tried implementing the suggested fix, but not sure we have the option of appending an arbitrary argument -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2"

As this is a known issue, it'd be nice if the software magically dealt with such known problems..

[doutriaux1]

@chaosphere2112 I just found a bug in CMake 3.2 and greater that is triggered by your x264 tarsal generated on a mac... Could you please regenerate the tarsal from a Linux machine? Thx.

[doutriaux1]

@aashish24 I reported the issue at:
http://public.kitware.com/Bug/view.php?id=15770

The issue is really that depending on the user CMake we have a different directory where configure resides. In our case I think it will be easy to avoid by simply regenerating the tarball on a Linux system.

[doutriaux1]

@durack1 I think our auto size detect code needs update, will fix for 2.4