Re: Handling live translation of cues to WebVTT

On Mon, Jan 27, 2014 at 11:35 PM, 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.

There are no existing cases where the parser modified (or even knows
about) a previous cue, so there's nothing to be consistent with.
Anyway, I think ignoring the fact that the cue has been modified is
the only sane thing to do here, I just wanted to check if you had
other plans.

>> 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.

What I meant is that a script can add multiple cues with the same id
while parsing is still happening, even ones that are far in the
future. I suppose the simplest thing would be to just remove them...

>> 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.

You are correct, it's likely that browsers will eventually optimize
getCueById and that reusing that would not add any cost.

So, to cut to the chase, I really think that trying to solve the "live
streaming with edits" case at this point is premature. I'm not saying
that it doesn't exist, it does, but it seems like an area where more
experimentation (using JavaScript) would be useful to inform the spec.
Remember that WebVTT doesn't support live streaming *without* edits
yet.

Philip

Received on Tuesday, 28 January 2014 08:19:33 UTC