As of today, having a MediaDecoder send audio and video to a MediaStream stops the audio playing to speakers. HTMLMediaElement::CaptureStream shouldn't stop audio playback of the media element per its spec, http://w3c.github.io/mediacapture-fromelement/. However, WebAudio's MediaElementAudioSourceNode should still stop audio playback of the media element per the WebAudio spec, http://webaudio.github.io/web-audio-api/#idl-def-MediaElementAudioSourceNode A discussion on solving this started in bug 1172394, which later became invalid. Let's continue here.

Bringing the discussion over here. (Maire Reavy [:mreavy] (Plz needinfo me) from comment #10) > (In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #6) > > I put together some cases and solution ideas in [0] Maire, do you want to > > check it out before inviting people? > > > > [0] https://etherpad.mozilla.org/capturestream-cases > > Thanks, Andreas. Your writeup is clear and concise and much appreciated. > > Paul - can you read over Andreas's writeup, in particular his proposed > solutions and weigh in on which one you prefer. > > NeedInfoing roc and jesup for their awareness and suggestions. Thanks (Randell Jesup [:jesup] from comment #11) > Seems reasonable, thanks. I'm tempted by the c++ 'polyfill' idea

I'm not sure what the question is. I'm fine with implementing this as specced, and I don't think it will be hard to do; we just need an internal HTMLMediaElement::CaptureStream method that takes a parameter indicating whether to stop audio playback.

Yeah same, I generally agree that this is what we should do, and an additional enum parameter in CaptureStream sounds good to me.

We can't tell how urgent this is. Can you provide a usecase?