546129 - audio/video with application/octet-stream Content Type not played; HTMLMediaElement.canPlayType("application/octet-stream") returns an empty string

Status: RESOLVED DUPLICATE of bug 567077

(Core :: Audio/Video, defect)

Description

[Nickolay_Ponomarev]

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#mime-types

> The MIME type "application/octet-stream" with no parameters is never a type 
> that the user agent knows it cannot render. User agents must treat that type 
> as equivalent to the lack of any explicit Content-Type metadata when it is
> used to label a potential media resource.
[...]
> The canPlayType(type) method must return the empty string if type is a type
> that the user agent knows it cannot render [...]

So media.canPlayType("application/octet-stream") should not return "", probably should return "maybe".

See http://mozilla.doslash.org/stuff/video-test/video.html for a testcase.

I'm assuming this is the reason a <video> with src pointing to a URL, requesting which results in a response with application/octet-stream Content-Type, does not load in the same testcase.

Here's the relevant source: http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsHTMLMediaElement.cpp#1239

Comment 1

[Nickolay_Ponomarev]

I tested on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a2pre) Gecko/20100212 Minefield/3.7a1pre

Google Chrome (5.0.322.2) on Mac plays both videos, but returns "" in canPlayType("application/octet-stream").

Safari (4.0.4 (5531.21.10)) doesn't play either video because it doesn't support ogg, but also returns "" in canPlayType("application/octet-stream").

(This report is inspired by http://stackoverflow.com/questions/2260321/media-err-src-not-supported-html5-audio-woes )

Comment 2

[cajbir (:cajbir)]

We don't do any content sniffing to work out what the content is - we rely on the correct mime type being provided. This is why application/octet-stream does not play and way we return "" for canPlayType.

Comment 3

[Boris Zbarsky [:bzbarsky]]

It's not clear to me why the spec special-cases this MIME type, exactly.  It's also not clear to me why the spec requires different type sniffing in different cases (which effectively rules out network-module-level type sniffing and means that every single consumer has to sniff individually and differently)...  It seems to me that making the spec saner in this case would be a better idea than changing our implementation.

Comment 4

[cajbir (:cajbir)]

This long thread has the backstory for those interested:

http://lists.w3.org/Archives/Public/public-html/2009Jun/0013.html

We've been opposed to implementing content sniffing for audio and video.

Comment 5

[Matthew Gregan [:kinetik]]

When this bug is fixed, the following test should pass:
(Note that the tests current sniff the user agent for Firefox--hopefully that'll be fixed soon.)

http://test.w3.org/html/tests/submission/Microsoft/video/video_003.htm

Comment 6

[Fabricio Campos Zuardi]

Can we skip the sniff when the author specifies the type?
For example, when the html source tag explicit says type='video/webm; codecs="vp8.0, vorbis"' on the source tag?

Or should this request be filed as a different bug?

BTW: Chromium loads a webm video served with application/octet-stream mime type.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Can we skip the sniff when the author specifies the type?

Easy enough on the Necko end; the caller just needs to tell it about the type hint and it will use that if the type is not specified.  Though note that application/octet-stream is treated as specified...

Comment 8

[Hixie (not reading bugmail)]

(In reply to Boris, in comment #3)
> It's not clear to me why the spec special-cases this MIME type, exactly.  It's
> also not clear to me why the spec requires different type sniffing in different
> cases (which effectively rules out network-module-level type sniffing and means
> that every single consumer has to sniff individually and differently)...  It
> seems to me that making the spec saner in this case would be a better idea than
> changing our implementation.

It seems it was in response to your request. :-)

   http://lists.w3.org/Archives/Public/public-html/2009Jul/0888.html

Comment 9

[cajbir (:cajbir)]

The fix for this bug shouldn't be to change canPlayType to 'maybe' for application/octet-stream. We don't do content sniffing so we definitely cannot play that mime type. By changing canPlayType we'd prevent client JavaScript from detecting this case unless we actually implement content sniffing on application/octet-stream.

Comment 10

[cajbir (:cajbir)]

Oops, meant to most comment 9 in bug 589564.

Comment 11

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Spec changed. <http://html5.org/tools/web-apps-tracker?from=5406&to=5407>

Comment 12

[Masatoshi Kimura [:emk]]

(In reply to comment #11)
> Spec changed. <http://html5.org/tools/web-apps-tracker?from=5406&to=5407>
It looks a mere markup change. The spec still requires sniffing.

Comment 13

[Boris Zbarsky [:bzbarsky]]

> It seems it was in response to your request. :-)

Hmm...  I think there was some miscommunication there, but given the broken threading it's hard to find exactly what the context was.  :(

Comment 16

[Mark Curtis]

Anything going on with this? I wanted to roll out an HTML5 video player, but I can't until this bug is squashed.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Why?  Is something preventing you from sending your video with a correct MIME type?

Comment 18

[Mark Curtis]

I don't know, is there?  The following code, which was taken from http://www.mozilla.com/en-US/firefox/beta/features/ doesn't work:

Once the source is changed to the Akamai server it no longer plays in Firefox 4, yet plays in Opera and Chrome. As the videos are hosted on a third party Akamai server, any modifications to the server are NOT an option, thus the bug I filed that was marked as a duplicate of this one.

    <video width="640" height="264" autoplay="autoplay" controls="controls" id="htmlPlayer" tabindex="0">
    	<source type="video/webm; codecs="vp8, vorbis"" src="http://a1135.g.akamai.net/f/1135/24935/1h/cchannel.download.akamai.com/24935/43kix/untitled1/oceans-clip.webm"></source>
        <source type="video/ogg; codecs="theora, vorbis"" src="http://a1135.g.akamai.net/f/1135/24935/1h/cchannel.download.akamai.com/24935/43kix/untitled1/oceans-clip.ogv"></source>
        <source type="video/mp4" src="http://a1135.g.akamai.net/f/1135/24935/1h/cchannel.download.akamai.com/24935/43kix/untitled1/oceans-clip.mp4"></source>
	</video>

Comment 19

[Boris Zbarsky [:bzbarsky]]

> As the videos are hosted on a third party Akamai server, any modifications to
> the server are NOT an option

You can't ask Akamai to send your content with the correct MIME type?  That seems ... surprising.  Have you tried doing that?

Comment 20

[Chris Pearce [:cpearce (Not reading bugmail)]]

Can you put a .htaccess file in that directory? If so, if the following .htaccess file in that directory, and Apache should/may serve the correct Content-Type.

AddType video/webm webm
AddType video/ogg ogg
AddType video/ogg ogv
AddType audio/ogg oga
AddType video/mp4 mp4

Note that IE9 is going to honour the Content-Type header as well (see http://www.w3.org/Bugs/Public/show_bug.cgi?id=11984#c6 ), so you'll have this problem with IE9 as well as Firefox.

Comment 21

[Paul Adenot (:padenot)]

This is now fixed, because we do sniffing.

Also, media.canPlayType("application/octet-stream") returns "", which is correct per spec:

> canPlayType(type) method must return the empty string if type is a type that the user agent 
> knows it cannot render or is the type "application/octet-stream"; [1]

[1]: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#mime-types