[FFmpeg-trac] #11055(avcodec:reopened): OGOP (Open GOP) in certain conditions may cause missing frames of decoding

[FFmpeg]

#11055: OGOP (Open GOP) in certain conditions may cause missing frames of decoding
-------------------------------------+-------------------------------------
             Reporter:  markfilipak  |                    Owner:  (none)
                 Type:  defect       |                   Status:  reopened
             Priority:  normal       |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  everything   |               Blocked By:
  OGOP                               |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by markfilipak):

 Replying to [comment:212 Balling]:
 > Yes, please open a new bug. After that I will close this one, the new
 file must contain your fixes for initial IDR frame and fixes for the two B
 frames stuff.

 Yes. In addition to the splice itself, the new 4 second video begins and
 ends on IDRs.

 \\
 > **Remember, Open GOP does not start with I frame, it starts with two B
 frames and all GOPs, whether closed or open, cannot end with B frame.**

 Do you have a reference for that? I've never seen a group_start_code that
 wasn't followed by an I-frame in the same PES packet, but I will look...

 ...I just checked several, from several sources, both NTSC and PAL. All
 GOP headers preceded I-frames, and in the same PES. I believe a GOP must
 begin with an I-frame...

 ...I just checked H.262. It says "After a GOP, the first picture shall be
 an I-picture". I believe it means "After a GOP **''header''**".

 {{{
 A Closed GOP       time ———>
       <-------closed GOP-------->  <---next GOP--->
 PTS order      ..B  B  P  B  B  P  I
                 ______/  ______/
                /        /
 DTS order   ..P  B  B  P  B  B
 }}}

 {{{
 An Open GOP        time ———>
       <-------open GOP------->  <---next GOP--->
 PTS order      ..B  B  P  B  B  I..
                 ______/
                /
 DTS order   ..P  B  B     B  B
                          open Bs
 }}}

 I know I've read in some authoritative document that an open GOP ends on a
 B-frame, but I can't find it right now.

 \\
 > https://www.andrew.cmu.edu/user/lshea/2.Tech_PDFs/Mpeg_and-
 h264_compression.pdf check this out, it has nice images of open gop
 starting with two B frames.

 I looked at that diagram. I'm pretty sure it was wrong, even in 2010. At
 least it shows B-frames referencing I-frames and reconstructed P-frames.
 That's more than I can say for your next reference.

 > ALSO, LOOK I found the nice image for this:
 https://avidemux.org/smif/index.php/topic,18247.msg83528.html#msg83528

 B-frames referencing reconstructed B-frames? That's the so-called
 "pyramid". O_k_a_y... But B-frames referencing B-frames on the other side
 of an I-frame? (whistling) I don't think so. What physical MPEG tag
 supports that claim?

 > IT SHOWS how the B frame depends on frame before I frame which is what
 makes it non-IDR.

 "makes it"? ... "it"? ... the B-frame? Are there such things as IDR
 B-frames and non-IDR B-frames? I don't think so.

 To my knowledge, what makes a GOP non-IDR is that it ends on a B-frame
 that has lost its future reference. What's confusing is that it's the
 _next_ GOP that's labeled "non-IDR", not the GOP that ends on a B-frame. I
 think MPEG labeled the _next_ GOP because it isn't known that a GOP _was_
 open until that next GOP, that next I-frame.

 This controversy needs to be resolved.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11055#comment:214>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker