- From: <bugzilla@jessica.w3.org>
- Date: Sat, 29 Oct 2011 08:56:30 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14104 --- Comment #13 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-10-29 08:56:28 UTC --- (In reply to comment #12) > Could you elaborate on those bullet points? Sure. The @secondsMissed attribute would be an attribute on the media element that says how many seconds ago the stream had started, i.e. what time offset currentTime=0 maps to. Given that the times in the WebVTT file would be relative to that original start time, you can calculate when the cues would need to be presented at by calculating currentTime + secondsMissed as the video's playback time. The reload mechanism on the <track> elements would mean that when the currentSrc resource's last cue has been read and is before the end of the video, while the video continues to load, do a HTTP byte range request for bytes on the currentSrc resource after the end of the file. E.g. if the currentSrc resource is 600KB long, then do a GET request with Range: bytes=600- . This would be repeated while more video is being downloaded and stopped otherwise. The repetition frequency would likely be attached to the request rate of the video. As for the change in WebVTT, the idea is that the following would be legal: WEBVTT 00:00:00.000 --> next This cue lasts until the next cue replaces it, i.e. 5.6 sec. 00:00:05.600 --> next Same here, i.e. 4.4 sec. 00:00:10.000 --> next If none follows, the cue lasts until the end of the video. These three together would allow for live captioning through streaming text. -- 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 Saturday, 29 October 2011 08:56:36 UTC