Re: metadata in the VTT file header

(reordered)

On Thu, Dec 22, 2011 at 1:18 PM, David Singer <singer@apple.com> wrote:

> Do we have proposals, or are we at the use-case and data-collection stage?
>

Ian on single-line file-level metadata:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-December/034026.html("File-level
would ...").  For single-line metadata, this seems
straightforward and obvious.

Another couple use cases:

Specifying default cue settings;
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029859.html
Specifying a class to apply to all cues is probably useful, too.

Specifying inline stylesheets.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/031916.html(search
for "STYLE-->").

We probably need to put in the file header some meta-data, that could be
> used for (for example)
> * if the VTT file is used by a 'media player' outside a web context
> * when the file is going to be, but not yet, embedded in a web context,
> information that will be needed to do that embedding right
>
> These categories probably overlap.  I'm thinking of examples like
> -- "looks better if these style-sheets are used"
> -- "has an overall language of en-US"
> -- "is intended for this 'kind' in HTML"
> -- "when used with the expected mpeg-2 transport stream, <this> VTT
> timestamp is (maps to) <that> MPEG-2 clock reference"
>

Hmm.  A lot of metadata is mirroring the information stored in <video> in
HTML.  Not all; the stylesheet use case, and the two I mentioned above,
probably wouldn't belong in <video>, but there's a lot of overlap.

The underlying reason for considering this duplication seems to be that
browsers want access to the metadata without having to load every .VTT
track in advance, while standalone players may not be loading video from an
HTML file in the first place.

Duplicating lots of metadata seems like an uncomfortable way forward.
It'll create more and more redundancy, more room for user error and stuff
to keep in sync, etc.  One or the other metadata would end up omitted
frequently: if providing it in the HTML works for the author's environment,
he won't know to supply it in the .VTT as well, resulting in content that
doesn't work in environments that actually need it.

I don't have an alternate solution right now--one which still allows UAs to
show information about subtitle tracks without loading dozens of external
VTT resources first--but it's worth thinking about.  This is hard to think
about concretely right now, since nobody has really talked about what the
standalone-player case and data will actually look like.  (Embedded in .MKV
files, as is normally done with .SSA and .SRT?  I doubt .VTT will gain
traction with communities currently using those formats if videos have to
be distributed as a bunch of loose .WEBM, .VTT and .CSS files.)

(If anyone's given serious thought to the standalone case, I'd be
interested in hearing about it in a separate thread.)

-- 
Glenn Maynard