<div class="gmail_quote">On Mon, Jul 27, 2009 at 3:48 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch" target="_blank">ian@hixie.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Fri, 10 Jul 2009, Aryeh Gregor wrote:<br>
> On Fri, Jul 10, 2009 at 4:57 AM, Robert O'Callahan<<a href="mailto:robert@ocallahan.org" target="_blank">robert@ocallahan.org</a>> wrote:<br>
> > The way we've implemented in Firefox, we'll return "yes" if you<br>
> > specify a codecs parameter and we support every codec in your list. So<br>
> > v.canPlayType("video/ogg; codecs=vorbis,theora") returns "probably" in<br>
> > Firefox 3.5. I think this is reasonable because I believe that, modulo<br>
> > bugs in our implementation, we support the full Theora and Vorbis<br>
> > specs. On the other hand, we will return "maybe" for<br>
> > v.canPlayType("video/ogg"). I think this distinction will be useful.<br>
><br>
> In what use-case would an author want to make use of the distinction? In<br>
> either case, your only course of action is to try playing the video.<br>
</div><div>> Maybe you'd try testing all the video types you support, and if one is<br>
</div>> "maybe" while another is "probably" you'd go with "probably"? That<br>
<div>> seems like a pretty marginal use case to help for the sake of such a<br>
</div>> confusing API. Programmers expect binary logic, not ternary (look at<br>
<div>> the complaints about SQL's NULL).<br>
<br>
</div>The main use case is ordering. If you have ten variants, you might want to<br>
try the "probably"s before the "maybe"s, especially if there are a lot of<br>
weird codecs involved, such that the "maybe"s might be able to play<br>
somewhat, just not as well as the "probably"s.<br>
<div><br>
<br>
On Fri, 10 Jul 2009, Philip Jagenstedt wrote:<br>
><br>
> I agree that the current interface is ugly and quite fail to see what the<br>
> use for it is. With a boolean return value, canPlayType("application/ogg")<br>
> would return true if one can demux Ogg streams.<br>
> canPlayType("application/ogg; codecs=vorbis,dirac") would return true if<br>
> one can demux Ogg and decode vorbis + dirac.<br>
<br>
</div>What would "canPlayType("video/ogg; codecs=vorbis")" return? There's not<br>
enough information there to say whether or not you can play a stream<br>
labeled that way.<br>
<div><br>
<br>
> Unless there's some compelling use case that can't be handled with the<br>
> above I'd support canPlayType returning a boolean. The only issue I can<br>
> see is that canPlayType(foo)==true might be interpreted as a strong<br>
> promise of playability which can't be given. In that case just rename<br>
> the function to wouldTryTypeInResourceSelection (no, not really).<br>
<br>
</div>You can use the method as it is now as a boolean method, in practice.<br>
However, I think there is value in being explicit that a "true" return<br>
value isn't really necessarily confident.<br>
<div><br>
<br>
On Fri, 10 Jul 2009, Philip Jagenstedt wrote:<br>
><br>
> Before someone conjures up an example where this doesn't exactly match<br>
</div>> the current behavior, the point is simply that calling canPlayType<br>
<div>> without out a codecs list or with specific codecs, you can learn exactly<br>
> what is supported and not out of the container formats and codecs you<br>
> are interested in, without the need for the strange<br>
> "probably"/"maybe"/"" API.<br>
<br>
</div><div>On Sat, 11 Jul 2009, Robert O'Callahan wrote:<br>
><br>
> I think it would be somewhat counterintuitive for<br>
> canPlayType("video/ogg") to return true, but canPlayType("video/ogg;<br>
> codecs=dirac") to return false.<br>
<br>
</div><div>On Sat, 11 Jul 2009, Philip Jägenstedt wrote:<br>
><br>
> Well I disagree of course, because having canPlayType("video/ogg") mean<br>
> anything else than "can I demux Ogg streams" is pointless.<br>
<br>
</div><div>On Sat, 11 Jul 2009, Robert O'Callahan wrote:<br>
><br>
> So you want "canPlayType" to mean one thing when provided a type without<br>
> codecs, and another thing when provided a type with codecs. I don't<br>
> think that's a good idea.<br>
><br>
> Anyway, it's too late. If you care passionately about this you should<br>
> have reopened this discussion months ago, not now that two browsers have<br>
> just shipped support for the API in the spec.<br>
<br>
</div><div>On Sun, 12 Jul 2009, Robert O'Callahan wrote:<br>
><br>
> IIRC some browsers using system media frameworks don't know what codecs they<br>
> support, so they still need to be able to answer "maybe" when codecs are<br>
> provided; you still need a three-valued result.<br>
><br>
</div><div>> I still think it would confuse authors if you return true for canPlayType(T)<br>
> and false for canPlayType(U) where U is a subset of T.<br>
<br>
</div>I'm with Robert on this. The idea is that you can take the actual MIME<br>
type of a file, and find out what the odds are that the file will play ok.<br>
In practice, the odds are lower with "video/ogg" than a type that<br>
explicitly lists a supported codec.<br>
<div><br>
<br>
On Sun, 12 Jul 2009, Philip Jägenstedt wrote:<br>
><br>
> Not that I except this discussion to go anywhere, but out of curiosity I<br>
> checked how Firefox/Safari/Chrome actually implement canPlayType:<br>
><br>
> <a href="http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support" target="_blank">http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support</a><br>
><br>
> Firefox is conservative and honest (except maybe for "audio/wav;<br>
> codecs=0", what could you do with the RIFF DATA chunk?) Safari gets<br>
> maybe/probably backwards compared to what the spec suggests. Chrome<br>
> seems to ignore the codecs parameter, claiming "probably" even for bogus<br>
> codecs. Authors obviously can't trust the distinction between "maybe"<br>
> and "probably" to any extent.<br>
<br>
</div>That certainly is unfortunate.</blockquote><div><br></div><div>Thanks for calling us out :)</div><div><br></div><div>We've addressed this in our latest builds. We now fall somewhere between Firefox and Safari in terms of conservativeness and honesty.</div>
<div><br></div><div>We still give bogus codecs a "maybe" if the container is supported, since that seems to be what the spec suggests. A "probably" is only for both a container and codec match.</div><div>
<br>
</div><div>Andrew</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<div><br>
<br>
On Sat, 11 Jul 2009, Maciej Stachowiak wrote:<br>
><br>
> If I were designing the API from scratch, I would have two functions,<br>
> "mightPlayType()" and "canDefinitelyPlayType()". That would make it<br>
> easier to write natural boolean expressions. However, I think the<br>
> current canPlayType() is good enough - the empty string pseudo-false<br>
> return should make it mostly ok to treat canPlayType as a boolean<br>
> method. Also, it's a change that we felt we could rush into Firefox and<br>
> Safari updates without undue risk, before the even more broken version<br>
> with the "no" return got locked in. To everyone proposing more<br>
> wide-ranging changes , this API is probably past the point where we can<br>
> freely change it any way we want.<br>
<br>
</div>Ok.<br>
<div><div></div><div><br>
--<br>
Ian Hickson U+1047E )\._.,--....,'``. fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a> U+263A /, _.. \ _\ ;`._ ,.<br>
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'</div></div></blockquote></div><br>