- From: Jeremy Doig <jeremydo@google.com>
- Date: Thu, 13 Nov 2008 10:52:43 -0800
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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081113/8079096c/attachment.htm>
Received on Thursday, 13 November 2008 10:52:43 UTC