[whatwg] <video> application/octet-stream

[Philip Jägenstedt]

On Thu, 22 Jul 2010 14:18:38 +0200, johan <johan at qx.se> wrote:

>
>
>> On Wed, Jul 21, 2010 at 10:24 AM, Chris Double
>> <chris.double at double.co.nz> wrote:
>>> On Thu, Jul 22, 2010 at 2:15 AM, Mike Shaver <mike.shaver at gmail.com>  
>>> wrote:
>>>> ...I would probably suggest that the
>>>> developers of said browser implement basic Ogg support (enough to say
>>>> "this is Ogg, so we don't support it"), and go back to solving more
>>>> pressing problems!
>>>
>>> Or the developers of said browser could obey the mime type that the
>>> server sent,
>>
>
>
> Yes please!
>
> While the mime type discussion has been specific to video so far, as an  
> author I'd like to take a step back and look at it in a more general  
> way. First off, I'd expect handling of mime types to be consistent  
> across the board of all mime types, and more specifically, I'd expect  
> browsers to respect them. Wether it's text, image or video.
> For example, if I serve a document, containing text that looks like an  
> html document, as text/plain, I'd expect the browser to serve it as  
> text/plain.

It's way too late to get anything resembling consistent handling across  
the board. For example, the MIME type is ignored for <img> and that cannot  
be changed. All we can hope for is making the best of the situation with  
new things like <video>.

> If my web server can't handle mapping from a specific file to mime type,  
> I can always deal with that through server side scripting, and instead  
> of providing direct access to "video1.ogg" I'd go through "video.php?1"  
> and set the headers myself. If I screw up, either through server side  
> scripting or due to not configuring the web server correctly, or by  
> choosing a web server that does not provide the functionality I need, I  
> do not see that as the fault of browser developers. However, I do find  
> it annoying to have to add a header like "x-content-type-options:  
> nosniff" to force certain browsers to respect my choice of mime type.

I hadn't heard of X-Content-Type-Options before, that certainly looks  
crazy.

> As for the issue of container format, I see this as a different matter.  
> Either you support the container format or not, and either way respect  
> the mime type for it. Wether you support zero, one or more of the  
> possible container payloads has nothing to do with respecting mime type  
> or sniffing. The mime type lets you decide wether to accept or reject  
> the container, and if you accept it you will of course have to find out  
> what codec to use.
>
> Also, the mime type/subtype can be followed by a parameter  
> attribute=value list, which should make it possible to specify a codec  
> thus even removing the need for a user agent to detect the format of the  
> container contents. If no such parameter is present, fallback to  
> ordinary format detection is of course necessary. And as far as I can  
> tell, this seems to be allready specified by  
> http://tools.ietf.org/html/rfc4281 in general and specifically for ogg  
> in http://tools.ietf.org/html/rfc5334#section-10

Specifying the codecs parameter is mostly useless, at least for Ogg and  
WebM. It doesn't help the slightest bit when trying to decode the video,  
it's only for canPlayType. (For example, when demuxing Ogg, apart from  
knowing what codec it is you're demuxing you'll also need to know the  
serial number of the stream and lots of other things.)

> Aside from that, I do not quite understand why this is discussed under  
> the title "application/octet-stream". Looking at  
> http://www.rfc-editor.org/rfc/rfc2046.txt, section 3.  Overview Of The  
> Initial Top-Level Media Types, bullet 5:
> "The subtype "octet-stream" is to be used in the case of uninterpreted  
> binary data, in which case the simplest recommended action is to offer  
> to write the information into a file for the user."

It's about application/octet-stream because the spec says (more or less)  
that canPlayType("application/octet-stream") should return "maybe", which  
I thought was pointless and wanted to remove. Since then, it's turned out  
that things are more broken than I though.

-- 
Philip Jägenstedt
Core Developer
Opera Software