[whatwg] Scripted querying of <video> capabilities

[Ian Hickson]

On Thu, 16 Oct 2008, Robert O'Callahan wrote:
> >
> > I have added window.navigator.canPlayType(mimeType). It returns 1, 0, 
> > or -1 to represent positive, neutral, and negative responses.
> 
> navigator.canPlayType could be confusing since authors might think it 
> includes media playable via plugins or other browser functionality. 
> Making it a method on <video>/<audio> would be more obvious and, I 
> think, no less useful in practice.

Ok. Done.


On Thu, 16 Oct 2008, Maciej Stachowiak wrote:
> 
> 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.

I've made the method return strings.


On Fri, 14 Nov 2008, Robert O'Callahan wrote:
> 
> I think it would be a lot better if there were two methods returning 
> booleans, say, "canPlayType" and "cannotPlayType".

I think it would be misleading to return false from cannotPlayType().


On Thu, 13 Nov 2008, 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

Well we have to have a maybe case, since the UA might not know the answer.


> 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 ?)

Clarified this.


On Thu, 13 Nov 2008, Philip Jägenstedt wrote:
> 
> 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 unsupporter (application/x-ms-dos-executable) and the more 
> trivial formats (audio/wav).

Indeed (except for audio/wave).


> When asking about application/ogg, this could mean 2 things:
> 
> 1. "can I demux Ogg streams?"
> 2. "can I demux Ogg streams and decode unknown codecs?"

It's the second (and thus the answer can only ever be "maybe" or "no").


> The answer to question 1 is reasonably simple to answer in most cases, 
> even if the underlying media frame doesn't support querying for mime 
> types a mapping between mime type and supported decoders isn't 
> impossible.
>
> The answer to question 2, on the other hand, is always "no" or "maybe".

Right.


> Unless the codecs parameter is to be made mandatory I think that spec 
> should explicitly make it such that the question asked is 1. In either 
> case we will end up there because 2 is not a meaningful question and 
> user agents will make untruthful answers in attempts to stay compatible 
> with unknown and future content (which might be supported by installing 
> new codecs in the media framework without upgrading the browser).
>
> Now, if the codec parameter is used then the user agent may answer yes 
> and no in a way that actually makes some sense.

The spec now encourages codecs="" be provided.


> I also think that this should be explicitly related to the type 
> attribute of the source element. One should be able to use canPlayType 
> to predict with 100% accuracy which source the user agent will use when 
> it encounters.

Done.


On Fri, 14 Nov 2008, Robert O'Callahan wrote:
> 
> The browser can only answer "no" or "maybe" in this case. That seems 
> fine to me. It lets the author know whether the browser can demux Ogg 
> streams, while staying consistent with the behaviour when codec 
> information is given in the MIME type.
> 
> I don't understand what the incentives are for browsers to lie. If we 
> start off telling the truth, then authors will have to write scripts 
> that either accept "maybe" or, better still, provide the codec 
> information, or their scripts won't work. I don't see how that would 
> change over time.
> 
> Authors should be strongly encouraged to give the codec parameters.

Agreed.


On Thu, 13 Nov 2008, Dave Singer wrote:
>
> Pitching in here, I think it's OK if we want to go to a two-state answer 
> -- but those answers are No and Maybe, not No and Yes.  There are, after 
> all, vanishingly small numbers of mime types where I can be 'completely' 
> (within reason) confident of a 'yes' answer.  On the other hand, given a 
> mime type I simply don't recognize, or a codec I know I don't have, I 
> can be confident of a No.
> 
> Documenting it as providing a No/Maybe indication, and that how positive 
> the 'Maybe' is depends to a large extent on how precise the supplied 
> mime type is, would be fine by me, I think.

I've left it as a three-state method, but encouraged implementors to not 
return a positive answer unless they're sure.

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