Can you please let us know if you find this issue on latest chrome stable: 53.0.2785.124? 

Thanks!

Re: Comment 4
This issue exists on Chrome M53. The power data on chrome stable 53.0.2785.124 is very close to stable 52.0.2743.91

Chrome 53.0.2785.124	  1066.09 (mW) 

can you send the output of 'adb shell dumpsys SurfaceFlinger' while the device is playing in full screen in both M51 and M52?  i only need the h/w composer state that's somewhat near the end, thusly:

h/w composer state:
  h/w composer present and enabled
Hardware Composer state (version 01030000):
  mDebugForceFakeVSync=0
  Display[0] configurations (* current):
    * 0: 1080x1920, xdpi=442.450989, ydpi=443.345001, refresh=16666667, colorTransform=0
  numHwLayers=5, flags=00000000
    type   |  handle  | hint | flag | tr | blnd |   format    |     source crop (l,t,r,b)      |          frame         | name 
-----------+----------+------+------+----+------+-------------+--------------------------------+------------------------+------
       HWC | b6716550 | 0002 | 0000 | 00 | 0100 | RGB_888     |    0.0,    0.0, 1080.0, 1920.0 |    0,    0, 1080, 1920 | com.android.systemui.ImageWallpaper
       HWC | b4dc28c0 | 0002 | 0000 | 00 | 0105 | RGBA_8888   |    0.0,    0.0, 1080.0, 1920.0 |    0,    0, 1080, 1920 | com.google.android.googlequicksearchbox/com.google.android.launcher.GEL
       HWC | b4dc3720 | 0002 | 0000 | 00 | 0105 | RGBA_8888   |    0.0,    0.0, 1080.0,   72.0 |    0,    0, 1080,   72 | StatusBar
       HWC | b6716a00 | 0002 | 0000 | 00 | 0105 | RGBA_8888   |    0.0,    0.0, 1080.0,  144.0 |    0, 1776, 1080, 1920 | NavigationBar
 FB TARGET | b6acfb40 | 0000 | 0000 | 00 | 0105 | RGBA_8888   |    0.0,    0.0, 1080.0, 1920.0 |    0,    0, 1080, 1920 | HWC_FRAMEBUFFER_TARGET

i'd like to see if (a) the device is in GLES composition or HWC composition, and (b) if we're supporting full screen playback on its own surface or not.

Re #6 Here's the h/w composer state

Chrome stable 51.0.2704.81
h/w composer state:
  h/w composer present and enabled
Hardware Composer state (version 01040000):
  mDebugForceFakeVSync=0
  Display[0] configurations (* current):
    * 0: 720x1280, xdpi=320.000000, ydpi=320.000000, refresh=16616816
  numHwLayers=3, flags=00000000
    type   |  handle  | hint | flag | tr | blnd |   format    |     source crop (l,t,r,b)      |          frame         | name 
-----------+----------+------+------+----+------+-------------+--------------------------------+------------------------+------
       HWC | b8fad768 | 0002 | 0000 | 00 | 0100 | ? 7f000001  |    0.0,    0.0, 1280.0,  720.0 |    0,  437,  720,  842 | SurfaceView
       HWC | b8faf4e0 | 0002 | 0000 | 00 | 0105 | RGBA_8888   |    0.0,    0.0,  720.0, 1280.0 |    0,    0,  720, 1280 | SurfaceView
 FB TARGET | b90a1c10 | 0000 | 0000 | 00 | 0105 | RGBA_8888   |    0.0,    0.0,  720.0, 1280.0 |    0,    0,  720, 1280 | HWC_FRAMEBUFFER_TARGET


Chrome stable 52.0.2743.91
h/w composer state:
  h/w composer present and enabled
Hardware Composer state (version 01040000):
  mDebugForceFakeVSync=0
  Display[0] configurations (* current):
    * 0: 720x1280, xdpi=320.000000, ydpi=320.000000, refresh=16666666
  numHwLayers=3, flags=00000000
    type   |  handle  | hint | flag | tr | blnd |   format    |     source crop (l,t,r,b)      |          frame         | name 
