Re: Removing cues with duplicate ids as a way to allow cue rewriting

Hi Brendan!

TextTrackCue.id is mutable, so that setter would have to throw (or
something) to guarantee that there are no duplicate ids. Elements have
non-unique ids and getElementById() can still be implemented efficiently,
so I disagree that a non-unique TextTrackCue.id is a problem worth solving
in its own right.

That being said, corrections in live broadcasts are a real thing in CEA-608
and the teletext system used in (at least) Sweden. As you say, the problem
can be solved by delaying the stream by some arbitrary amount, I guess 5
seconds would work in practice. Isn't there already that amount of delay
due to buffering, and if there isn't, would it be a problem to introduce 5
seconds of buffer for those users who would otherwise see captions being
corrected in real time?

Philip


On Fri, May 23, 2014 at 1:18 AM, Brendan Long <self@brendanlong.com> wrote:

>  I've proposed this in the past, but I think I've narrowed it down to
> specific changes, and I'm wondering if other people think this would be a
> useful way to allow rewriting of cues.
>
> *Why*
>
> In streaming text tracks, we need a way to fix incorrect cues. Some
> examples:
>
>    - In live TV, people type the captions in by hand<http://en.wikipedia.org/wiki/Closed_captioning#Television_and_video>shortly before you see them. If they make a mistake, we need a way to fix
>    it.
>    - CEA-608 and CEA-708 captions don't start with a convenient startTime
>    --> endTime block like WebVTT does. A caption ends when we get a command
>    that makes it stop displaying. If we want to transcode to WebVTT in
>    real-time, we have to either wait until the caption is over to translate it
>    (delaying the stream by some arbitary time in the hope that it will be long
>    enough), or we need to start a caption immediately with a guess of the end
>    time and then rewrite it once we know the correct end time (or rewrite it
>    to extend the end time until we find the correct one).
>
> *How*
>
> The solution I'm proposing is that if we see two cues with the same id,
> the earlier cue will be removed.
>
> some-id
> 00:00:00 --> 00:00:30
> This is an xeample
>
> some-id
> 00:00:00 --> 00:00:10
> This is an example
>
> In this example, the text "This is an example" will be displayed for 10
> seconds starting at time 0.
>
> *Why This Solution*
>
> This solution is nice because the syntax is simple and easy to understand,
> and it's powerful enough to rewrite any cue in any way you could possibly
> want, because the new cue completely replaces the old one.
>
> *Arguments against*
>
> This isn't particularly efficient. If you just want to change the time,
> you need to send the entire updated cue, instead of just the change.
>
> I don't think this is a big deal, because even the most heavily edited
> subtitle file will be orders of magnitude smaller than the accompanying
> video.
>
> *Specifically..*
>
> There are a couple ways of doing this in HTML:
>
>    1. Do this at the WebVTT-layer: If the WebVTT parser sees a cue with
>    the same id as an older cue, it explicitly removes the older cue from the
>    track and then adds the new cue.
>    2. Do this at the HTML layer: If any TextTrack gets a cue with the
>    same id as a cue it already has, it removes the old cue before adding the
>    new one.
>
> I think doing this at the HTML layer makes sense, because:
>
>    - ids should be unique anyway. That's why they're ids.
>    - TextTrack.getCueById() doesn't make sense if ids aren't unique.
>    - The implementation is much easier if we can throw a hash table in
>    TextTrack and use it for detecting duplicate ids, and for making
>    getCueById() fast.
>    - Handling weird edge cases is simpler:
>       - If JavaScript adds a cue with the same id as an existing cue, the
>       existing cue is removed.
>       - If the UA adds a cue with the same id as a cue added by
>       JavaScript, the cue added by JavaScript is removed (in this case,
>       presumably whatever trigger caused JavaScript to add that cue will be
>       triggered again).
>
> I think if we do this, it should *also* be added to the WebVTT spec, so
> files that do this will render properly in non-HTML media players.
>
> *More specifically**...*
>
> https://github.com/w3c/html/pull/20
>
> *Conclusion*
>
> Does this seem like a reasonable change to you?
>
>
>