GNOME Bugzilla – Bug 539858
not enough NEWSEGMENT events from matroskademux
Last modified: 2009-12-15 10:05:22 UTC
In case when a subtitle stream is lagging behind, matroskademux sends NEWSEGMENT events to its peers. It is done when the current position is at least 0.5 seconds after the end of the last packet is the stream (aka stream position). Well, this is not good enough: subtitles can overlap. This happens very often with SSA/ASS, most likely USF and probably plaintext subtitles as well. This means that even if there is a subtitle that ends far in the future, there still could be one starting in the past that we (an overlay element) have not seen yet. The solution is very simple: let's count the lag from the start of the last packet, not from the end of it. I'm attaching a patch implementing this.
Created attachment 113306 [details] [review] proposed patch Here is the patch.
Why is it necessary to send the NEWSEGMENT events for overlapping buffers? What happens without them? The reason why they're sent right now is, that the pipeline would stall if no buffers are sent after the end of the last buffer for more than ~3-4 seconds.
(In reply to comment #2) > Why is it necessary to send the NEWSEGMENT events for overlapping buffers? What > happens without them? Textoverlay can push video buffer only if it is sure that it has seen all the subtitle buffers with the less or equal timestamps. This is the case (or so it thinks) if either there is a buffer with end point in the future, or there was a NEWSEGMENT for text stream with start point in the future. With overlapping buffers, the first condition is incorrect. It results in lost subtitles. We can only be sure that we have seen all the subtitles from the past if the _start_ of some subtitle is in the future, or the same NEWSEGMENT condition. For example, if there were two subtitles with time intervals [0, 10] and [1, 2], the second one may never be displayed. This is not that important for textoverlay, because it does not support overlapping subtitles at all. In fact, the second buffer ([1, 2]) would be locked in text_chain until the end of the first one. I'm writing an overlay that supports overlapping subtitles. For this reason I can only rely on start points of text buffers to decide when to push the video frame. If I get a long subtitle buffer, only NEWSEGMENT events (starting from start of the buffer + 0.5 seconds) can tell me that video stream can progress.
If I read the above and following commit right, this should have been taken care of now (i.e. track positions using start times rather than end times). Feel free to re-open otherwise. commit 276a61ab2a18d8be793109819ce331dc1d9d98aa Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed Dec 9 16:41:04 2009 +0100 matroskademux: Fix position tracking and sending of filler segments