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.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
