Bug with b-frames?

[microchip]

Hi,

I pulled ffmpeg from git today and started to encode to mpeg2video with 2 b-frames in 2-pass mode. I noticed that the git version behaves differently than the 1.2.1 version of ffmpeg. I looked at the passlog file and noticed that all type:3 entries have in:0 and out:0. In 1.2.1, the type:3 entries have entries > 0. My command line for both git and 1.2.1 version is identical and is as follows:

/usr/local/bin/ffmpeg -i /home/neutrino/file2dvd/Con_Air/tmp30017.avi -f dvd -c:v mpeg2video -vf scale=720:368,pad=720:480:0:56,setdar=16/9 -sws_flags spline -aspect 16:9 -mbd 2 -precmp 2 -cmp 2 -subcmp 2 -trellis 2 -dia_size -1 -last_pred 4 -flags +mv0 -mpv_flags +cbp_rd -bf 2 -dc 11 -preme 2 -mv0_threshold 0 -bidir_refine 2 -g 18 -r 24000/1001 -b:v 4653k -c:a ac3 -b:a 192k -ar 48000 -passlogfile /home/neutrino/file2dvd/Con_Air/Con_Air -pass 1 -y /dev/null

The second pass is identical but with -pass 2 option. I also noticed that when using the git version, during the second pass, the bitrate seems very low compared to the first pass. This is not the case when using the 1.2.1 version of ffmpeg.

Both ffmpeg's are compiled with the following options;

./configure --enable-shared --enable-gpl --enable-version3 --enable-libx264 --enable-libxvid --enable-libmp3lame --enable-avresample

I am attatching 2 log files, one from ffmpeg 1.2.1 and one from the git version.

[Carl Eugen Hoyos]

I am not sure I understand this ticket: Do you just want to report that current git head does not produce the same output as FFmpeg 1.2 for a given command line? Or is there something wrong with the output file made with current git head?
Is the problem you see a different bit-rate? I wonder if there is input that allows to reach 4600k for dvd video, or to say it differently, I suspect everything looks great if you specify 4600k for dvd video. Or do you think that the incorrect frame numbers in the log file indicate a problem?

In any case: Please add the console output of the failing command (the second pass if two-pass encoding is necessary to reproduce the problem) to make this a valid ticket.

Looks like a regression since 80e9e63.

[microchip]

Hi Carl,

Thanks for the response. It produces a valid output but it's of low quality compared to the output of 1.2.1. I contribute this to the 0 entries for b-frames (in: 0 and out: 0) in the log file I attached for the git version. When I say low quality, I mean that I can see blocks all over the place while when using 1.2.1 this is not the case. I no longer have the film I used when I noticed this problem so I tried on a sample here and the problem is the same.

About the bitrate, in 1.2.1 when using 4600k as bitrate, the second pass would go up to 3000k while the git ffmpeg will go just over 1600k. That's a pretty big difference between the two versions

The second pass output for the sample I tried is as follows:

ffmpeg version N-53304-g2187600 Copyright (c) 2000-2013 the FFmpeg developers
  built on May 20 2013 19:53:33 with gcc 4.7 (SUSE Linux)
  configuration: --enable-shared --enable-gpl --enable-version3 --enable-libx264 --enable-libxvid --enable-libmp3lame --enable-avresample --prefix=/home/neutrino/local
  libavutil      52. 33.100 / 52. 33.100
  libavcodec     55. 10.101 / 55. 10.101
  libavformat    55.  7.100 / 55.  7.100
  libavdevice    55.  1.100 / 55.  1.100
  libavfilter     3. 68.101 /  3. 68.101
  libavresample   1.  1.  0 /  1.  1.  0
  libswscale      2.  3.100 /  2.  3.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  3.100 / 52.  3.100
[mpeg @ 0xff89c0] max_analyze_duration 5000000 reached at 5000000 microseconds
Guessed Channel Layout for  Input Stream #0.1 : stereo
Input #0, mpeg, from '/home/neutrino/file2dvd/jlo/tmp22404.mpg':
  Duration: 00:05:12.91, start: 0.280000, bitrate: 8234 kb/s
    Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720x576 [SAR 16:15 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0xa0]: Audio: pcm_s16be, 48000 Hz, stereo, s16, 1536 kb/s
[mpeg2video @ 0xffaa20] [lavc rc] Using all of requested bitrate is not necessary for this video with these parameters.
[dvd @ 0xffa140] VBV buffer size not set, muxing may fail
Output #0, dvd, to '/home/neutrino/file2dvd/jlo/jlo.mpg':
  Metadata:
    encoder         : Lavf55.7.100
    Stream #0:0: Video: mpeg2video, yuv420p, 720x576 [SAR 16:15 DAR 4:3], q=2-31, pass 2, 8000 kb/s, 90k tbn, 25 tbc
    Stream #0:1: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video -> mpeg2video)
  Stream #0:1 -> #0:1 (pcm_s16be -> ac3)
