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

[Ian Hickson]

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.


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.   `._.-(,_..'--(,_..'`-.;.'