User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36

Steps to reproduce:

Test here: https://codepen.io/raphaelrauwolf/embed/RwoQBPV?height=265&theme-id=dark&default-tab=result

or read bellow:

1. Get user media device permissions
   navigator.mediaDevices.getUserMedia({
   audio: true,
   video: true,
   })

2. Create a new MediaRecorder with the UserMedia stream as input
   new MediaRecorder(stream, {
   mimeType: 'video/webm'
   });

3. Add ondataavailable callback to log debug messages
   recorder.ondataavailable = (e) => { console.log(e) };

4. Disable the audio track of the input stream
   const audioStream = stream.getTracks().find(track => track.kind === 'audio');
   audioStream.enabled = false;

5. Start the recorder
   recorder.start(1000);

6. Wait for the first ondataavailable callback to get fired

7. Observe the delay and blob size in the event data

Actual results:

On Firefox, when the audio track is disabled, the first ondataavailable callback is getting fired after a long time (10+ seconds) and has a large blob attached, which is fine. Even calling requestData doesn't change the outcome, only fires a ondataavailable callback with an empty blob.

Expected results:

Like with other browsers (Chrome/Edge/Safari), the expected result would be a constant stream of ondataavailable callbacks without the initial delay and actual blobs in the event data.

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

Thanks for the testcase, which shows that the delay became longer in this range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=bb81093f7e325cf33c60a2a75aa4a13c4d971c6a&tochange=b9d2b93a0c31dceb20c9a592bc7fc13d711c613d

That seems to be an intentional change.
The code is waiting for non-silent input to determine the channel count for encoding.

If a silent AudioChunk could carry the channel count from the MediaStreamTrack settings, I wonder whether that would be sufficient to initialize the decoder.

Making channel count mandatory, even for null chunks, would probably be the way forward with the broadest coverage. So we don't hit this somewhere else too.