[Bug 21431] Specify splicing behavior for text tracks

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

Silvia Pfeiffer <silviapfeiffer1@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |silviapfeiffer1@gmail.com

--- Comment #2 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(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.


> 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. 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 03:39:42 UTC