[whatwg] Scripted querying of <video> capabilities
ian at hixie.ch
Fri Nov 14 23:17:31 PST 2008
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.
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
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 ?)
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
> The answer to question 2, on the other hand, is always "no" or "maybe".
> 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.
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.
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg