[FFmpeg-user] ticket/11055 FFmpeg reports inconsistent PTS, DTS between 3 invocations [was: Re: I found the bugs]

[Jim DeLaHunt]

I'm renaming this thread because I think it is zeroing in on the 
contents of <https://trac.ffmpeg.org/ticket/11055>.

On 2024-06-14 13:21, Mark Filipak wrote:

> Let me bring everyone up to date.
> ffmpeg -i ... -f framecrc
> ffmpeg -i ... -vf showinfo
> ffmpeg -i ... -show_frames
> All show differing DTS and PTS timestamps. showinfo & show_frames have 
> 2 second gaps.
> The question is: Which one shows the actual timestamps?

It seems to me that a better statement is:

    All three of these FFmpeg invocations should report the same PTS and
    DTS values for every frame of the 99-frame test video in the ticket.
    However, they report different PTS and DTS values. I claim that this
    is a bug in FFmpeg.

It is useful to know which option shows the actual timestamps, but 
knowing that does not show that the bug is fixed. It is good for a bug 
report to have a way to evaluate whether the bug is fixed.

By the wayt, intuitively it seems to me that for some or all videos in 
general, all three of these FFmpeg invocations should report the same 
PTS and DTS values. I don't know how general this claim should be. Maybe 
it is limited to videos with H.264 data? But that claim would perhaps be 
documented in a series of automated tests, and maybe in a further bug 
report.

> The MPV player pauses during that 2 seconds -- MPV gets timestamps 
> from FFmpeg.
> The VLC & PowerDVD players _do_not_ pause.
> The question is: Why does MPV have problems with a video that VLC & 
> PowerDVD play?

It seems to me that this points to a separate bug report based on the 
same test data, with a bug statement:

    A certain FFmpeg invocation generates a 99-frame test video which
    causes MPV player to pause in playback, but does not cause VLC and
    PowerDVD players to pause. There seems to be nothing in the FFmpeg
    invocation which commands that pause. I claim it is a bug that
    FFmpeg generates an output video which causes the MPV player to pause.

The fact that other players do not pause is not, at first glance, strong 
evidence about FFmpeg. Maybe those players are ignoring valid data in 
the test video which should command them to pause.

The fact that MPV player pauses may indicate a bug in that player, 
causing it to malfunction when playing back perfectly valid data in the 
video which FFmpeg generates.  In that case, the desired response might 
be for FFmpeg to generate different valid data which will work around 
that MPV player bug. Or, this FFmpeg bug report might be closed as not a 
bug in FFmpeg, and a bug report should be opened against MPV player.

> framecrc matches the actual timestamps. I read the actual timestamps 
> in the actual PES headers in the actual packets. So, I conclude that 
> framecrc is correct and that showinfo & show_frames are wrong.
This sounds to me like useful diagnosis information which will help with 
understanding the bug in FFmpeg which causes showinfo and show_frames 
output to be wrong.
> The question is: Why are three different parts of FFmpeg getting three 
> different timestamps?
>
> Why is this important?
> Every time you transcode, you're using timestamps from FFmpeg.
> Every time you splice (trim and join) you're using timestamps from 
> FFmpeg.
> Every time you get discontinuous DTSes, FFmpeg timestamps determine it.

Agreed that, given that DTS and PTS values are objectively known values 
in the video data, and given that they matter to many operations which 
FFmpeg performs, it is important that FFmepg always uses the correct 
values for DTS and PTS. If FFmpeg gets those values wrong when doing 
showinfo and show_frames, it might be getting them wrong in other 
editing operations.


> For your tasks, is FFmpeg getting the correct timestamps or the bogus 
> timestamps?
>
> Believe me, I now know how to do perfect splices. It's hard, time 
> consuming, and nerve wracking, but I know how to do it. Do you? 
> Wouldn't it be nice if FFmpeg did them consistently, and consistently 
> correctly? Then we all could all use '-ss' '-to' and a thousand other 
> things with confidence.
It seems to me that this goes beyond the scope of #11055. FFmpeg could 
fix bugs and get the behaviour of showinfo and show_frames right, but 
still not do perfect splices easily.  "FFmpeg does not do perfect 
splices easily" might well be the problem statement of a different 
FFmpeg ticket.
>
> I submitted the bug here: https://trac.ffmpeg.org/ticket/11055
>
> In comment 7, I wrote:
> =====
> "I can't parse M2TSes. So, I don't know if there's something else 
> that's tripping up FFmpeg.
> For example, there may be something is M2TS having to do with sequence 
> header that's not in
> VOBs."
> =====
>
> In comment 26, I wrote:
> =====
> I guess there is 'something else'.
> I discovered this: "co located POCs unavailable" while transcoding 
> (AVC->HEVC) and remuxing
> (M2TS->MP4). POCs are particular to H.264.
>
> Of course, it has no bearing on why framecrc, showinfo, and 
> show_frames differ.
>
> I read about POCs in H.264. I think there might be an effect on DTSes 
> & PTSes.
> Can you help me out with this?
> =====
>
> Can all who read this message help me out, and thereby help yourself? 
> Ask and I'll tell you how.

FYI, it is not clear to me what you are asking people to do to "help 
[you] out". But I think I am not your target audience.  My purpose is to 
help you make #11055 be a well-formed bug report which affords 
developers fixing one bug in FFmpeg. I suspect that helping you achieve 
your goals will require multiple, incremental, bug fixes.

Best regards,
       —Jim DeLaHunt