-----------+----------+------+------+----+------+-------------+--------------------------------+------------------------+------
       HWC | b7ebe810 | 0002 | 0000 | 00 | 0100 | ? 7f000001  |    0.0,    0.0, 1280.0,  720.0 |    0,  437,  720,  842 | SurfaceView
       HWC | b7e9c0f0 | 0002 | 0000 | 00 | 0105 | RGBA_8888   |    0.0,    0.0,  720.0, 1280.0 |    0,    0,  720, 1280 | SurfaceView
 FB TARGET | b7ee4ca0 | 0000 | 0000 | 00 | 0105 | RGBA_8888   |    0.0,    0.0,  720.0, 1280.0 |    0,    0,  720, 1280 | HWC_FRAMEBUFFER_TARGET

well, that's unexpectedly identical.  back to the starting point, i suppose.  it leaves we with some more questions:

does the power difference exist in non-fullscreen playback too?

also, how are you measuring power on this device?

can you provide a link to the source video?

how fast does the display on this device update?  i couldn't find it online.    i've seen a few cases where the new pipeline in 52 manages to display more frames than 51, for example.

It's observed that on Chrome 52.0.2743.91, larger temp binary files are generated under "cache/Media Cache" folder while playing video (M51: 530 Bytes, M52: 18.5 MB)

A possible cause of increased power consumption. (Heavier disk caches R/W or something behind)

+1 to Frank's comment, how is the smoothness of the playback in old vs new? More frames drawn == more power consumption. Also FWIW, local testing with Nexus devices does not show these power discrepancies. 

Re #8 #10
1. There's no distinct power difference at non-fullscreen playback mode, thus the issue exists only at fullscreen mode.

2. The source video can be found at below link (buck720p_h264.mp4, frame rate 30fps) https://drive.google.com/file/d/0B838V8-MbYiLVEpidDBKZUEzbHc/view?usp=sharing . 
We set up a LAN to perform the test.

3. System power is measured by power meter

4. Playback smoothness
fps data is obtained by fps-counter of chrome
                        non-fullscreen      fullscreen mode
Chrome 51.0.2704.81       20-60fps,avg 30        N/A 
Chrome 52.0.2743.91       29-31 fps             30 fps

Cannot get fps data on Chrome M51 since fps window is static. Try other tools further.

c#9: good catch.  however, since embedded playback power consumption is the same, it's probably unrelated.  there should be no caching differences between full screen and embedded.

c#11: it's surprising that the difference is confined to full screen playback only, given that the SurfaceFlinger stats are the same.  it's possible that something isn't letting the gpu sleep properly in 52; that's the main source of power savings.  normally, if SurfaceFlinger is using HWC rather than GLES composition, then there's no gpu work at all => power savings.

perhaps some per-gpu workaround in chrome is still poking at the gpu on every frame.

by end of week, i should have a device with a Mali T604.  i can check power consumption on that.

one more request -- can you send the output of chrome://gpu ?  i'd like to see which workarounds you have.  dalecurtis@ suggested that i might be able to repro it on different hardware with the right workarounds enabled manually.

Re #13
Add graphics info in the attachment

Deleted: chrome-gpu-info-M51&M52-on-B880.txt 2.3 KB

chrome-gpu-info-M51&M52-on-B880.txt 2.3 KB View Download

Could it be reproduced at your side?
Should you need further info, pls let me know.

on T604: i only got the device yesterday.  i should be able to get numbers today.

on N5 using your gpu info: didn't try.  the flags from chrome://gpu didn't have anything unusual.

it seems like spitzer is using slightly more power, though there is a lot of noise in the measurements.

i will start some longer tests and see if (a) there's an actual power difference with a sufficiently large averaging window, (b) if the playback quality is comparable, and (c) whether it's related to fetching or decoding / rendering.

i repeated this with a 7 minute 360p/30 video, and saw that spitzer (m52) uses about 4% less power than WMPA (m51).  i checked that i didn't have them backwards.

unexpected given c#17.  i'll repeat on the 720p link in c#11.

Do you use power monitor(power meter) to measure power? Attached a picture showing measurement setup.
There's small variance in measurement so test three times and take the medium.

Deleted: measurement-setup.PNG 7.5 KB

	measurement-setup.PNG 7.5 KB View Download

i have a monsoon on my desk, but i don't have a device with the right gpu that's been modified to work with it.

instead, i've been using a super old nexus 10, since at least it's got a mali gpu.  it also has an android-accessible Dallas Semiconductor DS2784.  it's not as good as the monsoon, but it's in the right general area.

