- From: David Singer <singer@apple.com>
- Date: Thu, 26 Feb 2015 08:59:17 -0800
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: Silvia Pfieffer <silviapfeiffer1@gmail.com>, John Luther <jluther@jwplayer.com>, Rick Eyre <rick.eyre@hotmail.com>, "public-texttracks@w3.org" <public-texttracks@w3.org>, Gary Katsevman <gkatsevman@brightcove.com>, Steve Heffernan <steve@zencoder.com>, Jeroen Wijering <jeroen@jwplayer.com>
> On Feb 25, 2015, at 18:18 , Philip Jägenstedt <philipj@opera.com> wrote: > > On Thu, Feb 26, 2015 at 12:13 AM, David Singer <singer@apple.com> wrote: >> >> >>> On Feb 24, 2015, at 18:57 , Philip Jägenstedt <philipj@opera.com> wrote: >>> >>> I think I agree with Silvia here, a STYLE block seems more natural >>> than putting it in the header. Note that we could still, if there are >>> strong reasons, drop any such blocks that come after any cue. It gives >>> us some flexibility with the streaming case, even if we don't use it >>> now. >> >> I don’t mind if it’s a block or part of the header, as long as it has to occur before the first cue. The point is that at the moment one can random access into a VTT file (not load it all from the beginning), once one has the ‘header’. I don’t want to lose that. In text, one might lose cues that have an end time that overlaps where you random access to, but in MP4 packing we even deal with that. > > What does this mean? The parser consumes all data from beginning to > end as a stream. Perhaps it could be proven that if you seek to a > random point and put the tokenizer+parser in a particular state then > the cues that it will output will be a subset of the cues output for a > sequential parse, but this isn't a property of WebVTT files I've ever > even considered. OK, but others have. If you find line breaks, and then double line breaks, you can now find the beginnings of blocks, and start finding cues and their start times, and then you can work out what to display given the time you wanted to start at. I have not seen this done in text, but it’s logically possible. As I say, in MP4 we even deal with the fact that there may be older cues that overlap the time you seek to. > > I think it would be fine to require style blocks to precede any cues, > but I think I'm maybe missing the actual rationale… > OK, maybe we don’t have to agree on the rationale. David Singer Manager, Software Standards, Apple Inc.
Received on Thursday, 26 February 2015 16:59:46 UTC