GNOME Bugzilla – Bug 707411
qtmux: what is purpose of MAX_TOLERATED_LATENESS?
Last modified: 2013-09-18 16:50:59 UTC
I don't quite understand what the purpose of MAX_TOLERATED_LATENESS is except to cause A/V sync issue, which it does remarkably well :) Basically, right now if first buffer PTS is > 0 and < 0.1s, the edit list is not written and the buffer starts from 0. Does anyone knows why this is supposed to happen and where is the 0.1s value from?
Do you have an easy testcase for this? Maybe Thiago knows what the point of this code was, it needs at least some explanation in the comments
mov files accumulate samples based on durations and assumes all streams start at timestamp 0. AFAIK the way to indicate that a stream starts 'late' is to add an edts entry stating the 'empty' period at the beginning and then another one with the real start time for the stream. As Sebastian said, do you have a test case? I guess the value must have been obtained from testing. Removing the MAX_TOLERATED_LATENESS would fix the problem for you? Also, this got me wondering how does mov files handle sparse streams, like subtitles.
Hi, my test case is simply audio stream that starts at 80ms (it's not an actual file, it's just something generated). Your explanation is correct of course, the issue is offset of first sample. This offset is represented in edit list. The problem with MAX_TOLERATED_LATENESS is that the offset is only added to edit list when bigger then 0.1s. Otherwise this offset is lost, causing A/V sync issues. I don't understand the purpose of MAX_TOLERATED_LATENESS. In which situation exactly would you want to throw away the offset of first sample and start from zero? The issue is resolved by removing the limit (or setting it to a very low number), but I'm curious about the reason why it is there in the first place. As for subtitles, I submitted patch to add timed text support to muxer ( https://bugzilla.gnome.org/show_bug.cgi?id=696437 ) but I'll probably need to attach rebased patch. Sparse streams work as follows: First sample offset is represented in edit list (just like any other streams) Gaps between subtitles are represented by empty samples. So the stream is not really sparse, it just contains samples with zero content length.
I don't think there is any reason for the choice of 100ms, it can be removed to add any start up lateness to edts if it exists. Do you want to provide a patch or should I fix it?
I can provide a patch.
Any news?
Sorry, bit busy now, I have bunch of patches I need to clean up and submit, this is one of them :) Hopefully I'll get to it soon. If you need it before that feel free to remove it yourself :)
Created attachment 254921 [details] [review] Patch to remove MAX_TOLERATED_LATENESS Took longer than it should have
commit b2982bb749232734ca9c7b658bc497cafaeffa8a Author: Matej Knopp <matej.knopp@gmail.com> Date: Sat Sep 14 16:03:20 2013 +0200 qtmux: remove MAX_TOLERATED_LATENESS