[whatwg] <video> application/octet-stream

[Philip Jägenstedt]

On Mon, 19 Jul 2010 13:20:40 +0200, Philip Jägenstedt <philipj at opera.com>  
wrote:

> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#mime-types
>
> There was some discussion about this, last in  
> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026409.html>
>
> I've tested Firefox 3.6.4, Firefox 4.0b1 and Chrome 5.0.375.99 and none  
> return "maybe" for canPlayType("application/octet-stream"). I couldn't  
> get meaningful results from Safari on Windows (requires restart to  
> detect QuickTime, perhaps?).
>
> It would appear that Opera is the only browser that supports  
> application/octet-stream. At the time I added this, it was simply  
> because it is true, maybe we can play it. However, I see no practical  
> benefit of this spec-wise or implementation-wise. Since no other  
> browsers have implemented it, I am going to remove it from Opera and  
> hope that the spec will be changed to match this.
>

Maciej reports that Safari will play <video> regardless of the MIME type.  
[1] I just tested Chrome and it also appears to play any MIME type. This  
is actually complete news to me, I'm not sure how I could have not known  
this. The spec currently doesn't match reality. This is what it seems like  
the reality is:

* Firefox is the strictest, accepting only the types it knows, and even  
refuses to play e.g. Ogg served as audio/wav. canPlayType matches this.

* Opera follows the spec, thus also accepting application/octet-stream, as  
long as it has no codecs paramter. The same code path is used for  
canPlayType and at load time, so they always match. However, serving Ogg  
as audio/wav will work just fine, and this is in lines with the spec. We  
*could* change this to be like Firefox, but obviously only if also  
removing support for application/octet-stream. We also have a bug that  
causes us to treat text/plain as application/octet-stream in some  
situations, but this is *not* intentional and something we could likely  
fix without compat issues.

* Safari and Chrome don't care about the MIME type, which doesn't at all  
match what they advertise in canPlayType.

We haven't seen any compat issues from our relatively strict handling yet,  
mostly because Firefox is even stricter and that we don't support any of  
the same formats as Safari. However, as soon as Chrome ships with WebM  
support with this lax handling, I expect we will start seeing issues. It's  
already a race to the bottom, and now would be a good time to figure out  
what to do.

I see 3 main options:

1. The spec and all implementations align with Firefox. This seems very  
unlikely, as there is certainly lots of MPEG-4 content served as  
text/plain that Safari won't play.

2. The spec doesn't change and all implementations align with it.

3. The spec requires the MIME type to be ignored completely, with  
canPlayType using MIME only as magic strings with no relation to its  
actual use in HTTP.

In terms of purity, option 1 is the most appealing. However, lots of  
questions on about <video> problems on e.g. StackOverflow seem to end up  
being about an incorrect MIME type. Lax handling has concrete positive  
effects: it's easy to set up. The only concrete negative effect I know  
about is getting a browser full of garbled text when navigating directly  
to a mislabeled resource. More sniffing could solve this, of course. (Bah!)

I'd like to hear from Mozilla, Google and Apple which of these (or other)  
solutions they would find acceptable.

[1] http://lists.w3.org/Archives/Public/public-html/2010Jul/0124.html

-- 
Philip Jägenstedt
Core Developer
Opera Software