Opened 8 years ago

Closed 8 years ago

#5138 closed defect (wontfix)

[H264 Decoder] Missing B frame in the H264 decoded stream.

Reported by: jbbetton Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: h264
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

Summary of the bug:
I use the demuxing_decoding example to decode an H264 stream that contains different sizes of sub-GOP (dynamic B-Frames). The first five sub-GOPs have 3 B-Frames. The sixth sub-GOP has 7 B-Frames and is not decoded correctly.

How to reproduce:

./demuxing_decoding CNBC_3B_7B_in.264 CNBC_3B_7B_out.yuv CNBC_3B_7B_out.pcm
ffmpeg version : git-master
built on CentOS 6.6

Result :

Coded frame 24 is missing. It should be between coded frames 17 and 23.

http://i.imgsafe.org/a7d9007.jpg

Attachments (1)

CNBC_3B_7B_in.264 (1.5 MB ) - added by jbbetton 8 years ago.

Download all attachments as: .zip

Change History (8)

by jbbetton, 8 years ago

Attachment: CNBC_3B_7B_in.264 added

comment:1 by Carl Eugen Hoyos, 8 years ago

Keywords: h264 added; H264 Decoder B-Frames removed
Reproduced by developer: set
Status: newopen

For future tickets: Please do not report a ticket with ffplay, ffprobe or demuxing_decoding if it is reproducible with ffmpeg.

Currently needs -strict 1, related to 10e55bd658b06034d700553190b419b1af92b7cb / b09ad37c83841c399abb7f2503a2ab214d0c2d48

$ ffmpeg -vsync 0 -strict 0 -i CNBC_3B_7B_in.264 -f null -
ffmpeg version N-77727-gf4c1a48 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      55. 12.100 / 55. 12.100
  libavcodec     57. 22.100 / 57. 22.100
  libavformat    57. 21.101 / 57. 21.101
  libavdevice    57.  0.100 / 57.  0.100
  libavfilter     6. 23.100 /  6. 23.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
Input #0, h264, from 'CNBC_3B_7B_in.264':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p, 1920x1088 [SAR 1:1 DAR 30:17], 30 fps, 30 tbr, 1200k tbn, 60 tbc
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf57.21.101
    Stream #0:0: Video: wrapped_avframe, yuv420p, 1920x1088 [SAR 1:1 DAR 30:17], q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc
    Metadata:
      encoder         : Lavc57.22.100 wrapped_avframe
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
frame=   60 fps=0.0 q=-0.0 Lsize=N/A time=00:00:02.06 bitrate=N/A speed=13.4x
video:28kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
$ ffmpeg -vsync 0 -strict 1 -i CNBC_3B_7B_in.264 -f null -
ffmpeg version N-77727-gf4c1a48 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      55. 12.100 / 55. 12.100
  libavcodec     57. 22.100 / 57. 22.100
  libavformat    57. 21.101 / 57. 21.101
  libavdevice    57.  0.100 / 57.  0.100
  libavfilter     6. 23.100 /  6. 23.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
Input #0, h264, from 'CNBC_3B_7B_in.264':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p, 1920x1088 [SAR 1:1 DAR 30:17], 30 fps, 30 tbr, 1200k tbn, 60 tbc
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf57.21.101
    Stream #0:0: Video: wrapped_avframe, yuv420p, 1920x1088 [SAR 1:1 DAR 30:17], q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc
    Metadata:
      encoder         : Lavc57.22.100 wrapped_avframe
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
frame=   61 fps=0.0 q=-0.0 Lsize=N/A time=00:00:02.03 bitrate=N/A speed=12.9x
video:29kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

61 output frames are bitexact compared with the reference decoder.

comment:2 by jbbetton, 8 years ago

Resolution: fixed
Status: openclosed

Thanks for the answer and the changesets.

comment:3 by Carl Eugen Hoyos, 8 years ago

Resolution: fixed
Status: closedreopened

I don't know if this ticket is valid or not or if it will be fixed or not, but it definitely isn't fixed.

comment:4 by Carl Eugen Hoyos, 8 years ago

How was your sample recorded? Is this the original broadcast stream or did you reencode it?

comment:5 by jbbetton, 8 years ago

It's not the original stream. I reencoded it to have dynamic B-Frames.

Last edited 8 years ago by jbbetton (previous) (diff)

comment:6 by Carl Eugen Hoyos, 8 years ago

Which encoder supports dynamic B-frames?

comment:7 by Carl Eugen Hoyos, 8 years ago

Priority: importantnormal
Resolution: wontfix
Status: reopenedclosed

A message is shown since 69dbecf920f6fe7e5a7fc0b38ecaeeb444bc1d7a that tells the user about the increasing reorder buffer by default.
I believe the default behaviour will not change as long as no encoder supports dynamic B-frames.

Note: See TracTickets for help on using tickets.