- From: Philip Jägenstedt <philipj@opera.com>
- Date: Fri, 24 Jan 2014 23:33:19 +0700
- To: Brendan Long <B.Long@cablelabs.com>
- Cc: "public-texttracks@w3.org" <public-texttracks@w3.org>
On Wed, Jan 15, 2014 at 5:42 AM, Brendan Long <B.Long@cablelabs.com> wrote: > I previously sent this email to the TimedText WG, but it was suggested by > Silvia that I should bring the conversation here. > > Two suggestions were made on that mailing list: > > It may be better to set the end time to a smaller value, so if something > unexpected happens, the cue will still go away eventually. We could probably > handle this by setting the end time to 10 or 20 seconds, and extending it if > we don't find the correct end time before the cue is supposed to end, like > so: > > 1 > 00:00:05 --> 00:00:20 > First cue > > NOTE We don't know when the cue ends yet at the 20 second mark, so we add > another 20 seconds > 1 > 00:00:05 --> 00:00:40 > First cue > > NOTE Now we know the correct end time > 1 > 00:00:05 --> 00:00:25 > First cue > > The other suggestion was just replacing the entire document to update a cue. > This would be useful because the document wouldn't increase in size forever. > The downside (my opinion) is that it would make the client more complicated > and less efficient (because we'd need to do polling). I don't think > unbounded file size would actually be a problem in WebVTT though, since the > UA isn't required to hold onto the original document. WebKit and > Chromium/Blink both don't -- They parse the file contents as they receive > it, then throw it away. Having looked at the original thread, I can only guess that you don't want to involve scripts, since if you can rely on scripts it seems like you could easily do what you're asking for. What is the reason that you do not want to use scripts here? Philip
Received on Friday, 24 January 2014 16:33:48 UTC