[Bug 21431] Specify splicing behavior for text tracks

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21431

--- Comment #6 from Cyril Concolato <cyril.concolato@telecom-paristech.fr> ---
(In reply to comment #2)
> (In reply to comment #0)
> > I just realized that the spec has no text about how splicing text tracks
> > should work. I need to review the algorithms a little more, but I believe
> > that they might behave in suprising ways with particularly long cues.
> > 
> > Here are some initial questions that I think need to be answered:
> > 1. If a media segment with cues overlaps existing cues in the source buffer
> > what should happen?
> 
> Assuming we have a video file with a text track (such as WebVTT in WebM)
> that we split into segments (source buffers), then transmit and cobble
> together for display in the client, would we repeat a cue that is still
> active, but not actually part of the current segment in the original file?
> 
> I actually think repetition should be possible (as a kind of "backup"), but
> should not lead to duplicate display. So, we'd need to be able to identify
> repeated cues and drop them on the floor.
> 
> > 2. Should existing cues in the SourceBuffer that are overlapped by cues in
> > the beginning of a new media segment get truncated?
> 
> If the new segment has a copy of an existing cue, it should not lead to
> duplicate display, i.e. one of the two needs to be dropped.
Let's take an example. You have a WebVTT file that has a single cue lasting
from 0 to 30 seconds. You split this file into 3 x 10s segments. I think in
that case that the cue in segment 1 should have a duration of 10s not of 30s.
In WebVTT over MP4, segment 2 will contain a sample marked as continuation of
the previous from 10 to 20. Same for segment 3. So assuming you drop segment 2
and display some other content (possibly with subtitles) for 10s and then push
segment 3, there won't be duplicate display. 

> 
> 
> > 3. If an existing cue spans the entire new media segment, does get split
> > into pieces or just stay visible for the whole period?
> 
> I think either should be possible, but just not lead to duplicate display.
> 
> > 4. Do text cues have dependencies like video frames do?
> 
> Each cue can stand on its own. 
>From a coding perspective, yes. From a rendering perspective, not always.

> The only kind of text track cue that has
> dependencies are chapters and we have therefore decided in WebM to move them
> to the file header and deliver in one set. Other cues should be completely
> independent.
> 
> > 5. I believe multiple cues starting at the same timestamp are allowed in a
> > single text track. If so, should overlaps at that timestamp remove all the
> > cues at the timestamp or should there be special rules that allow targetting
> > individual cues?
> 
> What overlaps are you referring to? Such as: segment overlaps and the cues
> being delivered twice? IMHO, all we need to make sure is that cues have a
> unique identifier and when delivered twice don't get added to the list of
> TextTrackCues for rendering. The server then has to make sure to provide the
> same identifier for the same cue in any segmentation.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 29 March 2013 08:20:48 UTC