[whatwg] Scripted querying of <video> capabilities

[Philip Jägenstedt]

I'm also a bit concerned about how to interpret the yes, no and maybe
return values. The truthful answer is going to be "maybe" for all but
the obviously unsupport (application/x-ms-dos-executable) and the more
trivial formats (audio/wav).

When asking about application/ogg, this could mean 2 things:

1. "can I demux Ogg"
2. "can I demux Ogg and decode an unknown codec"

If to answer yes the browser must be certain that it can play back all
content which could have the requested mime type then the answer must
always be "maybe" for container formats, e.g. "video/avi",
"video/x-msvideo", "application/ogg", "video/mp4", "video/mpeg" and so
on. Only if the codecs parameter is used is it ever possible to anwer
"yes"

It's hardly ever possible to answer "no" either, unless the underlying
media framework explicitly doesn't support a  When faced with something
unrecognized the safest thing is to say "maybe".

To sum up, the answer is always "maybe". This is nice for implementors
who don't need to write a lot of code, but it's not useful.

To fix this, I would suggest the following:

If the mime type is just a container format then the browser may answer
"yes" if it knows that it supports at least some content in that format
(again, it's difficult without 

On Thu, 2008-11-13 at 10:52 -0800, Jeremy Doig wrote:
> did this thread go anywhere ?
> i'm concerned about the "maybe" case - looks way too much like:
> http://en.wikipedia.org/wiki/DShow#Codec_hell
> 
> 
> also - when you probe for mime type, do you mean the entire "type"
> parameter (including the codecs string) ? for example, there are too
> many cases where just passing "video/mp4" would be insufficient.
> (fragmented index support ? base/main/high profile ? paff ? cabac ?)
> <source src="video.mp4" type="video/mp4; codecs="avc1.42E01E, mp4a.40.2"">
> 
> On Wed, Oct 15, 2008 at 11:14 PM, Maciej Stachowiak <mjs at apple.com>
> wrote:
>         
>         On Oct 15, 2008, at 1:44 AM, Ian Hickson wrote:
>         
>                 
>                 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.
>         
>         
>         This API would be tempting to treat as a boolean but would of
>         course do completely the wrong thing. I think it would be
>         better to either ensure that the positive and neutral
>         responses are both values that JS would treat as true (for
>         instance make the values true, "maybe" and false), or else
>         make all of the return values something self-descriptive and
>         symbolic (for instance the strings "yes", "maybe" and "no"). I
>         think 1, 0, -1 are neither clear nor likely to be in any way
>         beneficial for perforamnce.
>         
>         Regards,
>         Maciej
>         
> 
> 
-- 
Philip Jägenstedt
Opera Software