On Wed, Oct 21, 2015 at 7:00 AM, David Singer <singer@apple.com> wrote: > > > 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. > And now that we have ISD in TTML2, we no longer have that problem (if one chooses to stream ISD instances, each of which contains only the minimal style and other header data required to process that ISD instance). > > David Singer > Manager, Software Standards, Apple Inc. > > >
Received on Wednesday, 21 October 2015 17:54:40 UTC