[FFmpeg-trac] #11080(undetermined:new): FFmpeg timestamps do not consistently agree with packet timestamps

[FFmpeg]

#11080: FFmpeg timestamps do not consistently agree with packet timestamps
-------------------------------------+-------------------------------------
             Reporter:  markfilipak  |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by Balling):

 Damn, VQ analyzer is a monster. IT CAN FULLY EXPORT ANY FRAME IN ITS
 ENTERITY! I frame e.g. is 15 MB (!!!) when you convert its binary
 bitstream into actual names of parameters. This is no NATO tank, this is
 actual complexity.

 Here are all the warnings on your 11055 file (had to convert that to Annex
 B .h264 file, cause there is a bug apparently, lol, in VQ analyzer version
 7.4.0.80497 that it cannon open m2ts files).

 https://i.imgur.com/ZhtJsc8.png
  (in particular it warns that first nal is actually just non-IDR I frame,
 while it must be IDR I frame, and it also sees that frame_num has a gap in
 176th NAL (non-IDR I frame too) and has a gap in 182 NAL, so I believe
 maybe you copied the second Open GOP incorrectly).

 Also, I can see in hierarchy tab that it has some insane stuff. Basically
 on this image 2 red dots are the I frames (**still non-IDR**, remember),
 blue dots in one line are the P frames, remember the I frames and then P
 frames can be decoded independently without yet decoding B frames, so it
 is very nice property. https://i.imgur.com/jwFuQTE.png BUT THEN you can
 some horrible B frames dependency. You have First level B frames and then
 2nd level. And 1st level B frames are kinda normal, but then you have B
 frame 15/50 depending on 14/13. So 50th actual frame depends on 13th in
 presentation order. And, yes, they are 15th and 14th in DTS, but still.


 Also here are the warnings for your 11088: https://i.imgur.com/pGbfjYE.png
 (this shows you introduce another frame_num error on the analyzer (cause
 there is now no frame_num 228 as opposed to 11055), I believe that is
 another key issue here, clearly you cannot just cut frames with ffmpeg,
 because this is a warning about gap INSIDE the link between I and P in the
 initial I, b, B, P, where b is first level hierarchy and B is second level
 hierarchy in presentation order)

 and here is the hierarchy: https://i.imgur.com/LQGR7Jh.png

 I think I proved to you that the leading two B frames must be left in the
 file, why? Because recovery point behind the I frame says that you can
 decode all frames after recovery point, but you remove the 228 B frame
 which is as I understand must be decoded, and to decode that you need to
 decode another B frame.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11080#comment:49>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker