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

RESOLVED DUPLICATE of bug 567077

Status

()

Core
Audio/Video
RESOLVED DUPLICATE of bug 567077
7 years ago
4 years ago

People

(Reporter: Nickolay_Ponomarev, Unassigned)

Tracking

({html5, testcase})

Trunk
html5, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

7 years ago
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
(Reporter)

Comment 1

7 years ago
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

7 years ago
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.

Comment 4

7 years ago
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

Updated

7 years ago
Blocks: 589564

Comment 9

7 years ago
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

7 years ago
Oops, meant to most comment 9 in bug 589564.
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.  :(
Duplicate of this bug: 602597
(Reporter)

Updated

7 years ago
Duplicate of this bug: 602186

Comment 16

6 years ago
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?

Comment 18

6 years ago
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"; [1]

[1]: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#mime-types
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 567077
You need to log in before you can comment on or make changes to this bug.