.videoWidth/.videoHeight are not correct if hardware acceleration is used on macOS/Windows
Reported by
tim.krau...@gmail.com,
Sep 19 2017
|
|||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Firefox/56.0 Steps to reproduce the problem: 1. Enable hardware acceleration in Chrome on macOS or Windows. Restart Chrome (only necessary if hardware accceleration was disabled). 2. Open index.html. You'll see a rather large video (2048x864px). 3. Open chrome://media-internals and click on the active player. Values for width and height are set to 2048 and 864. 4. Disable hardware acceleration in Chrome settings and restart Chrome. 5. Repeat steps 2 and 3. Video will be very small and chrome://media-internals will report 64 and 27px. What is the expected behavior? Chrome should report correct video dimensions if hardware acceleration is enabled. What went wrong? Chrome reports wrong video dimensions if hardware acceleration is enabled. Did this work before? No Does this work in other browsers? Yes Chrome version: 61.0.3163.91 (Offizieller Build) (64-Bit) Channel: stable OS Version: OS X 10.12 Flash Version: The issue seems to be existing in every Chrome version down to (including) 45 according to screenshots I made with BrowserStack. Possibly in lower versions, too; but I can't see the video in these versions which might be related to the test case I've built. I've included a description of the issue in the index.html, too (nothing which isn't part of the ticket). Not sure if that is helpful. The affected component is probably Blink>Media but I'm not 100% sure.
,
Sep 19 2017
just tested with win10 with HW A. Enabled ``` just tested on this win10 render_id: 14 player_id: 0 origin_url: http://domain.fqdn/ frame_url: http://domain.fqdn/ frame_title: Test case for Chrome GPU acceleration bug url: blob:http://domain.fqdn/0b86fbd4-5112-4ae1-a646-a3f69f1ed154 pipeline_state: kSuspended found_video_stream: true video_codec_name: h264 debug: Video rendering in low delay mode. video_dds: false video_decoder: GpuVideoDecoder video_buffering_state: BUFFERING_HAVE_ENOUGH height: 27 width: 64 pipeline_buffering_state: BUFFERING_HAVE_ENOUGH event: PAUSE duration: 59.999999 ``` with HW A. Disabled ```` render_id: 6 player_id: 0 origin_url: http://domain.fqdn/ frame_url: http://domain.fqdn/ frame_title: Test case for Chrome GPU acceleration bug url: blob:http://domain.fqdn/4cf66427-6fc2-4368-8a37-8077b9004e0f pipeline_state: kPlaying found_video_stream: true video_codec_name: h264 debug: Video rendering in low delay mode. video_dds: false video_decoder: FFmpegVideoDecoder video_buffering_state: BUFFERING_HAVE_ENOUGH height: 864 width: 2048 pipeline_buffering_state: BUFFERING_HAVE_ENOUGH event: PAUSE duration: 59.999999 ``` Google Chrome 62.0.3202.18 (Offizieller Build) beta (64-Bit) (cohort: Beta) Überarbeitung 7ba42bf8da38fd2a88b71bea05df3ebfd29ee96c-refs/branch-heads/3202@{#152} Betriebssystem Windows JavaScript V8 6.2.414.7 Flash 27.0.0.130 C:\Users\windowsadmin\AppData\Local\Google\Chrome\User Data\PepperFlash\27.0.0.130\pepflashplayer.dll User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.18 Safari/537.36 Befehlszeile "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --disable-javascript-harmony-shipping --enable-devtools-experiments --enable-fast-unload --enable-webgl-draft-extensions --enable-webrtc-stun-origin --enable-experimental-extension-apis --flag-switches-end GPU on this rig is a NVIDIA GeForce GTX 950
,
Sep 19 2017
,
Oct 10 2017
Tested this issue on Windows 7, Mac OS X 10.12.6 using chrome latest stable #61.0.3163.100,canary #63.0.3236.0 Steps included are: 1.Disable hardware acceleration in Chrome on macOS or Windows. Restarted Chrome 2.Opened index.html and Unable to see a rather large video (2048x864px). @ reporter: Could you please find the attached screencast and let us know if anything is missed from our end. Thank you!
,
Oct 10 2017
rrkalavakuntla: Did you download the video_dump.mp4 which goes with the index.html? The index.html references it.
,
Feb 12 2018
Mac triage: kicking back to TE for re-test per #5.
,
Feb 14 2018
Checked the issue on reported chrome version 61.0.3163.91 using Mac 10.13.1 with the below mentioned steps. 1. Launched Chrome 2. Downloaded files video_dump.mp4 and index.html 3. Opened the downloaded file video_dump.mp4 and index.html. 4. Navigated to chrome://media-internals/ Note: Attaching the results from both scenarios i.e., Hard Ware acceleration ON and OFF. We observed both of them gave same video dimensions. Hence removing Needs-TestConfirmation.
,
Feb 14 2018
++Please let us know if we have missed anything in the process reproducing the issue.
,
Mar 9 2018
vamshi.kommuri: I think the problem is that Chrome blocks loading of local resources. If you look in the devtools console you'll see an error. Can you run a local webserver?
,
Mar 12 2018
Checked the issue as per comment#10. After opening the downloaded files from comment#0, we navigated to chrome://media-internals. Then Opened DevTools -> Console, We didn't observe any error in the console. Attaching the screen shot of the same. Removing Needs-TestConfirmation. @kylechar: Could you please let us know if anything missed from our side. Thanks!
,
Apr 16 2018
mac triage: ccameron@ can you peek at this and see what's going on?
,
Apr 16 2018
Adding labels for Windows and Mac, ->video team for triage
,
Apr 19 2018
,
Apr 19 2018
,
Apr 19 2018
I am unable to reproduce this issue on Mac. The test video does not hit any of the known edge cases (top-left frame cropping, for example), and VTVDA returns the |visible_rect| explicitly. I have no reason to believe that this bug still exists.
,
Apr 20 2018
1) Download the files 2) start a actual web server to serve the files `python -m SimpleHTTPServer` (inside the download dir) 3) open http://localhost:8000/
,
Apr 20 2018
#17: Thanks, I was missing that this only affects MSE playback. This issue is caused by a difference between the track's metadata (tkhd) and actual encoded media (avc1); the former reports 64x27 while the latter is 2048x864. It's not entirely clear to me what the correct behavior is, but our non-MSE implementation prioritizes the encoded media size, so we should probably do the same for MSE. This means that |natural_size| should be computed interpreting the track size as an aspect ratio and the |visible_rect| as the target size. FFmpegVideoDecoder already does this, which is why software decoding is not affected, even for MSE. The implementation is in GetNaturalSize() (https://chromium.googlesource.com/chromium/src/+/28255cf359c9978cc10525ad9ec178510999bbfe/media/base/video_util.cc#54). It doesn't make sense that every VideoDecoder needs to implement this same computation. Possibly we should move the implementation to VideoFrame.
,
Apr 25 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7eea95b1eef9e4fa509a05ade9fd89fd6507477d commit 7eea95b1eef9e4fa509a05ade9fd89fd6507477d Author: Dan Sanders <sandersd@chromium.org> Date: Wed Apr 25 00:18:38 2018 [media] Scale |natural_size| to match |visible_rect| for HW decoders. For some media, the container's |natural_size| is actually just an aspect ratio, and therefore we should not use it directly as the VideoFrame's |natural_size|. Instead it should be scaled based on the |visible_rect| of the decoded frame. FFmpegVideoDecoder already does this, this CL applies the same logic in GpuVideoDecoder and VdaVideoDecoder. Note: This change will make it possible for HW decoders to emit frames of different sizes without a config change, which was not possible before. Bug: 766657 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Change-Id: I7b263245c401c845bca30fa0683eb3e337ed6f81 Reviewed-on: https://chromium-review.googlesource.com/1022968 Commit-Queue: Dan Sanders <sandersd@chromium.org> Reviewed-by: Dale Curtis <dalecurtis@chromium.org> Cr-Commit-Position: refs/heads/master@{#553384} [modify] https://crrev.com/7eea95b1eef9e4fa509a05ade9fd89fd6507477d/media/base/video_util.cc [modify] https://crrev.com/7eea95b1eef9e4fa509a05ade9fd89fd6507477d/media/base/video_util.h [modify] https://crrev.com/7eea95b1eef9e4fa509a05ade9fd89fd6507477d/media/base/video_util_unittest.cc [modify] https://crrev.com/7eea95b1eef9e4fa509a05ade9fd89fd6507477d/media/filters/gpu_video_decoder.cc [modify] https://crrev.com/7eea95b1eef9e4fa509a05ade9fd89fd6507477d/media/gpu/fake_command_buffer_helper.cc [modify] https://crrev.com/7eea95b1eef9e4fa509a05ade9fd89fd6507477d/media/gpu/ipc/service/picture_buffer_manager_unittest.cc [modify] https://crrev.com/7eea95b1eef9e4fa509a05ade9fd89fd6507477d/media/gpu/ipc/service/vda_video_decoder.cc [modify] https://crrev.com/7eea95b1eef9e4fa509a05ade9fd89fd6507477d/media/gpu/ipc/service/vda_video_decoder_unittest.cc
,
May 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/af451f2b8adfb22eabf60b7232a3c050941c9261 commit af451f2b8adfb22eabf60b7232a3c050941c9261 Author: Dan Sanders <sandersd@chromium.org> Date: Tue May 01 19:21:23 2018 [media] Use pixel aspect ratio to compute |natural_size| in all decoders. This CL standardizes the |natural_size| computation in all decoder implementations to use the decoded |visible_size| and the VideoDecoderConfig's pixel aspect ratio. Bug: 766657 , 837337 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Change-Id: I01a5bd59c353d6f07fd02c9fc3d3e64ab1a04434 Reviewed-on: https://chromium-review.googlesource.com/1026992 Commit-Queue: Dan Sanders <sandersd@chromium.org> Reviewed-by: Xiaohan Wang <xhwang@chromium.org> Reviewed-by: Dale Curtis <dalecurtis@chromium.org> Reviewed-by: Frank Liberato <liberato@chromium.org> Cr-Commit-Position: refs/heads/master@{#555136} [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/base/video_decoder_config.cc [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/base/video_decoder_config.h [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/base/video_util.cc [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/base/video_util.h [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/base/video_util_unittest.cc [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/cdm/cdm_adapter.cc [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/cdm/cdm_adapter.h [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/filters/aom_video_decoder.cc [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/filters/ffmpeg_video_decoder.cc [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/filters/gpu_video_decoder.cc [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/gpu/android/media_codec_video_decoder.cc [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/gpu/ipc/service/vda_video_decoder.cc [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/gpu/ipc/service/vda_video_decoder_unittest.cc [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/media/gpu/windows/d3d11_video_decoder_impl.cc [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/third_party/WebKit/LayoutTests/platform/linux/compositing/video-frame-size-change-expected.png [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/third_party/WebKit/LayoutTests/platform/linux/compositing/video-frame-size-change-expected.txt [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/third_party/WebKit/LayoutTests/platform/linux/virtual/disable-spv175/compositing/video-frame-size-change-expected.png [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/third_party/WebKit/LayoutTests/platform/linux/virtual/disable-spv175/compositing/video-frame-size-change-expected.txt [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/third_party/WebKit/LayoutTests/platform/mac/compositing/video-frame-size-change-expected.png [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/third_party/WebKit/LayoutTests/platform/mac/compositing/video-frame-size-change-expected.txt [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/third_party/WebKit/LayoutTests/platform/win/compositing/video-frame-size-change-expected.png [modify] https://crrev.com/af451f2b8adfb22eabf60b7232a3c050941c9261/third_party/WebKit/LayoutTests/platform/win/compositing/video-frame-size-change-expected.txt
,
May 1 2018
Fixed in M68 Canary/Dev. |
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by tim.krau...@gmail.com
, Sep 19 2017