[FFmpeg-trac] #11055(undetermined:new): "showinfo", "-show_frames": bad PTS, where "framecrc" had expected; plus inconsistent playback

[FFmpeg]

#11055: "showinfo", "-show_frames": bad PTS, where "framecrc" had expected; plus
inconsistent playback
-------------------------------------+-------------------------------------
             Reporter:  markfilipak  |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  important    |                Component:
                                     |  undetermined
              Version:  git-master   |               Resolution:
             Keywords:  vf_showinfo  |               Blocked By:
  ffprobe -show_frames OGOP          |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by Jim DeLaHunt):

 @MasterQuestionable and @markfilipak, it is great to see you going through
 the evidence and comparing specific facts about the test video.  However,
 you seem to be talking past each other.

 Each of you is working from different evidence
 ([https://trac.ffmpeg.org/attachment/ticket/11055/Ticket_11055.m2ts.xml
 Ticket_11055.m2ts.xml] for @MasterQuestionable and the '-f framecrc'
 listing in the Description above for @markfilipak). Each of you is making
 assertions about the test video without showing exactly what data in
 evidence justifies your assertion. Neither of you seem to be making an
 effort to correlate your evidence with the other person's.

 For instance, @MasterQuestionable says in the
 [https://trac.ffmpeg.org/attachment/ticket/11055/Ticket_11055.m2ts.xml
 attachment description],

 > The video has bad timestamps:
 > |1| Frame
 [https://trac.ffmpeg.org/attachment/ticket/11055/Ticket_11055.m2ts.xml#L264
 #21] (ts: 5602.360789): would last ~ 2 s due to the next frame's PTS.…

 What is your evidence for this?  You link to
 [https://trac.ffmpeg.org/attachment/ticket/11055/Ticket_11055.m2ts.xml#L264|line
 264 of the XML attachment]. OK, that line in simplified form, and the
 following <frame> element on
 [https://trac.ffmpeg.org/attachment/ticket/11055/Ticket_11055.m2ts.xml#L277
 line 277], say:

 {{{
 <frame … pts="504212471" pts_time="5602.360789" pkt_dts="504385143"
 pkt_dts_time="5604.279367"
    best_effort_timestamp="504212471"
 best_effort_timestamp_time="5602.360789" …
    pict_type="B" …>
 <frame … pts="504392650" pts_time="5604.362778" pkt_dts="504392650"
 pkt_dts_time="5604.362778"
    best_effort_timestamp="504392650"
 best_effort_timestamp_time="5604.362778" …
    pict_type="B" …>
 }}}

 The pts_time value in Line 277 is 5604.362778, which is about 2 greater
 than the pts_time value in Line 264 (which is 5602.360789). So what? What
 does this mean for video playback?

 Are you saying that the frame described by Line 277 is physically the next
 frame in the stream after the frame described by Line 264?  What is your
 evidence for this?  Are you saying that the sequence of <frame> elements
 in the attached XML file matches the sequence of frame data bytes in the
 video file?

 The next <frame> element is
 [https://trac.ffmpeg.org/attachment/ticket/11055/Ticket_11055.m2ts.xml#L290
 line 290], which in simplified form says,

 {{{
 <frame … pts="504216225" pts_time="5602.402500" pkt_dts="504396404"
 pkt_dts_time="5604.404489"
    best_effort_timestamp="504396404"
 best_effort_timestamp_time="5604.404489" … pict_type="P" …>
 }}}

 The pts_time value in Line 290 is 5602.402500, which is less than the
 pts_time value in Line 277, and about 0.0417 greater than the pts_time
 value in Line 264.  Why should the player not display the Line 290 packet
 right after the Line 264 packet, and display the Line 277 packet 2 seconds
 later?  If you are going to find common ground with others in the
 discussion, I think you need to explain these things.

 And for instance, @markfilipak says:

 > You wrote: "Among the detected frames there was no sign of OGOP (Open
 GOP)."
 >
 > Wrong. Every GOP is open GOP.

 What evidence do you rely on for that?  Where in the bug report can others
 find that evidence?  Is it visible in the table you put in the
 description?

 You two might be able to help each other, but I think you won't succeed at
 doing that until you can find evidence that you both can work with, and
 until you figure out how to talk to each other instead of past each other.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11055#comment:78>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker