1631143 - The "video/mp4" mime type is not supported in MediaRecorder

Status: NEW

(Core :: Audio/Video: Recording, enhancement, P2)

Description

[Alexis Deveria]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

Create a MediaRecorder with options {mimeType: "video/mp4"}
Demo available at https://codepen.io/Fyrd/pen/LYpZYBM

Actual results:

Got the following error: NotSupportedError: MediaRecorder constructor: video/mp4 indicates an unsupported container

Expected results:

Recording should work and produce a valid video/mp4 file

Comment 1

[Tobias]

The mime type video/mp4 is not supported on any browser but video/webm;codecs=h264 is a supported options which is already working in Chrome.

Recording to h264 (which you are proposing) is already supported for WebRTC streaming and should really be added to MediaRecorder because VP8 recording of large screens (macOS retina devices) is really sluggish as there is no hardware support for encoding.

Comment 2

[Alexis Deveria]

Yes, I understand. My reason for the request is the app I work on (Adobe Spark Video) currently only accepts mp4 as input files as we use client-side trimming code to reduce upload size. Since our trimming code only works for mp4s and we'd like to include recording via webcam, it would be ideal for us if MediaRecorder could simply encode to mp4 as well.

I should also note that Safari does support video/mp4 when MediaRecorder support is enabled (via Experimental Features).

Comment 3

[chaser mina]

This is also what I look for in terms of sound. https://radiofrench.fr/ is what I would recommend to everyone.

Comment 4

[Mahesh Kini]

Hey team,

Can you take a look at this ? We're seeing this issue on the latest version of firefox [133.0 (aarch64)]. Other browsers like Safari, chrome support this container format, and on Firefox, we continue to see this error.

MediaRecorder constructor: video/mp4; indicates an unsupported container

The demo app posted above https://codepen.io/Fyrd/pen/LYpZYBM can be referred to to observe the error.

Is this something that you are willing to fix anytime soon ?

Thanks
Mahesh

Comment 5

[Jim Mathies [:jimm]]

Moving this into 2025 media team planning.

Comment 6

[Jim Mathies [:jimm]]

We don't support an mp4 muxer. Something we could add but not a huge priority. Alexis is this critical to something one of your services is doing?

Comment 7

[Alexis Deveria]

I'll let Mahesh answer that, as the request now comes from the successor of the application I originally filed this bug for.

Comment 8

[Mahesh Kini]

Hello Jim, our service intends to allow users to self record video and share it with other users of the service. The feature to self record video entails streaming audio and video inputs only from webcam (embedded/exrternal) and microphone (internal/external). In the future, we'd also want to add the ability to introduce captions/subtitles as well. For this we've been using MediaRecorder APIs. I am not sure if mp4-muxer is needed for the MediaRecorder functionality to work well.

Comment 9

[C.M.Chang[:chunmin]]

One alternative is to use the WebCodecs VideoEncoder and AudioEncoder for encoding video and audio, then rely on a third-party muxer - such as https://github.com/videojs/mux.js - to package the encoded data into MP4 files.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

It looks Chrome shipped this somewhat recently: https://chromestatus.com/feature/5163469011943424

Comment 11

[Jim Mathies [:jimm]]

We can add mp4 support, but it's another 3rd party library we'd have to integrate. That's not something we do unless there's advantages to it.

Comment 12

[Shailaja]

Hi Jim & Jeff - As Mahesh mentioned, we'll need mp4 support to enable the feature in Firefox. Until then, since we are unable to show the feature in Firefox, and we are requesting users to navigate to different browsers to access the feature. Please do keep us posted on any updates to your roadmap, thank you

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.