Cross-referencing https://bugs.chromium.org/p/chromium/issues/detail?id=654595#c12 since mcasas@chromium.org told me to attach the component:

Blink>MediaStream>Recording

to this issue. Unfortunately I did not see the component option when creating this post. :-\

Hey guys just as a head's up I may be able to reach out and see if any of our other users are experiencing this and willing to talk to any of y'all. Just let me know.

I'm also seeing this issue for about 5% of our users. On Chrome only, the MediaRecorder loads fine but then never fires ondataavailable events during recording. The only solution seems to be completely restarting the browser. Refreshing the tab does not fix the issue.

#6: Do you ever see empty data events being fired? That's what this bug is about, but I feel like if you see no data events getting fired at all it's potentially related.

On #6: if no ondatavailable events are being fired at all (as opposed 
to ondataavailable events being fired with empty data buffers), the
most likely situation is that the video is waiting for the audio or 
viceversa. In this cases, please verify that every tracks' |muted| is
false, and their |readyState| is "live", as a preliminary check.

#7: After logging, it seems that the ondataavailable event is never being fired. 

#8: I'll add some more testing to investigate further.

#9: how are you reproducing that, out of curiosity?

#10: I'm unable to consistently reproduce it locally so I've been looking at the logs from production deployments.

#11: Gotcha! Keep me posted. Was going to run Canary locally and try to get those logs but got dragged into a bunch of stuff. Really sorry about the holdup, but I'm not sure how much time I'll have over the next week or so. Scaling a startup is hard. :-\

Hey guys I have a user of Openvid (our Chrome extension) who is able to reproduce this issue. Would I be able to connect him to someone via email? If so, who would that be? Just want to see if we can nail down this bug.

Hey guys bump here?

#14 apologies we have been swamped of late with the ramp up to EOY.
Did you get some answers to #8 to help narrow the problem? Also,
if the user is having a Mac, it could not be unthinkable to use a
Chromium build and collect the Logs, wdyt?

I'm not sure what the technical prowess of this user is. I figured it'd be easier for the ask if they were conversing with someone directly on the Chromium team (if you guys don't mind me connecting you both over email). That way you could give them detailed instructions on how to get Canary and collect those logs (if they're not technically savvy then you could always ask them to jump on a Skype call). What do you think? I'd do this for you, but then I feel like there's another level of indirection. Figured it'd be worth it since it's tough for any of us to faithfully reproduce this bug.

vinay@: we'll be happy to interact via this bug ISO via
a parallel email conversation (although they can also use
chromium-dev@). The reason is simple: everything related
to this API and its implementation is public and it's best
if the resolution process is logged for future reference.

@mcasas: I completely understand. It's just tough to get our users (some of who aren't technically savvy) to go through a bug-tracking interface. I'll connect you with the user - does mcasas@chromium.org work or do you prefer another email address?

#18: correct, mcasas@chromium.org and then make sure 
chromium-dev@chromium.org is cc (or, I'll do it). Still,
better if replies come in this bug :-)

@mcasas: I have a user who is able to *faithfully* reproduce this bug. I am forwarding an email to both of you right now.

Bulk move
Blink>MediaStream>Recording ---> Blink>MediaRecording

@mcasas: any update on the email I sent connecting you and the previous person I had mentioned?

#23: Didn't receive any email :(
JIC: Send it to mcasas@chromium.org, cc:chromium-dev@chromium.org.

Huh that's who I sent it to!

Deleted: Screen Shot 2017-01-18 at 12.22.16 PM.png 69.2 KB

	Screen Shot 2017-01-18 at 12.22.16 PM.png 69.2 KB View Download

@mcasas: any update? Maybe you deleted the email by accident? I've been having quite a few other users experience this issue recently. I'm happy to forward someone else over too.

Snippet below did not work in chrome using latest Version 55.0.2883.95 (64-bit) on Mac OS Sierra 10.12.2 (no 'data avail' logged to console). When I replaced { video: true, audio: true } by { video: true} then it worked well. Reading the other comments, I exited chrome completely then everything started working again...


<!DOCTYPE html>
<html>
<body>

<script>

    function handleDataAvailable(event) {
        console.log('data avail');
    }

    function startRecording(stream) {

        var options = {mimeType: 'video/webm;codecs=vp9'};
        mediaRecorder = new MediaRecorder(stream, options);
        mediaRecorder.ondataavailable = handleDataAvailable;
        mediaRecorder.start(1000);

    }

    navigator.mediaDevices.getUserMedia({ video: true, audio: true }).then(startRecording);

