User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

1. Obtain a display media stream (e.g. the entire screen)
2. Create a MediaRecorder object for the stream with the "video/webm;codecs=vp8,opus" as MIME type
3. Start the media recorder wit

Actual results:

Following the starting of the media recorder above, no "start" or "dataavailable" events are ever fired, requestData will also only return zero-sized blobs.

Expected results:

What should happen is media recording.

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

The stream must not contain an audio track, that's critical for this bug report.

Thanks for the bug report and test case. I can reproduce this locally, and (per comments in the test) removing opus from the mimeType causes the test case to work as expected.

In the failing case (with opus included), it looks like Firefox's internal MediaEncoder never completes initialization as there's no audio track in the MediaStream to connect. The last thing logged is UpdateInitialized waiting for audio.

The test case is requesting a MediaRecorder for two tracks (vp8 and opus) and the MediaStream passed in only has a single (compatible) video track. From my limited understanding, either step 13 in the start algorithm applies (which seems not to be the case, since the single video track is compatible with webm and vp8) or the audio track should be generated as silence per this quote later in the start algorithm: "If any Track within the MediaStream is muted or not enabled at any time, the UA will only record black frames or silence since that is the content produced by the Track." (although it's not clear if that applies to tracks that aren't currently present in the MediaStream, since they are neither muted nor disabled).

Bryce or Andreas, any suggestions please?

I recall the spec discussion went along the lines of following the mime type to the letter because the site developer knows best, and allowing to catch errors early. As in if a vp8+opus mime type was passed in but on start() only a video track is present, this is an error because we were told to use opus but there is no audio track to use it on.

But now the spec says For each track in tracks, if the User Agent cannot record the track using the current configuration, then throw a NotSupportedError DOMException and abort these steps. which is not really along those lines, since we shall only check whether the video track can be recorded.

I'll need to revisit this and dig in deeper on how the discussion went, what the history says, and what has happened since.