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
signature.asc
Description: PGP signature
_______________________________________________ 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".
