[FFmpeg-devel] [PATCH] avformat/matroskaenc: Allow changing the time stamp precision via option

[Michael Fabian 'Xaymar' Dirks]

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