Press [q] to stop, [?] for help
[mpeg2video @ 0xff9340] warning: first frame is no keyframe
    Last message repeated 1 times

How to reproduce: just compile latest git and use -bf 2 for encoding. Then look at the log file and you'll see that all "type: 3" entries have "in: 0" and "out: 0" entries. Then look at the output file and you'll see blocks all over the place. At least this is the case here when comparing to the 1.2.1 version

[microchip]

A bit more information on this... Encoding with latest MEncoder from SVN exhibits the same problem but I guess this is because MEncoder uses libavcodec. If using 1-pass in both MEncoder and ffmpeg git with 2 b-frames then MediaInfo reports that they are used. If doing a 2-pass with both MEncoder and ffmpeg git, MediaInfo reports no b-frames. The log file of MEncoder also has all "type:3" entries set to "in:0" and "out:0", just like it is the case in ffmpeg git

[Carl Eugen Hoyos]

Also reproducible with mpeg4:

$ ffmpeg -i fate_suite/svq3/Vertical400kbit.sorenson3.mov -an -bf 2 -vb 400k -pass 1 out.avi

...

$ ffmpeg -i fate_suite/svq3/Vertical400kbit.sorenson3.mov -an -bf 2 -vb 400k -pass 2 -y out.avi
ffmpeg version N-53363-g1fded9b Copyright (c) 2000-2013 the FFmpeg developers
  built on May 23 2013 11:05:47 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
  configuration: --enable-gpl
  libavutil      52. 33.100 / 52. 33.100
  libavcodec     55. 10.101 / 55. 10.101
  libavformat    55.  7.100 / 55.  7.100
  libavdevice    55.  1.101 / 55.  1.101
  libavfilter     3. 69.100 /  3. 69.100
  libswscale      2.  3.100 /  2.  3.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  3.100 / 52.  3.100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x2e53a80] max_analyze_duration 5000000 reached at 5000998 microseconds
Guessed Channel Layout for  Input Stream #0.1 : mono
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'fate_suite/svq3/Vertical400kbit.sorenson3.mov':
  Metadata:
    creation_time   : 2001-03-20 16:17:18
    title           : Vertical Online SV3 Demo
    title-eng       : Vertical Online SV3 Demo
    artist          : Logan Kelsey
    artist-eng      : Logan Kelsey
    copyright       : © Vertical Online 2001
    copyright-eng   : © Vertical Online 2001
    encoder         : Sorenson Video 3
    encoder-eng     : Sorenson Video 3
  Duration: 00:00:43.58, start: 0.000000, bitrate: 580 kb/s
    Stream #0:0(eng): Video: svq3 (SVQ3 / 0x33515653), yuvj420p, 320x240, 391 kb/s, 30.02 fps, 30 tbr, 600 tbn, 600 tbc
    Metadata:
      creation_time   : 2001-03-20 16:17:18
      handler_name    : Apple Alias Data Handler
    Stream #0:1(eng): Audio: adpcm_ima_qt (ima4 / 0x34616D69), 44100 Hz, mono, s16p, 176 kb/s
    Metadata:
      creation_time   : 2001-03-20 16:17:18
      handler_name    : Apple Alias Data Handler
Output #0, avi, to 'out.avi':
  Metadata:
    encoder-eng     : Sorenson Video 3
    INAM            : Vertical Online SV3 Demo
    title-eng       : Vertical Online SV3 Demo
    IART            : Logan Kelsey
    artist-eng      : Logan Kelsey
    ICOP            : © Vertical Online 2001
    copyright-eng   : © Vertical Online 2001
    ISFT            : Lavf55.7.100
    Stream #0:0(eng): Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 320x240, q=2-31, pass 2, 400 kb/s, 30 tbn, 30 tbc
    Metadata:
      creation_time   : 2001-03-20 16:17:18
      handler_name    : Apple Alias Data Handler
Stream mapping:
  Stream #0:0 -> #0:0 (svq3 -> mpeg4)
Press [q] to stop, [?] for help
frame= 1308 fps=247 q=0.0 Lsize=    2247kB time=00:00:43.56 bitrate= 422.6kbits/s    
video:2211kB audio:0kB subtitle:0 global headers:0kB muxing overhead 1.669231%

The output file contains no b-frames, if -vb 400k is omitted, encoding fails which is also a regression.

[Michael Niedermayer]

Fixed in 5f44f47b7256659b45ae5e3edd558521fbf962e8