W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > September 2011

[Bug 14104] Video: Streaming text support in track element

From: <bugzilla@jessica.w3.org>
Date: Mon, 19 Sep 2011 22:44:11 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1R5mZP-0005L7-8g@jessica.w3.org>

--- Comment #8 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-09-19 22:44:09 UTC ---
Without a better understanding of how this is intended to work, I don't know
how to fix this.

Starting to play a video before the cues have all been received seems like a
bad idea in the general case, since the cues might be out of order, there might
be an arbitrarily large number of cues at the very first frame of video, etc.
In fact, WEBVTT simply isn't set up to handle streaming — given a situation
where the UA has received the first 5 minutes of video and has received 5MB of
cues including one at 4 minutes and 55 seconds, even if the cues were assumed
to be ordered, there'd be no way to know whether all the cues had been received
yet or not. If they had not, you'd want to pause or you'd miss cues (possibly
_all_ the cues, if the cue stream is just a few seconds behind where the video
stream is at, and the user never pauses to let it catch up).

The timing issue is also pretty serious. Since a streaming video can be joined
at an arbitrary time, and that time is considered t=0 unless the stream has
explicit timestamps (a pretty advanced feature as far as I can tell — does
anyone support this and have a video that they can demonstrate it with?),
there's simply no way that I can see for the system to know what times to use
in the cues except for the server to somehow recognise which video stream was
associated with which user — and then for the system to handle restarts. This
is especially problematic as presumably you wouldn't want unique timings for
each user anyway.

WebVTT was designed for static resources, where the users creating the
subtitles are as likely as not to be independent of the users creating the
videos. For dynamic streams with captions, it seems highly unlikely that you'd
have anyone doing the captions other than someone directly affiliated with the
original stream, and in that case you really should just have the stream itself
contain the titles. As far as I can tell that would solve all these problems

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 19 September 2011 22:44:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:03 UTC