[Bug 21431] Specify splicing behavior for text tracks

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

--- Comment #5 from Cyril Concolato <cyril.concolato@telecom-paristech.fr> ---
(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?
This is a tricky question because the overlap may be 'natural' in the original
content (at least in WebVTT) but if you're splicing a movie with subtitles with
an ad with subtitles, you probably don't want to keep rendering the movie
subtitles in the ad. 

> 2. Should existing cues in the SourceBuffer that are overlapped by cues in
> the beginning of a new media segment get truncated?
I would say if the media segment starts with a RAP, yes. It might be
problematic if it doesn't.

> 3. If an existing cue spans the entire new media segment, does get split
> into pieces or just stay visible for the whole period?
> 4. Do text cues have dependencies like video frames do?
In a sense, yes. You can create WebVTT streams where all 'frames' (access
units) are not RAP. Rendering of a WebVTT cue (in particular line positioning)
may depend on whether there is already a cue being displayed. So defining
WebVTT RAP depends on whether or not you want exact rendering. But it is
possible to rewrite a WebVTT file to force 'true' RAP. You might want to have a
look at:
http://concolato.wp.mines-telecom.fr/2012/09/12/webvtt-streaming/

> 5. I believe multiple cues starting at the same timestamp are allowed in a
> single text track. 
Yes.

> 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?
I don't see why you'd want to target individual cues. I think there could be a
flag indicating whether you want to keep existing overlapping cues or whether
you want to cut them short.

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

Received on Friday, 29 March 2013 08:12:44 UTC