[Bug 21431] New: Specify splicing behavior for text tracks

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

            Bug ID: 21431
           Summary: Specify splicing behavior for text tracks
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: adrianba@microsoft.com
          Reporter: acolwell@google.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

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?
2. Should existing cues in the SourceBuffer that are overlapped by cues in the
beginning of a new media segment get truncated?
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?
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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 29 March 2013 01:28:31 UTC