- From: <bugzilla@jessica.w3.org>
- Date: Wed, 28 May 2014 13:59:27 +0000
- To: public-texttracks@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25910
Bug ID: 25910
Summary: [WebVTT] A way to correct cues
Product: TextTracks CG
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: WebVTT
Assignee: dave.null@w3.org
Reporter: self@brendanlong.com
QA Contact: public-texttracks@w3.org
CC: philipj@opera.com, silviapfeiffer1@gmail.com
*Why*
In streaming text tracks, we need a way to fix incorrect cues. Some
examples:
* In live TV, people type the captions in by hand
<http://en.wikipedia.org/wiki/Closed_captioning#Television_and_video>
shortly
before you see them. If they make a mistake, we need a way to fix it.
* CEA-608 and CEA-708 captions don't start with a convenient startTime
--> endTime block like WebVTT does. A caption ends when we get a
command that makes it stop displaying. If we want to transcode to
WebVTT in real-time, we have to either wait until the caption is
over to translate it (delaying the stream by some arbitary time in
the hope that it will be long enough), or we need to start a caption
immediately with a guess of the end time and then rewrite it once we
know the correct end time (or rewrite it to extend the end time
until we find the correct one).
*How*
The solution I'm proposing is that if we see two cues with the same id,
the earlier cue will be removed.
some-id
00:00:00 --> 00:00:30
This is an xeample
some-id
00:00:00 --> 00:00:10
This is an example
In this example, the text "This is an example" will be displayed for 10
seconds starting at time 0.
*Why This Solution*
This solution is nice because the syntax is simple and easy to
understand, and it's powerful enough to rewrite any cue in any way you
could possibly want, because the new cue completely replaces the old one.
*Arguments against*
This isn't particularly efficient. If you just want to change the time,
you need to send the entire updated cue, instead of just the change.
I don't think this is a big deal, because even the most heavily edited
subtitle file will be orders of magnitude smaller than the accompanying
video.
See:
http://lists.w3.org/Archives/Public/public-html/2014May/0020.html
I originally proposed doing this in HTML, but Philip convinced me that that's
not a good idea. Having the WebVTT parser should be easy though.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 28 May 2014 13:59:33 UTC