- From: David Singer <singer@apple.com>
- Date: Wed, 25 Feb 2015 13:45:07 -0800
- To: Silvia Pfieffer <silviapfeiffer1@gmail.com>
- Cc: Gary Katsevman <gkatsevman@brightcove.com>, John Luther <jluther@jwplayer.com>, Philip Jägenstedt <philipj@opera.com>, "public-texttracks@w3.org" <public-texttracks@w3.org>, Rick Eyre <rick.eyre@hotmail.com>, Steve Heffernan <steve@zencoder.com>, Jeroen Wijering <jeroen@jwplayer.com>
> On Feb 25, 2015, at 12:45 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > > > On 26 Feb 2015 06:21, "David Singer" <singer@apple.com> wrote: > > > > > > > On Feb 25, 2015, at 11:19 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > > > > > > Definitely the block should be more backwards compatible, since we don't try have a mechanism for mutiline metadata headers. > > > > wow, you surprise me. the parser in the spec says you parse from the webvtt line to a blank line and treat all that as header material, doesn’t it? > > Yes. It also says that a metadata header consists of a name value pair on a single line. ah, right, that happened after we explored this the first time > > > what does it say about blocks that don’t look like cues, such as Notes? > > The current parser drops them as invalid cues. So it's an extension mechanism that we can make use of. It's probably better than inventing a means for multi line headers that will not be backwards compatible. OK. as might want to do some quick experiments, but this sounds plausible. > > Cheers, > Silvia. > > > > > > > > > Best Regards, > > > Silvia. > > > > > > On 26 Feb 2015 04:20, "David Singer" <singer@apple.com> wrote: > > > > > > > On Feb 25, 2015, at 9:13 , 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. > > > > > > > > > > I forgot to ask: which is the least disruptive to existing implementations? Extending the header, or a new block type? I think all existing implementations discard header lines until a blank line, don’t they, so that should be safe. What about skipping unrecognized blocks? Is that clear? > > > > > > > > > WEBVTT > > > Style: | > > > .stuff css style sheet > > > . > > > > > > Then the first note/cue > > > > > > > > > * * * * * * > > > > > > or > > > STYLE > > > .stuff css style sheet > > > > > > > > > NOTE/cue > > > > > > > > > David Singer > > > Manager, Software Standards, Apple Inc. > > > > > > > David Singer > > Manager, Software Standards, Apple Inc. > > David Singer Manager, Software Standards, Apple Inc.
Received on Wednesday, 25 February 2015 21:45:37 UTC