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

 Ticket_11080.m2ts is the same problem as ticket #11055 - not a valid
 stream

 Not cut/appended on IDR boundaries, no IDR pictures , decreasing frame_num
 and decreasing POC violations in coded stream order

 eg.
 Notice frame_num drops from 243 to 191

 There is a free online viewer; you can demux to elementary stream and
 upload
 VTCLab Media Analyzer
 https://media-analyzer.pro/app
 hex
 00002f7139 frame_num    243 (0xF3)
 00003938a0 frame_num    191 (0xBF)


 If you examine a retail open GOP BD, the frame_num increases with each
 coded picture including non-IDR "i" frames, until the next IDR where it
 resets to zero as per the h264 specs .

 "The value of frame_num is constrained as follows:
 – If the current picture is an IDR picture, frame_num shall be equal to
 0."

 When you stream copy & append segment the slice header frame_num , POC
 entries are retained from original stream. In Ticket_11080.m2ts, the
 latter appended section is closer in coded order to it's own IDR picture,
 so has a lower frame_num. When you join, there is now a decrease in
 frame_num  - this is a spec violation

 Either that section from <IDR> to the <frame before next IDR> from your
 original source stream has to be re-encoded before appending stream copied
 segments -  so the values frame_num and POC values reset and follow specs
 (then you can also get frame accurate cuts) - this is what "smart
 rendering" software does -  or you live with IDR boundaries and "coarse"
 edits (some open GOP BD's can have hundreds of frames before the next IDR)
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11080#comment:14>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker