On Mon, 2014-02-24 at 11:01 -0800, David Singer wrote: However, how much of the new cue replaces the old? start timestamp? end timestamp? attributes text? I was thinking everything, to keep the format simple. It could be repetitive if there are a lot of attributes, but the actual overhead should be insignificant compared to the video portion. Plus, this would only apply to live streaming, since non-live files could have duplicate cues removed, plus they could be easily compressed. what happens if someone re-defines a cue that I have already displayed? Moves the start timestamp to after where I am playing, so I was ‘incorrectly’ displaying it? If you change the start or end time of a cue<http://www.w3.org/html/wg/drafts/html/CR/embedded-content-0.html>, you run the "time marches on" steps, which (at a high level) can cause any cues to start or stop being displayed, along with firing events. Presumably changing any of the display-related stuff (vertical, snapToLines, text, etc.) would cause the cue to immediately change its display to match the new value. I think browsers already do both of these things when cues are changed via JavaScript. We may also want to add a "change" event to TextTrackCue (fired when any attributes change, or only when the UA changes them without JS requesting it?).
Received on Monday, 3 March 2014 19:26:54 UTC