1881826 - MediaRecorder never fires start or error if audio codec is requested in {mimeType} but no audio track is provided

Status: NEW

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

Description

[Ian Sibner]

Steps to reproduce:

Jsfiddle with a minimal repro: https://jsfiddle.net/ohdakuqL/4/

The basic steps are:

1. Obtain a display media stream (getDisplayMedia)
2. Record that stream using a media recorder

Actual results:

No 'dataavailable' events are fired on the recorder. Attempting to stop the recorder fires a start event (!!).

Expected results:

The recorder should work as it does with a getUserMedia stream. The 'start', 'stop', and 'dataavailable' events should be fired in the proper order.

Note: it is possible to work around this issue by adding any audio track to the MediaStream, as in this Jsfiddle: https://jsfiddle.net/vt8wc7nL/12/.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Recording' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Daniel Veditz [:dveditz]]

Confirming that this example works on Chrome but not Firefox.

Comment 3

[Daniel Veditz [:dveditz]]

Andreas: This is causing compat problems for Google Workspaces; can you take a look?

Comment 4

[Andreas Pehrson [:pehrsons]]

I'm heading out on PTO, maybe Jim can find someone else.

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Here's a different fiddle that works https://jsfiddle.net/jib1/y60598La/ so it's likely not ALL cases of gDM. Looking at what the differences are.

Comment 6

[Jim Mathies [:jimm]]

Tracing this back, it's been around for a long time (reproduces back to 2021).

Comment 7

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

The cause is the fiddle in comment 0 asking for opus (an audio codec) in { mimeType: "video/webm;codecs=vp8,opus" } without an audio track to record. This leaves the recorder without audio to mux. — It's been a while, but it looks intentional (recalling some still-outstanding spec ambiguity around mimetypes). Our read of the spec allow us to "Modify extendedMimeType by adding" but not removing. Happy to discuss.

But the bug is we don't surface this error and instead silently never fire the start event, which isn't great. Thanks for reporting it!

Workaround

Replace { mimeType: "video/webm;codecs=vp8,opus" } with { mimeType: "video/webm;codecs=vp8" } to only record video.

Comment 8

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Marking s3 since this has never worked, is not a regression, and a workaround exists.

Comment 9

[Ian Sibner]

Fascinating that specifying an audio codec was the bug. Thanks for tracking it down so quickly!

getDisplayMedia is an interesting case. The fiddle in comment 0 does ask for audio from the display media, but might not get it (e.g. tab audio is available in Chrome but the user could choose a window). It's a bit counterintuitive to have to check the stream for an AudioTrack in order to provide the right MimeType string.

In the meantime we'll work around it, but in general it feels less surprising (to me at least) if a MediaRecorder just ignores a codec if it doesn't apply.

Comment 10

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

In the meantime we'll work around it, but in general it feels less surprising (to me at least) if a MediaRecorder just ignores a codec if it doesn't apply.

Hi Ian, I agree with you and have tried to capture this in w3c/mediacapture-record#194 (comment), to see if we can get the spec changed here.