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

[Mark Filipak]

You see. This is the type of discussion that needs to occur _before_ a bug report is filed.

On 14/06/2024 19.03, Jim DeLaHunt wrote:
-snip-
>     A certain FFmpeg invocation generates a 99-frame test video which
>     causes MPV player to pause in playback,

That's not quite correct, Jim. The creation of the spliced video is perfect (as I can judge video 
perfection) and FFmpeg did what I asked it to do. The 'invocation' is _not_ the cause and is not the 
issue. The issue is that differing FFmpeg functions report differing timestamps.

> 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.

To clarify, to my knowledge and per my tests, there's nothing _in_ the video that would cause MPV 
(or any player) to pause. That is shown to be true by VLC and PowerDVD _not_ pausing.

I believe it is the routine that MPV uses within FFmpeg to _read_ the video's timestamps that causes 
it to pause for 2 seconds. To clarify: It's not that FFmpeg is pausing as it supplies timestamps, 
it's that those timestamps specify a pause, a two second pause. The timestamps are wrong, so the 
pause is wrong. It's not MPV's fault.

Let me put it another way: You transcode a video that has constant frame rate. When you play the 
output video, just made, MPV shows the frame rate varying -- a little up, a little down, a little up 
  again. Does that sound familiar?

> The fact that other players do not pause is not, at first glance, strong evidence about FFmpeg.

It's very strong evidence, in my opinion.

> Maybe those players are ignoring valid data in the test video which should command them to pause.

No, there's no such data that I can see -- that's why I asked for corroboration, to see more, to see 
whether other people can see more.

> 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.

Nope. MPV is doing what FFmpeg's bogus timestamps indicate it should do. The fault is not in MPV. 
MPV pauses because the timestamps jump from 504208717 PTS to 504392650. That's 183933 ticks, 2.0437 
seconds.

>> 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.

It should be a relatively simple matter of tracing, in the code, which routines are called by 
framecrc's processing and which routines are called by showinfo's processing.

>> 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.

The issue is not splices. The issue is framecrc, showinfo, and show_frames all getting different 
timestamps. The problem is in the underlying code that's called by those three.

>  "FFmpeg does 
> not do perfect splices easily" might well be the problem statement of a different FFmpeg ticket.

No. I'm pretty sure they are intimately related, that showinfo and show_frames are getting 
timestamps from the same FFmpeg internal routines that supply time stamps to '-ss' and '-to' and to 
many of those runs that complain about discontinuous DTSes.

Did you notice that show-frame's PTSes and DTSes are reversed? Of course, they're not actually 
reversed in the video, they're just being reported with DTS>PTS.

>> 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".

Ask. That's all. Ask. Each person who asks has capabilities unique to themselves. You want to help? 
Ask. I can supply whatever it is that will help.

> 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.

I disagree. I think there's a bug in the underlying code and that if the bug is fixed, a lot of 
stuff will suddenly work correctly. Of course, there will be some 'fixes' in the code that will stop 
working because they were bogus to begin with, but that's the way it is with software development.