Chromecast Screen Mirroring not working as expected on M70 |
|||||||||||
Issue descriptionChrome Version: <From about:version: Google Chrome 70.0.3538.28> Chrome OS Version: <From about:version: Platform 11021.23.0> Chrome OS Platform: <Coral/Santa> Please specify Cr-* of the system to which this bug/feature applies (add the label below). Steps To Reproduce: (1)Connect a wifi network that has cast option. (2)click on cast under uber tray (3)select the device and connect. (4)notifies that it is currently mirroring the screen, but the monitor goes blank. Expected Result: screen mirroring works and everything on the DUT can be mirrored. Actual Result: DUT connects and shows as casting, but the cast monitor goes blank. How frequently does this problem reproduce? (Always, sometimes, hard to reproduce?) Always Feedback report@ https://listnr.corp.google.com/report/85676362972 NOTE: 1)Disabling the "Cast streaming hardware video encoding" under chrome://flags resolves the issue. 2)cast option from "google home" app, and casting from chrome browser work fine.
,
Sep 24
,
Sep 24
Issue 887948 has been merged into this issue.
,
Sep 24
Issue 888474 has been merged into this issue.
,
Sep 24
It looks like this started with/before 70.0.3538.22 beta. I'm seeing this reported on a variety of Chromebooks on that version of M70 Beta: Cyan, Snappy, Winky, Auron_Yuna, Kip, and Nyan_Blaze. Sample User reports from 70.0.3538.22 beta: - http://listnr/product/208/report/85679933043 - http://listnr/product/208/report/85678713278 - http://listnr/product/208/report/85676712068 - http://listnr/product/208/report/85674081251 - http://listnr/product/208/report/85674075305 Most users report that the audio plays, but the screen remains black.
,
Sep 24
miu@, is this related to Bug 883984 ? One of the reports mentions something about working from incognito mode. Also the OP says it works when disabling hardware codec. 70.0.3538.22 was the first beta, so, we'd need to bisect a regression to something that landed since the M70 branch.
,
Sep 24
,
Sep 24
Issue 883568 has been merged into this issue.
,
Sep 24
Have repro (Peppy CrOS) here. Confirmed that mirroring will work if "Cast streaming hardware video encoding" under chrome://flags is disabled. Speculation: Might be related to the following: commit 4a74fb0fdb1fd882d4cc04cc4b8a6d339472e7d5 Author: Yuri Wiitala <miu@chromium.org> Date: Tue Aug 28 23:09:35 2018 Migrate viz::FrameSinkVideoCapturer to use new read-only shmem API. Investigating...
,
Sep 25
Confirmed: The commit started using the new shmem API, but VideoEncodeAccelerator was expecting a VideoFrame backed by the legacy shmem API. I have a fix that seems to work. Will polish-up tonight, and start code review tomorrow.
,
Sep 25
Up for code review: https://chromium-review.googlesource.com/c/chromium/src/+/1242396
,
Sep 26
Checking in on this, looks like the CL above is having some issue. Not sure if there's anyone looking at it.
,
Sep 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/13981d5683f8b2fb6d0ea73521e72bf075b529b1 commit 13981d5683f8b2fb6d0ea73521e72bf075b529b1 Author: Yuri Wiitala <miu@chromium.org> Date: Thu Sep 27 21:35:52 2018 [CrOS+Cast] Fix shmem issue causing black screen share when Casting. Adds a memcpy (unfortunately) to allow content::VideoEncodeAccelerator to pass VideoFrame data to a HW encoder. Commit 4a74fb0fdb1fd882d4cc04cc had migrated the VIZ screen capturer to use the new read-only shmem API; but, unfortunately, the VEA framework for HW video encode still expects/requires the use of the legacy shmem API. Also added a little extra logic to more-gracefully halt encoding once a fatal error occurs. This issue was revealed while diagnosing the above problem, and is being fixed here since it is related. TBR=pthatcher@chromium.org Bug: 888153 , 888829 Change-Id: I7e37c024f4c8b2648769b98040e3d28597b199fc Reviewed-on: https://chromium-review.googlesource.com/1242396 Reviewed-by: Yuri Wiitala <miu@chromium.org> Commit-Queue: Yuri Wiitala <miu@chromium.org> Cr-Commit-Position: refs/heads/master@{#594876} [modify] https://crrev.com/13981d5683f8b2fb6d0ea73521e72bf075b529b1/media/cast/sender/external_video_encoder.cc [modify] https://crrev.com/13981d5683f8b2fb6d0ea73521e72bf075b529b1/media/cast/sender/external_video_encoder.h [modify] https://crrev.com/13981d5683f8b2fb6d0ea73521e72bf075b529b1/media/cast/sender/video_encoder_unittest.cc [modify] https://crrev.com/13981d5683f8b2fb6d0ea73521e72bf075b529b1/media/cast/sender/video_sender_unittest.cc
,
Sep 27
Fix submitted. Requesting merge...
,
Sep 28
,
Sep 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3fff72e0471322cb300a4c5b6865ea6215402ad3 Commit: 3fff72e0471322cb300a4c5b6865ea6215402ad3 Author: miu@chromium.org Commiter: miu@chromium.org Date: 2018-09-28 21:57:17 +0000 UTC [CrOS+Cast] Fix shmem issue causing black screen share when Casting. Adds a memcpy (unfortunately) to allow content::VideoEncodeAccelerator to pass VideoFrame data to a HW encoder. Commit 4a74fb0fdb1fd882d4cc04cc had migrated the VIZ screen capturer to use the new read-only shmem API; but, unfortunately, the VEA framework for HW video encode still expects/requires the use of the legacy shmem API. Also added a little extra logic to more-gracefully halt encoding once a fatal error occurs. This issue was revealed while diagnosing the above problem, and is being fixed here since it is related. TBR=pthatcher@chromium.org Bug: 888153 , 888829 Change-Id: I7e37c024f4c8b2648769b98040e3d28597b199fc Reviewed-on: https://chromium-review.googlesource.com/1242396 Reviewed-by: Yuri Wiitala <miu@chromium.org> Commit-Queue: Yuri Wiitala <miu@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#594876}(cherry picked from commit 13981d5683f8b2fb6d0ea73521e72bf075b529b1) Reviewed-on: https://chromium-review.googlesource.com/1252847 Cr-Commit-Position: refs/branch-heads/3538@{#755} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
,
Sep 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3fff72e0471322cb300a4c5b6865ea6215402ad3 commit 3fff72e0471322cb300a4c5b6865ea6215402ad3 Author: Yuri Wiitala <miu@chromium.org> Date: Fri Sep 28 21:57:17 2018 [CrOS+Cast] Fix shmem issue causing black screen share when Casting. Adds a memcpy (unfortunately) to allow content::VideoEncodeAccelerator to pass VideoFrame data to a HW encoder. Commit 4a74fb0fdb1fd882d4cc04cc had migrated the VIZ screen capturer to use the new read-only shmem API; but, unfortunately, the VEA framework for HW video encode still expects/requires the use of the legacy shmem API. Also added a little extra logic to more-gracefully halt encoding once a fatal error occurs. This issue was revealed while diagnosing the above problem, and is being fixed here since it is related. TBR=pthatcher@chromium.org Bug: 888153 , 888829 Change-Id: I7e37c024f4c8b2648769b98040e3d28597b199fc Reviewed-on: https://chromium-review.googlesource.com/1242396 Reviewed-by: Yuri Wiitala <miu@chromium.org> Commit-Queue: Yuri Wiitala <miu@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#594876}(cherry picked from commit 13981d5683f8b2fb6d0ea73521e72bf075b529b1) Reviewed-on: https://chromium-review.googlesource.com/1252847 Cr-Commit-Position: refs/branch-heads/3538@{#755} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811} [modify] https://crrev.com/3fff72e0471322cb300a4c5b6865ea6215402ad3/media/cast/sender/external_video_encoder.cc [modify] https://crrev.com/3fff72e0471322cb300a4c5b6865ea6215402ad3/media/cast/sender/external_video_encoder.h [modify] https://crrev.com/3fff72e0471322cb300a4c5b6865ea6215402ad3/media/cast/sender/video_encoder_unittest.cc [modify] https://crrev.com/3fff72e0471322cb300a4c5b6865ea6215402ad3/media/cast/sender/video_sender_unittest.cc
,
Oct 1
Verified fixed on 70.0.3538.41 (Peppy)
,
Oct 3
Issue 891217 has been merged into this issue. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by avkodipelli@chromium.org
, Sep 21