In fact, raising to P1. I'd consider this a blocker for this feature, since this is causing very high CPU usage in background video-only HTMLMediaElements with looping enabled.

What do you think about disabling the optimization for video-only media? Seems like we'd suspend them anyway when in background, so the optimization is a no-op (well, as you found out, it's actually worse).

Seems like this is the prime use case for the feature on desktop, so I wouldn't disable the optimization.

Don't we suspend no-audio videos on desktop when they're invisible?
I meant if that's the case, disabling video track doesn't make sense, right? If we don't suspend them like we do on Android, maybe we should?

No, we don't do that today; that's what we're hoping for from this feature :) You're right that maybe just suspending them is okay too.

Right, I was hoping that maybe we could find with something better by using the information available to us in WebMediaPlayerImpl::UpdatePlayState_ComputePlayState. There's a bunch of different flags computed in there and I'm not sure yet which ones we need to adjust. If we suspend video-only media element, is it going to be automatically unsuspended once the tab gets into foreground? I.e. are we guaranteed to get WebMediaPlayerImpl::UpdatePlayState_ComputePlayState invoked again any time background/foreground status changes?

Yes, that's how all videos worked on Android before we allowed audible videos to play in the background. I imagine we'd have to set is_backgrounded to true on desktop if !paused && has_video && !has_audio or something like this.

Auto-pausing inaudible videos in the background sounds reasonable. Note that when I talked to Mozilla, they told me they simply restarted inaudible videos from the beginning when the page is foregrounded. I would assume they do that so they can free up some memory. It might break some pages though so I would prefer to start by simply pausing them.

Our suspend architecture allows us to drop all resources and keep the current time (modulo things like 200-vs-206 type responses)

Worth looking into then! :)

Sergey or anyone else, how does one measure the high CPU usage? I'd like to check that suspending silent videos actually solves the original problem.

I've noticed this when I opened a web page containing video-only element (https://youcontrol.com.ua/landing_001/) with  --enable-features=BackgroundVideoTrackOptimization flag and put the initial tab containing the video element into background by opening chrome://media-internals in a new tab. I've then observed chrome://media-internals tab being flooded with start/seek/stop events and being somewhat unresponsive and CPU usage for the chrome process was above 100% in top.

It sounds that it shouldn't be very hard to write a Layouttest for this. avayvod@, if you don't find a audio-only file in the LayoutTest files, I created one last week, I can upload it if needed.

+John

In the code review (https://codereview.chromium.org/2567833002) it was suggested the behavior change might be too big for a bug fix; however I think suspending inaudible background videos seems like a good solution:
- it makes the behavior consistent with Android
- it should save power
- it will be behind the flag and we will try to catch any downsides by experimenting before launching to 100%

A caveat in my CL I think is that we also wouldn't pause the videos with no-audio track after being in the background for a few seconds - something we do currently and what I believe breaks webpages that don't show controls to unpause the videos (e.g. in the case of the gif sites, page backgrounds and so on)

avayvod@, I assume we would resume these videos when going back to the page, right? If we do that, what would be the main issue for web pages using video as images or page backgrounds?

Well, that's why the cl has the second diff in it. The first diff enables the suspending logic on desktop (skipping streams with audio). That solves the issue except that there's the idle suspend timer that pauses the element that has been suspended for a few seconds. After that the element won't be resumed as it is. We could look into resuming but in the CL I simply don't schedule the timer for no-audio streams so they resume automatically when become visible.

You can check the idle suspension timer on Android already I believe - if one backgrounds a video-only element on Android for long enough, it won't resume when the page goes back to the foreground. I think it already breaks sites like gfycat.com on Android... Maybe we want to remove the suspension timer after all (streams with audio are not suspended and therefore not affected by the timer IIUC).

I spoke with Dan. It sounds like the user-facing behavior here is fine but there is concern about exposing suspend/resume control at a different level than before in the code. In other words this is a maintainability issue not a UX issue. Dan did I get that right?

Dan and I discussed this offline and agreed on pausing the silent videos when hidden and unpausing them when shown if they weren't paused in any other way before (e.g. by the page). I've updated my CL.

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

commit eb9098d5864f531fdc7d72550c4928daed0e626b
Author: avayvod <avayvod@chromium.org>
Date: Sat Jan 07 00:33:03 2017

[Video] Pause videos with no audio when in the background.

Pause video-only players when they go to background and continue playback when they go into foreground and hasn't been paused explicitly in the mean time.
Behind the experiment for optimizing background video playback.

BUG= 671381 
TEST=Manual

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

[modify] https://crrev.com/eb9098d5864f531fdc7d72550c4928daed0e626b/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/eb9098d5864f531fdc7d72550c4928daed0e626b/media/blink/webmediaplayer_impl.h

@avayvod-- Could you please let us know if there are any manual repro steps to reproduce the issue, if there is , please provide us the expected result . So , that we can verify it from Chrome-TE end.

Thanks!

hdodda@ Sure. See #c15 for the repro case.

1. Launch Chrome with --enable-features=BackgroundVideoTrackOptimization (can be enabled via chrome://flags).
2. Open a page with a video with no audio (e.g. https://avayvod.github.io/avayvod.github.io/EsteemedDescriptiveAttwatersprairiechicken.mp4) and play the video looped (right-click to loop on desktop).
3. Background the video and observe the chrome://media-internals for the player.

ER: the video is paused and the media logs reflect that
AR: the video was selecting and deselecting video tracks infinitely, flooding the media-internals page and making Chrome unresponsive.