Real-time video playback is cropped when hardware-acceleration is disabled and aspect ratio is set
Reported by
jwi...@rehearsal.com,
Jun 29 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Example URL: https://src.chromium.org/svn/trunk/src/chrome/test/data/webrtc/manual/constraints.html Steps to reproduce the problem: 1. Navigate to https://src.chromium.org/svn/trunk/src/chrome/test/data/webrtc/manual/constraints.html 2. Set Min to 640 x 360 and Aspect ratio to 1.777, then select the button "RequestGetUserMedia" (note the dimensions of the video) 3. Disable hardware-acceleration in Settings, restart Chrome, then repeat steps 1 and 2 What is the expected behavior? The dimensions of the video should be the same regardless of the hardware-acceleration setting. What went wrong? The video dimensions are rendered differently when hardware-acceleration is disabled. Did this work before? N/A Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: 51.0.2704.106 Channel: stable OS Version: OS X 10.11.5 Flash Version: Shockwave Flash 22.0 r0 Following the same steps in Firefox produces the expected behavior. Also, when using WebRTC to stream to a remote file, the video maintains it's proportions regardless of the hardware-acceleration setting. The issue is only with real-time playback.
,
Jul 11 2016
[triage]: perkj, can you triage this and find a suitable owner?
,
Jul 15 2016
My guess is that the hardware accelerated rendering path honors VidoeFrame::natural_size() != VideoFrame::visible_rect() != VidoeFrame::codec_size() correctly while sofware path does not. emircan, would you know where the hw path and sw path start to differ? They seem to be the same path at least up to media::GpuMemoryBufferVideoFramePool::MaybeCreateHardwareFrame
,
Jul 19 2016
perkj@, I tested with/without GpuMemoryBufferVideoFramePool and video stays in the same position. The problem should be somewhere in the rest of the pipeline between HW and SW paths. dcastagna@, do you know what might be different in the rest of the pipeline? Also, this certain page with params described in #1 hits the below DCHECK. I printed the visible_rect as well. What do we check visible_rect().y() for odd here? [26336:33543:0718/182601:FATAL:gpu_memory_buffer_video_frame_pool.cc(322)] Check failed: (video_frame->visible_rect().y() & 1) == 0. visible rect: 0,59 640x362
,
Jul 19 2016
I'm not sure what disable hardware acceleration does in the Settings. Does it disable GPU Compositing? If it disables GPU compositing it means we don't get GMBs video frames, and the compositing path for the video frames is completely different. Look for software_compositor in VideoResourceUpdater::CreateForSoftwarePlanes. In SoftwarePlaneDimension it seems to return coded_size if software_compositor is true. I'd start from there. Regarding the DCHECK, it checks that visible_rect x and y are even since we're moving the visible_rect origin to 0,0. Since the U and V planes are subsampled 2x2, we'd need to resample those in that case.
,
Jul 26 2016
VideoResourceUpdater::CreateForSoftwarePlanes is indeed called in this case. I tried to simply change all the coded_size() references with visible_rect() and data() with visible_data(). However, the placement is still the same.
,
Sep 23 2016
,
Sep 29 2016
,
Feb 6 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by yini...@chromium.org
, Jun 29 2016