STR: 1. Load the attached test case 2. In the console, type mediaRecorder.start(); 3. After a second or two, type mediaRecorder.stop(); in console 4. Now type mediaRecorder.start(); in console 5. Wait a few seconds Expected The rate of ondataavailable events coming in should be in the same after starting recording in step #2 vs. step #4. Actual The rate of ondataavailable events is adnormally high after step #4 in comparison to step #2. After step #2, waiting a few seconds might have 5 to 6 ondataavailable events. After step #4, waiting a few seconds might have 30+ ondataavailable events.

I checked the GetEncodedData() and it returns small bytes array after 2nd start. Discuss with slin, she says after remove the encoder listener, the status will enter stopped. So We may need to 1. have a reset function in encoder 2. re-create new encoder and forgot older one. Hi Roc, How do you think about this?

Once the encoder is removed from the MediaStreamGraph, it then stops encoding and terminates the container writer. Restart the encoder without re-initializing track encoders and container writer does not function proeprly for the current design.

I think you should recreate the encoder.

Always create encoder on start function.

carry reviewer.

https://hg.mozilla.org/integration/mozilla-inbound/rev/cafd483cc3cf Please fix your hg configuration so your name is set to "Randy Lin <rlin@mozilla.com>" instead of "<Randy Lin> rlin@mozilla.com". Also, a friendly reminder that your commit message should summarize what the patch is doing, not just restate the bug title.

Tested using comment 0's STR. I'm not seeing the spike immediately on start of recording the 2nd time, but instead, I'm immediately seeing a crash quickly on the 2nd time we record. See bug 894413 for a followup.