[Rethink] Support mkv|matroska|video/x-matroska in Firefox

UNCONFIRMED
Unassigned

Status

()

defect
P3
normal
UNCONFIRMED
2 years ago
6 days ago

People

(Reporter: tim.langhorst, Unassigned)

Tracking

Trunk
Points:
---
Bug Flags:
webcompat ?

Firefox Tracking Flags

(Webcompat Priority:?)

Details

(Whiteboard: [webcompat])

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.
Component: Untriaged → Audio/Video
Product: Firefox → Core
See Also: → 476727
(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.
No mp4 does not support opus,only vp9 inofficially. Tested with ffmpeg.
Component: Audio/Video → Audio/Video: Playback
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
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.
Alfredo,
Is it possible that we can add some telemetry to know how many attempts to play mkv format?
Flags: needinfo?(ayang)
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.
The only thing I can help with is to link the library: https://github.com/Matroska-Org/libmatroska
See Also: → 1429986
Bug 1429986
Flags: needinfo?(ayang)
(In reply to Alfredo Yang (:alfredo) from comment #9)
> Bug 1429986
Sweet!
(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.
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.
(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.
I want to add this table which shows who's the best: https://en.wikipedia.org/wiki/Comparison_of_video_container_formats
Flags: webcompat?
Whiteboard: [webcompat]

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

(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

(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.

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

(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.

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?

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

(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=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

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.

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?

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

Duplicate of this bug: 1551765
You need to log in before you can comment on or make changes to this bug.