I am doing a manual bisecting.

Unrelated to this bug, but since I just measured, Edge is about 3.5, which is expected comparing with Chrome M70's 4.0.

crouleau@: it seems we have a coverage gap in media lab's video testing

-crouleau since he moved on from video stack.
+some video folks

go/videostack-ava-sheriff has all the information on our process. A lot of bugs have been filed, so it's possible that we did catch this but then nothing has been done.

M70 cut is 587811, and M71 cut is 599034.

Bisecting between 587811 and 599091 results in nothing. Everything looks good.

So it's either a Cl merged back to M71 caused the regression, or Beta is running with some variations (experiments) that caused the regression.

Still digging...

Interesting. Even to the latest ToT build 605562, I can't repro a regression, but the regression is clear in Beta, Canary, Dev.

Pls land the fix to trunk ASAP and request a merge to M71 once change looks good in canary.

Is this only applicable to Windows or Other OSs too? 

Windows only

Ok, request a merge to M71 branch latest by Thursday morning so we can take it in for this week beta release. Otherwise, it will punt to next week beta release. Thank you.

Thank you for the info. I still haven't figured out what contributed to this regression. --use-cmd-decoder=validating/passthrough doesn't make a difference. video-to-surface does make a small difference, but that doesn't count for the big gap we see here.

Likely one of the experiments, but still need to look further. If it's one of the experiments, we can just turn it off on the server side.

Ok, sounds good. Pls keep the bug updated. 

Is there any update here? We won't block this week beta for this.

Still working on it. Getting the variations transferred over from chromium build to an official build is really complicated process!

Let's not block this week's beta update by this. Thank you.

M71 Stable promotion is coming VERY soon. Your bug is labelled as Stable  ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.

Friendly ping to get an update as per c#20.
Thanks..!

Sorry, still haven't been able to ping down what's the exact cause for this regression that happens only on official builds...

After further investigation, it seems like we do a lot of CPU intensive work on official builds at startup, which doesn't exits on Chromium.

For example, if I wait 5 minutes before measuring video power, the regression is only around 5%. If I wait 10 minutes before measuring, the regression isn't there at all.

At this point, I am closing this. I don't think start-up time power usage is a big concern because their affecting battery life is ignorable. We mostly care about video power when Chrome is mostly only playing video, not doing tons of other works.

dougman@: this is also an interesting data point for media lab's video power measurements.  I assume media lab runs chromium continuous builds? Although start-up power surge like I observed in this bug on official builds isn't as severe on chromium build, but still, we might want to wait a bit before starting measuring. That will give us more stable power measurement data.

That's an interesting observations.
To clarify, the power measurement tests in AV lab use Chrome canary build.

If it's Canary, unless you wait 5+ minutes, otherwise you are measuring way more than just video playing power and the results are somewhat invalid.

For now, I suggest if possible, switch to continuous build, in which the above mentioned noise is not as bad as official builds ...

Clifford, you could switch from using gs://chrome-unsigned version-numbered builds to using gs://chrome-test-builds/per-commit, which are the same builds that Telemetry uses. The problem is that they are numbered by revision rather than version number, so that would require a bunch of infrastructure changes for things like alerting and graphing.

I would suggest first testing to see if zmo's hypothesis is correct. This would be trivial to do simply by running a version numbered build and a revision numbered build in VideoStack AVA and seeing if the output is similar.

Caleb, thanks for the advance.
I was thinking the same thing too (revision vs version number).
The other option seems to be delaying the measurements after a period of time (as suggested 5 mins).
I am trying to see if that's an easier workaround.