[whatwg] Reworking the media load() algorithm so that it tries more than one video
ian at hixie.ch
Sun Nov 16 17:55:16 PST 2008
On Sat, 15 Nov 2008, Philip Jägenstedt wrote:
> The changes look like improvements to me, but I have some questions.
> 1. Is there any particular reason why step 7 "generate the list of
> potential media resources" is done in the synchronous part of the
> algorithm? Would it for example be an error to consider playing sources
> added in a loadstart event handler? As it stands one would have to
> actually make a list of candidate URLS and pixel ratio overrides "up
> front". I don't really object, I just want to confirm that this is
While readyState is NETWORK_EMPTY, setting .src, appending <source>
elements, or inserting a <video> into the document causes the load()
algorithm to be implicitly run. Once readyState is NETWORK_IDLE or
greater, those actions have no effect. So to prevent race conditions, the
list is generated immediately before setting readyState to a value other
> 2. Did you remove canPlayType? It was added in
> http://html5.org/tools/web-apps-tracker?from=2331&to=2332 and now it
> seems to be gone, but I can't find the revision in which that happened.
It's on HTMLMediaElement now.
> 3. MEDIA_ERR_DECODE isn't just for corrupted data. If <source
> type="application/ogg"> is given and the browser doesn't "know it cannot
> render" it but it turns out that it couldn't decode any of the content
> (perhaps it was Ogg FLAC), isn't MEDIA_ERR_DECODE precisely what should
No; now that load() tries multiple streams, that would cause a
I believe you sent this e-mail as I was updating the load() algorithm and
moving canPlayType() around, which is probable the source of your
confusion. I hope this clarifies things. Let me know if you disagree with
the changes that were made!
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg