ffmbc 0.7.4 : libx264 Input picture width is greater than stride

[in...@opsomai.com]

Hi,

We are converting automatically batches of SD files to H264, but some of the original files do not have a correct aspect ratio and interlaced metadata, i.e. they are analyzed as 5:4, which is the pixel ratio, and progressive, whereas their actual aspect ratio is 4:3 and their interlacing mode is BFF. You can find an example of such a file at the following URL: http://www.opsomai.com/download/5_4.mov. Since we are not supposed to "correct" original files errors, we have been using the following command for years (the real one is slightly more complex):

ffmbc -i 5_4.mov -f mp4 -vcodec libx264 -aspect 4:3 -pix_fmt yuv420p -b 1000k -vf "yadif=0:-1:1,scale=720:576,pad=768:576:24:0:black" -an -y 5_4.mp4

But it does not work anymore with 0.7.4. We get the following error message:

[libx264 @ 0x250c320] Input picture width (768) is greater than stride (736)

The same command works fine with 0.7.1. Of course, we get a non-desinterlaced MP4 file in pillarbox, which is normal, since it corresponds to the original file metadata (5:4 progressive). In order to make it works with 0.7.4, you must suppress the "yadif" filter or force it to consider the original file as a BFF file:

ffmbc -i 5_4.mov -f mp4 -vcodec libx264 -aspect 4:3 -pix_fmt yuv420p -b 1000k -vf "scale=720:576,pad=768:576:24:0:black" -an -y 5_4.mp4

ffmbc -i 5_4.mov -f mp4 -vcodec libx264 -aspect 4:3 -pix_fmt yuv420p -b 1000k -vf "yadif=0:1:0,scale=720:576,pad=768:576:24:0:black" -an -y 5_4.mp4

This is really annoying for us since our clients have numerous incorrect SD files like this one, because of not so professional video digitizing service providers.

Would it be possible to get back to the previous behavior in 0.7.5?

Thanks

David

[in...@opsomai.com]

Hi,

This "Input picture width is greater than stride" error can actually occur with correct files. It seems to be related to the lack of aspect ratio information in the source file. Here is an exemple, which comes from a old digitized film, with a picture dimension of 1484x1080: http://www.opsomai.com/download/StrideTest.zip

ffmbc_0.7.4 -i StrideTest.mp4 -f mp4 -vcodec libx264 -aspect 16:9 -pix_fmt yuv420p -b 6000k -vf "yadif=0:-1:1,pad=1920:1080:218:0:black" …

[libx264 @ 0x2258c00] Input picture width (1920) is greater than stride (1504)

ffmbc -i StrideTest.mp4 -f mp4 -vcodec libx264 -aspect 16:9 -pix_fmt yuv420p -b 6000k -vf "pad=1920:1080:218:0:black,yadif=0:-1:1" …

-> OK !

I am going to try to circumvent this problem by always applying "yadif" after "scale" and 'pad".

David

[in...@opsomai.com]

New update : it does not seem possible to circumvent this problem by applying "yadif" after "scale" and "pad", because the quality of the generated video is not acceptable. See screenshot below for an example (left : "yadif" before, right : "yadif" after).

Still looking for a way to bypass this problem!

David

[in...@opsomai.com]

Finally, we had to go back to 0.7.1, because I could not find a workaround for this memory error. It is unfortunate for us, since we lost the XAVC compatibility, but we get more files without an aspect ratio flag than XAVC files!

If anyone thinks of a workaround, please tell. Hopefully, this limitation will be removed in the final 0.7.5 version or in 0.7.6.

David