Issue metadata
Sign in to add a comment
|
getUserMedia + MediaRecorder for local recording result in a local 416 error
Reported by
oli...@ziggeo.com,
Apr 20 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30 Steps to reproduce the problem: Open file in Chrome 57. Wait for ~10 seconds. Check the JS console. It should now display a 416 error. What is the expected behavior? It should not show any error and play the 5 second recording back in the browser. What went wrong? Not sure. One seems to be able to workaround this problem by picking a particular codec in MediaRecorder like VP9. The default seems to fail. Did this work before? Yes Chrome 56 Does this work in other browsers? Yes Chrome version: Chrome Version 57.0.2987.133 (64-bit) Channel: stable OS Version: OS X 10.12.4 Flash Version: Shockwave Flash 25.0 r0 Unfortunately it does not happen in every Chrome 57. Older MacBooks seem to be particular affected.
,
Apr 21 2017
Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.4 with chrome #57.0.2987.133, #60.0.3076.0 Bisect Info: =========== Good build : 56.0.2905.0, Revision Range- 428611 Bad build : 56.0.2906.0, Revision Range- 428890 After executing the per-revision-bisect script, i got the following CL's between good and bad build versions ============================================ https://chromium.googlesource.com/chromium/src/+log/037e116c05a8cb78b41c70008b1daf8d9620ea80..e2ab4313f9aad6c29633b07c58064052de8a44f6 The suspecting CL is : ====================== https://chromium.googlesource.com/chromium/src/+/e2ab4313f9aad6c29633b07c58064052de8a44f6 Review-Url: https://codereview.chromium.org/2444153002 mcasas@- Could you please look into this issue, if it's related to your change? if not could you please help us to reassign this issue to the right owner. Thank You...
,
Apr 25 2017
,
Apr 25 2017
I could repro and I think I understand what's going on. The changes
in #2 essentially alligned the Chrome behaviour with FireFox, so
that start() will buffer forever -- or until stop()
The lines:
setTimeout(function () {
mediaRecorder.stop();
// ...
var superBuffer = new Blob(recordedBlobs, {type: 'video/webm'});
are executed after the timeout of 5000ms, but since start() was called
with no parameters, nothing has been collected in |recordedBlobs| and
|superBuffer| is essentially an empty blob that causes the error when
feeding it to a <video> tag.
Parallel to this, if you add a breakpoint in
mediaRecorder.ondataavailable = function (e) {
if (e.data && e.data.size > 0)
recordedBlobs.push(event.data);
you'll see how _after_ stop(), the recorded (big) blob is received.
All this behaviour is consistent with the Spec [1].
oliver@ziggeo.com you could move the blob-creation-and-plugging to
ondataavailable -- or probably (not 100% sure right now) to a newly
added onstop event handler.
[1] https://w3c.github.io/mediacapture-record/MediaRecorder.html#mediarecorder-methods
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by oli...@ziggeo.com
, Apr 20 2017