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

Issue 842931 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug



Sign in to add a comment

Nexus 7 fullscreen video playback fails

Project Member Reported by vsupruniuk@google.com, May 14 2018

Issue description

Chrome Version: 68.0.3413.0
OS: Android 5.1.1

What steps will reproduce the problem?
(1) Open https://www.w3schools.com/html/html5_video.asp
(2) Start video playback then switch to fullscreen mode

What is the expected result?
video and sound plays successfully in fullscreen mode

What happens instead?
Screen goes black, however sound plays successfully

Link to CL: https://chromium.googlesource.com/chromium/src/+log/539937d7cce565ab995c962e2edb314deb48731b..f680291c2d0aaa1935e1a6c10bd0562aea45e96f

bisect_builds output:
Downloading list of known revisions... (use --use-local-cache to cache and re-use the list of revisions)
Total of 100 percent of perf builds available in the range
Downloading revision 554468...
Bisecting range [554249 (good), 554687 (bad)].
Trying revision 554468...
Installing /tmp/bisect_tmpzufc2N/ChromePublic.apk on adroid device...
Launching  chrome on adroid device...
Revision 554468 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 554577...
Bisecting range [554468 (good), 554687 (bad)].
Trying revision 554577...
Installing /tmp/bisect_tmprAAay5/ChromePublic.apk on adroid device...
Launching  chrome on adroid device...
Revision 554577 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 554522...
Bisecting range [554468 (good), 554577 (bad)].
Trying revision 554522...
Installing /tmp/bisect_tmpMtHpVR/ChromePublic.apk on adroid device...
Launching  chrome on adroid device...
Revision 554522 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 554549...
Bisecting range [554522 (good), 554577 (bad)].
Trying revision 554549...
Installing /tmp/bisect_tmpMSJema/ChromePublic.apk on adroid device...
Launching  chrome on adroid device...
Revision 554549 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 554563...
Bisecting range [554549 (good), 554577 (bad)].
Trying revision 554563...
Installing /tmp/bisect_tmp9Nr8kY/ChromePublic.apk on adroid device...
Launching  chrome on adroid device...
Revision 554563 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 554556...
Bisecting range [554549 (good), 554563 (bad)].
Trying revision 554556...
Installing /tmp/bisect_tmp_rD73X/ChromePublic.apk on adroid device...
Launching  chrome on adroid device...
Revision 554556 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 554559...
Bisecting range [554556 (good), 554563 (bad)].
Trying revision 554559...
Installing /tmp/bisect_tmp4D99wI/ChromePublic.apk on adroid device...
Launching  chrome on adroid device...
Revision 554559 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 554557...
Bisecting range [554556 (good), 554559 (bad)].
Trying revision 554557...
Installing /tmp/bisect_tmpn7EJgV/ChromePublic.apk on adroid device...
Launching  chrome on adroid device...
Revision 554557 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 554558...
Bisecting range [554557 (good), 554559 (bad)].
Trying revision 554558...
Installing /tmp/bisect_tmp2hCkFm/ChromePublic.apk on adroid device...
Launching  chrome on adroid device...
Revision 554558 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
You are probably looking for a change made after 554558 (known good), but no later than 554559 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/539937d7cce565ab995c962e2edb314deb48731b..f680291c2d0aaa1935e1a6c10bd0562aea45e96f



 
Components: Internals>Media>Hardware
Labels: -Pri-3 ReleaseBlock-Stable M-68 Pri-1
Status: Assigned (was: Untriaged)
Note that 
Components: Internals>Services>Viz
Note that this is failing on ToT. This is passing for VP9 videos, but failing on H264 videos, so we think it is hardware-decode related. The culprit is crrev.com/554559 . liberato@ should be able to help viz team understand how video team is using their code in this case.
Cc: reve...@chromium.org
Project Member

Comment 4 by bugdroid1@chromium.org, May 17 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9c9ce82fac113a031ea2d059ff9799e15e9abdb3

commit 9c9ce82fac113a031ea2d059ff9799e15e9abdb3
Author: liberato@chromium.org <liberato@chromium.org>
Date: Thu May 17 21:05:23 2018

Skip opacity check for underlays on Android.

We cannot cancel an overlay on android since there is no fallback.
Also, the resource's idea of opacity is unrelated to what the
overlay actually contains; it's just a dummy resource.

This CL skips the opacity check on Android.

Bug:  842931 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I8223ca35f78548e3150af05efa715fdd801e115e
Reviewed-on: https://chromium-review.googlesource.com/1062017
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559675}
[modify] https://crrev.com/9c9ce82fac113a031ea2d059ff9799e15e9abdb3/components/viz/service/display/overlay_strategy_underlay.cc
[modify] https://crrev.com/9c9ce82fac113a031ea2d059ff9799e15e9abdb3/components/viz/service/display/overlay_strategy_underlay.h
[modify] https://crrev.com/9c9ce82fac113a031ea2d059ff9799e15e9abdb3/components/viz/service/display/overlay_unittest.cc
[modify] https://crrev.com/9c9ce82fac113a031ea2d059ff9799e15e9abdb3/components/viz/service/display_embedder/compositor_overlay_candidate_validator_android.cc

Status: Fixed (was: Assigned)
I see. Thanks for taking care of this. We've been talking about using a ChromeOS specific overlay strategy so as to avoid breaking Androids use. I guess that's not longer an academic concern.
np.  i thought it was assigned to me, actually.  :)

android could use a "require overlay" flag, similar to what we have for windows.  that would also prevent this, but i haven't had a chance to add it.
Verified on Chrome:68.0.3437.0 Device:Dell Venue 10 7040/LMY47I
Issue 840317 has been merged into this issue.

Sign in to add a comment