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

On 05/28/2014 08:28 AM, Philip Jägenstedt wrote:
>
>> 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?
Yes, but the buffered range would need to be larger, since we would 
actually need data out of it. Maybe that doesn't matter.

> 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.
Yes, in CEA-708 we would probably have to treat the correction as a new 
cue. It's possible we could use heuristics to figure out that a change 
is meant to be a correction, but I'm not sure about the accuracy.

Received on Wednesday, 28 May 2014 13:52:23 UTC