[whatwg] HTML5 video element - default to fallback in cases where UA can't play format
Philip Jägenstedt
philipj at opera.com
Thu Dec 3 05:13:50 PST 2009
On Thu, 03 Dec 2009 03:31:27 +0100, Kit Grose <kit at iqmultimedia.com.au>
wrote:
> On 28/10/2009, at 1:10 PM, Aryeh Gregor wrote:
>
>> On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose <kit at iqmultimedia.com.au>
>> wrote:
>>> Can I get some sort of an understanding on why this behaviour (non-
>>> descript error in supported UAs rather than using the fallback content
>>> that can provide alternate access methods) would be preferred?
>>
>> Suppose browsers fell back to the contents if they couldn't play any
>> of the sources. Then what happens if the browser isn't sure whether
>> it can play a video until it's started loading it? This would be
>> extremely common -- it would happen any time the source is given with
>> src="", or if <source> elements are given with no type="", or even if
>> there was a type="" but the browser wasn't sure it supported the exact
>> versions or didn't fully trust the author or whatnot. Then does the
>> browser not load the contents until it figures out it can't play the
>> video, then load the contents at some undefined later time? So
>> scripts execute out of order and so on?
>
> Sorry to resurrect an old thread but I was using my iPhone and had an
> extra couple of questions about this I was hoping people might be able
> to answer for me.
>
> The iPhone (and other similar devices) are restricted to certain file
> formats and even bitrates/image sizes. When the iPhone encounters our
> <video> element, I can supply a non-compatible video (still in an MP4
> container) and the iPhone knows to mark the video in place as
> non-playable. If I whack in a compatible H.264 video, the video is shown
> as playable.
>
> Can someone explain to me how this works, given Aryeh's response above?
> Surely if the iPhone can determine its capacity to be able to play a
> video file, other UAs could do likewise and fall back on the content
> accordingly as UAs with zero <video> support do?
I know nothing about the iPhone, but any UA can know if it can play a
resource or not simply by trying and adjusting the UI as appropriate. One
*could* use the same hooks to display fallback content in those cases, but
it is a very bad idea. Apart from the things Aryeh mention, because of how
the resource selection algorithm works, you can never know if there will
be a playable resource later, so there's no point where it's appropriate
to show the fallback content. The only remaining option is flip-flopping
between replaced content (video) and fallback content, which don't want
(especially considering that the fallback content is likely to contain
<object> for Flash or some other legacy fallback).
--
Philip Jägenstedt
Core Developer
Opera Software
More information about the whatwg
mailing list