[whatwg] <video> application/octet-stream
philipj at opera.com
Fri Jul 23 01:52:55 PDT 2010
On Thu, 22 Jul 2010 22:40:44 +0200, Maciej Stachowiak <mjs at apple.com>
> On Jul 22, 2010, at 3:30 AM, Philip Jägenstedt wrote:
>> On Thu, 22 Jul 2010 11:22:45 +0200, Henri Sivonen <hsivonen at iki.fi>
>>> Chris Double wrote:
>>>> As I mentioned in a previous email, the sniffing could result in a
>>>> reasonable amount of data being consumed. I'm sure people who run
>>>> sites that share HTML 5 video would appreciate browsers not consuming
>>>> data bandwidth to sniff files that they've already specified as being
>>>> something the browser doesn't support.
>>> I think the solution to this concern is to allow authors of
>>> bandwidth-sensitive to specify the type attribute on <source> or the
>>> Content-Type header on the HTTP response to say something other than
>>> application/octet-stream or text/plain. For best performance, authors
>>> should use the type attribute in multi-<source> cases anyway.
>> Chrome and Safari ignore the MIME type altogether, in my opinion if we
>> align with that we should do it full out, not just by adding text/plain
>> to the whitelist, as that would either require (a)
>> canPlayType("text/plain") to return "maybe" or (b) different code paths
>> for checking the MIME type in Content-Type and for canPlayType.
> I don't think canPlayType("text/plain") has to return "maybe". It's not
> useful for a Web developer to test for the browser's ability to sniff
> to overcome a bad MIME type. canPlayType should be thought of as testing
> whether the browser could play a media resource that is "really" of a
> given type, rather than labeled with that type over HTTP.
Right, it certainly isn't useful, I'm just pointing out that this is what
happens if one adds text/plain to the list of "maybe" codecs rather than
ignoring Content-Type altogether, which is the only thing you can do
within the bounds of the current spec to get text/plain to play. The only
3 serious options I know are still the ones I outlined in my earlier email.
More information about the whatwg