- 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