New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 610497 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Hangouts incoming video is blocky on device Samus

Project Member Reported by srcv@chromium.org, May 9 2016

Issue description

Chrome Version: 52.0.2727.0 / 8297.0.0 dev
Device: Samus

What steps will reproduce the problem?
1. Join a two way successful hangout call between device Samus and desktop(Linux). 
2. Observe the audio and video quality on device and desktop
3. Device outgoing audio and video are clear but device incoming video from desktop is blocky and shows purple shades in between
4. Now try to screeshare the device screen with desktop by clicking on Hangout settings and select "Internal display" from available screensharing option windows

Expected result:
a) Audio and video should be clear from both the ends-device Samus and desktop
b) Selecting 'Internal display' on device for screensharing should display the entire device screen on desktop

Actual result:
a) Device outgoing audio and video are clear but device incoming video from desktop is blocky and shows purple shades in between
b) Selecting 'Internal display' on device for screensharing displays blank video on desktop screen

Notes:
1) This issue is observed 2/3 attempts of hangout calls on device Samus
2) Hangout screensharing is working as expected when windows other than "Internal display" are selected for screensharing
3) Device built-in camera is working fine
4) Please find attached generate_logs, https://test.webrtc.org results from device Samus and webrtc-internals dump from device and desktop



 

Comment 2 by srcv@chromium.org, May 9 2016

Cc: rohi...@chromium.org
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=8637440191

Note:
Checking M50 beta and M51 beta builds to find if this issue is a regression. I will update the bug accordingly.
This sounds like two completely different issues that probably should be tracked separately.

Comment 4 by srcv@chromium.org, May 9 2016

Summary: Hangouts incoming video is blocky on device Samus (was: Hangouts incoming video is blocky on device Samus and screensharing is not working for 'Internal display')
Made 2-3 attempts to reproduce "Internal display" screensharing issue on device but was able to reproduce only incoming video blockiness on device Samus during hangout with desktop.

Changing bug summary so that it tracks only hangouts incoming video blockiness on device Samus.


Cc: avkodipelli@chromium.org
Components: OS>Kernel>Video
Labels: -Pri-2 ReleaseBlock-Dev M-52 Pri-1
Since this breaks Google Hangouts, marking this as a dev blocker.
Labels: VideoShortList
srcv@ have you found out is it a regression?

Comment 8 by srcv@chromium.org, May 10 2016

Labels: -Type-Bug Type-Bug-Regression
Summary: Regression: Hangouts incoming video is blocky on device Samus (was: Hangouts incoming video is blocky on device Samus )
I was able to reproduce this issue on device Samus with latest M51 beta
(51.0.2704.37 / 8172.25.0).

Note: 
1. This issue was not observed on device Samus with M50 stable (50.0.2661.91 / 7978.66.3.
2. This issue was not observed on device Samus with M51 dev (51.0.2704.26 / 8172.12.0 dev )

Marking this issue as a regression.
Cc: gkihumba@chromium.org
Labels: -ReleaseBlock-Dev ReleaseBlock-Beta
Changing this to M52 release block beta since it's a regression
s/regression/not regression
Labels: M-51
Grace, I think #8 means that this is a recent regression in M52 and M51 due to a CL which also got merged back to M51.
Thanks! This would be a regression between 8172.12.0 and 8172.25.0 then.
Would you perhaps be able to try to bisect that range please?
Would you also be able to test with and without RTC hardware decode acceleration (disable-webrtc-hw-decoding in about:flags) and also verify relevant histograms (Media.RTCVideoDecoderInitDecodeSuccess)? Thanks.
Labels: -ReleaseBlock-Beta ReleaseBlock-Stable
Moving this to ReleaseBlock-Stable since this is already live in the current Beta push.

We should still try to get this fixed in the next stable push.
Labels: Needs-Bisect Needs-Feedback
Owner: srcv@chromium.org
Status: Assigned (was: Untriaged)
[triage]: Assigning to srcv@ to bisect per #13. Ted, feel free to re-assign if someone else should do it.
Labels: -Needs-Feedback

Comment 19 by srcv@chromium.org, May 16 2016

Owner: tnakamura@chromium.org
Re-tested hangouts on device Samus with latest M51 beta ( 51.0.2704.42 / 8172.28.0 ). I was not able to reproduce this issue with and without RTC hardware decode acceleration (disable-webrtc-hw-decoding in about:flags)

Assigning this bug to tnakamura@ for deciding next steps.


 

Comment 20 by srcv@chromium.org, May 16 2016

Meanwhile, I will try to reproduce this issue with latest M52 dev and update this bug accordingly. 
It's not reproduced anymore? Can we close this?
Labels: -ReleaseBlock-Stable
Since this is no longer reproducing, removing the release block, please re add if it does repro, presumably this will be closed as WontFix.
Ranjani, Ted, a friendly ping.
Status: WontFix (was: Assigned)
Please reopen if you can repro.

Comment 25 by srcv@chromium.org, May 31 2016

Tested hangouts on device Samus with M52 52.0.2743.11 / 8350.13.0 dev and could not reproduce this issue. Hangouts incoming and outgoing video are clear from device Samus.

Sign in to add a comment