- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 4 Mar 2011 08:06:41 +1100
- To: Eric Carlson <eric.carlson@apple.com>
- Cc: Sean Hayes <Sean.Hayes@microsoft.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On 04/03/2011, at 3:29 AM, Eric Carlson <eric.carlson@apple.com> wrote: > > On Mar 2, 2011, at 4:17 PM, Silvia Pfeiffer wrote: > >> >> On Thu, Mar 3, 2011 at 4:44 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote: >> >>> Q1: Should the loaded event be delayed until after the text parser has completed? >> >> What is "completed"? There is no notion of "these are all the cues >> available" for a live stream, so the notion of "complete" has >> deliberately been avoided IIUC. >> > I don't think the spec supports cues in a live streams because a media element's readyState can not reach HAVE_METADATA until all non-disabled text tracks are "ready", which is defined as "have a text track readiness state of loaded or failed to load". To me this means that a cue file that doesn't loads completely will make a video unplayable. > > eric This depends on the definition of "loaded". If "loaded" means: the decoding pipeline has been set up for this track, then we can start decoding as soon as we have the first few bytes of that track - or maybe the first cue. I'd find it shocking if we have to wait until all cues have been read in before being able to decode video data. In synchronously multiplexed files like Ogg that would mean waiting until the complete file was received. Silvia.
Received on Thursday, 3 March 2011 21:07:26 UTC