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

On Tue, May 27, 2014 at 5:01 PM, Brendan Long <self@brendanlong.com> wrote:
>
> On 05/26/2014 04:18 AM, Philip Jägenstedt wrote:
>
> 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 makes sense. It probably isn't worth handling at the HTML level. Doing
> this in the WebVTT parser would work though.

Can you file a WebVTT bug for live streaming with corrections? If one
treats the corrected cue like a new cue, maybe it can be solved in the
same way as cues with initially unknown end times that can at any time
be replaced by a new cue. (No solution exists for that either, yet.)

> 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?
>
> Delaying the stream would make CEA-608 and CEA-708 to WebVTT translations
> mostly work, but I don't see how it would help with corrections.
>
> I'm not really a fan of using a delay. Most cues only last a short time, but
> it's possible to have arbitary-length cues, and no amount of delay will
> always help. It also seems like a time delay (even a short one) is much more
> significant than a tiny amount of extra bandwidth and processing to send out
> a replacement cue.
>
> With buffering, don't video players usually let the video play until the
> buffer completely runs out? If we need data in the buffer to display
> captions at the current position, then we'd have to stop playback whenever
> the buffer is too small. For example, if we need a 5 second buffer for
> smooth playback, and we have a 5 second delay in our captions, then we'll
> need to have a 10 second buffer for smooth playback with captions. This is
> probably a bit simplistic, but I don't think the buffer helps as much as
> you're suggesting.

If the server isn't able to add the delay, then the client could just
pause when currentTime is getting too close to the end of the buffered
range, right?

BTW, can you actually reliable differentiate between corrected cues
and new cues in CEA-608? It seems to me like you'd have to make shaky
assumptions about which commands were used to arrive at the currently
visible text. It would be great if it were possible, because delaying
the stream somewhat and seeing the correct text from the beginning
seems like a win for the user.

Philip

Received on Wednesday, 28 May 2014 13:29:26 UTC