Re #17
We see on M51, it costs more power at first, but drops after tens of seconds. So with a sufficiently long play time (300s, etc), we observe M51 consumes less than M52. How does the 720p video in c#11 come out?

the tests i ran were 7 minutes, so it should capture the transient response you're describing.

i haven't been able to take the measurements yet for 720, unfortunately.  ETA is today or monday.

sorry for the delay.  still haven't gotten back to this.

as an aside, i'm also going to try this on a Samsung S6, which has a T760.

i measured somewhere between 2-8% more power in WMPI (m52) than WMPA (m51) in embedded playback on the S6.

it's pretty noisy, though.  I'm also unsure how accurate it is.  It's unclear how android measures (or perhaps guesses at) battery current on these devices.  still trying to figure that out.

Thanks for your reply. Is the result of Samsung S6 also from the 720p video in c#11 ?

Since android-system-based power result remains suspicious, may try power meter approach if condition permits (such as modify super old device?). 

We can help to bisect chrome binary to locate the potential patch that causes problem, however, we don't have existing chrome binary files between 51.0.2704 and 52.0.2743. Is there any middle version binary available?

Any update?

not much, unfortunately.  i haven't been able to get back to this.

bisect: thanks for the offer, but i'm not sure that there's much to find.  M52 turns on the unified media pipeline by default, which almost entirely replaces chrome's use of android MediaPlayer with MediaCodec.  The CL that flips the default state to 'unified media pipeline' will be the one that seems to cause the power regression in a bisect.

i can generate binaries for you to test, but right now, i've got very little to go on.

i'll try playing more demanding videos to see if i can make the power difference stand out enough that it's reliably detectable.  then, i'll have some chance of figuring out the cause.

Thanks for the information about media pipeline change.
we will try below flag to verify if it is related to unified media pipeline at the same time: 
const char kDisableUnifiedMediaPipeline[] = "disable-unified-media-pipeline";

hrm, seems like this comment didn't ever successfully post last week:

here's some preliminary results.  it's running on a samsung s6, screen brightness set to minimum, location services off, wifi off, not airplane.  media is 360p30 big buck bunny playing in full screen.  I was using ToT, turning on or off the unified media pipeline.  that's about the same as m52 or m51, respectively.

when i repeated with embedded playback, it showed little difference between wmpa and the unified pipeline.

Deleted: 360p30_bbb_fullscreen.png 12.0 KB

	360p30_bbb_fullscreen.png 12.0 KB View Download

this morning, i turned off all video updates (video_layer_impl::SetNeedsRedraw() { return; }), and modified AVDA to render to front buffer rather than discard in ReusePictureBuffer -- i.e., we'll render every frame, but never mention it to the compositor.

the result is much closer to m51.  numerically, between 50-250 above (~400 seconds), we get unified / wmpa = 1.37, and unified-without-redraw / wmpa = 1.04.

remember that all of these have the screen brightness at minimum, and other power savings measures, so the effect is exaggerated quite a bit.

next step is to see what part of composition is causing the difference.

note that this actually fits pretty well with the symptoms we've observed far -- m51 embedded runs the compositor on every frame, just like the unified pipeline.  however, there are some differences in full screen playback that short-cut the compositor in the m51 case.  our power measurements showed no difference in the m50 time frame, but perhaps something in the compositor changed that we need to work around.

or, maybe it will be some unavoidable overhead, e.g. extra IPC with the browser process or similar, that we can't really do much about.

Deleted: 360p30_bbb_fullscreen_plus_no_redraw.png 13.4 KB

	360p30_bbb_fullscreen_plus_no_redraw.png 13.4 KB View Download

GLRenderer:BeginDrawingFrame and ::FinishDrawingFrame seem to be doing some extra GL work that's contributing to the power.  see attached graph, where "simplified Begin / Finish Drawing" is the unified pipeline plus some over-simplifications to remove this extra work.

numerically, for it's about 10% worse than WMPA, vs. about 40% worse than wmpa for the unmodified unified media pipeline.  recall that turning off the compositor completely was about 4% worse, from c#30.  however, unlike that approach, one might expect that these simplifications could be made to work in production.  :)

i'd appreciate it if you could give this apk a try with your power setup to see what differences you see, if any, as a sanity check.  my measurements are much less accurate than yours with a monsoon.  please run it with "disable unified media pipeline" turned off (i.e., the link should read 'enable' in about://flags.  that's somewhat confusing.)  running it both ways might be a good idea too, since many things have changed since m51.  this is based on ToT.

