- From: <bugzilla@jessica.w3.org>
- Date: Fri, 29 Jun 2012 04:46:07 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14104 --- Comment #39 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2012-06-29 04:46:16 UTC --- (In reply to comment #38) > I had assumed that live subtitling would necessarily need to include support > for live subtitling correction. If this is not the case, that changes the > design space substantially. It is not the case. It's a feature that we may introduce at a later stage, but not one I've seen used anywhere on the Web in live streamed captions. > If anything, it makes the issue in comment 25 more > critical, since we can no longer show the cues incrementally but need to know > when we have the whole cue and when we're missing the next cue. The video continues to provide the timeline, of course. The browser can only do best effort. If there is a cue that has to be displayed at a certain time, because the video's time has reached it, but the cue has not been received yet by the browser because the latency on the subtitle stream is higher than on the video stream, then it can't be displayed (the browser wouldn't even know it existed). However, video requires more bandwidth than text tracks in general, so I don't see this problem occuring frequently. > I don't understand what you mean about reloading the WebVTT file. Surely the > only sane way to do live streaming is to stream. I don't understand what you mean about "to stream" it. Streaming is defined for audio and video as consecutively loading byte ranges. Are you implying that this also applies to text files? And that therefore this use case is already covered? -- 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, 29 June 2012 04:46:18 UTC