[whatwg] Scripted querying of <video> capabilities

[Ian Hickson]

On Tue, 14 Oct 2008, Robert O'Callahan wrote:
> On Tue, Oct 14, 2008 at 12:13 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> 
> > While the underlying media frameworks can't necessarily answer, "if I 
> > give you a file with this MIME type, can you play it?", they can at 
> > least give a yes/no/maybe answer, which can still be quite helpful, 
> > since the UA will know it does not need to check some media streams at 
> > all.
> 
> I agree. If the API lets us answer "maybe", there is not much need or 
> temptation to lie, and we can still return information that could be 
> useful to scripts.

I have added window.navigator.canPlayType(mimeType). It returns 1, 0, or 
-1 to represent positive, neutral, and negative responses.


On Mon, 13 Oct 2008, Maciej Stachowiak wrote:
> >
> > Also, should we make .load() asynchronous as far as selecting a media 
> > file goes? Right now, a media file has to be instantaneously and 
> > synchronously selected, so the UA can't try each one in turn.
> 
> I believe the original design intent was to make selection completely 
> static and not not based on a fallback-like approach of trying each in 
> turn. Let's assume IE implements <video> at some point but does not 
> support Ogg or MPEG-4 out of the box. Then an author wishing to provide 
> 3 media streams could still likely get the job done, since browsers 
> could likely determine whether or not particular basic content types are 
> supported. It might be hard to get more complex cases right though.

On Tue, 14 Oct 2008, Robert O'Callahan wrote:
>
> IMHO load() should be asynchronous and should try each in turn. That 
> would dramatically increase the power of fallback and doesn't seem to 
> cost too much. Chris Double points out that there are edge cases where 
> some streams in a container are supported, but others aren't; for 
> example a framework might support only Ogg Vorbis but not Theora, and 
> you try to play a Vorbis+Theora file, and you get no error from the 
> framework, but you might have preferred to fall back. However, if the 
> author provided the right MIME information, the UA could know that there 
> is supposed to be video, and detect that there isn't any video coming 
> out, and fall back.

On Tue, 14 Oct 2008, Robert O'Callahan wrote:
> 
> We definitely have to change that! Having load() synchronous would be a 
> disaster.

On Tue, 14 Oct 2008, Eric Carlson wrote:
>
> I agree! A truly synchronous load() will result in a terrible user 
> experience as a UA may need to download a significant amount of data 
> before it knows if a file is playable.

Right now the spec picks a resource *without checking with the server*, 
statically, and then the method returns, and then asynchronously it checks 
to see if the resource is usable.

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.


On Tue, 14 Oct 2008, Dave Singer wrote:
> > 
> > This brings up another point, which is, is the "type" attribute on 
> > <source> actually useful? Should we remove that and just have browsers 
> > probe the video subsystem for each resource? We can always add the 
> > attribute back later if it becomes useful again, but I'd rather not 
> > have something that isn't used by browsers, since then it'll be used 
> > wrong by authors, making it useless forever.
> 
> I think it is.  Without it, the UA would have to open each source and 
> get its type via HTTP content-type, which is a lot slower, wouldn't it?  
> Is it clear that if the type is supplied in the markup, the UA can (and 
> probably will) use it for content selection, at least at the coarse 
> level, thus avoiding opening connections for files it knows (from the 
> type) it cannot support.

If we make the load() asynchronous and allow probing from the client 
(testing each potentially supported resource in turn), should we make the 
type optional, then?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'