24709 2014-02-18 08:50:48 +0000 WebVTT: make "region" definitions like NOTE s 2015-11-05 12:56:10 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified PC All RESOLVED MOVED v1 P2 normal --- 1 silviapfeiffer1 dave.null eric.carlson lorettaguarino philipj silviapfeiffer1 singer zcorpan public-texttracks oldest_to_newest 100794 0 silviapfeiffer1 2014-02-18 08:50:48 +0000 Moving region definitions out of the WebVTT header into the "body" could allow us to redefine existing regions (as is necessary sometimes for CEA708) and define new regions dynamically during the cause of the file (as is necessary sometimes with live streaming). 100810 1 singer 2014-02-18 18:16:10 +0000 But of course that's one reason it's defined like it is...exactly so that there are no 'surprises' in the middle of the stream. We need to find a balance here. 100834 2 silviapfeiffer1 2014-02-19 01:25:32 +0000 What "surprises" are you concerned about? It's common for CEA708 captions that a block of captions moves to a different location. We can't do that without the ability to change a region definition. Their timing would need to be attributed to the next cue. 100865 3 philipj 2014-02-19 10:07:40 +0000 I rather strongly support changing the syntax to be NOTE-like, but that's not enough for changing regions dynamically -- that would require attaching timing information as well. Is that really common enough that it needs to have a declarative solution? 100937 4 singer 2014-02-20 01:19:03 +0000 Actually a much better reason not to do this is random access. At the moment, you can chunk up or random, access a VTT file using its header only as the initialization. Once you introduce a state setting that persists, this is no longer possible, and you have to scan all the time from the beginning to know the current state at any time. Say, for example, we do HTTP-chucnked streaming, and the content owner promises the (fairly simple) "no cue has a time span the crosses a chunk boundary". I can now random access given the header info, and then the chunk that spans the time I want to start at. Introduce mutable regions and we either have to ban them in this case, or the file author has to replicate them at the front of every chunk, or other hacky things... 100940 5 silviapfeiffer1 2014-02-20 02:49:39 +0000 (In reply to David Singer from comment #4) > Actually a much better reason not to do this is random access. At the > moment, you can chunk up or random, access a VTT file using its header only > as the initialization. Once you introduce a state setting that persists, > this is no longer possible, and you have to scan all the time from the > beginning to know the current state at any time. > > Say, for example, we do HTTP-chucnked streaming, and the content owner > promises the (fairly simple) "no cue has a time span the crosses a chunk > boundary". I can now random access given the header info, and then the > chunk that spans the time I want to start at. Introduce mutable regions and > we either have to ban them in this case, or the file author has to replicate > them at the front of every chunk, or other hacky things... We discussed that at FOMS and it seemed that this case can be addressed by adding the currently active region definitions to every chunck. Since the chunks are normally created by tools, that should not cause any extra trouble. Right now, the regions have to be made available anyway and I was told that HLS was going to copy the region definitions into every chunk anyway. So, there's not really any extra overhead for this. 100976 6 singer 2014-02-20 18:22:10 +0000 If the tool is willing to replicate the header info into every chunk, and is willing to make sure that the chunk boundaries don't intersect a cue duration, then each chunk can as easily be a separate VTT file; and it's then clear what's happening (that the chunks stand alone, since that is a characteristic of VTT). If I can add the 'header info' I can also add the WebVTT line. 101077 7 silviapfeiffer1 2014-02-21 00:22:48 +0000 (In reply to David Singer from comment #6) > If the tool is willing to replicate the header info into every chunk, and is > willing to make sure that the chunk boundaries don't intersect a cue > duration, then each chunk can as easily be a separate VTT file; and it's > then clear what's happening (that the chunks stand alone, since that is a > characteristic of VTT). > > If I can add the 'header info' I can also add the WebVTT line. IIUC that's already how HLS is dealing with WebVTT. For example, see these: * the M2U8 file http://cdnbakmi.kaltura.com/api_v3/index.php/service/caption_captionasset/action/serveWebVTT/captionAssetId/0_ucxlurda/a.m3u8 * the referenced 1.vtt file http://cdnbakmi.kaltura.com/api_v3/index.php/service/caption_captionasset/action/serveWebVTT/captionAssetId/0_ucxlurda/segmentIndex/1.vtt * the referenced 2.vtt file http://cdnbakmi.kaltura.com/api_v3/index.php/service/caption_captionasset/action/serveWebVTT/captionAssetId/0_ucxlurda/segmentIndex/2.vtt 124088 8 zcorpan 2015-11-05 12:56:10 +0000 https://github.com/w3c/webvtt/issues/231 As far as I can tell from the discussion, having region definitions mixed with cues doesn't help streaming compared to using separate VTT files when region definitions change in a stream, so that aspect is WORKSFORME but we still want to change the syntax.