[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 pdr0):

 Replying to [comment:32 markfilipak]:

 >
 > You have a parser for MPEG2TS? Actual physical bits would help me to see
 what you're writing about. I write that because it seems to me you (or
 MPEG) are mixing stream frames, which have only timestamps and not frame
 numbers, with something that goes by frame numbers. I suspect they're
 actually frame offsets, not frame numbers. I suspect they're used for
 transforming slices between reference slices in other frames as opposed to
 transforming while frames. I suspect this has something to do with POC,
 which I find to be 'prescribed' rather than 'described', and so, seems
 rather vague and subject to interpretation.
 >
 Stream parser like Stream Eye has been mentioned several times. It was
 first thing I mentioned in 11055 .


 This link is from Iain E. Richardson's , “The H.264 Advanced Video
 Compression Standard” . It's a good book, and the author is a known expert

 PLEASE READ! This explains frame_num and POC in simple terms
 https://www.vcodex.com/h264avc-picture-management


 In the simplest terms - Frame_num refers to decoding order . POC refers to
 the display order . Both frame_num and POC are found in the slice headers
 and refer to the actual h264 video stream, not something container
 specific like m2ts , ts, mp4, mkv etc... Frame_num has to increase by 1
 every frame until the next IDR, POC does not . But if you get either
 frame_num or POC decreases, the stream does not conform to specifications
 .

 The most common cause of decreases in frame_num or POC types of non
 conforming streams are.... you guessed it... bad cuts and appends. e.g. An
 "I" frame is mistaken for IDR

 Both frame_num and POC reset to zero at each IDR. Since you have no IDR's
 you have wild frame_num (243) compared to the encoded frame count (97),
 because you are missing frames up to the previous IDR from the original
 stream. ie. your 1st "i" frame is frame 243 compared to it's own IDR
 (frame zero) in the original stream.  The decrease in POC and frame_num
 are from the appended section, which was closer in proximity to it's own
 IDR (fewer missing frames, thus a lower value) .  Thus, you must cut on
 IDR boundaries as explained earlier , or re-encode the affected section
 before joining if you needed frame accurate cuts. The re-encoded section
 places a new IDR, the frame_num and POC are reset to zero, and that
 section is a valid video sequence. (It's a bit more complicated than that,
 you generally have to encode using similar settings for a proper join, and
 if it was for authored BD, there are potential VBV issues)


 > 2 - I have a proposal: Since this is going beyond a bug report and the
 time you are putting in is growing, how about I pay you? Money for
 instruction. That would only be fair to you and I'm willing to do it. If
 such instruction does reveal an actual bug, wonderful. If it doesn't
 that's fine too.

 You want a teacher who intimately knows the specs. Sorry, that's not me.


 Bottom line -  Ticket_11055.m2ts, Ticket_11080.m2ts are invalid streams
 for the reasons previously posted. If you post a valid spec video
 sequence, and there are ffmpeg timestamp issues, then it should be
 investigated.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11080#comment:36>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker