Re: [RFC] WebM temporal metadata

On Tue, Apr 10, 2012 at 2:11 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Mon, Apr 9, 2012 at 10:22 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> wrote:
>>
>> I think we are all pretty much agreed that the browser should in
>> principle ignore all headers.
>
>
> I disagree.  It makes sense to have a copy of the <track> metadata, which
> implementations would use.  That allows WebVTT files to be applied to video
> files without an encloding HTML wrapper.  (Video players often load
> .SRT/.SSA files if they're next to a video file in a directory and have a
> similar filename, but they usually show up as "language: unknown".  This
> would be worse with VTT, since it wouldn't be able to detect the data kind.)
>
> It also gives muxers a source for that metadata, so it's easier to create
> eg. WebM files with that data embedded.  (Having to manually tell muxers
> what the contents of caption files are because the files don't have this
> sort of metadata is awful.)

Hmm, actually, I agree.

Well, then we should properly parse the metadata and the browser
actually needs to do something with it. This would include style
sheets, and @kind, @srclang settings etc. Similar to how cascading
style sheets work, we should probably make the settings in the WebVTT
file header the default setting for the <track>, which is overridden
by any settings that the Web page author provides in the <track>
element's attributes and the Web page's CSS.

This will actually make it easier, since we don't have to distinguish
between things that the browser needs to interpret and things it can
ignore.


> This means we need to think about namespacing, too, so future standardized
> headers can be less likely to clash with user headers.

Not sure about explicit namespacing, but we definitely need to define
a standard set of names that WebVTT supports.

> Making everyone
> prefix their custom attributes, like "data-*" attributes is ugly (which
> means many people won't do it), so maybe the standardized fields should look
> like:
>
> VTTKind: subtitles
> VTTLanguage: en
> VTTSourceLanguage: zh_CN
> VTTLabel: English
>
> with headers not prefixed with "VTT" being user-defined.  That makes these
> headers ugly, though, which is a bit annoying since every VTT file should
> have them.

VTTDefaultCueSetting:
VTTDefaultStyles:
VTTDataFormat:
VTTDataHint:

While ugly, it is also very obvious what is standard and people can
come up with any other stuff without fear of clashing. OTOH if a
user-created name becomes widely used, we can't just provide support
for it as it is, but instead have to introduce a relacement name with
the prefix. Is there any way to win this?

>> Therefore, I would propose introduction of an interface function to
>> the TextTrack object [1] that provides the list of headers:
>> DOMString getHeader();
>> In this case, the JS programmer can parse the text into a list of
>> name-value pairs and determine what to do with it.
>>
>> Alternatively, this could be improved through introducing a
>> TextTrackHeader object which is a list of name-value pairs.
>
>
> I'd prefer a proper API like this over than something I have to pick apart
> by hand.  The cookie DOM API is one of the ugly bits of the platform; let's
> not repeat that.
>
> If we don't care about allow duplicates or preserving order, it could just
> return a dictionary:
>
> { VTTKind: "subtitles", VTTLanguage: "en", VTTSourceLanguage: "zh_CN",
> VTTLabel: "English" }
>
> which is about as convenient as JS APIs get.

Fine by me. I like this.

Cheers,
Silvia.

Received on Tuesday, 10 April 2012 04:27:46 UTC