On 2021-05-20 21:20, Nicolas George wrote:
Michael Fabian 'Xaymar' Dirks (12021-05-20):
There are plenty of reasons to know the actual frame rate with high
precision.
Editing software needs to know this to initialize effects, timelines
and projects.
I doubt they do that without building an index in the first place.
At the current time there aren't many editors that support Matroska, but Black Magic
Design DaVinci Resolve is one of them. Resolve approximates the 60 fps footage to be
59.94 fps, which is close but not exact - off by just 0.06 seconds. This is enough to
create an audio drift of 1 second after just 16.67 seconds, as changing the
"source" frame rate apparently means speeding up the footage.
You could consider this a "bug", but is this really a bug or is this just
terrible time stamp support in Matroska? In my opinion it is the latter.
Players need it to queue the right amount of frames at the right time.
No, they need to queue _enough_ frames, and for that timestamps are
enough.
You probably have a different idea of a audio-video player than i do.
Transcoding requires it to encode at the right rate.
Encoding mostly does not care about rate.
libx264, nvenc, amf, qsv, and probably plenty of other encoders disagree, as
they base their bitrate decisions on how much bitrate is available at the
current time.
Remuxing requires it so that it doesn't end up as "variable" without
Why would it be a problem?
requiring extensive extra parameters and scripting to get FFmpeg to
like the MKV file.
Please be more specific.
I think the next lines explain enough:
ffmpeg -i "raw60fps.y4m" -c:v libx264 (other parameters) -o "a.mkv"
ffmpeg -i "a.mkv" -c copy "a.mp4"
FFmpeg generates an mp4 file that is variable, not constant. This happens with every MKV file muxed
as 1ms, as Matroska so far has no proper frame rate tags or rational per-track time bases.
"-vsync cfr" does not fix this issue. "-framerate 60" does not fix this issue.
None of the supposed workarounds are true fixes for the issue. This isn't a fix for the issue
either, but it increases the precision enough to not require either of those parameters. It also
works around most frame rate detection code.
I don't see a single reason to not offer users the choice to increase
the precision to their liking.
I see no reason not to. But I also see no reason users should do it, and
you have not convinced me.
Because 1ms is not enough to properly represent anything except the previously
stated rates. I think we're going in circles here now.
I have yet to see anyone use timestamps wrong.
I suggest you spend a little time doing support on the users
mailing-list and you will see plenty.
Timestamps should be as accurate as possible, especially when you
consider that even with 1µs of precision in a 64-bit timestamp, you
can still mux for at least 584000 years before you have to wrap around
to zero again.
You need to learn about the difference between accuracy and precision.
I am aware of the difference between accuracy and precision, even though
English is my third language:
- https://www.merriam-webster.com/dictionary/precision, entry 1 of 2, 1.
- https://www.merriam-webster.com/dictionary/accuracy, 1.
I do not appreciate this hostility about two words that in my language end up
being the exact same word. I will retreat from further discussion with you for
this reason.
--
Sincerely | Mit freundlichen Grüßen
Michael Fabian 'Xaymar' Dirks
Software Designer & Engineer
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