https://drive.google.com/file/d/0B7ROFckpOJrgRWc2QUc2WUdBOWs/view?usp=sharing

please note that the apk isn't going to be super stable.  some important parts of the compositor are turned off, for testing.  i was using a url of the form "file:///sdcard/bbb...mp4", so it was as simple of a page as possible.

Deleted: 360p30_bbb_fullscreen_plus_simplified_compositor.png 13.8 KB

	360p30_bbb_fullscreen_plus_simplified_compositor.png 13.8 KB View Download

We will try your apk with the two ways and let you know the results, thanks for your progress!

Sorry for the delay. 
We test your apk on B880 device using LAN (http://192.168.1.2/...mp4) and find that the power with "disable-unified-media-pipeline" flag is 9.3% less than default(without flag) in fullscreen mode, and 5.0% more than default in non-fullscreen mode.

                                           fullscreen       embedded
with "disable-unified-media-pipeline"      919.24            1273.56
default(without flag)                      1005.13           1210.07

Also test M52(stable 52.0.2743.91) applying the "disable-unified-media-pipeline" flag. It seems that unified-media-pipeline causes the power discrepancy.

                                           fullscreen       embedded
with "disable-unified-media-pipeline"      933.41            1242.56
default(without flag)                      1007.41           1217.16

Deleted: B880-power-curve-M52-fullscreen.PNG 114 KB

	B880-power-curve-M52-fullscreen.PNG 114 KB View Download

Deleted: B880-power-curve-M52-embedded.PNG 117 KB

	B880-power-curve-M52-embedded.PNG 117 KB View Download

comparing the default row from c#34 (1005) to the default row from c#35 (1007), it looks like the my change made no difference at all from M52.

one important point: my apk will install chromium (blue icon), not chrome.  is there any chance that you perhaps tested chrome in c#34?  i apologize for not mentioning that when i sent it.

unified-media-pipeline: this switch changes out a lot of code, so it's hard to tell specifically what's the cause.

that's ok. i'm sure that use the chromium apk you provided in c#34.

sorry for the delay.  i was ooo tuesday and didn't get back to this today.

i have to give this a more thought.  i'm unsure why i'm seeing a power savings while you are not.  it makes me concerned that my power measurement method is suspect.

We test power on Chrome stable M49(earliest stable version has unified-media-pipeline flag), M51, M52, M54 with Unified-Media-Pipeline(UMP) switch flag. 
The results show as below (may be useful).

Fullscreen:
       disable-UMP      enable-UMP     diff(ena-dis)
M49       917.00*         1213.87      296.87 (32.4%)
M51       910.22*         1047.33      137.11 (15.1%)
M52       924.78          1020.17*      95.39 (10.3%)
M54       925.80          1010.04*      84.24 ( 9.1%)
YourAPK   911.97          1005.94*      93.97 (10.3%)

Embedded:
       disable-UMP      enable-UMP     diff(ena-dis)
M49       1234.54*        1218.24      -16.3 (-1.3%)
M51       1252.78*        1257.52        4.7 ( 0.4%)
M52       1270.29         1217.29*     -53.0 (-4.2%)
M54       1270.44         1220.75*     -49.7 (-3.9%)
YourAPK   1274.61         1258.33*     -16.3 (-1.3%)

Note: * means default

It seems that Unified-Media-Pipeline cost more power from the start (more overhead ?)
The gap between WMPI and WMPA is narrowing in the process of implementation , but there's still 9-10% gap under fullscreen mode after landing.

Re #38
do you have any device on which you can try both Monsoon monitor and android-system-based method ? then you can compare and verify.

Monsoon monitor approach is relatively more reliable, accurate and recommended. If condition permits, may modify super old device to work with Monsoon. 

Any view or update, please ?

sorry for the delay.

i don't have the ability to modify a device for the monsoon.

to be honest, i'm running out of ideas until i can get a local repro.  it seems that whatever i found in c#31 didn't generalize to the device that you are testing.  i can create an apk that turns off the entire compositor during full screen playback, but it's not clear what to do with the outcome of that test unless i can diagnose it locally.

This week we observed the power discrepancy between WMPI and WMPA on Nexus 4 device (CPU: Qualcomm Snapdragon APQ8064, GPU: Adreno 320 )
Although the power curve of Nexus 4 oscillates back and forth instead of steady with time like B880, according to the average power, M52 with WMPI costs 13.4% more power than M52 WMPA (disable unified-media-pipeline(UMP)).

Fullscreen:
        disable-UMP       enable-UMP        diff(enable-disable)
M52       1294.47          1467.53*               173.06 (13.4%)

* default
Note: 1) test 3 times, get the medium
      2) use Android 5.1.1(LMY48T) image, M52 cannot be installed on 4.x

