W3C home > Mailing lists > Public > public-texttracks@w3.org > September 2012

Re: Metadata in the VTT file header (bug 15851), use cases (and a need to close this)

From: Dave Singer <singer@apple.com>
Date: Wed, 12 Sep 2012 20:46:51 -0700
Cc: Philip Jägenstedt <philipj@opera.com>, public-texttracks <public-texttracks@w3.org>
Message-id: <45F992E1-E923-4968-8CED-6F0667D504FB@apple.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>

On Sep 12, 2012, at 19:43 , Silvia Pfeiffer wrote:

>> MPEG-2 TS timestamps cycle, and I don't think WebVTT ones are allowed to.  Re-writing entire files, finding every timestamp in them, is a lot less 'trivial' than a mapping.
>> MPEG-2 TS continues to be a popular format, despite its age.  It is the media format behind our live streaming system, for example.
> For the record: I don't think MPEG-2 TS are a use case for us, exactly
> because they don't fit the model of a time-linear media resource. I
> would expect them to be used only through adaptive streaming where
> either the JS will map the data to the timeline using the MediaSource
> API, or a DASH-type file will make sure the timing is provided
> consistently.
> Do you have a concrete example where that would not be sufficient?

I don't think that the mapping will fit into every manifest format, and I am not at all convinced it belongs in the manifest file at all.

I don't think it needs to be standardized -- as Ian says, the distributor can insert it.  But they just need to be able to insert it in a 'safe' way (that is known to avoid other attributes, and which fits into the header parsing).

>>> For the record, I'm also not very enthusiastic about adding key-value metadata to WebVTT. Duplicating language and kind seem like a nice way to confuse, and browsers would just ignore the metadata anyway. The suggested syntax for multi-line values also looks pretty exotic to me.
>> You're assuming a browser embedding; we envisage VTT used in a whole bunch of scenarios and locations.
> Not surprisingly: I agree. :-)
>> Given the need for a value-terminator and a header-block-terminator (blank line), escaping lines that look like those (plus escaping lines that look like the escape) seems pretty simple, obvious, and minimal.  The choice of the 'bracketing' characters is taste;  I suggested [[ and ]], others preferred "|" and ".".  As long as the terminator is rare in the obvious use-case (CSS), I don't think it really matters.
> Again: I agree. Let's pick one way and then move on.
> I've just tested what Simon suggested earlier in Google Chrome, Opera
> Next and Safari and they can all deal with it:
> language: fr
> kind: subtitles
> #foo { color:green }
> i { font-family:serif }
> #bar { color:red }
> foo
> 00:00:00.000 --> 00:00:05.000
> testing <i>testing</i>
> It's pretty and browsers can deal with it.

It has a HUGE problem that I layer out in my previous email.  People will write


because they can.  And then all the issues with either lack of random access (if the stylesheet doesn't apply to the first two cues) or look-ahead and lack of incrementality (you cannot decode and go) apply.  It's simply not worth it to avoid escaping blank lines.

> The rest of the tools will
> then just have to deal with pushing everything before the first valid
> cue (one that has a --> in it) into the header (even if that's
> different to how the WebVTT spec is written). If we make specs for
> such other tools outside the core WebVTT spec here, that should not be
> a problem, I guess.
> Cheers,
> Silvia.

Dave Singer
Multimedia and Software Standards, Apple

Received on Thursday, 13 September 2012 03:47:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:20 UTC