[whatwg] Reworking the media load() algorithm so that it tries more than one video

[Philip Jägenstedt]

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
intentional.

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.

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
happen? In other words, the word "corrupted" ought to be "unrecognized",
"not decodable" or something which doesn't imply that the media resource
itself is at fault.

Philip

On Fri, 2008-11-14 at 06:51 +0000, Ian Hickson wrote:
> On Thu, 16 Oct 2008, Robert O'Callahan wrote:
> > >
> > > I am proposing changing the spec to make the load() not select a 
> > > resource. Instead, load() would immediately return, and the user agent 
> > > would then asynchronously try each resource that it might otherwise 
> > > use in turn, firing a single loadstart event at the start, lots of 
> > > progress events, and then a loadedmetadata or error event depending on 
> > > how things go.
> > 
> > That sounds good.
> 
> I've now done this. This is a pretty big change. I'm sure I've screwed 
> something up in the process.
> 
> Implementors! Please let me know if you see anything newly broken with 
> loading resources! Thanks. :-)
> 
> Cheers,
-- 
Philip Jägenstedt
Opera Software