- From: Philip Jagenstedt <philipj@opera.com>
- Date: Fri, 10 Jul 2009 23:37:04 +0200
On Fri, 10 Jul 2009 23:26:40 +0200, Philip Jagenstedt <philipj at opera.com>
wrote:
> On Fri, 10 Jul 2009 19:23:44 +0200, Aryeh Gregor
> <Simetrical+w3c at gmail.com> wrote:
>
>> On Fri, Jul 10, 2009 at 4:57 AM, Robert
>> O'Callahan<robert at ocallahan.org> wrote:
>>> The way we've implemented in Firefox, we'll return "yes" if you
>>> specify a
>>> codecs parameter and we support every codec in your list. So
>>> v.canPlayType("video/ogg; codecs=vorbis,theora") returns "probably" in
>>> Firefox 3.5. I think this is reasonable because I believe that, modulo
>>> bugs
>>> in our implementation, we support the full Theora and Vorbis specs. On
>>> the
>>> other hand, we will return "maybe" for v.canPlayType("video/ogg"). I
>>> think
>>> this distinction will be useful.
>>
>> In what use-case would an author want to make use of the distinction?
>> In either case, your only course of action is to try playing the
>> video. Maybe you'd try testing all the video types you support, and
>> if one is "maybe" while another is "probably" you'd go with
>> "probably"? That seems like a pretty marginal use case to help for
>> the sake of such a confusing API. Programmers expect binary logic,
>> not ternary (look at the complaints about SQL's NULL).
>
> I agree that the current interface is ugly and quite fail to see what the
> use for it is. With a boolean return value,
> canPlayType("application/ogg")
> would return true if one can demux Ogg streams.
> canPlayType("application/ogg; codecs=vorbis,dirac") would return true if
> one can demux Ogg and decode vorbis + dirac. Differentiating between
> "maybe"/"probably" really seems like an edge use case, but you could if
> you really wanted to:
>
> function tertiaryCanPlayType(mime) {
> [container, codecs] = mime.split(";");
> if (canPlayType(mime)) {
> return codecs ? "probably" : "maybe";
> } else {
> // if there are codecs, canPlayType(container) would tell you if
> problem is with the container format or the codecs
> return ""; // was "no"
> }
> }
Before someone conjures up an example where this doesn't exactly match the
current behavior, the point is simply that calling canPlayType without out
a codecs list or with specific codecs, you can learn exactly what is
supported and not out of the container formats and codecs you are
interested in, without the need for the strange "probably"/"maybe"/"" API.
> Unless there's some compelling use case that can't be handled with the
> above I'd support canPlayType returning a boolean. The only issue I can
> see is that canPlayType(foo)==true might be interpreted as a strong
> promise of playability which can't be given. In that case just rename the
> function to wouldTryTypeInResourceSelection (no, not really).
>
--
Philip J?genstedt
Core Developer
Opera Software
Received on Friday, 10 July 2009 14:37:04 UTC