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

Re: metadata in the VTT file header, re-starting the conversation

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 23 Feb 2012 22:07:46 +1100
Message-ID: <CAHp8n2mgGeRJgNex07FHuyBarPq4yQRz6gJg4Kdt_AA-mXYbqg@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: public-texttracks@w3.org
On Thu, Feb 23, 2012 at 8:29 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Wed, 22 Feb 2012 22:13:55 +0100, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On Thu, Feb 23, 2012 at 5:31 AM, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>> On Wed, 22 Feb 2012 00:31:42 +0100, David Singer <singer@apple.com>
>>> wrote:
>>>> Hi
>>>> this conversation petered out, and we could really do with a way to
>>>> store
>>>> attributes in the VTT file header:
>>>> a) documented (standard)
>>>> b) vendor-specific and experimental, probably
>>>> Does anyone have any preferred syntax for doing this?  It's a little
>>>> tricky, because one of the values I'd like to support is in-line CSS
>>> In my private and humble opinion, a standardized format for metadata in
>>> WebVTT overkill and not really something we need for v1. I'd prefer to
>>> simply have some form of comment block that people can experiment with
>>> before trying to go further.
>> The need for this metadata is not with browsers, who can already get
>> all the required information from the HTML <track> element. Desktop
>> players are in an entirely different situation and lack that
>> information. We need to provide a means to deliver that information to
>> desktop players and indeed other desktop applications. Putting it
>> outside of the WebVTT file is impractical. If we leave the format in
>> which this data is given open for experimentation, we will get files
>> in all sorts of formats that won't be able to be parsed by typical
>> applications.
> What information is it that desktop players need?

They have to react differently to the data in the cues depending on
whether it is a caption/subtitle, a description, a chapter or a
metadata file. So this information is vital to have.

Also, the information as to what language the track is in would be
very important to display in the list of available caption tracks. For
example, VLC currently loads all the SRT tracks for a video that are
in the same directory, but only displays them as "track1", "track2",
"track3", etc. which is pretty useless from a UI POV. Instead, if
there was a normative location to describe the language, VLC could
display that language.

> Do any existing players do
> anything at all with metadata contained in any existing text tracks formats?

I've tried VLC and some SSA files with metadata, but also only ever
got "track1", "track2". I don't think we should tolerate this
situation, however. Also. if they knew that a WebVTT file was a
description file, they could ask to turn on the screenreader, for
example, rather than ignoring it.

> The only really useful thing that I can think of is language-based font
> switching, and I've never seen a standalone player that does this.

It's not all about what the player (and in fact other desktop
software) do automatically. It's also what is possible to be displays
on the UI.

>> One such application is indeed the parsing of WebVTT
>> files and encapsulation into media files such as WebM and MPEG. There
>> is already a spec for parsing such metadata and putting it into WebM
>> files right now. We don't want there to be a different and competing
>> one for MPEG.
>> In fact, this needs to be resolved soon so the WebM and MPEG
>> encapsulation specs can go forward.
> I'll have to read up on the WebM metadata thread soon, because I don't see
> why it would be dependent on the format WebVTT uses.

It's here: http://wiki.webmproject.org/webm-metadata/temporal-metadata/webvtt-in-webm
The value of the @kind attribute is included in the CodecID; metadata
is stored in CodecPrivate etc.
It's very important to take care of the metadata during encapsulation.

Received on Thursday, 23 February 2012 11:08:38 UTC

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