Re: Handling live translation of cues to WebVTT

I am concerned about whether the old cue had knock-on effects that differ from its replacement — so those effects would have to be undone and re-done – as well (can there be, e.g. scroll?).

On Jan 27, 2014, at 8:35 , Brendan Long <B.Long@cablelabs.com> wrote:

> On Mon, 2014-01-27 at 10:01 +0700, Philip Jägenstedt wrote:
>> Should the old cue be removed and a new one inserted, or should the
>> old cue be updated in place?
>> 
> Adding a new cue would be convenient, since we could notify JavaScript via oncuechange. Changing the cue would be nicer if we had an onchange event on TextTrackCue..
> 
>> What should happen if the previous cue has already been modified by scripts?
>> 
> I don't have strong feelings about this either way. We should do whatever would be consistent with how we handle script modification in other cases.
> 
>> What happens if there are multiple existing cues with the same id?
>> 
> The last cue in the WebVTT file is the only one that matters. All others should be ignored.
> 
>> Whatever the answers to these questions, it seems like in order to be
>> efficient, for each parsed cue, one must check if there is already a
>> cue with the same id. This will either make the parser O(n^2) or
>> require a hash table, i.e. more memory, and this cost will be payed by
>> all users of WebVTT, not just live streaming with edits.
>> 
> The memory usage of a hash table would be tiny compared to the size of an actual cue. Some UA's might use hash tables here anyway, to make getCueById() more efficient.

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 28 January 2014 02:28:02 UTC