Incoming video is blocky on device Spring during hangout with desktop(Linux) |
||||
Issue descriptionChrome version: 51.0.2694.1 / 8134.0.0 dev What steps will reproduce the problem? 1. Join a two way successful hangout call between device Spring user and desktop(Linux) user 2. From device Spring, select the screenshare option from the left side of the hangout window 3. A new window with the different screens shows up for the selection 4. Select any one of the options from the mini window and then click on 'Share' option at the bottom Expected result: Incoming and outgoing video should be clear on both desktop and device Spring Actual result: Device outgoing video is clear but device incoming video from desktop is blocky (in between). Video for bug description: https://drive.google.com/file/d/0B_iIlDy84LyFdVhTTUlZWUtIZ2M/view?usp=sharing Notes: 1. This issue is so far observed 2 out of 3 attempts. 2. Please find attached webrtc-internals dump from desktop and device Spring 3. Also find attached generate_logs dump from device Spring 4. Feedback submitted for this issue: https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=user:srcv&lReport=7738593063 (pressed alt+shift+i a couple of times on device screen causing feedback submission window to appear on it)
,
Apr 2 2016
Thanks, Ted! Sure, we can take a look. Ranjani, are you able to reproduce the problem after disabling video HW decoding? AFAICT, there have been no changes in Daisy-* video code recently but it would be good to know the behavior after after disabling video HW decoding.
,
Apr 5 2016
,
Apr 21 2016
Sorry.. I missed out updating this bug. tnakamura@: 1) Not sure if this is a regression on M51. As far as I remember, this issue was not seen on device Spring with M50 version. I will retest and update this bug accordingly 2) I did not noticeably observe any errors in histograms Rohit@: I was not able to reproduce this issue on device Spring with 51.0.2704.15 / 8172.6.0 dev after disabling video HW decoding Please find attached webrtc-internals for hangout on device spring with enabling and disabling hardware decoding
,
Apr 22 2016
Thanks, Ranjani! I don't think anything changed at CrOS video side on daisy but Pawel can correct me. If this is a regression, we should make this bug RBS.
,
Apr 22 2016
I was able to reproduce this issue on device Spring with M50 50.0.2661.87 / 7978.62.0 beta with default chrome://flags settings i.e., enabling video hardware decoding.
,
Jun 9 2016
Retested hangouts on device Spring with M52 52.0.2743.32 / 8350.21.0 beta and observed hangouts incoming video blockiness only when screensharing a youtube video. Note: Incoming video started displaying pixelated video (slightly) as soon as youtube video is started in another window(in background) on device Spring. Incoming video blockiness increased with screensharing that youtube video. Feedback submitted for this issue: https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=user:srcv&lReport=9626575166
,
Jun 9 2016
WebRTC internals dump from device Spring and Linux Desktop: https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/599643/
,
Aug 25 2016
Hangouts incoming video blockiness is intermittently observed on device Spring with M54 54.0.2831.0 / 8731.0.0 dev while sharing a youtube video.
,
Jan 6 2017
This issue is not observed during hangouts between Linux desktop and device Spring with M56 56.0.2924.53 / 9000.50.0 beta. Hangouts incoming and receiving videos were slow(video lag) but there was no video blockiness. https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/599643/Logs%20for%20hangout%20betwene%20linux%20and%20Spring/ |
||||
►
Sign in to add a comment |
||||
Comment 1 by tnakamura@chromium.org
, Apr 1 2016Owner: rohi...@chromium.org
Status: Assigned (was: Untriaged)