Can you provide the device model that you're seeing this issue in?  Thanks.

It's a Sony Xpery Z Ultra

Thank you for providing more feedback. Adding requester "candrada@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Note:
1) This issue is observed on all devices 
2) Good Build:  57.0.2987.77
   Bad Build:   57.0.2987.88
3) Bisect range: https://chromium.googlesource.com/chromium/src/+log/57.0.2987.77..57.0.2987.88?pretty=fuller&n=10000
4) Unable to find exact culprit as there are no enough builds.
5) Please find logs and video taken on Moto G4 Plus/7.0.0 @ http://go/chrome-androidlogs1/6/703105

mlamouri@, Can you please take look in to this issue.

That sounds like a power saver issue. I don't see anything in the bisect range that changed this behaviour but assigning to Dale as his team could have a first look into this.

From bisect range, most likely change is avayod@'s change to update play state. Possibly we're not sending the right flags to MediaWebContentsObserver anymore to preserve the power save blocker. I don't have an android device with me today, so can't look. =>avayod since I think those changes got merged to M57 as well.

amueller326@ are you able to reproduce this on Chrome Beta (M57) too?

At the first glance, seems like we do report the state as GONE, instead of playing, to the delegate for the video only streams as they don't have remote controls. We should only do that however when the player is or is going to be suspended I think (so otherwise it is in the PLAYING state). Dan, WDYT? 

https://cs.chromium.org/chromium/src/media/blink/webmediaplayer_impl.cc?rcl=da65ddd7e896738a9ccbeacf277105394d429291&l=2030

This sounds reasonable. It sounds like another case where one value (player state) has been overloaded with multiple meanings (power block and media controls); perhaps a future refactor should separate those.

avayvod@ can you confirm if this bug made it to m57 as part of the bg playback merges? We'll likely need to merge your fix if so, otherwise we may get a bunch of complaints about things like animated "gifs" not keeping the phone awake.

Yeah, this patch was merged (the cl range mentioned in #c5 is from 57).
The batteries will last longer though :P

+amineer since this is in M57

The fix is in CQ: https://codereview.chromium.org/2767253002

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

commit 5f34b644166c2dc02f7f937f69ce0fd08e89e626
Author: avayvod <avayvod@chromium.org>
Date: Thu Mar 23 03:14:04 2017

Don't GONE the unsuspended video only players

Video only players are reported to RendererWebMediaPlayerDelegate as GONE
even if they're playing. This CL would make sure we only report suspended
players as GONE. This affects the logic in MediaWebContentsDelegate that
creates the power blocker for videos.

BUG= 703105 
TEST=manual

Review-Url: https://codereview.chromium.org/2767253002
Cr-Commit-Position: refs/heads/master@{#458995}

[modify] https://crrev.com/5f34b644166c2dc02f7f937f69ce0fd08e89e626/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/5f34b644166c2dc02f7f937f69ce0fd08e89e626/media/blink/webmediaplayer_impl_unittest.cc

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approved for M57 branch 2987 and M58 branch 3029 assuming no merge conflicts / significant refactorings to contend with.

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

commit 83cf01eb0a7b96415d46bd7b9dcd91d2cda43c23
Author: Anton Vayvod <avayvod@google.com>
Date: Thu Mar 23 03:34:44 2017

Don't GONE the unsuspended video only players

Video only players are reported to RendererWebMediaPlayerDelegate as GONE
even if they're playing. This CL would make sure we only report suspended
players as GONE. This affects the logic in MediaWebContentsDelegate that
creates the power blocker for videos.

BUG= 703105 
TEST=manual

Review-Url: https://codereview.chromium.org/2767253002
Cr-Commit-Position: refs/heads/master@{#458995}
(cherry picked from commit 5f34b644166c2dc02f7f937f69ce0fd08e89e626)

Review-Url: https://codereview.chromium.org/2773573003 .
Cr-Commit-Position: refs/branch-heads/2987@{#868}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/83cf01eb0a7b96415d46bd7b9dcd91d2cda43c23/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/83cf01eb0a7b96415d46bd7b9dcd91d2cda43c23/media/blink/webmediaplayer_impl_unittest.cc

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

commit 48a23073e515d9c8677358ddf8a5897d25a9f504
Author: Anton Vayvod <avayvod@google.com>
Date: Thu Mar 23 03:39:17 2017

Don't GONE the unsuspended video only players

Video only players are reported to RendererWebMediaPlayerDelegate as GONE
even if they're playing. This CL would make sure we only report suspended
players as GONE. This affects the logic in MediaWebContentsDelegate that
creates the power blocker for videos.

BUG= 703105 
TEST=manual

Review-Url: https://codereview.chromium.org/2767253002
Cr-Commit-Position: refs/heads/master@{#458995}
(cherry picked from commit 5f34b644166c2dc02f7f937f69ce0fd08e89e626)

Review-Url: https://codereview.chromium.org/2763373003 .
Cr-Commit-Position: refs/branch-heads/3029@{#378}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/48a23073e515d9c8677358ddf8a5897d25a9f504/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/48a23073e515d9c8677358ddf8a5897d25a9f504/media/blink/webmediaplayer_impl_unittest.cc

Anwer to comment 9: Yes i have the same behavior with M57

This issue is now not reproducible on latest M57, will verify on next M58 latest build and close the issue.

verified with Chrome '57.0.2987.126' on Galaxy S5.

avayvod@, since we merged a change for this back to stable, can you please fill out a postmortem via the process @ go/chrome-postmortems and share it with me when ready for review?

cc:govind. The bug actually affects other platforms as well and hasn't made it into the last stable build. I don't think it alone justifies a spin of stable release as the impact is less severe on desktop but thought I'd inform the TPM.

cc:ketakid for CrOS

The postmortem is hosted internally at go/chromepostmortem376.

Tested the issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.3 using chrome latest Beta M58-58.0.3029.41 by following steps mentioned in the original comment. Observed that screen is active when playing the videos(With/without sound) are playing as expected. Hence adding TE-Verified label.

Please find the screen cast for reference.

Thank you!

Deleted: 703105.ogv 5.0 MB

	703105.ogv 5.0 MB View Download

I tested 57.0.2987.110 and 59.0.3053.3 on Ubuntu and can confirm that on the Stable build my screen went off after being idle for 5 minutes (the timeout I set on the machine) while watching the video with no audio track (one at http://storage.googleapis.com/watk/v). The bug didn't reproduce on Canary. 

re #32: 57.0.2987.110 doesn't include this fix. Please use 57.0.2987.133 for testing. Thank you.

Right, Dale asked me to verify if the bug exists on desktop platforms in the postmortem document, hence testing on .110

Verified the issue on Windows 10, Mac OSX 10.12.3 and Linux(ubuntu 14.04Lts) with Chrome version 57.0.2987.133. 

Steps Followed :
1. launch Chrome and Visit https://storage.googleapis.com/watk/v
2. Play buck720p30_h264_noaudio.mp4 

Observed behavior :
Screen never went to sleep.