[Nexus 7 General] bftb0:
For the type of video playback bcvictory is using, HW mode actually increases the number of available hours of play (uses less power). So I can definitely see why he would want to avoid HW decoding - even though you would set it to exactly the opposite if you wanted to actually watch videos without draining the battery too much!

Some number of weeks ago I ran (partial discharge*) tests using only the stock JDQ39 kernel, MX player and a single looped video, but configuring MX Player's options or other system options.

pct/hr hours Description

23.3% 4.3 S'ware render, 4 threads max, Brightness Min, Interactive gov
22.7% 4.4 S'ware render, 2 threads max, Brightness Min, Interactive gov
10.7% 9.4 H'ware render, Brightness Min, Interactive gov
13.3% 7.5 H'ware render, Brightness Max, Interactive gov
10.7% 9.4 H'ware render, Brightness Min, Conservative gov
9.3% 10.7 H'ware render, Brightness Min, Powersave gov (Fmin=340 Mhz)

pct/hr = rate of battery discharge per hour

hours = Expected runtime (hours) extrapolating to 100%-to-0% battery consumed

* every test was started with the battery at about 86-87% and the video loop run for 90 minutes. The partial battery discharge observed in these cases was between 14% to 35%.

I can certainly see why bcvictory wanted his battery tests done in a reasonable amount of time - if he used HW acceleration, probably it would take him 10 days to get the tests done!

Note that (in my single-kernel tests):

a) use of Hardware rendering typically halved the power consumption, (or alternately, doubled the extrapolated 100% battery use hours) compared to software rendering.

b) the number of threads available to the MX Player didn't make any difference.

c) the difference between min brightness and max brightness made a noticeable, but not huge difference

d) For the Powersave governor, I adjusted the Fmin upwards (from the default) until there was no noticeable stuttering of the video-it would not run at the default Fmin.** No doubt the frame rate was lower though. Even given this extremely conservative rate governor, the power savings was tiny.

While some might find these results a little bit surprising, it shows just how dependent a benchmark is on the nature of the load that is used for testing. For video playback, there is no OpenGL scene rendering taking place, as might be the case for synthetic scenes such as with games. Most of the computational work is in decompressing the input stream and running the decoder(s). The fact that adding additional software threads in the pure-software rendering case didn't change the result shows that (in my case anyway) this was not a computationally bound process. Yet, allowing some aspects of MX Player to offload floating-point work to the HW decoder made a huge difference in power consumption!

Would that situation be different if Mx Player had been compiled to take advantage of NEON? Maybe so, maybe not.

Video playback can be a little bit strange as a benchmark for power consumption, even though it is a very real world usage-case scenario: it is of obvious importance to people that want to watch videos. But because the decoder is allowed to drop frames in order to meet timing deadlines (so the video/audio plays back at "real-time" speed), the amount of computational work that is performed is variable. Got a high-speed CPU/GPU? More frames per second = more computational work performed per second.

cheers

** yes you can use Trickster Mod with the stock JDQ39 kernel. Some of the governors available are buggy, though.