Windows 8.1 Battery Life Investigation: 1080p Video Playback
by Jarred Walton on November 6, 2013 8:13 PM EST_678x452.jpg)
A couple weeks back, I posted a short article on battery life with Windows 8.1 looking at whether or not it had changed compared to Windows 8. The short summary is that no, it did not change appreciably, though at least one of the tests I ran showed worse battery life with Windows 8.1 compared to Windows 8. There are quite a few variables, and we try to minimize the impact of other elements on battery life, but since I can’t easily go back and retest the original Windows 8 results it’s difficult to say for certain if the drop is consistent among laptops or something specific to the Sony VAIO Pro 13.
One interesting subject did come up with that article, however, and it was something I wanted to investigate further. One of the readers asked about what program we were using for video playback in our “Heavy” test, and I responded we use Media Player Classic Home Cinema (MPCHC). One of the main reasons we use MPCHC is that our test video is a 1080p MKV file with a high bitrate video, specifically it’s a 10.4Mbps video stream using the AVC High L4.1 profile. The file also has a 510Kbps 6-channel DTS audio stream, and that’s where we start to run into trouble with our choice of video playback software. MPCHC supports the file natively, as does VLC, but Windows Media Player and the Windows 8 Video app would require additional codecs (they show the video but don't handle the audio). Rather than deal with those issues, I chose (back in the Windows 7 era) to simply use MPCHC 64-bit and call it a day.
Keep in mind that we’re dealing with something of a worst-case scenario in terms of battery life, so as long as the workload is consistent among tested laptops we’re don’t have a problem. However, I wanted to look at a variety of programs and decoding video on Windows 8.1, and as Windows Media Player and Video couldn’t handle our original file natively I had to resort to using a different video file.
For this testing, I grabbed a 1080p MP4 video that worked with all four video playback options. The file is a 2.03 Mbps MP4 with an AVC High L4.1 profile video stream and a 93.8 Kbps 2-channel AAC audio stream. (Update: I also used the 720p MP4 file we use for tablet battery life testing, which I only tested with the Modern Video app. It's a 4Mbps video stream using the AVC High L3.1 profile, with a 2-channel 164Kbps AAC audio stream.) I tested with MPCHC, VLC, Windows Media Player, and the Modern UI Video app – and the last I tested with and without activating desktop mode to see if that made a difference. I also tested the original MKV file with both MPCHC and VLC as a reference point.
In all cases the software is set to loop and a local file logs the time until the laptop shuts off (at 1% battery life remaining). All of the video players were using the default GPU decoding (DXVA) for the initial testing; I am in the process of running additional tests (e.g. MPCHC will be retested with EVR mode enabled). Here are the current results.
The results are interesting to say the least. If we start with the MKV file compared to the MP4 file, VLC actually ends up doing a bit better than MPCHC by 7%. Switch to the lower bitrate MP4 file and MPCHC comes out ahead by 3%. There are differences, but it’s not so much that one would worry much about it. It’s when we start to look at the two Microsoft applications that we get some startling results.
Windows Media Player manages 418 minutes of playback time with the MP4 file – or 32% better than MPCHC and 36% better than VLC. That’s a huge difference and suggests that Microsoft still knows a thing or two about optimizing better than the third part video applications. If that’s not enough, the Windows 8 Video app ends up surpassing Windows Media Player by an additional 13% in Modern mode – or nearly 50% more than MPCHC and 54% more than VLC.
As for launching from the desktop vs. staying in the Modern UI, we see a 2% difference by staying within the Modern UI, so it’s measurable but not massive. Personally, I use so many desktop mode applications that I'm not sure it's realistic to even stay exclusively in the Modern UI, but it does make a slight difference in battery life.
Of course there’s more to the story than simply which media player gets the best battery life. Are they all showing the same quality and doing the same work? That’s difficult to say without further analysis. It could be that WMP and Video are offloading more work to the GPU than CPU, or perhaps the opposite. Either way, the battery life results show just how big of a factor software optimizations can be.
Looking at the big picture, with the Windows 8 Modern Video app and sporting a 37Wh battery, the Sony VAIO Pro 13 manages nearly eight hours of battery life on a 1080p video file. Our tablet video file is a 720p video file with a higher bitrate but lower resolution, and with that Surface Pro 2 and updated firmware gets just under eight hours of battery life as well – on a smaller 10.6” display and with a higher capacity 42Wh battery. (Note that Anand tested Surface Pro 2 with the Modern Video app as well.) Update: I tested the VAIO Pro 13 in the Modern Video app with the 720p tablet MP4; battery life is slightly higher than with the 1080p MP4, as seen in the updated chart.
It’s clear that Sony has done more to optimize for battery life on the VAIO Pro 13 than any other Haswell laptop that we’ve encountered. We’re still not at the point where Haswell with Windows 8 matches the various Android or iOS devices on video playback, but with the right tuning of hardware and software that goal may be within reach, especially with a 10” display and other hardware tweaks. Unfortunately, most laptop manufacturers haven’t put in the effort to get there, but Sony shows what’s possible and we hope to see better efforts in this area from other manufacturers going forward.
I'm still looking at running additional tests of video playback battery life on the VAIO Pro 13, while I still have it in hand. If you have any specific requests (e.g. "Run MPC-HC version XYZ with the ABC decoder"), send me an email and I will try to accommodate any reasonable requests. Keep in mind that every test run requires at least six hours (including recharge time) and as much as ten hours, so realistically I can at best run two battery tests per day. Again, feel free to email me if you have any other suggestions or questions.
Facebook
Twitter
RSS
61 Comments
View All Comments
geok1ng - Thursday, November 7, 2013 - link
http://en.wikipedia.org/wiki/Sampling_rate"The Nyquist–Shannon sampling theorem states that perfect reconstruction of a signal is possible when the sampling frequency is greater than twice the maximum frequency of the signal being sampled"
geok1ng - Thursday, November 7, 2013 - link
Because of the Nyquist-Shannon theorem, sampling rates higher than about 50 kHz to 60 kHz cannot supply more usable information for human listeners.Higher rates such as 192 kHz are prone to ultrasonic artifacts causing audible intermodulation distortion, and inaccurate sampling caused by too much speed.[6] The Audio Engineering Society recommends 48 kHz sample rate for most applicationsjohn13 - Thursday, November 7, 2013 - link
What are you talking about? The sampling rate is different from the bit rate. You're confusing them as one thing.A5 - Thursday, November 7, 2013 - link
You are dramatically wrong in thinking sample rate and bit rate are the same thing. They're not.john13 - Thursday, November 7, 2013 - link
It seems that you don't know much about signal processing either.kaworu1986 - Thursday, November 7, 2013 - link
Why is it that neither Microsoft, nor Apple nor Google natively support MKV?Since it is just a container, it shouldn't be much work to add support if used with standard codecs like h264, which are already supported in other containers. It is also anything but new at this point and is in very widespread use.
Personally, I find it beyond annoying that I can't watch my videos on my iPad or Surface unless I am willing to remux them (and transcode the audio, since mp4 doesn't support AC3 streams).
azazel1024 - Thursday, November 7, 2013 - link
I'll admit that native mkv support is annoying, but I long, long ago in a home office far away just encoded all my videos to .mp4 high profile. I come across an MKV, in to Handbrake it goes. Probably some quality loss transcoding it that way, but it isn't ever something I've noticed.All my own rips are just native mp4 high profile with 2-channel AAC audio and done. It meets my quality expectations and works across all of the devices I have tried without problems. Generally 720p for high def sources with the occasional 1080p thrown in the mix for things that I really, really care about having max quality for; supposing I am not just plunking the blu ray in to the drive and watching it that way. On my mobile devices, I am not noticing a quality difference when viewing on such a small screen and on my TVs, 32" and 42" I barely notice a quality difference at my viewing distances between 720p and 1080p, its there but small and generally not worth the ~2x increase in file sizes and storage space required for that. That is ignoring the whole issue of needing to re-transcode the video to something smaller and/or needing to store two copies when I want to load it on my 16GB iPhone or iPad (or T100 in a couple of weeks...though that thing will have substantially more storage space with a little 64GB micro SD card in there). It just isn't pratical to be tossing a 4-8GB 1080p movie on my phone.
inighthawki - Thursday, November 7, 2013 - link
Could you clarify what exactly you mean by this:"As for launching from the desktop vs. staying in the Modern UI, we see a 2% difference by staying within the Modern UI, so it’s measurable but not massive. Personally, I use so many desktop mode applications that I'm not sure it's realistic to even stay exclusively in the Modern UI, but it does make a slight difference in battery life."
Is this simply try to imply the difference between loading the file entirely from within the metro video app vs launching it by going to desktop and finding the file (and then ending in the video app)? I was a bit confused at first since there is a different metric for WMP (desktop mode).
Thanks
JarredWalton - Thursday, November 7, 2013 - link
Yes, someone mentioned in the previous article that Windows 8 doesn't load up a bunch of stuff related to the desktop until you first use the desktop (or a desktop application). So normally I open Windows Explorer, go to C:\Benchmarks (where I put all the test files), and launch the video file from there -- right-click and "Open With..." and select the appropriate player. However, I was curious to see if it would make a difference if I rebooted, opened the Video app, and then opened the file from there. It made a slight difference, but there are other factors as well....Specifically, for all of the other testing, I have a batch file that spits out the time to a local file every 60 seconds. The laptop is set to shut down at critical battery level (1%), so when power is gone the file stops getting updates. I can then do the math to figure out how long the laptop was running. Since launching a batch file obviously requires the use of the desktop, for the "stay 100% within Modern UI" testing I used a different PC set to ping the test laptop once every 30 seconds. It's possible the batch file uses fractionally more power than the pinging, so that might account for the 9 minute difference (+/- margin of error).
g0blue - Thursday, November 7, 2013 - link
As a graphics driver developer, I can say there are quite a few things that can affect battery life during video playback. Windows 8.1 includes support for a couple things that are HW dependent that can have a noticeable effect:- Multi-plane Overlay: This allows the display HW to composite the video with the video controls or desktop, all depending on the surface format the video decoder outputs and the HW used. I don't think Haswell supports this at all, but I could be wrong. If this is enabled (especially in desktop mode), it could save a lot of GPU work per frame. In full screen mode this still may be useful for scaling the video using the display HW rather than the 3D portion of the GPU. The display can usually do it more efficiently.
- Variable refresh rate: This is dependent on the actual display panel used along with the GPU, and the video being displayed. If the video is a native 24FPS (i.e. from film) video and being displayed full-screen, the app can request that the refresh rate of the panel be lowered to 48Hz. This increases fluidity by switching from a 3:2 display pattern to displaying each video frame for 2 display frames. Decreasing the refresh rate also lowers memory bandwidth (and power consumed) for driving the display. I think only the metro video app supports this and may explain some of the efficiency there.
There is also what other people have mentioned: how much work is the GPU doing vs. the GPU, how optimized in the CPU code on each of the players, etc.