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

[Nicolas George]

Michael Fabian 'Xaymar' Dirks (12021-05-20):
> 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.

There is absolutely no doubt this is a bug, because timestamps do not
drift.

And just in case you are not convinced this is a bug, if the issue was
what you thought it was, you would get a drift of one second after two
thousand seconds, or at worst one thousand. Not sixteen.

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

They can make their bitrate decisions with timestamps.

> > > Remuxing requires it so that it doesn't end up as "variable" without
> > Why would it be a problem?

You neglected to answer this. It's a shame, because it was the most
important question.

> 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 am not sure about this, but I am very dubious, because as far as I
know, our MP4 muxer only supports constant frame rate.

> Because 1ms is not enough to properly represent anything except the
> previously stated rates. I think we're going in circles here now.

I am sorry, but the arithmetic rules that limit 1 ms to exactly
represent only a handful of rates applies to 1 ns too, because the prime
factors are the same.

And we are indeed going in circles, because I have already explained
this: a smaller time base will not fix bad math, it will only make it
accumulate slower.

> > > I have yet to see anyone use timestamps wrong.
> > > 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.

How was I supposed to know about your language? And why should I care?
There was no hostility in my message, only a little tiredness. The only
thing that matters is that you used the wrong concept. Note: the wrong
concept, not just the wrong word. Your current mail confirms this.

So, let me state it clearly: one millisecond is not very precise, but it
is accurate enough for most uses, because most timings, about contents
and hardware, is significantly less accurate.

You have yet to produce arguments to contradict this.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210520/d9c87df4/attachment.sig>