- From: Brendan Long <self@brendanlong.com>
- Date: Wed, 28 May 2014 08:51:44 -0500
- To: Philip Jägenstedt <philipj@opera.com>
- CC: public-html <public-html@w3.org>
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