[whatwg] <video> application/octet-stream

[Philip Jägenstedt]

On Thu, 22 Jul 2010 22:40:44 +0200, Maciej Stachowiak <mjs at apple.com>  
wrote:

>
> 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>  
>> wrote:
>>
>>> 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.

-- 
Philip Jägenstedt
Core Developer
Opera Software