[Rethink] Support mkv|matroska|video/x-matroska in Firefox
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
Webcompat Priority | P2 |
People
(Reporter: tim.langhorst, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [webcompat])
Attachments
(1 file)
12.76 KB,
video/x-matroska
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20171122140526 Steps to reproduce: Try to embed a mkv file: <video controls> <source src="video_file.mkv" type="video/x-matroska"> </video> Actual results: Firefox says it's not supported. Expected results: Firefox should support it, because there are many codecs today and if i use for example h264 and opus together the only container supporting it is matroska converting opus is no option, because is the de facto best audio codec and converting the video to vp9 would be nice, but I neither have the time to do that on my cpu (would take more than 2200 hours) nor a hardware encoder. This is specific to me, but I think I'm not the only one, who encounters such problems.
Updated•6 years ago
|
(In reply to Tim Langhorst from comment #0) > Firefox should support it, because there are many codecs today and if i use > for example h264 and opus together the only container supporting it is > matroska Both H.264 and Opus are supported in MP4.
Updated•6 years ago
|
Reporter | ||
Comment 2•6 years ago
|
||
No mp4 does not support opus,only vp9 inofficially. Tested with ffmpeg.
Updated•6 years ago
|
Reporter | ||
Comment 3•6 years ago
|
||
Matroska file are actually really nice to use, because: 1. There are very good tools (mktoolnix(-gui), mkvmerge, Mkclean) 2. Support for most features a container need and almost any codec (even yuv4) 3. Streaming support 4. Open source tool and standard
Reporter | ||
Comment 4•6 years ago
|
||
Implementation shouldn't be hard because WebM essentially is matroska: "The WebM container is based on a profile of Matroska." - Wikipedia, WebM (Also you can for example use matroska tools for webm because of this fact.) And sorry for the Typos.
Hey, I'm a webmaster trying to share content, I chose matroska and I just discovered that firefox couldn't embed it, while it works for chromium, even outdated versions (from debian jessie). Please consider supporting mkv's containers ? Please ? :( At least I would like an explanation on the technical reason here, must be one, because I'm really surprised.
Comment 6•6 years ago
|
||
Alfredo, Is it possible that we can add some telemetry to know how many attempts to play mkv format?
Reporter | ||
Comment 7•6 years ago
|
||
caniuse has no statistics about this so I think that's very difficult. The only thing I can do is to underline it's features again. And of course the fact that with WebM already some kind of Matroska support is included.
Reporter | ||
Comment 8•6 years ago
|
||
The only thing I can help with is to link the library: https://github.com/Matroska-Org/libmatroska
Comment 10•6 years ago
|
||
(In reply to Alfredo Yang (:alfredo) from comment #9) > Bug 1429986 Sweet!
Comment 11•6 years ago
|
||
(In reply to j.rios from comment #5) > Hey, > I'm a webmaster trying to share content, I chose matroska and I just > discovered that firefox couldn't embed it, while it works for chromium, even > outdated versions (from debian jessie). > > Please consider supporting mkv's containers ? Please ? :( > At least I would like an explanation on the technical reason here, must be > one, because I'm really surprised. There are no technical reasons here. We just hope the internet can be as simple as possible and hesitate to support more formats. But if it is really popular, we will consider supporting it. Bug 1429986 is to check how many attempts to play mkv on Firefox and we will check if we should support it or not.
Comment 12•6 years ago
|
||
This is fair. Thanks. I too, crave for a simpler web. I'm basically a JS hater. My surprise originally comes from the fact that I always saw heavy-browsers as "universal fileviewers", or at least, for videos. I really doubt telemetry will reveal any "heavy need", in fact I only stumbled on the issue recently, which means that I never knew. I guess my best shot is to make a turn for "webm" the "Google/Chrome format" ; guess I shouldn't feel wrong about it, it's CC-BY after all.
Reporter | ||
Comment 13•6 years ago
|
||
(In reply to Blake Wu [:bwu][:blakewu] from comment #11) > (In reply to j.rios from comment #5) > > Hey, > > I'm a webmaster trying to share content, I chose matroska and I just > > discovered that firefox couldn't embed it, while it works for chromium, even > > outdated versions (from debian jessie). > > > > Please consider supporting mkv's containers ? Please ? :( > > At least I would like an explanation on the technical reason here, must be > > one, because I'm really surprised. > There are no technical reasons here. We just hope the internet can be as > simple as possible and hesitate to support more formats. But if it is really > popular, we will consider supporting it. Bug 1429986 is to check how many > attempts to play mkv on Firefox and we will check if we should support it or > not. Exactly, that, why I proposed matroska because mp4 supports that, WebM that and ogg that, but if you have matroska you'll never need anything different, because matroska supports it all (that I think why ripped movies are mostly in mkv). The only choice you have to use JavaScript players, that support dash, have bad quality or have hundreds of different formats.
Reporter | ||
Comment 14•6 years ago
|
||
I want to add this table which shows who's the best: https://en.wikipedia.org/wiki/Comparison_of_video_container_formats
Reporter | ||
Comment 15•6 years ago
|
||
Also this might be interesting: https://en.wikipedia.org/wiki/Comparison_of_video_player_software?wprov=sfla1#Container_format_ability
![]() |
||
Updated•6 years ago
|
Updated•5 years ago
|
Comment 16•5 years ago
|
||
It seems that when google chrome records H.264 videos (MediaRecorder API) it only supports it inside matroska container and firefox can't play those files. I think it is pretty serious reason to consider matroska support besides other reasons.
Here I found the chromium issue about their implementation: https://bugs.chromium.org/p/chromium/issues/detail?id=601636
Comment 17•5 years ago
|
||
(In reply to Ignl from comment #16)
It seems that when google chrome records H.264 videos (MediaRecorder API) it only supports it inside matroska container and firefox can't play those files. I think it is pretty serious reason to consider matroska support besides other reasons.
Here I found the chromium issue about their implementation: https://bugs.chromium.org/p/chromium/issues/detail?id=601636
Well I tried to play a mkv file that is on my cloud (I use Nextcloud) and the file launch on chrome but without sound. But in the other hand, on Firefox, the player says that he can't handle this format.
So it would be cool, if Firefox supports mkv videos because as Tim said, it's usefull to have it when you are in a streaming situation like me.
Also, it would be even more cool if it supports subtitles.
PS: Here is a illustration https://imgur.com/a/mzjmcCv
Comment 18•5 years ago
|
||
(In reply to Mathieu Heurtevin from comment #17)
Well I tried to play a mkv file that is on my cloud (I use Nextcloud) and the file launch on chrome but without sound. But in the other hand, on Firefox, the player says that he can't handle this format.
same use case here. MKV support would be very useful.
Comment 19•5 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 20•5 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Updated•5 years ago
|
Comment 21•5 years ago
|
||
(In reply to Blake Wu [:bwu][:blakewu] from comment #11)
(In reply to j.rios from comment #5)
Hey,
I'm a webmaster trying to share content, I chose matroska and I just
discovered that firefox couldn't embed it, while it works for chromium, even
outdated versions (from debian jessie).Please consider supporting mkv's containers ? Please ? :(
At least I would like an explanation on the technical reason here, must be
one, because I'm really surprised.
There are no technical reasons here. We just hope the internet can be as
simple as possible and hesitate to support more formats. But if it is really
popular, we will consider supporting it. Bug 1429986 is to check how many
attempts to play mkv on Firefox and we will check if we should support it or
not.
MediaRecorder API for Safari is coming (h264 of course). For cross browser interoperability h264 will be used but because Chrome puts it in Matroska container Firefox won't play it. Because of that basically a choice for a webmaster comes down to Chrome+Safari or Chrome+Firefox support. That's really not good for Firefox. Once some novel websites that leverages MediaRecorder API doesn't work on Firefox users will be forced to switch browsers. I think it would be very smart to preemptively add Matroska support ASAP.
Comment 22•5 years ago
|
||
The webm files output by MediaRecorder
at Firefox and Chromium are dissimilar in more measurable ways than one. Firefox contains cues and duration and has a size greater than Chromium https://stackoverflow.com/questions/54651869/why-does-firefox-produce-larger-webm-video-files-compared-with-chrome/54652768. mkvmerge
is not able to merge a webm file output by Firefox with a webm file output by Chromium https://gist.github.com/guest271314/f942fb9febd9c197bd3824973794ba3e , https://gist.github.com/guest271314/17d62bf74a97d3f111aa25605a9cd1ca. Not sure if it is proper to compare the output of MediaRecorder
between Firefox and Chrome. There are several differences in the implementations.
https://wiki.mozilla.org/Media/openh264 states
OpenH264 is sandboxed for security reasons
though it is not clear at http://www.openh264.org/faq.html or https://github.com/cisco/openh264 which specific security issues are being referenced.
Is the reason the h264
codec is not available for for MediaRecorder
at Firefox a licensing issue (https://bugzilla.mozilla.org/show_bug.cgi?id=1143631; https://pagure.io/fesco/issue/1359; https://bugzilla.redhat.com/show_bug.cgi?id=1155499; https://www.mpegla.com/wp-content/uploads/n-10-08-26.pdf.)?
(In reply to Blake Wu [:bwu][:blakewu] from comment #11)
There are no technical reasons here. We just hope the internet can be as
simple as possible and hesitate to support more formats.
That is a valid point https://superuser.com/questions/1281836/what-does-matroska-have-which-webm-doesnt-that-made-the-differentiation-necess.
Chromium currently supports video/x-matroska
. The WebM version of Matroska is very limited; it can move no faster nor output a file having any less size outside the scope of VP8
or VP9
, while the container supports multiple codecs. Different combinations of containers and codecs provide solutions for different uses cases. Limiting options does not necessarily result in simplicity. The opposite can occur; where users attempt to find ways around the deficiencies of the default and exclusive containers and codecs available.
One practical reason to at least support x-matroska;codecs=avc1
and/or video/x-matroska;codecs=h264
is that the file size of the resulting webm file at Chromium using codecs=h264
or codecs=avc1
(openh264) is less than either codecs=vp8
or codecs=vp9
. The quality (pixelation; aspect ration) of the images within video where h264
is used greater than vp8
or vp9
. Is there a reason that openh264 is not supported for MediaRecorder
mimeType
?
Comment 23•5 years ago
|
||
Hi,
Just found this bug after filing my own (I searched for 'webm', not for 'matroska').
But it might be worth referring to it here: https://bugzilla.mozilla.org/show_bug.cgi?id=1562862
Basicly I made a small patch to allow 'webm' files (or matroska if you wish) to contain the h.264 video codec.
It is a small 30 line patch
Comment 24•5 years ago
|
||
(In reply to Jeroen Vreeken from comment #23)
Hi,
Just found this bug after filing my own (I searched for 'webm', not for 'matroska').
But it might be worth referring to it here: https://bugzilla.mozilla.org/show_bug.cgi?id=1562862Basicly I made a small patch to allow 'webm' files (or matroska if you wish) to contain the h.264 video codec.
It is a small 30 line patch
Hi. There is evidently confusion involved in this matter. If *oogle Chrome and Chromium have abandoned the premise of supporting only VP8 and Vorbis, specifically implemented at MediaRecorder
API, Mozilla should be able to follow suit and in fact go further than any presumed limitations which WebM purportedly specifies.
Reporter | ||
Comment 25•5 years ago
|
||
Basicly I made a small patch to allow 'webm' files (or matroska if you wish) to contain the h.264 video codec.
It is a small 30 line patch
Instead of patching unofficial codecs into webm, it would make far more sense to just make mkv happen, it's basically the same as webm but with all the codecs officially supported (so no 100 patches to add support for unofficial codecs but instead just one bigger to support them all (only at container level of course)). I don't know any codec that doesn't fit into mkv (and all of the ones Firefox supports work). With webm this goes on and on with for example subtitle and audio codecs.
Why recreate something that already exists?
Comment 26•5 years ago
|
||
I already changed the patch to allow the video/x-matroska mimetype.
This way you can already use matroska with the currently supported codecs (including h.264).
Additional codecs not currently supported would need some more work per codec anyway as decocing is done seperate from container/demuxer support
Comment 28•4 years ago
|
||
Re https://bugzilla.mozilla.org/show_bug.cgi?id=1562862#c11
One practical reason to at least support x-matroska;codecs=avc1 and/or video/x-matroska;codecs=h264 is that the file size of the resulting webm file at Chromium using codecs=h264 or codecs=avc1 (openh264) is less than either codecs=vp8 or codecs=vp9
Comment 29•4 years ago
|
||
Almost 2k20 and still many mkv cant be played on firefox. Waiting for this feature for 3 years.
Comment 30•4 years ago
|
||
I built my own search engine it indexes all of my video camera footage and it uses mkv....would be nice to actually see them in my search engine and view the footage on firefox.
Comment 31•4 years ago
|
||
I want this too, would use it on daily basis if Firefox adds MKV support.
Comment 32•4 years ago
|
||
With communities like Plex or Jellyfin, MKV is the most widely used container format. And since most people use a web browser to stream their content, Firefox not supporting MKV is a real problem. One the one hand, you really want to use Firefox for all of its benefits. On the other hand, having the server direct-play the files instead of having to transcode them would greatly improve playback and server performance.
There are thousands of users out there that would benefit from native MKV support on a daily basis.
Comment 33•4 years ago
|
||
I'm actually really surprised that firefox doesn't support this, and is even hesitant to. Like the post above me points out plex and jellyfin are very large and growing every day and the overwhelming majority of media that these serve are mkv files. I don't understand why the file container that has basically been the standard for home media for well over 10 years isn't supported. Now with the case of plex and jellyfin it isn't /that/ big of a deal because you can just remux it into another container, but I've actually come across a usecase where I actually need mkv support in my browser. It's really sad for me, but I may need to rebase my workflow around a chromium based solution if this isn't supported which I would really love to avoid.
Comment 34•3 years ago
|
||
Please support MKV! I would like to know what keeps you from doing it.
Comment 35•3 years ago
|
||
Same here please support MKV, the bug is 3 years old
Comment 36•3 years ago
|
||
It should be possible to reverse the offer and answer at https://gist.github.com/guest271314/04a539c00926e15905b86d05138c113c to stream H264 and Opus from Chrome to Firefox using RTCPeerConnection
.
Comment 37•3 years ago
|
||
I am honestly disappointed that Firefox isn't supporting Matroska, altough it is the standard for plex or jellyfin and supported by Chrome or Android. My server wouldn't need to transcode all my videos everytime I want to watch trough Firefox.
Comment 38•3 years ago
|
||
Note, technically Firefox does support playback of Matroska files with VP8, VP9, Opus codecs at HTMLMediaElement
, e.g.,
input.onchange = async ({target:{files:[file]}}) => {
console.log(file);
video.src = URL.createObjectURL(file);
}
and
video.src = '/path/to/media.mkv';
just not when navigated to at address bar and loaded as a media document or set directly; Chrome and Chromium also exhibit that behaviour; Chrome supports playback of video/x-matroska;codecs=h264
recording with MediaRecorder
and playback at HTMLVideoElement
, "tip-of-tree" Chromium does not, unless built by a distribution that affirmatively enables OpenH264 support.
Is the ultimate goal to playback H264/AVC1 in a Matroska container?
Comment 39•3 years ago
|
||
See for interoperability see also
- Issue 601636: MediaRecorder: support H264 for video encoding https://bugs.chromium.org/p/chromium/issues/detail?id=601636#c32
- Issue 1072056: The "video/mp4" mime type is not supported in MediaRecorder https://bugs.chromium.org/p/chromium/issues/detail?id=1072056#c8
Comment 40•3 years ago
|
||
There is evidently concern re patent claims https://source.chromium.org/chromium/chromium/src/+/master:third_party/openh264/README.chromium, in spite of http://www.openh264.org/.
Comment 41•3 years ago
|
||
Note: If this is ever implemented for MediaRecorder
, e.g., https://bugs.chromium.org/p/chromium/issues/detail?id=601636, CodecPrivate
is evidently a required element for H264 in Matroska container, see https://bugs.chromium.org/p/chromium/issues/detail?id=1161944.
Comment hidden (me-too) |
Comment 43•3 years ago
|
||
(In reply to Jeroen Vreeken from comment #42)
'if ever implemented' is not the problem here. I posted patches 2 years ago to make it work. Never got a single technical reply.
This is a purely political thing.
So I recommend everybody to just leave mozilla to rot in peace and use Palemoon instead as they were actually interested in a solution.
Developers in the field can build this from scratch, write the specification, if necessary, and implement this - without an official patch applied to Mozilla source code.
For example, Web Speech API does not specify a) capture of speech synthesis audio output https://lists.w3.org/Archives/Public/public-speech-api/2017Jun/0000.html; or b) SSML input parsing https://github.com/guest271314/SSMLParser; thus browsers by default stable release means do not implement either. It might take some time to arrange all of the pieces to achieve the requirement, achievable nonetheless with or without waiting on any individual or institution to do anything.
It took several years for Chrome to implenent variable pixel dimension encoding and decoding, consistently, without crashing
Here we have several options. I will share a few that I have considered and which are certainly possible using Native Messaging https://github.com/guest271314/native-messaging-mkvmerge at any browser that supports that API (Chrome, Chromium, Firefox, Nightly, I have not tried at Brave yet), or WebTransport https://github.com/guest271314/webtransport/blob/main/webTransportAudioWorkletWebAssemblyMemoryGrow.js (not implemented at Nightly that I am aware of).
- Use mpv controlled from JavaScript at the browser, precedence is mpv.js
- Use native WebRTC or just enough SDP to connect and stream from the machine controlled by JavaScript at the browser, several applications support SDP and stream creation, e.g., aoirtc, gstreamer, pulse audio webrtc plugin
- Use ogv.js
- Write everything from scratch from and in the field (deliberately avoiding creation and usage of terms of art that might confuse some users https://github.com/guest271314/SpeechSynthesisRecorder/issues/18)
What do you want to do?
All of the above can be explored concretely while maintaining this issue and others and using the browsers to find workarounds that might be capable of achieving the requirement within a given API's capabilities, yet possibly outside of the scope of any written specification that implementers decide to adopt https://github.com/guest271314/SpeechSynthesisRecorder/issues/17, https://github.com/guest271314/captureSystemAudio even if the specification is already composed by an individual outside of the consortium of organizations that are not necessarily aligned or consistent: Competing interests, some disclosed. I am well-suited to the navigate in the domain of politics. I deal with facts, not fiction or folklore. Which could very well get an individual banned for thousands of years from contributing to organizations that cannot answer questions which would expose their ignorance of the subject-matter https://github.com/guest271314/banned/issues/2 which their censorship of the term "Negro" does anyway that is, just because an individual has a title, letters, or represents some would-be lauded institution is attempting to dictate what words are "not allowed" (effectively trying to control language, while carefully omiting words they use, typical special-interest proaganda) does not mean they are the smartest people in the room, in fact in this case I am the expert on the subject matter of the fraud of "race theory", they should known better, that is why no individual or institution in the known universe has been able to repudiate the conclusions where I settled the matter using the scientific method, nor will anyone ever be able to Race theory is a fraud https://guest271314.medium.com/race-theory-is-a-fraud-45802992f5bb : End of their story.
"Choose the lesser of the evil people, and the devil still gon' win
It could all be over tomorrow, kill our masters and start again"
- Run the Jewels, A Report to the Shareholders/Kill Your Masters
Comment 44•3 years ago
|
||
is there a particular reason you are introducing irrelevant political nonsense into this discussion?
Comment 45•3 years ago
|
||
(In reply to xxrishoxx from comment #44)
is there a particular reason you are introducing irrelevant political nonsense into this discussion?
I do not post "nonsense" of any kind, so I have no idea what you are referring to.
All humans activities are political in nature.
I am pointing out that just because someone has a shiny little badge, title, or extra letters they print behind their name does not mean they are the smartest people in the room, or will make the correct decision, even if there are no sound alternatives, given the continuance of their self-interest might lay in the balance. Therefore, I reject individuals' and institutions' frauds, fairy tales, fiction, and folklore at the outset an proceed with achieving the requirement by any means. That is a sound counter to organizations' omissions, non-disclosure, failure to implement or fix an API for years.
I do not beg. I ask. In the meantime I roll my own. That is what I am saying. That requires the temerity to challenge whatever system is in place directly, yet without rancor, rather with facts, which settle all disputes. Truth does not need explanation, untruth does.
Re-read both comments. Intellectual property is a political animal: I own X idea. If I had not written my own patent claims I would have been paying at least $475 per hour for writing the archaic language of claiming ownership of thoughts. I roll my own. I have have done so up to SCOTUS, twice, by myself, where I would have been paying at least that much per hour over the course of years had I not done my own reasearch and written my own briefs, motions, answers, etc.
There is no technical reason that Matroska container including the various codecs supported by the standard/specification (EBML, etc.) cannot be implemented immediately at Firefox https://github.com/ietf-wg-cellar/matroska-specification/blob/master/codec_specs.md.
The decision not to is clearly purely political, or if you prefer, based on the risk of action by the intellectual property "owners", for example, should something go wrong, that is, the insurance game. And depending on which issue or bug you read the political matter was settled re H264 and AAC, or the matter is still ripe.
https://bugs.chromium.org/p/chromium/issues/detail?id=601636#c29
H.264 is not supported in the default Chromium build.
Anyone who turns on H.264 when building Chromium takes on the responsibility of complying with all relevant licenses; the default Chromium builders don't do this.
https://bugs.chromium.org/p/chromium/issues/detail?id=601636#c32
Copyright is not the problem. Patents are.
For some indication of what the problem might be, check out https://www.mpegla.com/programs/avc-h-264/
compare
https://bugs.chromium.org/p/chromium/issues/detail?id=1072056#c8
Yup, using a JS / wasm MP4 muxer should be possible, either from that API or by transcoding a MediaRecorder-produced webm container with H.264 video.
For audio, AAC-LC is actually now patent-unencumbered (the spec dates from 1997) and is actually the profile used for the vast majority of aac encoded content. RedHat have been shipping a modified fdk-aac for a few years now with the more recent features stripped out, which could be built for web assembly: https://src.fedoraproject.org/rpms/fdk-aac-free
So it's technically possible to get client-side mp4/h264/aac recording implemented on Chrome now without requiring patent licenses, but it still quite a bit of work to get all the parts together. This bug relates to adding support for "video/mp4" directly in MediaRecorder which would make life so much easier and avoid the need for all the support wasm / js that would be required.
see also
https://bugs.chromium.org/p/chromium/issues/detail?id=980822
A webm file should never be created with a h264 track. Only containers such as mp4, matroska, mpeg (ts or ps) can include a h264 track.
and
https://bugs.chromium.org/p/chromium/issues/detail?id=980822#c12
Notwithstanding its absence from the standard, there's a good use case for the MIME type
video/webm; codecs="avc1.42E01E"
: generating webcam-sourced video for decoding with Broadway (https://github.com/mbebenita/Broadway).There's also a valid argument that boxing formats (webm / mp4 / mov) should be implemented orthogonally to the codec bitstreams they contain.
Please don't remove this MIME type from Chromium's MediaRecorder capabilities.
The matter is still being sorted out re patent claims. Wait, or proceed, in the field as developers in spite of Chrome or Firefox? To proceed requires a decision to confront the conflicts above, and perhaps unintended consequences. I am prepared for that, politcally, physically, and if necessary supernaturally. We can build this whole thing in a GitHub repository and implement it ourselves, without asking absentee technocrats or patent attorney for permission. If you do not get what I am saying here, I don't know what to told you.
Comment 46•3 years ago
|
||
My use case is to record (server-side) WebRTC-compatible audio and video. MKV is an obvious choice that supports all of Opus, VP8, VP9 and H264 in Matroska container here and today, while MP4 compatibility with those codecs is not great.
For instance this is what happens when I try to mux VP8 into MP4 (which is technically supported) using ffmpeg that is available in Ubuntu 20.10 repos:
[mp4 @ 0x5621a55b3d00] Could not find tag for codec vp8 in stream #0, codec not currently supported in container
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
It would be be much easier if I didn't have to implement support for multiple containers just because Firefox can't include +1 library on top of already supported and related WebM. For many people this is just one more reason to not use Firefox, which makes me, Firefox user, very sad.
Updated•3 years ago
|
Comment 47•3 years ago
|
||
This bug is more relevant now with AV1 support in Firefox. The only two container formats for AV1 are Matroska and the ISO Base Media File Format (video/mp4). Since the latter doesn't support modern audio codecs such as opus, Matroska is the only other option for combining audio and video in a single file.
Comment 48•3 years ago
|
||
Even I need support for MKV very badly.
![]() |
||
Updated•2 years ago
|
Comment 49•2 years ago
|
||
Why is .mkv not yet supported. It seems to become the standard in video content encoding and delivery due to the vastly extended features compared to .webm.
Hence, I think adding support should be far up the list.
Even YouTube and other platforms seem to target .mkv for HDR content delivery.
Comment 50•2 years ago
|
||
If this is something that the team isn't opposed to, I'm happy to lend my development time towards this.
(In reply to Blake Wu [:bwu][:blakewu] from comment #6)
Alfredo,
Is it possible that we can add some telemetry to know how many attempts to
play mkv format?
I will comment on this briefly. I think you may find that the data you get may be skewed due to selection bias here, as both the Chromium (link to comment here) and Firefox do not fully support the container. As a result, people who may desire to use the format may be forced to remux or otherwise repackage their content.
Even YouTube and other platforms seem to target .mkv for HDR content delivery.
Is this the case? YT appear to allow Matroska as an input format, but I have not seen them serve media in it. I see them use WebMs.
(In reply to Chris Tam from comment #50)
If this is something that the team isn't opposed to, I'm happy to lend my development time towards this.
Redirecting to :jimm.
Comment 52•2 years ago
|
||
(In reply to guest271314 from comment #38)
Note, technically Firefox does support playback of Matroska files with VP8, VP9, Opus codecs at
HTMLMediaElement
, e.g.,
just not when navigated to at address bar and loaded as a media document or set directly; Chrome and Chromium also exhibit that behaviour; Chrome supports playback ofvideo/x-matroska;codecs=h264
recording withMediaRecorder
and playback atHTMLVideoElement
, "tip-of-tree" Chromium does not, unless built by a distribution that affirmatively enables OpenH264 support.Is the ultimate goal to playback H264/AVC1 in a Matroska container?
I couldn't make it work.
But yes, MKV support would be really nice. At least partial support with VP8, VP9 and h264 codecs.
Comment 53•2 years ago
|
||
(In reply to nicomu.net from comment #52)
(In reply to guest271314 from comment #38)
Note, technically Firefox does support playback of Matroska files with VP8, VP9, Opus codecs at
HTMLMediaElement
, e.g.,
just not when navigated to at address bar and loaded as a media document or set directly; Chrome and Chromium also exhibit that behaviour; Chrome supports playback ofvideo/x-matroska;codecs=h264
recording withMediaRecorder
and playback atHTMLVideoElement
, "tip-of-tree" Chromium does not, unless built by a distribution that affirmatively enables OpenH264 support.Is the ultimate goal to playback H264/AVC1 in a Matroska container?
I couldn't make it work.
But yes, MKV support would be really nice. At least partial support with VP8, VP9 and h264 codecs.
The last time I tested it was possible to set src of HTMLMediaElement to .mkv in HTML and the media would play.
On Firefox 90 this message is logged to console
HTTP “Content-Type” of “video/x-matroska” is not supported. Load of media resource blob:https://fiddle.jshell.net/0e434e1b-b3b4-41cd-9c8c-8a4f4a2890dc failed. _display
Cannot play media. No decoders for requested formats: video/x-matroska
We can still play the media in spite of the warning by setting Content-Type
of response or type
of new File
or Blob
to 'audio/webm;codecs=opus'
.
<!DOCTYPE html>
<html>
<head>
<title>Test Matroska with Opus audio track playback on Firefox 90 and Chromium 95</title>
</head>
<body>
<input type="file" accept=".mkv" />
<!--
Firefox 90 warning for .mkv file with one Opus audio track
HTTP “Content-Type” of “video/x-matroska” is not supported. Load of media resource blob:https://fiddle.jshell.net/0e434e1b-b3b4-41cd-9c8c-8a4f4a2890dc failed. _display
Cannot play media. No decoders for requested formats: video/x-matroska
-->
<audio controls src="test_matroska_audio.mkv"></audio>
<script>
const input = document.querySelector('input[type=file]');
const audio = document.querySelector('audio');
audio.onloadedmetadata = (e) => console.log(audio.duration);
input.onchange = async ({
target: {
files: [file],
},
}) => {
let blob;
if ('mozCaptureStream' in audio && 'CanvasCaptureMediaStream' in globalThis) {
blob = new Blob([file], {type:'audio/webm;codecs=opus'});
}
console.log(blob || file);
audio.src = URL.createObjectURL(blob || file);
};
fetch('test_matroska_audio.mkv')
.then((response) => response.arrayBuffer())
.then((ab) => audio.src = URL.createObjectURL(new Blob([ab], {type:'audio/webm;codecs=opus'})))
</script>
</body>
</html>
Comment 54•2 years ago
|
||
(In reply to nicomu.net from comment #52)
(In reply to guest271314 from comment #38)
Note, technically Firefox does support playback of Matroska files with VP8, VP9, Opus codecs at
HTMLMediaElement
, e.g.,
just not when navigated to at address bar and loaded as a media document or set directly; Chrome and Chromium also exhibit that behaviour; Chrome supports playback ofvideo/x-matroska;codecs=h264
recording withMediaRecorder
and playback atHTMLVideoElement
, "tip-of-tree" Chromium does not, unless built by a distribution that affirmatively enables OpenH264 support.Is the ultimate goal to playback H264/AVC1 in a Matroska container?
I couldn't make it work.
But yes, MKV support would be really nice. At least partial support with VP8, VP9 and h264 codecs.
Alternatively, for Opus, VP8, VP9. Theora, Vorbis; AVC/H.264/MPEG-4p10, MP3 in Matroska container does not decode.
fetch('./video.mkv')
.then((response) => {
console.log(response.headers.get('Content-Type'));
if (response.headers.get('Content-Type') === 'video/x-matroska') {
return new Response(response.body, {headers:{'Content-Type':'video/webm;codecs=vp9'}}).blob()
}
return response.blob();
})
.then((blob) => {
console.log(blob.type);
video.src = URL.createObjectURL(blob)
});
Comment hidden (advocacy) |
Comment hidden (advocacy) |
Updated•2 years ago
|
![]() |
||
Updated•2 years ago
|
Comment hidden (advocacy) |
Updated•2 years ago
|
Updated•2 years ago
|
![]() |
||
Updated•2 years ago
|
![]() |
||
Updated•2 years ago
|
Comment 59•2 years ago
|
||
I was surprised today when Firefox 100.0.2 direct-played AV1 in MKV today when testing the AV1-transcoding-capabilities of my 10600K for Jellyfin. It appears there is some level of support for MKV now.
Comment 60•2 years ago
|
||
(In reply to Roov4.email from comment #59)
I was surprised today when Firefox 100.0.2 direct-played AV1 in MKV today when testing the AV1-transcoding-capabilities of my 10600K for Jellyfin. It appears there is some level of support for MKV now.
This is just because Firefox supports AV1. Remember that the WEBM file format spec is just a pure subset of MKV, so the parser is likely just parsing the AV1 video (+ compatible audio codec) in the MKV format as valid WEBM (which it is) and playing it.
Updated•2 years ago
|
![]() |
||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 63•1 year ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates, 25 votes, 62 CCs and 16 See Also bugs.
:jimm, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Comment 64•1 year ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Comment hidden (off-topic) |
Comment hidden (metoo) |
Comment hidden (advocacy) |
Updated•8 months ago
|
Comment hidden (me-too) |
Comment 70•2 months ago
|
||
This is also requested on Mozilla Connect. See here: https://connect.mozilla.org/t5/ideas/add-support-for-matroska-media-container-mkv-files/idi-p/15935
Description
•