[FFmpeg-trac] #11080(documentation: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:  task         |                   Status:  new
             Priority:  normal       |                Component:
                                     |  documentation
              Version:  unspecified  |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by Balling):

 First of all I agree that, indeed, 11055 sample is more correct with first
 4 frames, Open GOP must start with BBI order. (Well, I BB in coding
 order.) FFmpeg must have no problem (so it is a bug), IMHO, with decoding
 this file even if omit those two preceding PTS B frames. Analyzers decode
 11055 and 11088 the same and just fine. Still, the consensus is too
 preserve all frame_num like in 11055. Or use mp4 container edit lists?

 Second of all, stop sending all that stuff to ffmpeg-user mailing listing,
 they do not know what they are talking about except Paul and Michael. This
 file has no mixed splices. This IS A BLU-RAY, the spec per H.264 on Blu-
 ray requires 4 slices on each frame, this was a big thing when it was
 finally added to x264 encoder, which is btw still considered state of the
 art...


 Finally, I think I found the real issue here: see analyser, why is this P
 frame recogized somewhere in the second cut of frames??? BOTH 2 analyzers
 behave like this:

 Let's open a new bug about how it cannot decode BBI if you cut two first B
 frames, maybe because of that frame!! https://i.imgur.com/DcWUnnz.png This
 frame PTS 13 (and logically it should be there) yet it places it somewhere
 in the end.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11080#comment:77>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker