mcasas@ I can repro this fairly easily, and it seems to happen only when audio is added as well. More interestingly, as soon as the tab goes inactive we stop getting ondataavailable calls - even though the audio stream should trigger them. Is there any design assumption on that we'll get video frame regularly? 

@niklase that is *exactly* what we're seeing. I figured the audio activity would fire ondataavailable calls.

#1: MediaRecorder will record incoming video and audio 
as it comes, with no particular assumptions on its 
cadence or periodicity, and no control on it either.
IOW if the MediaStream Track(s) do no deliver data,
there's nothing MR can do about it.

From the description of the situation, it seems like a
Tab pauses altogether sending data to the associated 
capturing MediaStream Tracks when sent in the background.

The crash in the extension and/or the recorder going
south when getting fresh data is something else. May I
asked niklase@/vinay@ to send a crash report? I think that
if you launch with the flag --single-process, a crash will
take down the whole browser and it'll show up in 
chrome://crashes/ tab, please paste the crash ID here and
I'll take a look.

It looks like you get crash reports even in normal mode, check out

90ac3e4b00000000
e99f9a5900000000
27f82c069b00000000

Also, this seems to happen also without specing interval parameter, but the behavior seems somewhat different. Instead of crashing quickly it locks up the tab while the Recorder app CPU spikes for a while.

FTR, same signature as
https://bugs.chromium.org/p/chromium/issues/detail?id=627529
https://bugs.chromium.org/p/chromium/issues/detail?id=606648

Hey @mcasas other than running Chrome with the --single-process flag, is there anything I need to enable to get you the crash log other than getting you the ID?

vinay@, I think we're good since we can repro this internally.

Awesome! Let me know if I can help in any way.

Hey guys so another one of our users has an issue where the MediaRecorder does not actually give us any blobs at all. Sometimes it fixes itself if he restarts his browser, but it will end up in a state where it begins to not hand out blobs again. Would you like me to open a new issue with his browser/OS version and any other info? He would like to remain anonymous, but I can ferry any requests you guys have to him.

We've actually seen this issue (which may be separate from the issue here) from a couple other people who do not have the most up-to-date OS (Windows 8, OSX 10.10.5, etc.), but I'm not sure if that's relevant or not.

Re. #11, plz file in a new crbug.com/new and make sure
the component is Blink>MediaStream>Recording, so it's correctly
routed/ triaged.

From the first crash in #5, it seems like the problem is in a
certain:
  observer->contextDestroyed();
that jumps to ~MediaRecorderHandler() and then to ~WebmMuxer().
The crash signature is shared by many other bugs (see #7), so
this might some side effect of a funky destruction sequence. Is
the MediaRecorder being instantiated in the extension or in other
JS? 

Would it be possible to have a minimal repro case to see if
the culprit is MediaRecorderHandler or is something else?

I think the actual crash sometimes happen after the real problem, sometimes not until you close the app/page. The callbacks lock up much sooner. What I do to repro:

1. Install and launch https://github.com/niklasenbom/RecordingApp. For a cleaner repro case change app.js, recorder.start(); to recorder.start(500);
2. Check "Include Microphone Audio"
3. Click "Record Chrome Tab" and select another open tab with static content (no ads etc)
4. Scroll the tab a bit, put it in the background
5. Wait 20 secs, click on the shared tab

It helps to add a console log for recorderOnDataAvailable

In our case, the MediaRecorder instance is created and destroyed in the same place (in the background script). We ensure that only one MediaRecorder instance is live at any given time and destroy that instance on any errors during the recording or if a recording is finished or canceled.

@mcasas - created bug for other issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=654910

I was not able to attach a component through that bug creation flow at crbug.com/new. Sorry about that!

Tried to repro by following the steps in #14 and ToT (#425839). 

Found no crash, MediaRecorder did recover always, however when 
I kept the recorded tab in the background for a while (>10s 
approx), I could see logs like this:

[35997:35997:1018/145438:WARNING:video_capture_oracle.cc(256)] Out of order frame delivery detected (have #272, last was #273).  Dropping frame.

... recording logs meaning recording OK...

[35997:35997:1018/145452:WARNING:video_capture_oracle.cc(256)] Out of order frame delivery detected (have #280, last was #281).  Dropping frame.

... recording logs meaning recording OK...


[35997:35997:1018/145452:WARNING:video_capture_oracle.cc(256)] Out of order frame delivery detected (have #282, last was #283).  Dropping frame.
[1:2:1018/145452:VERBOSE1:video_track_recorder.cc(338)] non keyframe 66639B, 5547520153682 bogo-microseconds ms
[1:1:1018/145452:VERBOSE1:webm_muxer.cc(131)] OnEncodedVideo - 66639B
... etc...

vinay@, is there any way you could try to repro with a recent
Canary and see if the error/crash is still there?

For the record, I used the command line

./out/gn/chrome -vmodule=*_recorder*=1,*webm*=1 --use-fake-ui-for-media-stream https://www.linuxtv.org/downloads/legacy/video4linux/API/V4L2_API/spec-single/v4l2.html#v4l2-queryctrl

erickr@, miu@, re. #17: it seems like the VideoCaptureOracle
sees frames out of order when the tab has been in the background
for a while, is this expected?

This should not happen. In the past, this indicated a compositor bug. So, maybe that has regressed again. Ugh. However, there's another possibility I saw once before, and meant to look into: When the mouse cursor is moved, frames will be force-captured. There might be a logic issue where the "subscriber-captured" frames are coming out-of-order w.r.t. the force-captured frames. Nevertheless, the out-of-order frame delivery logic should prevent problematic video frames from being delivered downstream from the browser process: As the logs indicate, it will drop old frames.

mcasas@ I can repro for you with a recent Canary later in the evening. Currently I have my own fire to put out for Opentest that's causing our recording services to become increasingly latent over time (with no jump in memory or CPU). Fun! :P

@mcasas I added the Canary - do you know what the equivalent command on Mac is? Would it just be:

open Google\ Chrome\ Canary.app -vmodule=*_recorder*=1,*webm*=1 --use-fake-ui-for-media-stream

?

#21: I think Canary has debug logic stripped, the command line only
applies to a Chromium local build, and in that case the executable
is under ./out/gn/Chromium.app/Contents/MacOS/Chromium, assuming
the build output folder is out/gn.

#22: Ok cool. Am I looking in the right place?

https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/

Latest hash?

#23: Canary is always auto updated to the latest version,
which can be checked in https://omahaproxy.appspot.com, the
link you provided is storage for e.g. bisect scripts.

I think that  https://crbug.com/675521  had the same root cause
and it has been Fixed, so probably this bug is fixed as well.

I ran the steps in #14 for quite a while and could not crash 
at all, *although* we're still getting frames out of order:

[20594:20594:0106/172240.429431:WARNING:video_capture_oracle.cc(260)] Out of order frame delivery detected (have #337, last was #338).  Dropping frame.

Preventively marking as Fixed, vinay@opentest.co, could you
please confirm or reopen? Thanks!