W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

[whatwg] <video> application/octet-stream

From: Philip Jägenstedt <philipj@opera.com>
Date: Fri, 23 Jul 2010 10:52:55 +0200
Message-ID: <op.vgagahdlatwj1d@philip-pc.gothenburg.osa>
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
Received on Friday, 23 July 2010 01:52:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:25 UTC