[whatwg] <track> / WebVTT issues

[Ralph Giles]

On 21/09/11 02:15 AM, Philip Jägenstedt wrote:
> Implementors of <track> / WebVTT from several browser vendors (Opera,
> Mozilla, Google, Apple) met at the Open Video Conference recently. There
> was a session on video accessibility,[1] a bunch of new bugs were filed
> [2] and there was much rejoicing.
>
> There were a few issues that weren't concrete enough to file bugs on,
> but which I think are still worthwhile discussing further:
>
> == Comments ==
>
> If you look at the source of the spec, you'll find comments as a v2
> feature request:
>
> COMMENT -->
> this is a comment, bla bla

I don't like the format either. I do think it's very important we have 
some mechanism for multi-line file level metadata, embedded css, etc. so 
the files can live on their own.

The syntax section also suggests all metadata has to be on the signature 
line, while the parser will actually skip everything between the 
signature and the first double line terminator.

For in-caption, <! comment> is a good idea. Semantically it's a bit 
weird to not mention it in the spec, since everything else has an end 
tag, but the parser will ignore it as we want.


> The parser is fairly strict in some regards:
>
> * must use exactly 2 digits for minutes and seconds
> * minutes and seconds must be <60

I'm not normally one for restrictions, but parser also says the 
(optional) hours field must have "two or more" digits, with no maximum 
value specified.

If we all agree on an implementation limit, it could be helpful to 
specify one. Storing milliseconds in a 32 bit type gives a little over 
1000 hours of timestamps. Single-precision float runs out of useful 
precision after about 50 hours. I'd suggest a two or three digit limit 
on hours to avoid requiring a 64 bit type. If we don't care about that,
then 10 digits is a reasonable limit to avoid running out of precision 
with doubles.

> A small percentage of cues (or cue text) will be dropped because of
> these constraints and this is not very likely to be noticed unless the
> entire video+captions are watched.

This is a very good point.

> 02:00.000 --> next
> Last Chapter
>
> Cues would be created with endTime = Infinity, and be modified to the
> startTime of the following cue (in source order) if there is a following
> cue. This would IMO be quite neat, but is the use case strong enough?

This would also nicely solve the latency issue with generating live 
captions. With both use cases together, I'd be in favour of this, but we 
have other issues to address before live VTT streams work in the <track> 
element. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=14104

  -r