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: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 2 Sep 2012 13:58:29 +0200
Message-ID: <CAHp8n2m3npELX75x0+D0fBr_ZvV3wRZdS5uOWWnCkgQ46=VXoA@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: David Singer <singer@apple.com>, public-texttracks <public-texttracks@w3.org>
On Sun, Sep 2, 2012 at 1:16 PM, Simon Pieters <simonp@opera.com> wrote:
> On Sun, 02 Sep 2012 11:31:13 +0200, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> I would prefer if we didn't have to escape anything.
> OK, good. :-)
>> But I also agree
>> that pushing a header into a "broken cue" is rather fragile.
> I don't understand what's fragile about it.
>> I am in
>> particular concerned that it might end up as a cue inside
>> encapsulations that follow the parsing algorithm of WebVTT. E.g. say
>> you're parsing a WebVTT file according to its structure to encapsulate
>> them into WebM, then you would end up identifying the header until the
>> first empty line, then identifying the cues. And as you identify a cue
>> that you cannot give a time segment to (because there is none), you
>> drop the cue on the floor. This means that a WebM encapsulation would
>> always drop an inline style sheet.
> The spec says to drop the header on the floor as well, so a WebM
> encapsulation that implements the current spec would drop an inline style
> sheet in the header as well.
>> If we could extend the WebVTT parser to have, say
>> END
>> as the header and ignoring everything betwen WEBVTT and END, then we
>> could do whatever in the header, including having blank lines.
> It would not make any difference to existing parsers.

No, it wouldn't. But once we have a mechanism to identify the end of
the header, if we store and header information in cues, then
everything that makes a clean separation between headers and cues
(such as a WebM encoder) will be able to deal with the headers, but
would drop the cues on the floor. WebM has already made precautions
for headers and anything that's between the WEBVTT marker and the
first cue (not the first successfully parsed cue!!) is regarded as the
header, see http://wiki.webmproject.org/webm-metadata/temporal-metadata/webvtt-in-webm

"all the text (up to and excluding the linefeed separator that
demarcates the file-wide metadata and the first cue) could be stored
in the CodecPrivate sub-element of the Track element"

>> It's
>> not backwards compatible with the blank line mechanism, but it might
>> not be too late to introduce something like this.
> I don't see the benefit over not using the END marker. If we can make
> breaking changes, then certainly we can design something that doesn't need
> escaping.

Please, let's do so. Do you have a suggestion?

> But we already have built-in extension points in the parser
> (per-file headers, cue-level blocks (can be per-file if we want), per-cue
> settings...) so we don't need to do breaking changes to the parser and still
> have a syntax that doesn't need escaping.
>> Then we could have multi-line header fields with blank lines like this:
>> language: fr
>> kind: subtitles
>> #foo { color:green }
>> i { font-family:serif }
>> END
>> foo
>> 00:00:00.000 --> 00:00:05.000
>> testing <i>testing</i>
> Existing parsers would drop the headers and the STYLE and END blocks on the
> floor and successfully parse the cue.

Yes. The propsoed WebM encapsulation would keep the file-wide headers,
but drop the Stye on the floor. That's the problem I'd like to avoid.

Received on Sunday, 2 September 2012 11:59:16 UTC

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