- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 12 Jan 2012 13:31:16 -0500
On 1/12/12 12:46 PM, Francis Boumphrey wrote: > and as far as I can see there is no way for me as an author to > know that the video is not being played If true, this should be simple to fix. But I would think that there was a way to detect this via the readyState or error properties. In particular, if the error.code is MEDIA_ERR_SRC_NOT_SUPPORTED that would seem to be a strong indication that the format could not be played, right? > Even here I have a problem. In which order does the user-agent check the > source files (in Chrome it seems to be in the order in which they are > written, but there is no guidance here in the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-media-load-algorithm step 3 says: Otherwise, if the media element does not have a src attribute but has a source element child, then let mode be children and let candidate be the first such source element child in tree order. and same section starting at "Otherwise, the source elements will be used; run these substeps:" explicitly talks about trying the <source> elements in document order. So what Chrome is doing is exactly what the spec requires. > Also will my user agent down-load the file that it cannot play, thus using > up band-width? That's up to the to some extent UA, but I'd think that if you list a type="whatever" and the UA doesn't support the type, any sane UA would skip the download. Specifically, see substep 5 of the "run these substeps" section mentioned above: 5. If candidate has a type attribute whose value, when parsed as a MIME type (including any codecs described by the codecs parameter, for types that define that parameter), represents a type that the user agent knows it cannot render, then end the synchronous section, and jump down to the failed step below. So the only way for a UA to not skip the <source> is if it doesn't know it can't render the type. -Boris
Received on Thursday, 12 January 2012 10:31:16 UTC