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

On Thu, Sep 13, 2012 at 1:46 PM, Dave Singer <singer@apple.com> wrote:
>
> 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:
>>
>> WEBVTT
>> language: fr
>> kind: subtitles
>>
>> STYLE
>> #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
>
> header
> cue
> cue
> style
> cue
> cue
>
> 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.


Let them do it - as those styles inserted at a later stage have no
effect and are dropped on the floor as invalid cues, I don't really
see a problem with it.

I agree with you that we don't want to allow any of this header data
anywhere else. In a validator they would be raised as invalid.

I'd like to get to a stage where we can properly define a proper header.

Cheers,
Silvia.

Received on Thursday, 13 September 2012 04:35:06 UTC