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