Definitely the block should be more backwards compatible, since we don't try have a mechanism for mutiline metadata headers. 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. > >
Received on Wednesday, 25 February 2015 19:20:28 UTC