Re: Support for advanced caption features (inc rollup)

On 12-12-04 2:42 PM, Ian Hickson wrote:

> Given that neither <video> nor WebVTT support real-time captioning, this 
> is kind of moot in a discussion of WebVTT and <video>.

WebRTC video playback happens through a <video> element. There is no
explicit text track in WebRTC (yet!) but one could send real-time text
over a DataChannel and call addCue() with it when it arrives. Is this
not real-time captioning with <video>?

Citing WebVTT limitations is a bit circular. We've never had concensus
for live-streaming support in WebVTT, which is imposes very similar
contraints to real-time updates, despite past proposals. This isn't a
new use-case.

I'm sympathetic to not baking in legacy complexity from TV standards,
but I don't think this is a good argument against region.

> (Note that instant messaging isn't "roll-up", by the way. It's line-at-a- 
> time, and as a near non-stop user of this medium, I'm pretty confident in 
> saying that that is fine.)

As I recall, the one trouble we had with defining live streaming is that
WebVTT cues include their own duration, so one needs either to be able
to update the previous caption, or to send with some default duration
and have client-side roll-up and expiry take care of accumulation when
multiple cues are active simultaneously. That doesn't seem like a
different contraint from CC-style word-at-a-time updates.

What saves you with instant messaging is that you're looking only at the
start time with a 'transcript' style layout, or a system notification
with its own timeout--both of which effectively handle accumulation for
you. Or am I misunderstanding your example?

Of course, if you're calling addCue() with data from an XHR or
DataChannel, you could also handle the roll-up manually.

 -r

Received on Wednesday, 5 December 2012 19:44:39 UTC