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

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

From: <bugzilla@jessica.w3.org>
Date: Mon, 28 Nov 2011 23:56:55 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RVB4B-0002pR-A6@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14104

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|NEEDSINFO                   |
            Summary|Video: Streaming text       |<track> Video: Streaming
                   |support in <track> element  |text support in <track>
                   |                            |element

--- Comment #21 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-11-28 23:56:52 UTC ---
For those live streams, the video seems to include an internal time, which the
captions presumably use as well. So that's rather different than what you were
proposing.

For that kind of case, what we'd really want is not a static file to download,
it would be a stream. You'd want to tell the server around when to start
(presumably automatically), and you'd want to update the cues in real time,
presumably throwing cues away that are before the earliest start time.

That doesn't seem too unreasonable.

To support things like inline live corrections, though, we'd probably want a
different format than WebVTT, or at least some variant on it. e.g.:

--------------8<--------------
WEBVTT

00:00.000 --> 00:05.000
captions that were available before the user connected

01:00:00.000 --> 01:02:00.000
bla bla bla

LIVE--> align:middle rollup-size:3
<01:03:11.004> Bla bla <01:03:11.353> bla <rollup> <01:03:11.653> bal
<01:03:11.710> <redoline> bla <01:03:12.004> bla bla...
-------------->8--------------

...where in a LIVE block, timestamps indicate when the following text should
appear, <rollup> indicates when to go to the next line, <redoline> indicates
that the current line should be deleted in favour of new text... This is just a
strawman, I don't know what the right solution is here.

In particular, what should happen if you seek backwards to a point between when
a line was rolled up and a correction was made? Should we show the incorrect
text, or should the incorrect text be dropped in favour of the new text? When
should the new text appear, should it appear at the time of the incorrect text?
How should corrections be made? Should anything be allowed after a LIVE block,
or is a LIVE block forcibly the last block of a file?

-- 
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, 28 November 2011 23:57:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 28 November 2011 23:57:02 GMT