Have you got suitable device to modify ? any question ?

Unfortunately, not yet.  I'll update this thread.

Any update, please? 
if Acer liquid Z630 is unavailable at the moment, maybe start from existing old device? Since it's observed that the power discrepancy exists in other device with a Snapdragon CPU (c#43).

Zheda, are you able to offer any insight on where the power usage is going? 

At this point there's no way we'll be switching back to the old path; that ship has sailed, so insight into what might be going wrong from your side would be helpful.

WMPI(enable unified media pipeline) costs more power than WMPA only under fullscreen. So I capture some traces while playing fullscreen videos with enable UMP and disable UMP flag. It seems that the gpu behavior between WMPI and WMPA is different (DoCommitOverlayPlanes for WMPI while DoSwapBuffers for WMPA). 
A lot of trace info are missing for WMPA trace file during no touch input, thus i cannot compare workloads of both. Is it because WMPA fullscreen video streaming is taken over by the system during this time ?

Yes, WMPA uses Android's MediaPlayer which handles all aspects of the playback including rendering to a SurfaceView without going through Chrome's compositor. Are you able to compare GPU utilization? That's what we found to be most important in the past, i.e., using the GPU as little as possible for fullscreen playback. And that's why we introduced DoCommitOverlayPlanes, because it skips GLSwapBuffers. There's also probably more cpu utilization due to the cc code we run every frame, but it's unclear how large of an effect that has.

i try to use Graphics Performance Analyzers to estimate the CPU and GPU utilization of IA devices (power discrepancy also reproduced). 11% more aggregated CPU load is observed for WMPI (experiment on chrome M52, enable and disable unified media pipeline). However, unfortunately GPU utilization info cannot be obtained with fullscreen playback.

So far higher CPU utilization is a possible cause to higher power consumption.

CPU load is believable.  here's why i believe it:

in embedded playback, both pipelines run the compositor in essentially the same way.  the network stack is different.  but, we see the same power consumption approximately.  maybe some more power is spent in one spot, and less in some other, or maybe it's the same across the entire pipe.  we can't say with the information we have.

however, in full screen, we can look at how the pipeline changes.  the compositor isn't run at all for non-UMP, which reduces both CPU and GPU load.  in UMP, the compositor is run, but hopefully does no GPU work.  most everything else is the same as it was in embedded mode (e.g., decoders + network stack, etc.), or is the same between ump / non-ump full screen (i.e., SurfaceView).  so, it seems like it really comes down to "extra CPU and/or GPU load caused by the compositor".  this reasoning certainly isn't perfect, of course.

my apk tried to turn off additional GPU work for UMP full screen that we hadn't noticed before, but very little happened to the power consumption of UMP.  assuming that my apk actually worked as expected on this device (hard to say), then it looks like CPU is the likely culprit here.

it's a little tricky in that any time GPU load > 0, we have a static power usage.  so, i guess that we'd need to verify that the gpu load is about the same for my apk with UMP as it is for any of the other non-UMP apks except mine, during full screen playback before we can say for sure if it's CPU load or not.

Chrome tracing can capture cpu utilization as well. I remember seeing 3 cores utilized for WMPI vs 2 for WMPA at one point. I suspect there's more work we could do towards making the compositing step for fullscreen as much of a no-op as possible.

The inference makes sense. Maybe it's potential opportunity to optimize compositing. Do you have any BKM to monitor GPU load?

Using chrome tracing, CPU usage for non-ump fullscreen playback is unexpectedly "much" less than that for ump playback. I guess some usage is not shown.

i'm closing this as wontfix, mostly because i don't see much that we can do with it.

there is work underway to lower the CPU usage of the renderer during video playback, but it's unclear that it will affect fullscreen terribly much.

Is there any bug issue or design doc for the work in progress?
For this issue, please close it. Thanks.

crbug.com/746182 tracks replacing VideoLayerImpl with cc::Surfaces.