Closed Bug 875573 Opened 7 years ago Closed 5 years ago
Add support for m4v as 'video/x-m4v' MIME type
Some users report m4v video files are not read by Firefox if they only add "AddType video/x-m4v .m4v" in the .htaccess. It's fixed by adding "AddType video/mp4 .mp4 .m4v". Considering renaming the .m4v into .mp4 is enough to be read by Firefox, just add support of this MIME type.
What will other browsers do? If they play "video/x-m4v" happily, what about other random mime-types? (In other words, isn't it a result of the sniffing?) What happens if "X-Content-Type-Options: nosniff" is added to the HTTP header?
The addtype workaround doesn't work, of course. As a video-website we expect Firefox to know the common suffix .m4v, as do other browsers, OS and local video players. It has a lot of consequences for video websites to change the name of tons of video files. And for users, too: Podcast players will display old videos as new and unseen. Masatoshi, you definitely should not engage in software for human beings.
(In reply to Belles Lettres from comment #2) > Masatoshi, you definitely should not engage in software for human beings. Wow, that's a great way to ask for help & support. You never learned to speak with human beings, do you? (That's a rhetorical question. This is not a dicussion forum but a Bug tracker. Please stick to human rules and the netiquette, and be helpful and cooperative if you want to have your problem fixed.)
(In reply to Florian Bender from comment #3) I'm not asking for support. I have registered here for reporting a severe bug that makes Firefox incapable of playing files suffixed with .m4v.
1. You did not report anything, just added an unproductive comment (together with a totally unrelated, supposedly offensive comment) to this bug. 2. You do not understand the real issue of this bug: It's about a (probably bogus) MIME type setting by servers Firefox does not understand (likely correctly so). Firefox can play .m4v files if they are served with the (correct) video/mp4 MIME type and if Firefox can play .mp4 files at all (currently not supported on all platforms, see depending bugs in bug 799318). 3. You could have answered the questions raised here to actually advance the bug, and to get this issue resolved. Don't just demands thing to get fixed. Fix them yourself (if you need assistance, ask for it), or provide any help to get them fixed ASAP (this includes research not directly tied to producing code). Otherwise, let others do their job and don't bother them with unnecessary comments. I will not answer any more comments regarding this topic, this is not the place for it. Use the appropriate channels for anything not related to fixing this bug, e. g. mailing lists, groups, forums, email …
I'm not interested in improving Firefox and you didn't have to answer in the first place. I simply want users with Firefox or Internet Explorer 6 to be able to watch the video they want. I discovered the same bug in iOS two years ago and it took Apple one hour to understand the problem and one update cycle to fix this simple issue. I had tested all combinations of mp4/m4v-suffixes and mime-type-declarations, before posting here. Firefox is unable to play all HTML 5 video elements that do not have mp4 in the suffix AND in the mime-type-attribute which means that a great lot of videos won't be played although FF has finally learned to play the standard video format after all those years you knowing better and websites like ours paying for double webspace.
Here is something slightly different, but very related. Austrian major TV broadcaster ORF often provides videos on their news site with ending .m3u8 (could this be some kind of playlist?) which refuse to play in Firefox (Flash disabled, Firefox 24 on Linux64 with gstreamer enabled). An example can be seen at http://vorarlberg.orf.at/news/stories/2598062/ I assume it's something that could easily be fixed on their side. But I tried to contact them before and they are not very responsive. If there is a way to make this work by Firefox it would be great.
(In reply to Markus Popp from comment #7) > Here is something slightly different, but very related. Austrian major TV > broadcaster ORF often provides videos on their news site with ending .m3u8 > (could this be some kind of playlist?) which refuse to play in Firefox > (Flash disabled, Firefox 24 on Linux64 with gstreamer enabled). An example > can be seen at http://vorarlberg.orf.at/news/stories/2598062/ .m3u8 is used to HTTP Live Streaming(HLS).
Current B2G do not call FramebufferNativeWindow::compositionComplete().
(In reply to Sotaro Ikeda [:sotaro] from comment #10) > Current B2G do not call FramebufferNativeWindow::compositionComplete(). Sorry, the above is for different bug...
I tested the following in Firefox, Chrome and Safari and IE: document.createElement("video").canPlayType("video/x-m4v") All browsers except Firefox return "maybe", and play a (unprotected) m4v file correctly once renamed to mp4, so all that needs to be done is to add m4v as an alias for the mp4 mime type.
This is a pretty common issue  as m4v files geht more popular and the fix should be quite trivial I guess. Anyone?  https://stackoverflow.com/questions/31853743/is-mv4-video-supported-by-all-systems-browsers/31855964#31855964
(In reply to silverwind from comment #13) > This is a pretty common issue  as m4v files geht more popular and the fix > should be quite trivial I guess. Anyone? I'd r+ a patch http://mxr.mozilla.org/mozilla-central/source/dom/media/DecoderTraits.cpp
Here's my attempt at adding this mimetype. The change in MP4Decoder::CanHandleMediaType is the only one necessary for .canPlayType to correctly return "maybe" on my Windows machine. The other two changes seemed only logical to support other platforms. I ran mochitest in dom/media and couldn't find any related failures, but would appreciate if someone could double check the test results.
Attachment #8649411 - Flags: review?(ajones)
5 years ago
Attachment #8649411 - Flags: review?(ajones) → review+
The test is failing like https://treeherder.mozilla.org/logviewer.html#?job_id=13111683&repo=mozilla-inbound Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/72ab85dd82ab
Looks like I missed adding the type for linux somewhere, investigating.
Updated patch to also include the type in GStreamerFormatHelper. Requesting a try build on r+ on all platforms running mochitest on dom/media.
5 years ago
Attachment #8651190 - Flags: review?(ajones) → review+
Committers: this is untested on linux, but if the test I modified passes it's good to go.
I tested in the latest Nightly, it works fine with this example: data:text/html;charset=utf-8,<video controls><source src%3D"http%3A%2F%2Fmastbaumbishop.wikispaces.com%2Ffile%2Fview%2Fsample.m4v%2F77739109%2Fsample.m4v" type%3D"video%2Fx-m4v"><%2Fvideo> Local m4v videos are played normally too. Of course, it worked previously in FF40 if the webmaster used type="video/m4v" which is the MIME type that should be used because it's standardized in an RFC and tracked by IANA (see http://www.iana.org/assignments/media-types/media-types.xhtml).
I forgot that: Do we need to update that page? https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats#Browser_compatibility
> video/m4v you surely mean video/mp4, right? video/m4v never was a thing and video/x-m4v was primarily pushed by Apple, because of their optional DRM in the format, for which I think there is none in Firefox afaik. > Do we need to update that page? I don't think that table needs an update, because in essence nothing has changed in regards t codec support, and the new mime type is treated exactly as mp4. The only real impact of this change is that .canPlayType now returns "maybe" instead of "", which should fix the playback on players that check format with this.
Release Note Request (optional, but appreciated) [Why is this notable]: [Suggested wording]: Improved support for x-m4v video format [Links (documentation, blog post, etc)]: Silverwind (or anyone else), if you have a better way to word the release note please needinfo me with your suggestion. Thanks!
Looks fine to me as a short summary. Technically x-m4v was already playable, this change only affects feature detection through HTMLMediaElement.canPlayType() , which some sites are likely doing.  https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType
(In reply to silverwind from comment #28) > Looks fine to me as a short summary. Technically x-m4v was already playable, > this change only affects feature detection through > HTMLMediaElement.canPlayType() , which some sites are likely doing. Would you say this improves playback for a large subset of videos? Not looking to quantify, but wondering if it's worth calling out as a win within our blog post in 43? Or is this more of a quiet mention as a release note only?
> Would you say this improves playback for a large subset of videos? Not > looking to quantify, but wondering if it's worth calling out as a win within > our blog post in 43? Or is this more of a quiet mention as a release note > only? From my tests, Firefox already played any mp4 video fine as long as the bytestream is of a supported format, it doesn't really care what mime-type the file is served with. To present a custom error, applications can try to pre-determine support with canPlayType, which this patch fixed for this particular mime-type. I'm really not sure how widespread this pattern is, but it ought to fix a few cases where m4v wouldn't play because the application naively assumes the browser couldn't play it. Do what you like with this info, I don't think it warrents a callout on the blog thought :)
You need to log in before you can comment on or make changes to this bug.