getUserMedia Constraints for 640x360 and 320x180 display black band on top
Reported by
an...@techgentsia.com,
Mar 28 2016
|
|||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36 Example URL: https://simpl.info/getusermedia/constraints/ Steps to reproduce the problem: 1. Started Chrome with switches : --use-fake-ui-for-media-stream --use-fake-device-for-media-stream 2. Launch chrome and navigate to https://simpl.info/getusermedia/constraints/ 3. click qvga or vga. What is the expected behavior? video with no black band on top and video not cropped at bottom. What went wrong? Video cropped at bottom and black band at top. Did this work before? N/A Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: 49.0.2623.87 Channel: n/a OS Version: 6.3 Flash Version: Shockwave Flash 21.0 r0
,
Mar 28 2016
This issue can also be reproduced from: https://src.chromium.org/svn/trunk/src/chrome/test/data/webrtc/manual/constraints.html
,
Mar 29 2016
,
Mar 30 2016
Unable to reproduce the issue on win8.1 chrome version 49.0.2623.110 with following steps 1. Launched chrome with --use-fake-ui-for-media-stream --use-fake-device-for-media-stream 2. Navigated to https://simpl.info/getusermedia/constraints/ 3. clicked qvga Could not see any video crop or black band -Please find the screenshot Could you please upgrade to latest stable version and see if the issue still exists
,
Mar 31 2016
Updated To chrome Version 49.0.2623.110 m. i am attaching files for both 320x180 and 640x360. i will be testing it on different computers. sorry for the delay in answer. different timezones, i guess.
,
Mar 31 2016
I can successfully replicate this behavior on any Windows Server 2012 R2 Essential. On windows 7 SP1. It is a miss and hit. i don't have access to windows 8 or 8.1. i can also replicate this issue on windows 2012 r2 server builds @ google cloud.
,
Mar 31 2016
Thank you for providing more feedback. Adding requester "tkonchada@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 31 2016
phoglund@ - does the video band/cropping look familiar? ankur@ - can you describe your use case? As far as I know, the --use-fake-ui-for-media-stream and --use-fake-device-for-media-stream are present only for running tests, and are not meant for use in normal usage of Chrome.
,
Apr 1 2016
Thank you for providing more feedback. Adding requester "tnakamura@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 1 2016
Replying to multiple comments... #2 - Please don't use any pages in https://src.chromium.org/svn/trunk/src/chrome/test/data/webrtc/manual because those pages were deprecated back in 2014. The current set of WebRTC sample pages can be found in github at https://webrtc.github.io/samples/, and the resolution test page in particular can be found at https://webrtc.github.io/samples/src/content/getusermedia/resolution/. (It would separately be nice to know where you got that reference to the old src.chromium.org test pages, but that's outside the scope of this bug.) #8 - You said, "i don't have access to windows 8 or 8.1.", but your original report's user agent included "Windows NT 6.3," which is the product version corresponding to Windows 8.1, according to https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions#Client_versions. :) #11 - The fact that you're seeing the same "band" behavior with a real camera makes me think you might be hitting some sort of issue that isn't directly related to WebRTC. Can you try a few more scenarios? a) Create a new Chrome profile (https://support.google.com/chrome/answer/2364824) and restart Chrome without any command line flags. Do you still see the band at the top of the videos in the constraints test page? b) With the same new profile, do you see the same band in a loopback call (https://appr.tc/?debug=loopback)? What about a 2-party apprtc call? c) With the same new profile, do you see the same band at the top of other html5 videos, such as those rendered in youtube.com? d) And to test out your theory that this is some sort of hardware or OS issue ("...show this issue belong to HP and Microsoft"), can you try those same pages with Firefox and let us know if you see the same band?
,
Apr 4 2016
#2 i did a google search. #8 windows server 2012 R2 essential also reports Windows NT 6.3 i could not try apprtc because i could not find constraints for video. but i tried https://webrtc.github.io/samples/src/content/peerconnection/constraints/ for 320x180. It also has loopback call. attaching the screenshot. i searched youtube but it doesn't seem to provide 180p video in settings. firefox fails with 320x180 constraints.
,
Apr 4 2016
Attaching fake media stream for two different profiles
,
Apr 4 2016
Attaching two different use windows 7 machine use cases, where one works and one does not
,
Apr 4 2016
Attaching a test of capturing video @ 320x240. but requesting from chrome @ 320x180.
,
Apr 4 2016
Thank you for providing more feedback. Adding requester "tnakamura@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 4 2016
#14: "i could not try apprtc because i could not find constraints for video." Try video=minWidth=640,maxWidth=640,minHeight=360,maxHeight=360 For example, for a 2-party call, try https://apprtc.appspot.com/?video=minWidth=640,maxWidth=640,minHeight=360,maxHeight=360 and for a loopback call, try: https://apprtc.appspot.com/?debug=loopback&video=minWidth=640,maxWidth=640,minHeight=360,maxHeight=360 tommi@ and phoglund@ - do either of you have any idea why the local preview would shows bands, but the corresponding received video does not? I'm leaning toward this being some sort of machine issue because of comment #17, but I don't know what else to check to try to narrow down why some machines experience this issue, and why others don't (and why it shows up even with the fake device/UI flags).
,
Apr 5 2016
I have no idea, and I haven't seen bands anywhere for a long time as far I can recall. perkj, under what conditions does bands appear in local preview or remote view?
,
Apr 5 2016
This looks like a regression in Chromes render pipeline. The local preview should be rendered without a black row at the top. Since the remote rendering looks correct my guess is that its a regression in how Chromes render pipeline handle the media::VideoFrame::visible_rect() and media::VideoFrame::natural_size()
,
Apr 5 2016
Can this be platform specific? I tried building my own version on Linux Version #384558 (51.0.2697.0 (64-bit)) https://apprtc.appspot.com/r/512138481?debug=loopback&video=minWidth=320,maxWidth=320,minHeight=180,maxHeight=180 and had no problem.
,
Apr 5 2016
@perkj on windows 7 , it is hit and miss, some machines do some do not(the machine you don't want to show the behavior certainly do). but i can always replicate the issue from windows server 2012 r2 essential. i tried it on server build @ google cloud.
,
Apr 5 2016
Thank you for providing more feedback. Adding requester "tnakamura@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 5 2016
,
Apr 8 2016
So we have a regression when a widescreen aspect ratio is selected, on Windows only. Who wants to bisect?
,
Apr 8 2016
I tried this on Windows at home without being able to repro (Win 10). So it only seems to happen on some machines. My guess is that somewhere on some GPU / OS combinations- Chromes local rendering does not consider media::VideoFrame::visible_rect - media::VideoFrame::natural_size combinations as it should. So it seems hard to track down without reproducing first and it is not necessarily a regresssion. This is most likely somewhere in the CC and/or GPU process.
,
Apr 8 2016
#28 - as perkj@ noted, this is hard for us to bisect since, so far, no one from either Chrome or WebRTC has been able to repro locally. ankur@ - if you have python 2.X on your Windows machine, can you try bisecting? Please use the instructions for "bisect-builds.py", *not* "run-bisect-manual-test.py," in https://sites.google.com/a/chromium.org/dev/developers/bisect-builds-py
,
Apr 11 2016
@tnakamura bisect between which two builds . i have been seeing this issue for a very long time. you can check this issue on windows server 2012 essential build. i tried it on the google cloud, and was able to replicate it every time. i don't have access to any other cloud provider.
,
Apr 11 2016
Tried to reproduce this issue on Various Win7/10 platforms with different GPUs (both on 'Canary#52.0.2705.0' & 'Stable#49.0.2623.112') - still no luck. ankur@, Could you please attach chrome://gpu? Thank you!
,
Apr 12 2016
ankur@, Thank you for sharing the GPU info. This seems to be specific to "Intel" Graphics and i am able to reproduce this on one of the Win7 machine with Intel GPU. Will provide you with the bisect information soon. Thank you!
,
Apr 13 2016
This seems to be fixed in (M51 & M52) and below is the reverse bisect info. https://chromium.googlesource.com/chromium/src/+log/71c98a834a281a42e23b0305bfd7dba46b891434..22621b962b34d3a4ac63060b1114f54462cb8837 Bad Build: 51.0.2664.0 Good Build: 51.0.2672.0 Below are the two GPU related changes that might have fixed this issue? If so we can merge-request this fix to M50. https://chromium.googlesource.com/chromium/src/+/f19a055c3b9317cefb595826f1bda987fd8ba2d7 https://chromium.googlesource.com/chromium/src/+/bddee54521cae58e45f7ff92a2bf5819d7fe49de ericrk@/sunnyps@, could you please look into the above GPU related changes in possible? Please feel free to re-assign in case if this is not related to your changes. Thank you!
,
Apr 13 2016
,
May 11 2016
Eric, can you please check if this bug is indeed fixed?
,
May 11 2016
The two changes listed are very unlikely to be related to the change. From looking at the bisect range, I'd suspect https://codereview.chromium.org/1737253002, as it does appear to touch video code. Also adding emircan@, might your change have been responsible for this? I'll try to confirm this on my home machine which should be able to repro (windows machine with intel).
,
May 12 2016
erickr@, the camera output does not contain any alpha channel. I don't think that CL would break/fix this issue.
,
May 12 2016
Hmmm - so this definitely isn't my CL (the code in that CL doesn't run on windows). Sunny, is there a chance this was your CL? doesn't seem related to the issue, but hard to tell. I can't reproduce this on either of my Windows machines (Win10 with nVidia / Win10 with intel) on Chrome 50 stable. I am building before/after builds for the 2 CLs that seem most interesting to me, manoranjanr@, would you be able to test these on the machine that repros?
,
May 12 2016
No, I don't think so. The code in my CL isn't being used.
,
May 12 2016
Given that I can't repro and that tracking down the fix may be pretty involved, I wonder if it's even worth it at this point? From what manoranjanr@ said, this is fixed in 51 which will release on may 25. Seems unlikely that we'd get a merge in for 50 in time for it to matter. Manoranjanr@, can you confirm that this is fixed in 51 beta and close out the issue? Thanks!
,
May 12 2016
This is working fine in Latest Beta#51.0.2704.47 and marking this issue 'WontFix' as we are expecting M51 stable promotion soon (~by end of May). PS: I am reproducing this issue on Latest Stable#50.0.2661.102 for Win7 (Intel) 64-bit OS. Thank you!
,
May 13 2016
Hi, i see that it is not fixed in 52.0.2734.0 canary. regards
,
May 13 2016
I am not seeing this issue on Chrome#52.0.2734.0. Are you still using the same repro case as below? Steps to reproduce the problem: 1. Started Chrome with switches : --use-fake-ui-for-media-stream --use-fake-device-for-media-stream 2. Launch chrome and navigate to https://simpl.info/getusermedia/constraints/ 3. click qvga or vga. Thank you!
,
May 13 2016
Hold on., you mean to say the video is still cropping at the bottom w/o a block border on the top??
,
May 14 2016
Yes. I tested using https://webrtc.github.io/samples/src/content/peerconnection/constraints/ and set constraints to 320×180. I am still getting cropped video and black band. |
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by an...@techgentsia.com
, Mar 28 2016191 KB
191 KB View Download