[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:156 MasterQuestionable]:
 > ͏    Read context. (± 15 surrounding posts expected)
 > ͏    [ Through search preferable; but mostly shouldn't be necessary. ]

 I have no idea what you are referring to.

 > ͏    Reincluding what's just a few lines away creates excessive
 verbosity:
 > ͏    Which may in turn downgrade readability.

 Please use the "Reply" link when replying. I use "(o) Threaded" mode in
 these strings of replies and when you don't use "Reply" then I, and the
 threading mechanism, don't know what to do and  can't find what you are
 replying to.

 > ͏    And all which of "Ticket_11055.m2ts"..?

 I have no idea what you are 'saying'.

 > ͏    What is unclear in comment:72?
 > ͏    I believe everything's been already mentioned.

 In your comment 72, you multiplied the DTSes and PTSes by 3753.75 ticks-
 per-second. Why did you do that?

 > ͏    The interpreted B-frames' DTS seems seriously wrong.
 > ͏    (non-sense per B-frame's nature)

 All the DTSes and PTSes in the left hand column of the table in "Summary
 of the bug" are directly from the PES packets.

 >
 > ͏    I wonder if the issue would influence "00305.m2ts", "00306.m2ts".
 > ͏    (so avoiding the possibility of "Ticket_11055.m2ts" improperly
 produced)

 What would you like me to do? Do you want me to print all the PTSes and
 DTSes in 00305.m2ts and 00306.m2ts? I will do whatever you want. I think
 this bug is critical, and this case provides a perfect way to fix it
 simply by tracing the code that works from framecrc into and through the
 library functions versus the code that doesn't work from showinfo and
 show_frames into and through the library functions.

 Look at my table -- the table in the "Summary of the bug". Look at the
 columns for __packet analyzer__ and _____framecrc______. Do you not
 believe those DTSes and PTSes?

 I understand that 'showinfo' presents timestamps _after_ decoding. Why are
 those timestamps different?

 I'm not sure that 'show_frames' presents timestamps _after_ decoding or
 not.

 So much of FFmpeg is mysterious because it's not documented. Why/how are
 'showinfo' and 'show-frames' getting bad DTSes and PTSes?

 I will do anything to help. What can I do?
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11055#comment:158>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker