New issue
Advanced search Search tips

Issue 794216 link

Starred by 2 users
Status: Fixed
Owner:
tmathmeyer@chromium.org
Closed: Jan 2018
Cc:
sande...@chromium.org
liber...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

[Android]Only part of the remote video is displayed on a mobile device with hardware acceleration

Project Member Reported by braveyao@chromium.org, Dec 12 2017 
This is firstly reported in https://github.com/webrtc/apprtc/issues/511.

Here is an easy way to reproduce it:

1. Test with Chrome(any version) on two Android devices.
2. Join same room of apprtc demo, with url: https://appr.tc/?vsc=vp8&vrc=vp8&hd=true, to establish a video call between the two devices.
3. Wait for a while, most probably the frame size will be scaled down from 1280x720 to 960x540 to 640x360, due to limitation of CPU and network.
4. Then you will see that the remote view of each peer can only show part of the image. The more frame size scaled down, the less image you'll see.

If you disable the HW decoding in chrome://flags, #disable-webrtc-hw-decoding, then this problem can't be reproduced.

Comment 1 by braveyao@chromium.org, Dec 12 2017

Components: -Internals>Compositing
Owner: dalecur...@chromium.org
Status: Available (was: Untriaged)
After some initial investigating, I found the decoded frames passed to webmediaplayer_ms.cc show some difference between HW and SW decoders when incoming video has size scaled down on the fly, for example:

HW decoding -
 		coded size 1280x720
 		visual size 0,0 960x540
 		natural size 960x540
SW decoding -
 		coded size 960x540
 		visual size 0,0 960x540
 		natural size 960x540

So when frame size is down from 1280x720 to 960x540, it appears to me that the frame isn't wrapped correctly from HW decoder, coded-size mismatches with others.
I have problem to track down how the decoded data is read out and wrapped into frame from HW decoder. dalecurtis@, could you please have a check and forward to right person?

Comment 2 by dalecur...@chromium.org, Dec 12 2017

Cc: tmathmeyer@chromium.org sande...@chromium.org
Components: Internals>Media>Hardware
Owner: liber...@chromium.org
Status: Assigned (was: Available)
Hmm, I don't see anything different in how RTCVideoDecoder::PictureReady() is packaging video frames relative to GpuVideoDecoder. They both seem to pull the coded_size from the picture buffer.

It's possible both have issues with this case then. =>liberato for a further look. Might also be a good bug for tmathmeyer@.

Comment 3 by braveyao@chromium.org, Dec 12 2017 

If VideoFrame is created with visible_rect.size(), instead of pictureBuffer.size() in RTCVideoDecoder::PictureReady(), then the problem won't happen any more.
So the root reason is the picture size in picture_buffer isn't updated to the new decoded size, I suppose.

Comment 4 by liber...@chromium.org, Dec 12 2017 

c#3: yeah, i also suspect that it's just plain wrong everywhere.  i remember that we had code to update the picture buffer size in the renderer, but maybe it isn't working anymore.

Comment 5 by liber...@chromium.org, Dec 13 2017

Cc: -tmathmeyer@chromium.org liber...@chromium.org
Owner: tmathmeyer@chromium.org
i tried to replicate this yesterday, but couldn't get it to lower the resolution (but it did crash my phone!).  i suspect that RTCVideoDecoder isn't checking for size_changed properly when a PictureBuffer arrives.  GpuVideoDecoder handles this case specially.

tmathmeyer@ agreed to pick this one up.

Comment 6 by tmathmeyer@chromium.org, Jan 9 2018 

For some reason my rebase has played some tricks on the chromiumreview server and it didn't post a message here on merge:
https://chromium-review.googlesource.com/c/chromium/src/+/853113

regardless, I am closing this bug now.

Comment 7 by tmathmeyer@chromium.org, Jan 9 2018

Status: Fixed (was: Assigned)

Comment 8 by dalecur...@chromium.org, Jan 9 2018 

The commit message is lacking the magic incantation "BUG= 794216 " or "Bug:  794216 "
►

Sign in to add a comment