[whatwg] Serving up Theora <video> in the real world

[Andrew Scherkus]

On Mon, Jul 27, 2009 at 3:48 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 10 Jul 2009, Aryeh Gregor 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).
>
> The main use case is ordering. If you have ten variants, you might want to
> try the "probably"s before the "maybe"s, especially if there are a lot of
> weird codecs involved, such that the "maybe"s might be able to play
> somewhat, just not as well as the "probably"s.
>
>
> On Fri, 10 Jul 2009, Philip Jagenstedt wrote:
> >
> > 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.
>
> What would "canPlayType("video/ogg; codecs=vorbis")" return? There's not
> enough information there to say whether or not you can play a stream
> labeled that way.
>
>
> > 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).
>
> You can use the method as it is now as a boolean method, in practice.
> However, I think there is value in being explicit that a "true" return
> value isn't really necessarily confident.
>
>
> On Fri, 10 Jul 2009, Philip Jagenstedt wrote:
> >
> > 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.
>
> On Sat, 11 Jul 2009, Robert O'Callahan wrote:
> >
> > I think it would be somewhat counterintuitive for
> > canPlayType("video/ogg") to return true, but canPlayType("video/ogg;
> > codecs=dirac") to return false.
>
> On Sat, 11 Jul 2009, Philip Jägenstedt wrote:
> >
> > Well I disagree of course, because having canPlayType("video/ogg") mean
> > anything else than "can I demux Ogg streams" is pointless.
>
> On Sat, 11 Jul 2009, Robert O'Callahan wrote:
> >
> > So you want "canPlayType" to mean one thing when provided a type without
> > codecs, and another thing when provided a type with codecs. I don't
> > think that's a good idea.
> >
> > Anyway, it's too late. If you care passionately about this you should
> > have reopened this discussion months ago, not now that two browsers have
> > just shipped support for the API in the spec.
>
> On Sun, 12 Jul 2009, Robert O'Callahan wrote:
> >
> > IIRC some browsers using system media frameworks don't know what codecs
> they
> > support, so they still need to be able to answer "maybe" when codecs are
> > provided; you still need a three-valued result.
> >
> > I still think it would confuse authors if you return true for
> canPlayType(T)
> > and false for canPlayType(U) where U is a subset of T.
>
> I'm with Robert on this. The idea is that you can take the actual MIME
> type of a file, and find out what the odds are that the file will play ok.
> In practice, the odds are lower with "video/ogg" than a type that
> explicitly lists a supported codec.
>
>
> On Sun, 12 Jul 2009, Philip Jägenstedt wrote:
> >
> > Not that I except this discussion to go anywhere, but out of curiosity I
> > checked how Firefox/Safari/Chrome actually implement canPlayType:
> >
> > http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support
> >
> > Firefox is conservative and honest (except maybe for "audio/wav;
> > codecs=0", what could you do with the RIFF DATA chunk?) Safari gets
> > maybe/probably backwards compared to what the spec suggests. Chrome
> > seems to ignore the codecs parameter, claiming "probably" even for bogus
> > codecs. Authors obviously can't trust the distinction between "maybe"
> > and "probably" to any extent.
>
> That certainly is unfortunate.


Thanks for calling us out :)

We've addressed this in our latest builds.  We now fall somewhere between
Firefox and Safari in terms of conservativeness and honesty.

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.

Andrew


>
>
>
> On Sat, 11 Jul 2009, Maciej Stachowiak wrote:
> >
> > If I were designing the API from scratch, I would have two functions,
> > "mightPlayType()" and "canDefinitelyPlayType()". That would make it
> > easier to write natural boolean expressions. However, I think the
> > current canPlayType() is good enough - the empty string pseudo-false
> > return should make it mostly ok to treat canPlayType as a boolean
> > method. Also, it's a change that we felt we could rush into Firefox and
> > Safari updates without undue risk, before the even more broken version
> > with the "no" return got locked in. To everyone proposing more
> > wide-ranging changes , this API is probably past the point where we can
> > freely change it any way we want.
>
> Ok.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090727/fed79e55/attachment-0002.htm>