getUserMedia with unsupported resolution results in white bar video
Reported by
maxstol...@gmail.com,
Dec 8 2016
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36 Steps to reproduce the problem: I'm not sure how to re-produce this problem without specific hardware, sorry! I'm using a MacBook Pro (Retina, 13-inch, Early 2015). 1. Load https://jsfiddle.net/9t3szw0L/35/ 2. Press start 3. Notice white bar What is the expected behavior? Given 640x360 is not supported by my camera, I would expect Chrome to throw an error when I call getUserMedia with that resolution specific. What went wrong? It renders an unsupported resolution by introducing a white bar. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 55.0.2883.75 Channel: stable OS Version: OS X 10.11.1 Flash Version: Shockwave Flash 23.0 r0
,
Dec 13 2016
,
Dec 14 2016
guidou@ can you take a look and help with triage? I thought it might be related to the earlier work on constraints. If not, feel free to assign it back.
,
Dec 14 2016
,
Dec 16 2016
Chrome will adapt the resolution to the requested one by using cropping. Not failing because you request 640x360 is not a bug, but a feature. The white band does look like a bug, but I've been unable to reproduce it on any platform with any current version. Can you reproduce the white band reliably?
,
Dec 16 2016
,
Apr 18 2017
This seems to be a Mac-specific issue. I can reproduce on Mac, but not on Linux, Android or Windows. Will look into it.
,
Apr 18 2017
emircan@: Can you take a look? Maybe this is caused by a bug in the mac-specific code for video capture. Resolution adjustment (VideoTrackAdapter) works fine on the other platforms. Since that code is the same for all platforms I don't think the problem is there.
,
Apr 18 2017
,
Apr 25 2017
Issue 715101 has been merged into this issue.
,
Apr 25 2017
Unable to repro on Macbook Air (Early 2015). I tried Chrome 58 and 60. @guidou: What hardware/software did you use in your repro on Mac?
,
Apr 26 2017
It looks like this bug is very old, but it does not always reproduce. I tried with this version of the repro script that uses old-style code so that it runs on older versions: This is my experience on a MacBook Pro (Late 2013). I cannot reproduce with 57 stable: 57.0.2987.133 (Official Build) (64-bit) I can reproduce with the following Canaries: 60.0.3074.0 (Official Build) canary (64-bit) 60.0.3080.5 (Official Build) canary (64-bit) I tried a bisect and this is the result: Newest known version that does not reproduce the bug: 35 .0.1864.0 (Developer Build 253992) Oldest version that reproduces the bug: 37 .0.2048.0 (Developer Build 276960) All versions ran by bisect-builds.py between this range crash. They don't crash because of the getUserMedia stuff, but because the builds are apparently too buggy. They crash on almost everything. I have no idea why I can reproduce the bug on almost everything except stable 57.
,
Apr 26 2017
Some extra data: I upgraded to Stable 58.0.3029.81 (Official Build) (64-bit) and it reproduces the bug. OS version is macOS Sierra 10.12.4. Graphics Intel Iris Pro 1536 MB
,
Apr 26 2017
I also tried with a MacBook Air Mid 2013 (OS X El Capitan 10.11.6) and the bug does NOT reproduce with any Chrome version I tested. Versions tested: Chrome Beta 58.0.3029.54 Chrome Beta 58.0.3029.81 Chromium 56.0.2922.0 (432493) Chrome Canary 60.0.3080.5 So it looks like you need a MacBook Pro to reproduce the bug. Also, the script I used for old Chrome versions is https://jsfiddle.net/k5aepa7s/5/
,
Apr 26 2017
Thanks, guidou@. I may have to go find more MacBooks to test on. Just tried two other models with no success: MacBook Pro (13-inch, 2016, Four Thunderbol 3 Ports) 60.0.3080.5 No repro 57.0.2987.133 No repro MacBook Pro (Retina, 15-inch, Mid 2015) 60.0.3080.0 No repro 57.0.2987.133 No repro |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by erikc...@chromium.org
, Dec 9 2016Status: Untriaged (was: Unconfirmed)