I think this may be a duplicate of crbug/691106. Please make sure that this isn't fixed when the fix for crbug/691106 comes in.

one addition, this also happen on 720p30fpsVP9 video. The usual power usage for 720p30fpsVP9 is around 1.90+/-0.05. Since 2/12, it spikes to 2.09~2.21

on the same day build, crbug/691106 is fixed. there is normal power usage number for 1080p60fpsH264 or VP9 video. so this issue is different from crbug/691106.
I can keep monitor it for a few days to rule out random flake on this device. If it consistently repro, we definitely need take a look.
give back to eric.

I've noticed that uptick as well, starting right around 58.0.3001.0. I will keep this bug until Tuesday, pull #'s again, and if we're still sitting high, I'll route to Caleb to bisect (again).

I don't think this is a real bug; I think it is likely already fixed. Here are steps to figure out if it was fixed by the ANGLE roll from crbug/691106

0. Open a terminal on a corp linux box and authenticate your machine:
$ prodaccess

1. Make a citc client:
$ g4d -f investigation

2. Make sure the client is synced to latest google3 version:
$ g4 sync

3. move to the Video Stack AVA directory:
$ cd chrome/videostack/testing/av_analysis

4. Run blaze command to run the test:
$ blaze test --notest_loasd --test_strategy=local --test_output=streamed --test_timeout=10000 :<device>_<browser>  --test_filter=<class name>.<test method name> --test_arg=--build=<chrome revision>

A. The --notest_loasd argument says to use your own credentials to run the test instead of using test credentials.

B. The --test_strategy=local argument says to start the test on your own machine instead of on Forge.

C. The --test_output=streamed argument says to get output from the test as it comes instead of getting a whole batch of it at the end.

D. The device names can be listed using the following command:
$ cat build_defs.bzl | grep name\':
For this test use device "surfacepro_corem3_6y30_intelhd515_win10"

E. The browser is "chrome" unless you want to run against "edge" or "safari".

F. The --test_filter argument is optional. If you don't include it, it will just run the whole suite of tests instead of just one, which is fine if you're willing to wait. I'm working on simplifying this, but currently you have to read the code to find the class name. For all desktop chrome tests, the class name is "ChromeVideoStackSwarmingTest". You can find this name by reading the chrome_videostack_swarmingtest.py file. Also in the same file is the list of test names. You can find the list of tests by running:
$ cat chrome_videostack_swarmingtest.py | grep "def test"
In this case, you want "test720p30fpsH264"

G. The --test_arg=--build=<chrome revision or version> argument says which version of chrome to run against. It takes either a chrome revision like "450521" or a chrome version like "58.0.3010.0". For this test, go to crbug/691106 and find the changelist https://chromium.googlesource.com/chromium/src/+/4c068148da571995bf8582415ae3eb8f29ad0af8 that was supposed to fix the bug. In that changelist it says the "Cr-Commit-Position" is 450521. So run against 450521 to run the first version of Chrome that has the fix, and run against 450520 to run against the last version of Chrome before the fix.

The full blaze command is 
$ blaze test --notest_loasd --test_strategy=local --test_output=streamed --test_timeout=10000 :surfacepro_corem3_6y30_intelhd515_win10_chrome  --test_filter=ChromeVideoStackSwarmingTest.test720p30fpsH264 --test_arg=--build=450521

5. I would recommend running the test twice so that you can make sure that results are consistent
$ for i in `seq 2`; do blaze test --notest_loasd --test_strategy=local --test_output=streamed --test_timeout=10000 :surfacepro_corem3_6y30_intelhd515_win10_chrome  --test_filter=ChromeVideoStackSwarmingTest.test720p30fpsH264 --test_arg=--build=450521; done

6. If the command fails and says something about an allocation timeout, then that means that the device or the recorder for the device is being used by another test. To check the status of the device and its recorder, go to https://omnibot.googleplex.com/device_manager/device and search for the device name. The name of the related recorder is in the Groups list of the device. If either of these two devices is not Free, then you have to wait for them to become free.

7. The test will take several minutes to run.

8. Go to https://av-analysis.corp.google.com/#/get-testpasslist/2/VideoStack to see your run. type your alias into the Owner box to filter to only tests run by you. If you want freezing/smoothness results instead of power results, you have to wait longer.

9. Run another test against 450520 to make sure that the commit for 450521 was what actually caused the improvement.

For the command, you also need to add --nocache_test_results otherwise the command will only run once.:

$ for i in `seq 2`; do blaze test --notest_loasd --test_strategy=local --test_output=streamed --test_timeout=10000 :surfacepro_corem3_6y30_intelhd515_win10_chrome  --test_filter=ChromeVideoStackSwarmingTest.test720p30fpsH264 --test_arg=--build=450521 --nocache_test_results; done

I checked the last several days power usage data, starting 2/18 58.0.3016.0 build, 720p30fpsH264 video file power usage is back to normal (~1.65), but 720p30fpsVP9 video power usage is still higher (~ 2.11) than expected value (~1.95).
I'll keep eye on it for a few more days (until this Friday) to see if it will get any better.

the power usage value for 720p30fpsVP9 dropped to 2.04 on 2/22, though slightly higher than expected 1.91, but is better than before.
the power usage value for 720p30fpsH264 is back to normal range 1.60~1.65
It is ok to resolve this bug now.