- From: David Singer <singer@apple.com>
- Date: Wed, 21 Oct 2015 15:00:10 +0200
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: Cyril Concolato <cyril.concolato@telecom-paristech.fr>, "public-texttracks@w3.org" <public-texttracks@w3.org>
> On Oct 21, 2015, at 14:36 , Philip Jägenstedt <philipj@opera.com> wrote: > > On Wed, Oct 21, 2015 at 2:17 PM, David Singer <singer@apple.com> wrote: >> >> Yes, the static transcoding case is easier. It is, alas, not the only one. > > What we are talking about is the conformance requirements of > standalone WebVTT files and what the WebVTT parser will do if > encountering style blocks after a cue. No, I think I must disagree. Is such a restriction written anywhere (that files cannot be incrementally produced)? You might argue that the incremental production case isn’t specifically included either, but I think we live in a world with more english than german rules :-) <https://en.wikipedia.org/wiki/Everything_which_is_not_forbidden_is_allowed#National_traditions> > In this context, static > resources really is all that exists, as live captioning with > <track>+WebVTT [1] hasn't been spec'd. If there are other contexts > that use the WebVTT syntax and parser in a streaming mode, then that > would be interesting to know. AFAICT, it would only be a situation > like that where there could be a problem, and if it's only a > hypothetical at this point I don't think that should affect how WebVTT > works in the context of <track>. No, it’s not hypothetical. DASH/MP4/VTT relies on this, and it was (and is) seen as a core advantage of VTT over TTML. David Singer Manager, Software Standards, Apple Inc.
Received on Wednesday, 21 October 2015 13:00:44 UTC