Issue metadata
Sign in to add a comment
|
MediaRecorder randomly fires onstop event
Reported by
soe...@zfaas.com,
Apr 28 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36 Steps to reproduce the problem: 1. Use a Linux or ChromeOS computer, use navigator.mediaDevices.getUserMedia to retrieve a 480p, 4:3 media stream (with audio) 2. Initialize the MediaRecorder with the "video/webm; codecs=h264,opus" MIME type (we could not see any issues for VP8 and VP9) 3. Implement the "ondatavailable" and "onstop" event handlers of the MediaRecorder instance 4. Start the MediaRecorder instance with a 30 second interval What is the expected behavior? Every 30 seconds, ondataavailable should be called with a Blob instance that contains the media recording of the past 30 seconds. The onstop event handler should not be called before the recorder is explicitly stopped. What went wrong? We see sporadic issues where the "onstop" event will be autonomously invoked (ie., without previously calling the stop() function on the MediaRecorder instance). This happens more often after a previous recording was completed. When "onstop" is autonomously called, it is often after a few seconds of recording. Typically, there is a call to "ondataavailable", immediately followed by "onstop". We do neither call the stop() nor requestData() function of the MediaRecorder instance. So far, we have only observed this issue on Linux-based systems, namely Ubuntu workstations and also an ARM-based ChromeOS laptop. Did this work before? Yes cannot tell, we have initially seen this with the very latest stable Chrome version Does this work in other browsers? Yes Chrome version: 58.0.3029.81 Channel: stable OS Version: Ubuntu 17.04 Flash Version: So far, we have only seen this when using the "video/webm; codecs=h264,opus" MIME type.
,
Apr 29 2017
,
Apr 29 2017
,
May 24 2017
We've seen this issue happen very frequently lately, across both Windows and Mac, but only in Chrome 58. We only see this when trying to record a low-res video with a constrained resolution, while default sized videos work fine. It appears to us that it's the maxHeight & maxWidth properties in the constraints.video.mandatory object that's passed into the getUserMedia call thats causing this issue. At least it doesn't appear when we remove them, so maybe it's something related to the camera not being able to record in the that resolution. If this is indeed the issue, then it used to work, earlier when the camera didn't support the required resolution, we'd get an error. But when no error is being thrown, we kinda need to record in the default resolution of the camera. We've made this JSBin to test out the issue: https://jsbin.com/xujuxoyise/edit?js,console,output Note that it does require the ID from your camera to be inserted into the function (I can clean it up if needed).
,
May 24 2017
#4: Obvious question but, have you tried with a recent Canary (M60)?
,
May 24 2017
Yes, after the fact we also tried it in Chrome Canary (M60) but it also failed there, the JSBin also fails in Canary (M60).
,
May 25 2017
Running the jsfiddle in Cr I see that video_track_recorder.cc is getting 0 sized encoded frames, causing WebmMuxer to throw an error that is translated to stop(). This only seems to happen in the beginning of the capture, so I'm tempted to do something at the webm_muxer.cc level for starters while we dig deeper. M58 is about the time that https://crrev.com/2623353004/ landed, which taught MRecorder to choose the most-likely hardware accelerated codec if mimeType is left unspecified (landed in 57.0.2980.0), so we might have started using H264 where VP8 was used before -- if I configure: mimeType: 'video/webm;codecs="vp8"' in the jsfiddle, I see no zero-size encoded frames.
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d70bf910b3b5ee3bfe5afe95031044bfff6523ff commit d70bf910b3b5ee3bfe5afe95031044bfff6523ff Author: Miguel Casas-Sanchez <mcasas@chromium.org> Date: Thu May 25 16:10:23 2017 WebmMuxer: handle zero-sized encoded frame in OnEncodedVideo() This CL teaches WebmMuxer to ignore zero-sized encoded frames in WebmMuxer::OnEncodedVideo(), because these are produced sporadically by the openh264 encoder. Bug: 716451 Change-Id: I06261320e1bc6a7042dc7c6a6917115e6ba5e51a Reviewed-on: https://chromium-review.googlesource.com/514412 Reviewed-by: Emircan Uysaler <emircan@chromium.org> Commit-Queue: Miguel Casas <mcasas@chromium.org> Cr-Commit-Position: refs/heads/master@{#474668} [modify] https://crrev.com/d70bf910b3b5ee3bfe5afe95031044bfff6523ff/media/muxers/webm_muxer.cc
,
May 25 2017
tobiaschristensen@gmail.com, can you plz verify that #8 solves your problem? I'm not 100% sure the original issue would be tackled as well, but it's worth a try, could you please try as well soeren@zfaas.com ? Marking as fixed tentatively, will reopen if not fixed. [1] will tell us exactly which version of Chrome has the fix. [1] https://storage.googleapis.com/chromium-find-releases-static/index.html#r474668
,
May 25 2017
That worked, thanks!
,
May 26 2017
,
May 26 2017
This bug requires manual review: We are only 10 days from stable. Please contact the milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 26 2017
We are less than a week away from Stable. Is this critical for M59 or can it wait until M60? This bug has been open for almost more than a month as well. Seems like a small change - but is there enough unit test coverage for this? Is this overall a safe merge?
,
May 26 2017
#13: it's a painful bug and the fix is trivial: check for size zero and return true if so, besides the modified code is only used for MediaRecording. Diff: (https://chromium-review.googlesource.com/c/514412/2/media/muxers/webm_muxer.cc)
,
May 26 2017
Small change, considered safe, and verified in comment 10 - approving this merge for M59.
,
May 26 2017
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2ab7d0b017153fb1bde72ebe8f1c865f03a3c249 commit 2ab7d0b017153fb1bde72ebe8f1c865f03a3c249 Author: Miguel Casas-Sanchez <mcasas@chromium.org> Date: Fri May 26 17:29:13 2017 WebmMuxer: handle zero-sized encoded frame in OnEncodedVideo() This CL teaches WebmMuxer to ignore zero-sized encoded frames in WebmMuxer::OnEncodedVideo(), because these are produced sporadically by the openh264 encoder. Bug: 716451 Change-Id: I06261320e1bc6a7042dc7c6a6917115e6ba5e51a Reviewed-on: https://chromium-review.googlesource.com/514412 Reviewed-by: Emircan Uysaler <emircan@chromium.org> Commit-Queue: Miguel Casas <mcasas@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#474668} Review-Url: https://codereview.chromium.org/2903373004 . Cr-Commit-Position: refs/branch-heads/3071@{#701} Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641} [modify] https://crrev.com/2ab7d0b017153fb1bde72ebe8f1c865f03a3c249/media/muxers/webm_muxer.cc
,
Jun 7 2017
The NextAction date has arrived: 2017-06-07 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by soe...@zfaas.com
, Apr 29 2017