[Ffmpeg-devel] [BUG] -vframes with x264 encoding and b frames

[Michael Niedermayer]

Hi

On Tue, Oct 31, 2006 at 12:43:49PM +0100, Baptiste Coudurier wrote:
> Hi
> 
> I just spotted a bug when using -vframes with h264 encoding (x264):
> 
> ffmpeg -vframes 100 -i file.mpg -vcodec h264 -bf 2 test.h264
> 
> 
> FFmpeg version SVN-r6848, Copyright (c) 2000-2006 Fabrice Bellard, et al.
>   configuration:  --enable-gpl --enable-faac --enable-dts --enable-a52
> --enable-x264 --enable-faad --enable-static --enable-mp3lame
> --enable-pthreads --enable-xvid --enable-pp --enable-amr_nb --enable-amr_wb
>   libavutil version: 49.0.2
>   libavcodec version: 51.23.0
>   libavformat version: 50.6.0
>   built on Oct 31 2006 11:56:20, gcc: 4.1.2 20061028 (prerelease)
> (Debian 4.1.1-19)
> 
> Seems that stream 0 comes from film source: 25.00 (25025/1001) -> 25.00
> (25/1)
> Input #0, mpeg, from 'file.mpg':
>   Duration: 00:00:24.1, start: 0.220000, bitrate: 11959 kb/s
>   Stream #0.0[0x1e0]: Video: mpeg2video, yuv422p, 720x608, 11386 kb/s,
> 25.00 fps(r)
>   Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, 384 kb/s
> File 'test.h264' already exists. Overwrite ? [y/N] y
> Output #0, h264, to 'test.h264':
>   Stream #0.0: Video: h264, yuv420p, 720x608, q=2-31, 200 kb/s, 25.00 fps(c)
> Stream mapping:
>   Stream #0.0 -> #0.0
> [h264 @ 0x85dd338]using SAR=1/1
> [h264 @ 0x85dd338]using cpu capabilities MMX MMXEXT SSE SSE2
> Press [q] to stop encoding
> frame=  100 q=31.0 Lsize=     292kB time=3.9 bitrate= 616.3kbits/s
> video:292kB audio:0kB global headers:0kB muxing overhead 0.000000%
> [h264 @ 0x85dd338]slice I:9     Avg QP:31.00  size:  7526
> [h264 @ 0x85dd338]slice P:33    Avg QP:31.00  size:  4165
> [h264 @ 0x85dd338]slice B:56    Avg QP:33.00  size:  1659
> [h264 @ 0x85dd338]mb I  I16..4: 80.7%  0.0% 19.3%
> [h264 @ 0x85dd338]mb P  I16..4: 22.1%  0.0%  0.0%  P16..4: 14.4%  0.0%
> 0.0%  0.0%  0.0%    skip:63.5%
> [h264 @ 0x85dd338]mb B  I16..4:  5.5%  0.0%  0.0%  B16..8: 15.4%  0.0%
> 0.0%  direct: 0.9%  skip:78.2%
> [h264 @ 0x85dd338]final ratefactor: 38.75
> [h264 @ 0x85dd338]SSIM Mean Y:0.9726804
> [h264 @ 0x85dd338]kb/s:608.3
> 
> x264 clearly says total frames number is 98.
> Increasing number to 101 gives 99, 102 gives 100, 103 gives 101.
> 
> Now when not using bf 2:
> ffmpeg -vframes 100 -i file.mpg -vcodec h264 test.h264
> 
> [h264 @ 0x85dd338]using SAR=1/1
> [h264 @ 0x85dd338]using cpu capabilities MMX MMXEXT SSE SSE2
> Press [q] to stop encoding
> frame=  100 q=31.0 Lsize=     321kB time=4.0 bitrate= 657.9kbits/s
> video:321kB audio:0kB global headers:0kB muxing overhead 0.000000%
> [h264 @ 0x85dd338]slice I:9     Avg QP:29.33  size:  8460
> [h264 @ 0x85dd338]slice P:91    Avg QP:31.00  size:  2770
> [h264 @ 0x85dd338]mb I  I16..4: 78.9%  0.0% 21.1%
> [h264 @ 0x85dd338]mb P  I16..4: 12.8%  0.0%  0.0%  P16..4: 16.0%  0.0%
> 0.0%  0.0%  0.0%    skip:71.2%
> [h264 @ 0x85dd338]final ratefactor: 38.67
> [h264 @ 0x85dd338]SSIM Mean Y:0.9752094
> [h264 @ 0x85dd338]kb/s:656.4
> 
> Final count is correctly 100 frames.
> 
> The bug does not appear when using lavc mpeg4 encoder with b frames.

i think the cause is that libavcodec/x264.c does not implement
CODEC_CAP_DELAY

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is