Closed Bug 975809 Opened 10 years ago Closed 9 years ago

Video format or MIME type is not supported. - should do content sniffing on video tag

Categories

(Core :: Audio/Video: Playback, defect)

Product:
Core
Component:
Audio/Video: Playback
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1048579

People

(Reporter: hendry, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140214013806

Steps to reproduce:

Visit http://video.geekout.org.uk/#http://mr2011.s3.amazonaws.com/2009-01-01/GOPR0020.mp4




Actual results:

Get a "Video format or MIME type is not supported." message


Expected results:

MP4 video should have played back.

Other videos on the same page, from the same gopro, encoded the same way, seem to play back fine, e.g. http://video.geekout.org.uk/#http://mr2011.s3.amazonaws.com/2009-01-01/GOPR0019.mp4

The videos were encoded via ffmpeg using: https://github.com/kaihendry/recordmydesktop2.0/blob/master/htmlvideo#L38
Tested on Latest m-c win32 Tinderbox build, running on win7 x64 
cset: https://hg.mozilla.org/mozilla-central/rev/84c9885475e7

I see same as comment #0 

confirming and setting to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Untriaged → Video/Audio
Product: Firefox → Core
OS: Linux → All
Version: 27 Branch → Trunk
The ones that play have a Content-Type of video/mp4 as expected.  The one that does not has a Content-Type of binary/octet-stream.
(In reply to Bill Gianopoulos [:WG9s] from comment #2)
> The ones that play have a Content-Type of video/mp4 as expected.  The one
> that does not has a Content-Type of binary/octet-stream.

Hmm the Firefox debugger is a bit weird. http://r2d2.webconverger.org/2014-02-23/firefox-network-debugger-columns.html

Why is the browser being pedantic about the content-type all of a sudden? Are you saying the is an Amazon S3 bug? Chrome offers a much better UX.

Or are you saying I must put the video/mp4 content type on my video elements? Still seems a bit urgh. I'm afraid if I update http://video.geekout.org.uk/ I sort of kill the bug's test case.
Well the browser is supposed to respect the Content-Type header.  The fact that IE has always ignored the Content-Type if it conflicts with what they consider a known extension is NOT in conformance with the specification.

SO, what is going on here is that you either did something different when you uploaded the 2 files to the Amazon server, or it has some kind of content sniffing code that detected one of the files as an MP4, but somehow failed to detect the other one as such.

In any event this is not a Mozilla bug.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
There was no difference when uploading the MP4 to AWS S3.

If you want Firefox to be pedantic, you are simply going to lose market share to Chrome. Reminds me of the silly XHTML versus HTML arguements.
(In reply to Kai Hendry from comment #5)
> If you want Firefox to be pedantic, you are simply going to lose market
> share to Chrome. Reminds me of the silly XHTML versus HTML arguements.

This comment in non-nonsensical as Chrome does not play the GOPR0020.mp4 file as a video either.
http://video.geekout.org.uk/#http://mr2011.s3.amazonaws.com/2009-01-01/GOPR0020.mp4 works fine in Chromium	33.0.1750.117 (Developer Build 252094)


http://r2d2.webconverger.org/2014-02-23/working_in_chrome.html

Btw, I changed on my local copy to use:

<source src='<?php echo $v; ?>' type='video/mp4'> in

https://github.com/kaihendry/videomarker/blob/master/t.php#L3

And it still doesn't work in Firefox. I can come up with a reduced test case if needed?
The first step in simplifying your test case would be to remove the "http://video.geekout.org.uk/#" part of the URL and just give the link to the video.

It would probably be useful if you would contact your support people for the Amazon service and have them answer why it serves the files GoPR0019.mp4 and GOPR0020.mp4 with different Mime Types.

I downloaded both files using wget and ran the Linux file command and it correctly identifies both as being "ISO Media, MPEG v4 system, version 1".
Actually, a really interesting question would be why it EVER returns binary/octet-stream, as that is NOT a valid Mime type.  The correct Mime Type for an octet-stream is application/octet-stream.  "binary" is NOT a valid Mime registry.
BTW. Before, someone corrects me, I do know that the term MIME has been deprecated and these are now more correctly called Media Types.  I was just using the vernacular.
You have to pay Amazon to get service you know. :(

I made a case test where I've defined the media type as video/mp4 and it still does not work in 27.0.1.
http://video.geekout.org.uk/975809-typed.html

Can you please re-open this issue Bill? Feel free to rename it point to a AWS S3 fault, if you feel that's really where the blame lies.
You submitted the bug.  You should have permission to re-open it if you wish.  BTW the server is still returning the file as type binary/octet-stream.
Oh and i don;t get this, so you are using Amazon for hosting yet you have to pay them per incident for support?  Well that seems lame.
Welcome to the cloud Bill. Luckily I know someone who works for Amazon, so I will make an enquiry.

Still there is a couple of open issues here:

* Why doesn't the video/mp4 content type override work:
http://video.geekout.org.uk/975809-typed.html
* Why doesn't Firefox just try play http://mr2011.s3.amazonaws.com/2009-01-01/GOPR0020.mp4 despite the wrong mimetype (binary/octet-stream) being served, like what Chrome does.
http://video.geekout.org.uk/#http://mr2011.s3.amazonaws.com/2009-01-01/GOPR0020.mp4
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
I moved this to the correct component for you.
Component: Video/Audio → File Handling
Status: REOPENED → NEW
Hardware: x86_64 → All
(In reply to Kai Hendry from comment #14)
> Welcome to the cloud Bill. Luckily I know someone who works for Amazon, so I
> will make an enquiry.
> 
> Still there is a couple of open issues here:
> 
> * Why doesn't the video/mp4 content type override work:
> http://video.geekout.org.uk/975809-typed.html
tp://mr2011.s3.amazonaws.com/2009-01-01/
> GOPR0020.mp4

Well that clearly did nto work on the server side so that is not a Firefox issue.

> * Why doesn't Firefox just try play http://mr2011.s3.amazonaws.com/2009-01-01/GOPR0020.mp4 > despite the wrong mimetype (binary/octet-stream) being served, like what Chrome does.
> http://video.geekout.org.uk/#http://mr2011.s3.amazonaws.com/2009-01-01/GOPR0020.mp4

Chrome did not play this for me.  it saved the file to disk.
To make it perfectly clear.  Under Linux (which is the OS this was originally filed under) This URL http://mr2011.s3.amazonaws.com/2009-01-01/GOPR0019.mp4  plays the video.  This URL http://mr2011.s3.amazonaws.com/2009-01-01/GOPR0020.mp4 saves the file to disk.
Blocks: mimesniff
(In reply to Bill Gianopoulos [:WG9s] from comment #9)
> Actually, a really interesting question would be why it EVER returns
> binary/octet-stream, as that is NOT a valid Mime type.  The correct Mime
> Type for an octet-stream is application/octet-stream.  "binary" is NOT a
> valid Mime registry.

I think it intentionally returns an unknown MIME types for the very reason that browsers sniff the mime type "application/octet-stream".
It's the failure of the interoperability effort to pile more and more ad-hoc workarounds each other.
(In reply to Bill Gianopoulos [:WG9s] from comment #8)
> The first step in simplifying your test case would be to remove the
> "http://video.geekout.org.uk/#" part of the URL and just give the link to
> the video.

No, that misses the point. Chrome and Firefox behave the same if you visit the video's url directly, the different behaviour is that Firefox will not play the content when in the video tag and you press the play button, see screenshot:

http://farm4.staticflickr.com/3809/12743408183_40641c605d_o.png
OK. So i guess what you are asking for is not what I thought originally, but content sniffing on the video tag.
Component: File Handling → Video/Audio
Summary: Video format or MIME type is not supported. → Video format or MIME type is not supported. - should do content sniffing on video tag
(In reply to Hixie (not reading bugmail) from comment #18)
> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=11984 for the spec status
> of this.

So perhaps what is needed here is, if the issue is, you can't depend on cloud servers providing a correct content type, then you should be able to specify a Content-type on t e video tag to override the content-type returned bu the server.

Expecting the user-agent to do content sniffing is problematic on multiple levels.  Can't copy what a different browser does because they will claim patent infringement, etc.
I'm told S3 will serve you the file with the same mimetype as you uploaded it. Somehow s3cmd got this mimetype wrong sometimes. Amazon guys say I can update the metadata of the S3 object, though I've yet to figure this out. https://github.com/aws/aws-cli/issues/670

Nonetheless a video tag content type override would be nice. I can't help but wonder why can't source type double up for this? http://video.geekout.org.uk/975809-typed.html
(In reply to Bill Gianopoulos [:WG9s] from comment #22)
> Expecting the user-agent to do content sniffing is problematic on multiple
> levels.  Can't copy what a different browser does because they will claim
> patent infringement, etc.

This is already being done on multiple levels in multiple different areas. The problematic part is only determining browsers do, determining which of these possibilities is the "best" one, and getting the non-conformers to conform.

As Hixie noted, the discussion about what the best course of action is is happening elsewhere; this bug is not a particularly productive place for it.
Component: Audio/Video → Audio/Video: Playback
Hm, bug 1048579 should fix this.
Status: NEW → RESOLVED
Closed: 10 years ago → 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.