[whatwg] HTML5 video element - default to fallback in cases where UA can't play format

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

Received on Thursday, 3 December 2009 05:13:50 UTC