</script>
</body>
</html>

Yep just ran into this as well. Restarting worked, but this is the first time I've ever gotten it. My guess is that something recent shipped with Chrome that has increased the likelihood of this bug happening.

Hmm I tried that snippet in both Canary and Stable on a Mac 10.12.2 
and couldn't repro.  When both video and audio are expected (because 
of the #tracks of the MediaStream |stream|), WebmMuxer will wait for
audio encode and video encode _both_ to be present before writing 
anything (which bubbles up to ondataavailable).  With webm_muxer traces
on, this would translate into e.g. 

[2120:775:0123/081118.556756:VERBOSE2:webm_muxer.cc(171)] OnEncodedAudio - 289B
[2120:775:0123/081118.557153:VERBOSE1:webm_muxer.cc(249)] AddAudioTrack format: 1 channel_layout: 2 channels: 1 sample_rate: 48000 bits_per_sample: 16 frames_per_buffer: 2880 effects: 0 mic_positions: 
[2120:775:0123/081118.557813:VERBOSE1:webm_muxer.cc(183)] OnEncodedAudio: delaying until video track ready.
[2120:775:0123/081118.617170:VERBOSE2:webm_muxer.cc(171)] OnEncodedAudio - 358B
[2120:775:0123/081118.617435:VERBOSE1:webm_muxer.cc(183)] OnEncodedAudio: delaying until video track ready.
[2120:775:0123/081118.678772:VERBOSE2:webm_muxer.cc(171)] OnEncodedAudio - 383B
[2120:775:0123/081118.679889:VERBOSE1:webm_muxer.cc(183)] OnEncodedAudio: delaying until video track ready.
[2120:775:0123/081118.689924:VERBOSE1:webm_muxer.cc(139)] OnEncodedVideo - 279B
[2120:775:0123/081118.729232:VERBOSE1:webm_muxer.cc(139)] OnEncodedVideo - 2663B
[2120:775:0123/081118.739368:VERBOSE2:webm_muxer.cc(171)] OnEncodedAudio - 383B
[2120:775:0123/081118.795731:VERBOSE1:webm_muxer.cc(139)] OnEncodedVideo - 1377B
[2120:775:0123/081118.816607:VERBOSE2:webm_muxer.cc(171)] OnEncodedAudio - 383B
[2120:775:0123/081118.836786:VERBOSE1:webm_muxer.cc(139)] OnEncodedVideo - 940B
[2120:775:0123/081118.866693:VERBOSE2:webm_muxer.cc(171)] OnEncodedAudio - 383B
[2120:775:0123/081118.920951:VERBOSE2:webm_muxer.cc(171)] OnEncodedAudio - 383B
[2120:775:0123/081118.928420:VERBOSE1:webm_muxer.cc(139)] OnEncodedVideo - 1315B
[2120:775:0123/081118.978875:VERBOSE2:webm_muxer.cc(171)] OnEncodedAudio - 383B
[2120:775:0123/081118.993694:VERBOSE1:webm_muxer.cc(139)] OnEncodedVideo - 1979B
[2120:775:0123/081118.994117:VERBOSE1:media_recorder_handler.cc(318)] Slice finished @ 27697393225 bogo-microseconds


