Closed Bug 546129 Opened 13 years ago Closed 10 years ago
audio/video with application/octet-stream Content Type not played; HTMLMedia
Element .can Play Type("application/octet-stream") returns an empty string
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
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 )
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.
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.
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.
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
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.
> 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...
(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
Spec changed. <http://html5.org/tools/web-apps-tracker?from=5406&to=5407>
(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.
> 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. :(
Anything going on with this? I wanted to roll out an HTML5 video player, but I can't until this bug is squashed.
Why? Is something preventing you from sending your video with a correct MIME type?
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>
> 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?
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.
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";  : http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#mime-types
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 567077
You need to log in before you can comment on or make changes to this bug.