After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 707411 - qtmux: what is purpose of MAX_TOLERATED_LATENESS?
qtmux: what is purpose of MAX_TOLERATED_LATENESS?
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal normal
: 1.1.90
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-09-03 18:02 UTC by Matej Knopp
Modified: 2013-09-18 16:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to remove MAX_TOLERATED_LATENESS (1.22 KB, patch)
2013-09-14 14:06 UTC, Matej Knopp
committed Details | Review

Description Matej Knopp 2013-09-03 18:02:56 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?
Comment 1 Sebastian Dröge (slomo) 2013-09-04 08:40:59 UTC
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
Comment 2 Thiago Sousa Santos 2013-09-04 11:41:54 UTC
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.
Comment 3 Matej Knopp 2013-09-04 12:53:33 UTC
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.
Comment 4 Thiago Sousa Santos 2013-09-04 13:13:02 UTC
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?
Comment 5 Matej Knopp 2013-09-04 13:14:51 UTC
I can provide a patch.
Comment 6 Thiago Sousa Santos 2013-09-10 22:54:11 UTC
Any news?
Comment 7 Matej Knopp 2013-09-10 23:31:29 UTC
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 :)
Comment 8 Matej Knopp 2013-09-14 14:06:54 UTC
Created attachment 254921 [details] [review]
Patch to remove MAX_TOLERATED_LATENESS

Took longer than it should have
Comment 9 Thiago Sousa Santos 2013-09-16 14:14:34 UTC
commit b2982bb749232734ca9c7b658bc497cafaeffa8a
Author: Matej Knopp <matej.knopp@gmail.com>
Date:   Sat Sep 14 16:03:20 2013 +0200

    qtmux: remove MAX_TOLERATED_LATENESS