So, it might be that the audio is not being produced correctly and/or 
not being received correctly at the muxer level. IOW this problem might 
be a systemic one of audio not-ok.  I wonder if either of you could 
build a Chromium or download one (https://download-chromium.appspot.com/)
and run with e.g.:

  -vmodule='*recorder_handler*=2,*webm*=3,*track_recorder*=2' 

to see these traces; if "delaying until video track ready" (resp. audio)
is repeatedly seen (coming from [1,2]), it means that audio is not being
encoded correctly...

[1] https://cs.chromium.org/chromium/src/media/muxers/webm_muxer.cc?q=webm_muxer.cc&sq=package:chromium&dr&l=152
[2] https://cs.chromium.org/chromium/src/media/muxers/webm_muxer.cc?q=webm_muxer.cc&sq=package:chromium&dr&l=183

Running the binary from https://download-chromium.appspot.com/, where should I look for your traces? I don't see any and my snippet runs fine...

~/Downloads/chrome-mac/Chromium.app/Contents/MacOS $ ./Chromium  -vmodule='*recorder_handler*=2,*webm*=3,*track_recorder*=2'
2017-01-23 17:54:30.717 Chromium[46322:4221351] NSWindow warning: adding an unknown subview: <FullSizeContentView: 0x7fd2730cb2c0>. Break on NSLog to debug.
2017-01-23 17:54:30.717 Chromium[46322:4221351] Call stack:
(
    "+callStackSymbols disabled for performance reasons"
)
2017-01-23 17:55:13.511 Chromium[46322:4221351] Couldn't find or read strings file SlicesStrings
2017-01-23 17:55:32.248 Chromium Helper[46334:4221733] Couldn't set selectedTextBackgroundColor from default ()

Oh rats! Probably the Chromium build is compiled with NDEBUG so it
won't show up. Compiling it would be the only option, just in case
I'm trying to add a Chromium.dmg local build.

fails at runtime

~/Downloads/chromium-built_with_debug/Chromium.app/Contents/MacOS $ ./Chromium  -vmodule='*recorder_handler*=2,*webm*=3,*track_recorder*=2'
dlopen /Users/chris/Downloads/chromium-built_with_debug/Chromium.app/Contents/MacOS/./../Versions/58.0.2991.0/Chromium Framework.framework/Chromium Framework: dlopen(/Users/chris/Downloads/chromium-built_with_debug/Chromium.app/Contents/MacOS/./../Versions/58.0.2991.0/Chromium Framework.framework/Chromium Framework, 261): Library not loaded: @rpath/libchrome_dll.dylib
  Referenced from: /Users/chris/Downloads/chromium-built_with_debug/Chromium.app/Contents/Versions/58.0.2991.0/Chromium Framework.framework/Chromium Framework
  Reason: image not found
Abort trap: 6

Double rats! The packaging script for Chromium builds is not 
maintained anymore, so the only remaining option is to compile
a Chromium, chris@ have you done that before?

no never :( 

may be u can compile for me on your macOS 10.12.2 machine and send over?

#35: then please follow [1].  It's going to take a while, in // I'll
try to resuscitate the packaging script and repackage a Chromium.dmg

[1] https://chromium.googlesource.com/chromium/src/+/master/docs/mac_build_instructions.md

Sorry, I cannot do the built it's gonna drag me too far.... but I'll wait for your new binary

Got it compiled and packaged again - I forgot I had my build in 
component mode, and (our) packaging only works in static linking 
mode.

Uploaded to https://drive.google.com/open?id=0B82Jhdx0kSTVeFlDZzVZUjJ0M1U

./Chromium  -vmodule='*recorder_handler*=2,*webm*=3,*track_recorder*=2' 2> chromium.log

file attached

~/Downloads/chromium-built_with_debug_static_link/Chromium.app/Contents/MacOS $ ./Chromium  -vmodule='*recorder_handler*=2,*webm*=3,*track_recorder*=2' 2> chromium.log

file attached

Deleted: chromium.log 76.5 KB

chromium.log 76.5 KB View Download

Reading the logs in #42, it's a correct recording sequence, right?

As the log shows ('data avail' logged), it's indeed a correct recording sequence. In other words the handleDataAvailable function from the snippet #28 is correctly triggered. The bug hasn't showed up since I restarted chrome half way through my post #28

I will need to wait until later this evening to get you a log, but I will say that we currently do the following sequence:

1. Create the video stream (screen or cam)
2. Create the audio stream
3. Take the track from the audio stream and add it to the video stream
4. Pass the resultant stream into the MR

So I will try testing this specific sequence later tonight. Restarting the browser works for some individuals but not all.

@mcasas: any update on the two individuals I sent to you? Could you send them instructions perhaps on how to get you logs? It seems like they can reproduce 100% reliably, so if things are fixed on their end with the latest build and this code as well as code running the sequence I outlined above, it could be that the issue is resolved. That seems like a better marker to test here given how often those individuals run into the issue.

#46: the best option is to open the Chromium build in #39 and
run it like in #42 (with or without redirection to log file).
Hadn't got much traction on the mail side :-/

Another thing that came to mind is that if you make a MediaStream
_but_ dont cast it to a <video> tag, in some cases (Android?)
that marks the individual tracks as inactive. Could you please 
make sure about their status, e.g. in Chrome

stream.getTracks().forEach((track) => { console.log(track.readyState); })

and that their |muted| attribute is false. Otherwise probably
we'll be waiting for the audio/video forever. (That's a good
check to add to the WebApss anyhow).

To answer comment #47, when I worked out the minimal snippet the video tag didn't change anything to the bug (I tested with and without the tag).

#47: I will go ahead and test this, but I think getting these individuals to test is going to be key if possible. Namely, because they are the only ones I've seen of our 60k+ users who can reliably reproduce the issue. It would be the surest thing to shed light on the situation. Otherwise I believe we're going to continue to have this issue popup and push off figuring out the root cause since the issue is inherently unreliably produceable for everyone in this thread.

@mcasas: I have re-pinged Justin (second email I sent to you/second user).

@mcasas I pinged Justin West (the second user I sent you) and he said he never got an email from you. Do you need me to ferry instructions over? We've been seeing this bug more often and I really think it's something that shipped recently.

Regarding #47, our Chrome extension only runs on desktop. For checking `readyState` on the track, what would the order of operations be? That if `readyState` is not good or `muted` is applied to the track, we should show the user an error saying we couldn't grab audio from their microphone? Does this potentially mean a mic driver bug has been shipped to Chrome?

@mcasas: also I tried downloading the DMG but it gets stuck right at the end of the download. Any ideas?

So I just canceled the download at the very end, renamed the file as a DMG and ran the command. Logs attached. Everything worked fine until I ended the recording which crashed Chromium (I used the Loom extension to test this - I log data events to console when they come through so you can see at the very end there's an empty data event, but that seems ok - I only error out on 10 consecutive empty data events).

The error that crashed it was preceded by:

"WARNING:audio_low_latency_input_mac.cc(1679)] AU in: Total glitches=1. Total frames lost=659 (15 ms)"

I did notice a bunch of

"[3694:775:0124/033016.125512:VERBOSE1:webm_muxer.cc(183)] OnEncodedAudio: delaying until video track ready."

near line 535. You had mentioned that the users affected by this issue may have bad audio issues, but it's been happening to a lot of our users (including myself very rarely but more often than before), so, per #50, maybe I just need to be doing `readyState` checks?

Woops forgot to include the log.

Deleted: chromium.log 255 KB

chromium.log 255 KB View Download

#52, #53: yeah, the crash is unrelated and the logs of the Audio
being delayed until the Video are harmless as long as the video
eventually arrives, which it does, so those logs correspond to a
successful recording session.

@mcasas:

I had a user run Chrome locally with the same commands and leave the debug log to grow. They provided me with some information when these empty data events get raised. It seems like the logs are short so I'm not sure what happened to a lot of them, but hopefully this info gives you a hint as to what's going on here.

The attached image is the error he said he saw when it was happening:

IOVARendererID property not found

But I looked at the logs (also attached) and I saw:

WebContentsDelegate::CheckMediaAccessPermission: Not supported.

show up a lot more. Again, the logs seem short so I'm not sure if these are related to the issue for sure, but he seemed confident that these things happened when he started getting empty data events.

I'm thinking of restarting my Chrome instance (not Chromium) and then leaving it running for when I run into this issue as well. Hopefully I uncover something useful.

Deleted: chromium.log 21.8 KB

chromium.log 21.8 KB View Download

Deleted: image.png 64.6 KB

	image.png 64.6 KB View Download

@mcasas: Any additional update here? Are you guys seeing an increased prevalence of this error? I ran the numbers on our support tickets, and this issue has shot up in prevalence by almost 350% since last month. That's way too high at our user base (75k people) for it to be a coincidence. What else can I do to help man? I'm a little desperate to be completely honest, and I know your hands are full with other bugs, but this one in particular has become a lot worse. If you need me to do something else, I'd be happy but some feedback would be good to rest a worrying soul. :-P

#56: repro'ing locally or getting the logs while being reproduced
remotely are the only ways. #55 doesn't seem to be a working 
recording session at all, since there is no webm_muxer,
media_recorder_handler or video/audio_track_recorder logs.

My browser is currently in this state, we are using MediaRecorder with video and audio track. But the ondataavailable callback was never called. However, when I switched to a video-only stream with getUserMedia, the callback will be called again. 

We (Flipgrid.com) have also been seeing an increasing amount of customer-reported issues caused by this since we started using WebRTC from August 2016 (roughtly 5% of our support tickets). As mentioned from #6, restarting the browser has been the only reliable way to fix this. We are not able to reliably replicate this. I also opened Chrome Canary and tried to record a video+audio stream, and it worked. So I'm thinking it's not an OS issue. 

I'm not going to close my Chrome for now, but is there a way to turn the logging on without restarting the app with a flag? 
Please let me know if I can be of assistance. 

#58: that would be great (a way to get logs when the process has already started).

My guess is that the audio MediaStreamTrack, does not produce any data. As a consequence as per #30, the webm muxer fails to work too, waiting for audio indefinitely. 

This would be consistent with what we observed with using MediaStreamAudioTrack from NaCl. In this case, MediaStreamAudioTrack::GetBuffer callbacks never get called.
I was able to reproduce this once on a Windows test device immediately after a Chrome update with an external mic (but unfortunately never again since rebooting). IIRC neither NaCl MediaStreamAudioTrack::GetBuffer, nor MediaRecorder.ondataavailable got called in this state, nor did the WebAudio API receive anything, while the mic did still show activity in the level indicator in Windows sound settings.


Might be related to:  https://crbug.com/637558 

guidou@, what's the best way to see from the JS layer if a
given Audio MediaStreamTrack has stopped sending data for
any reason? (I see that |muted| is not wired for audio tracks).

Any updates on this? Ran into mic issues and checked `muted` which was still false. Not really sure how else to check. `readyState` and `enabled` also indicate that the mic is ok

Looking for an update on this too. We seem to see it more with users that have multiple audio/video devices. We're working on logging device data more accurately and will be able to post logs once we get it on prod.

#64: I would too. I tried doing the mic check/warn the user before they start recording, but that doesn't seem to work (all audio tracks seem valid/not muted). I haven't had much luck or visibility into what's going on with this bug.

We have bumped into this issue it seems, specifically on Windows. Anyone had any progress?

#66: You should take a look at the microphone on Windows vs. the other OS you're testing on. It's happened to us on all platforms. I believe it's a mic connection issue b/w Chrome and the driver.

And when I say "mic connection issue", I don't mean with your computer. I mean that Chrome has specifically lost connection or something is borked there. A restart of Chrome fixes it, but it is a really bad experience for those who build extensions that rely on the MediaRecorder. :-\

As an update, this seems to happen a lot more with Tab mode. From a user:

"I did discover this morning that if I choose Capture → Desktop → Application Window and then select the Chrome window, rather than trying to capture the Current Tab, it does work correctly. This is a usable (even if not ideal) workaround for the moment, since I simply made the Chrome window fullscreen to hide the URL bar and tabs."

Could we get an ETA on the fix for this? It's been almost a *full year* with literally no update since I posted this bug. It would even be useful if someone were to say "hey we're probably not going to look into this for the foreseeable future". That would be better than radio silence for a bug that renders an API completely unusable.

Would still like to get a response on this as well. We run into this issue ~300 times a day with our current userbase.

mcasas@ is currently OOO, but will be back next week and will be able to provide an update.

mcasas@: |muted| is now wired for audio tracks (since M61).

Hey,

Found this thread helpful. Thanks

Here is my contribution :
chrome.tabCapture.capture({ video: true, audio: true (...) => ondatavailable always empty
chrome.tabCapture.capture({ video: true/*, audio: true */(...) => ondatavailable works fine

It tested with audio: false => issue still there.

Restarting, deleting profile did not change anything to this issue. Bug appears in 100% cases

Environnement : Version 60.0.3112.78 (Build de développement) Built on Ubuntu , running on Ubuntu 16.04 (64 bits)

Removing myself as owner of these issues are marking them 
for retriaging.

Any way we can work on getting a new owner for this ticket?

#75: I know this is gonna sound harsh, but it didn't matter much when there was an owner. Nothing was looked into. People reporting the bug were told to run a canary version of Chrome with logs enabled to track down the bug for the maintainer with little to no feedback when asking for advice on how to debug better/keep logs running at all times. I know it's a bummer since this is a bug that silently breaks the whole MediaRecorder API, but I think it's better off keep this unassigned if the Chrome team doesn't seriously plan on looking into it.

Christian, can you take a fresh look at this?

This issue might be related to https://bugs.chromium.org/p/webrtc/issues/detail?id=4799

Seems like that might be the case

In the WebRTC Update 2017 session recorded at the Kranky Geek 2017 event held at Google last friday, Justin Uberti (Engineering lead for WebRTC in Chrome) talks in depth about mic issues on macOS and a fix that'll be shipped in Chrome 63:

The mic input reliability stuff starts at about 10 minutes and 30 seconds in:
https://youtu.be/PEXnbTyygi4?t=10m33s

There's more talk about changes to the audio subsystem that are coming in the next 6 months that'll make audio on Chrome even more reliable:
https://youtu.be/PEXnbTyygi4?t=15m36s

#81: Woooooah great find!