[whatwg] <video> application/octet-stream
Philip Jägenstedt
philipj at opera.com
Tue Jul 20 02:48:40 PDT 2010
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
More information about the whatwg
mailing list