- From: <bugzilla@jessica.w3.org>
- Date: Fri, 20 Apr 2012 01:26:53 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14104 --- Comment #37 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2012-04-20 01:26:51 UTC --- I'd actually prefer if we didn't get side tracked in this bug with introducing markup for editing cues. I don't actually think there is a big requirement for editing on the Web, since for live captioning & streaming we can delay the transmission to make sure the captioner has finished fixing their transcript. What I was trying to focus on in this bug was not the WebVTT markup, but the problem that WebVTT files may get changed while the video is playing back and that this is a legal use case for live streaming and that in this case the browser needs to reload the WebVTT file frequently. The problems that Philip lists can be addressed: #1 would make use of the startDate together with the currentTime to know when to display cues #2 every time the WebVTT file has been loaded, the browser returns to HAVE_METADATA - it doesn't need to wait In fact, the server could be clever and provide to newly connected clients just the cues that relate to the part of the video that they are currently looking at. Though in this case it's almost identical to loading the captions via JS. What the browser still doesn't know is when it has to reload the WebVTT file. That's why I suggested a @live attribute which would cause the browser to frequently reload the WebVTT file. I can see three different ways to trigger a reload: * whenever the browser runs out of cues for a video (in fact, this could likely be useful in general) * when a startDate is given on the video and the browser runs out of cues * when a @live attribute is given on the video and the browser runs out of cues Also, we'd need to limit the number of reload tries if there are no changes to the WebVTT file. -- Configure bugmail: https://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 Friday, 20 April 2012 01:26:55 UTC