Awesome, this is really useful information. I'd be curious about browsers as well, I remember reading an article, perhaps a year ago or more, that Internet Explorer provided the best battery life as opposed to Chrome.
What was the version of MPCHC used? You should test with the latest nightly, and test the decoding options on Lav-Filters. I'm guessing that you tested with the default CPU decoding. Quick Sync will probably be much better, test with DXVA also while you're at it.
MPCHC defaults to dxva2 now with evr. The standard builds should be tested. I would like to see if there is a difference between 32bit and 64bit versions of MPCHC and VLC.
Are the performance and stability isues with the 64-bit version of MPC-HC resolved now? Where the VLC and MPC-HC MP4 tests using DXVA? I'm sure the Windows native apps uses it.
As for the Vaio, any updates on the bad WiFi on it?
The large battery life difference for hardware accelerated decoding warrants further investigation. It would be nice if someone figures out why this is and what settings, if possible, can change this.
I like MPC-HC because it doesn't require codec packs that mess with the OS and I like the jumping feature with the arrow keys. VLC is too flaky for me.
According MPC-HC's changelog, the latest version (1.7.0) has switched to using the LAV Filters internally. I haven't updated to the newer version yet mainly due to not using my Windows install much. I wonder if there are some issues with the LAV transition.
There was an update a few weeks ago that resolved the issue with the WiFi not resuming after sleep. I'm not entirely sure how much if at all it helped the issues Jarred reported he had with the range and signal dropoff, but I haven't had any problems since.
So what player will future tests use? I mean VLC which is very popular is better as well as both of Microsoft's solutions. It simply seems misleading to the viewers and punishes your Windows based devices reviews as compared to the iOS and Android devices that do not suffer with an inefficient video player.
I'm curious if the Mac systems can be tested with a single video application that also runs on Windows. Something equally optimized for both platforms. Which while it am typing seems to be an easy thing to argue about from platform to platform. Video is always a challenge to find a good format for all devices and maximizes quality at various resolutions.
I think using MP4+AAC is optimally optimized for both platforms since both Apple and Microsoft support it natively. You aren't going to find a third party software that will do as well.
I mean, technically you could try QuickTime on Windows, but I doubt it will be optimized as much on Windows.
Keep in mind that the "Heavy" test is designed more as a worst-case scenario and the use of MPCHC on Windows platforms means all of the tested laptops are on equal footing. Comparing Windows with OS X of course creates complications -- and that goes for the choice of audio playback software in the Medium test, web browser selection, media player, and other power settings. Apple does very well at optimizing their OS and software for battery life it seems, but I've always been a bit hesitant to compare cross-OS battery life scores for the above reasons.
If we're going to suggest cross platform software, I would suggest iTunes+QuickTime. The problem is Apple won't optimize for Windows, so the next best solution would be to use MP4+AAC and use iTunes on Mac and WMP on Windows.
To play files with DTS audio streams as well as MKVs in the native apps, I use Shark007 codecs which, unlike other codec packs, keeps the install/uninstall and setting changes very clean (just beware the offers to install malware when you first install the pack, sigh). Changing to Gabest splitter under the MKV and MPG~MP4 tabs will do the trick.
Love that codec, no bloat and useless stuffs, clean all-in-one shortcut to settings and good integration with all existing players. Highly recommended.
You need to uninstall those first. Not 100% certain, but I think the installer detects other packs and will automatically uninstall them for you with your permission. Don't quote me on that though as I've never had to do that myself.
Also, please remember that it will try to trick you into installing malware the first time you install it! So be vigilant! Why Shark007, WHY????
FWIW, I also set everything to use ffdshow dxva codecs, I find I get the best experience with that combined with my settings I posted before.
I'm curious if there's any way to determine exactly how much of the decoding is being offloaded to the fixed-function logic blocks on the CPU rather than by software--I almost never play longer videos on my laptop off of airplaines, and my kids are at an age where having my laptop open and watching a movie in flight is challenging, so that is also largely a moot point for me. However, I'm interested in a comparison of the video decoding logic in Haswell and the logic in my various ARM SoCs (and Bay Trail too!); any thoughts you have would be greatly appreciated.
If you do feel like adding one more test, YouTube is probably the most-used video player on my laptop, though doing a proper comparison with YouTube probably requires uploading a video, then downloading the video that gets posted, as I have no idea what sort of software Google is using on their end to do the encoding. And I have no idea if it's possible to get YouTube to cache an entire video and play it forever, so maybe it's hopeless to get a real comparison--but even a non-comparable data point would be good to see.
Could you share the test clips you're using (both mkv and mp4) so I can do my own tests with different settings in MPC-HC? I have the same laptop so the results should be comparable to yours.
The 1080p MP4 file is Oblivion. I'm sure you can figure out where to find it, but email me if you want more specifics. (Note: Film selection was not a part of the equation; it was the only 1080p MP4 I had on hand.)
Jarred I think I have an answer to your question. Reading your Vaio review it seemed to hint that Sony has throttled the 4400 IGP. The 4400 on the Surface might not have been throttled at all. There's your battery runtime difference, and since this was noticed on video testing then it might also be that the GPU is doing the work, otherwise the load would have been greater on the Vaio.
Too bad Anand did not test the Surface as an ultrabook(which it actually is) and probably due to time constraints stopped at tablet testing. Some PC performance numbers compared with your Vaio numbers would have shed some light on this.
Interesting, but I wonder how using a Metro MKV player (mobile.HD) will affect battery life. My understanding is that the application just demuxes it and sends the stream to the native windows renderer - so battery life should be comparable.
Also this asks another question - how is battery life affected by browser choice, my adhoc observations are that IE11 is better for battery life than Chrome - but would be nice to have some tests around this.
Jarred, you should make clear what encoding you use for both video and audio streams in the tested content. MP4 and MKV are containers and can potentially contain H.264 or MPEG-2 or MPEG-1, etc. The L4.1 profile designation suggests H.264/AVC, however "MP4 High L4.1" is arguably incorrect term.
What would make most sense would be to put the mp4 video and audio stream into an mkv, and the mkv video and audio stream into mp4s, and then test battery life across various players to see if it's just the player/container combo that isn't working, or whether there's an underlying issue with certain files being too demanding (e.g. the integrated GPU can't manage to keep up and then needs some CPU assist, increasing load, for example).
As someone already suggested, if you posted up the video files (the mkv and mp4) that you used, people would probably be happy enough to crowdsource some testing of different variables on their own systems.
I mentioned the MP4 above (Oblivion); the MKV is Harry Potter 1 (Sorcerer's Stone). I really don't have the time or inclination to fiddle with demuxing and remuxing the AV streams as I am already way behind on a bunch of reviews. The battery testing is thankfully something that I can set up and run in the background, so if you have any other settings/apps you'd like me to test on the VAIO Pro 13 with the MP4 file, let me know!
What Windows 8.1 needs to have is a PureMedia mode. Whereby the OS shuts down everything that isn't needed to play video and audio. No other services trying to ping out to the web, other stuff churning in the background etc. etc.
Great for when on a flight etc. I know there have been similar BIOS level systems but its about time this was built into Windows.
"510Kbps 6-channel DTS audio stream". I would imagine what kind of alien ears would need this kind of Kpbs for good audio quality. Most people with money to buy a semi-decent 6channel speakers can not hear beyond 10kHz frequencies, a simple lesson on signal decoding would show that you only need to sample at twice the max frequency, hence 48Kbps is the most a human need, at any age, for perfect audio reproduction. AT is dealing with problems caused by audiots who don't know SHT about signal processing or human audio physiology and try to sell high bitrate streams as better sound experience.
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"
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 applications
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).
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.
"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).
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).
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.
I have noticed that MPCHC has a hard time with 1080p mkv files. And I think evr is mandatory for gpu acceleration on MPCHC now. VLC has some acceleration built in now.
Also the version of MKVMerge used to create the file can actually change how it plays in dramatic ways.
You can mux h264 and dts into and mp4 file as well.
Could you run the tests with a tool that tracks wattage info from the battery, and see how accurate the reporting is? If the hardware itself is accurate over, say, an hour, you'd just need to run the test for a specific amount of time and take the average wattage. That would also reduce the skew caused over time by a wearing battery (which shouldn't be a problem on something like the Sony, but which may crop up with cheaper devices, over a couple dozen complete drains).
For software it's only fair to use one given with the OS (in this case Video Metro) as it will be the most commonly used by users as well as a cross-Platform one such as VLC, although it's certainly not optimized for battery life.
I am genuinly interested in how Sony optimized battery life when all components are standard and it will certainly not patch the OS. If you really calibrate all monitors to have the same luminosity, I can think of only 2 parts playing a major role: the battery itself and the screen. Could you test both hypothesis? e.g. switch the sony battery with say a x1 battery and normalize results according to battery size. With a little McGyver tuning it shouldn't be too hard.
Switching screens would be much harder, but could you run the tests with the screen deactivated? This would show how much of an inpact the screen has on battery usage for video.
Hi, I did a similar comparison test between Windows 7, 8, 8.1. I hope I am allowed to link here, but you can find it at youtube.com/watch?v=BAbEkHfx8FA. I have found that 8.1 does improve in video playback battery life on my test device. If you like my content also check out madpc.be.
I have timed battery life during video playback while measuring GPU usage on a Dell Venue Pro 11 tablet with the Video app and VLC. The Venue Pro 11 plays video for 10.5 hours with the Video app, which is phenomenal! Read the entire article: http://helgeklein.com/blog/2014/02/gpu-acceleratio...
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
61 Comments
Back to Article
munim - Wednesday, November 6, 2013 - link
Awesome, this is really useful information. I'd be curious about browsers as well, I remember reading an article, perhaps a year ago or more, that Internet Explorer provided the best battery life as opposed to Chrome.Andre Carmel - Wednesday, November 6, 2013 - link
What was the version of MPCHC used? You should test with the latest nightly, and test the decoding options on Lav-Filters. I'm guessing that you tested with the default CPU decoding. Quick Sync will probably be much better, test with DXVA also while you're at it.JarredWalton - Wednesday, November 6, 2013 - link
MPCHC defaults to DXVA mode for what it's worth. I figured four media players was a reasonable start and left it at that.Andre Carmel - Thursday, November 7, 2013 - link
What is the decoder used? I'm asking because the newest versions of MPCHC switched to Lav Video Decoder.toyotabedzrock - Thursday, November 7, 2013 - link
MPCHC defaults to dxva2 now with evr. The standard builds should be tested. I would like to see if there is a difference between 32bit and 64bit versions of MPCHC and VLC.jason11 - Wednesday, November 6, 2013 - link
Are the performance and stability isues with the 64-bit version of MPC-HC resolved now? Where the VLC and MPC-HC MP4 tests using DXVA? I'm sure the Windows native apps uses it.As for the Vaio, any updates on the bad WiFi on it?
jason11 - Wednesday, November 6, 2013 - link
Also, test DXVA and Quick Sync with the MKV files using VLC and MPC-HC.JarredWalton - Wednesday, November 6, 2013 - link
All of the files default to DXVA decoding on MPCHC and VLC. What else is going on, I don't know for sure.jason11 - Thursday, November 7, 2013 - link
That's weird then. What was the CPU utilization? There could be a regression bug.morts - Thursday, November 7, 2013 - link
The large battery life difference for hardware accelerated decoding warrants further investigation. It would be nice if someone figures out why this is and what settings, if possible, can change this.I like MPC-HC because it doesn't require codec packs that mess with the OS and I like the jumping feature with the arrow keys. VLC is too flaky for me.
shing3232 - Thursday, November 7, 2013 - link
Can you add a test for Quick sync in MPC-HC?JarredWalton - Thursday, November 7, 2013 - link
Quick Sync for playing video? I thought QS was only for encoding -- where are you wanting me to enable this setting?morts - Thursday, November 7, 2013 - link
The LAV filters can use DXVA or Quick Sync to accelerate video decoding.JarredWalton - Thursday, November 7, 2013 - link
Currently testing with EVR (not EVR Custom Presenter). I'll see about LAV afterwards....morts - Thursday, November 7, 2013 - link
According MPC-HC's changelog, the latest version (1.7.0) has switched to using the LAV Filters internally. I haven't updated to the newer version yet mainly due to not using my Windows install much. I wonder if there are some issues with the LAV transition.Omniwar - Thursday, November 7, 2013 - link
There was an update a few weeks ago that resolved the issue with the WiFi not resuming after sleep. I'm not entirely sure how much if at all it helped the issues Jarred reported he had with the range and signal dropoff, but I haven't had any problems since.dylan522p - Wednesday, November 6, 2013 - link
So what player will future tests use? I mean VLC which is very popular is better as well as both of Microsoft's solutions. It simply seems misleading to the viewers and punishes your Windows based devices reviews as compared to the iOS and Android devices that do not suffer with an inefficient video player.eanazag - Wednesday, November 6, 2013 - link
I'm curious if the Mac systems can be tested with a single video application that also runs on Windows. Something equally optimized for both platforms. Which while it am typing seems to be an easy thing to argue about from platform to platform. Video is always a challenge to find a good format for all devices and maximizes quality at various resolutions.michael2k - Thursday, November 7, 2013 - link
I think using MP4+AAC is optimally optimized for both platforms since both Apple and Microsoft support it natively. You aren't going to find a third party software that will do as well.I mean, technically you could try QuickTime on Windows, but I doubt it will be optimized as much on Windows.
Krysto - Thursday, November 7, 2013 - link
Better to use VLC since it's cross-platform, and we can get a sense of battery life performance across platforms.JarredWalton - Thursday, November 7, 2013 - link
Keep in mind that the "Heavy" test is designed more as a worst-case scenario and the use of MPCHC on Windows platforms means all of the tested laptops are on equal footing. Comparing Windows with OS X of course creates complications -- and that goes for the choice of audio playback software in the Medium test, web browser selection, media player, and other power settings. Apple does very well at optimizing their OS and software for battery life it seems, but I've always been a bit hesitant to compare cross-OS battery life scores for the above reasons.michael2k - Thursday, November 7, 2013 - link
If we're going to suggest cross platform software, I would suggest iTunes+QuickTime. The problem is Apple won't optimize for Windows, so the next best solution would be to use MP4+AAC and use iTunes on Mac and WMP on Windows.rainking430 - Wednesday, November 6, 2013 - link
To play files with DTS audio streams as well as MKVs in the native apps, I use Shark007 codecs which, unlike other codec packs, keeps the install/uninstall and setting changes very clean (just beware the offers to install malware when you first install the pack, sigh). Changing to Gabest splitter under the MKV and MPG~MP4 tabs will do the trick.bountygiver - Wednesday, November 6, 2013 - link
Love that codec, no bloat and useless stuffs, clean all-in-one shortcut to settings and good integration with all existing players. Highly recommended.JNo - Thursday, November 7, 2013 - link
Does Shark007 install easily alongside existing installed codecs/players? (I have K-lite codec pack & VLC).Or will it interfere with them and I should uninstall those first?
rainking430 - Thursday, November 7, 2013 - link
You need to uninstall those first. Not 100% certain, but I think the installer detects other packs and will automatically uninstall them for you with your permission. Don't quote me on that though as I've never had to do that myself.Also, please remember that it will try to trick you into installing malware the first time you install it! So be vigilant! Why Shark007, WHY????
FWIW, I also set everything to use ffdshow dxva codecs, I find I get the best experience with that combined with my settings I posted before.
jhoff80 - Wednesday, November 6, 2013 - link
Personally, I kind of wonder how a Metro MKV player like mobile.HD would compare to the desktop apps.teiglin - Wednesday, November 6, 2013 - link
I'm curious if there's any way to determine exactly how much of the decoding is being offloaded to the fixed-function logic blocks on the CPU rather than by software--I almost never play longer videos on my laptop off of airplaines, and my kids are at an age where having my laptop open and watching a movie in flight is challenging, so that is also largely a moot point for me. However, I'm interested in a comparison of the video decoding logic in Haswell and the logic in my various ARM SoCs (and Bay Trail too!); any thoughts you have would be greatly appreciated.If you do feel like adding one more test, YouTube is probably the most-used video player on my laptop, though doing a proper comparison with YouTube probably requires uploading a video, then downloading the video that gets posted, as I have no idea what sort of software Google is using on their end to do the encoding. And I have no idea if it's possible to get YouTube to cache an entire video and play it forever, so maybe it's hopeless to get a real comparison--but even a non-comparable data point would be good to see.
skiboysteve - Wednesday, November 6, 2013 - link
Jared you are awesome. Thanks for listening and spending the time to test. this data is great!skiboysteve - Wednesday, November 6, 2013 - link
Jarred*ajp_anton - Thursday, November 7, 2013 - link
Could you share the test clips you're using (both mkv and mp4) so I can do my own tests with different settings in MPC-HC? I have the same laptop so the results should be comparable to yours.JarredWalton - Thursday, November 7, 2013 - link
The 1080p MP4 file is Oblivion. I'm sure you can figure out where to find it, but email me if you want more specifics. (Note: Film selection was not a part of the equation; it was the only 1080p MP4 I had on hand.)ananduser - Thursday, November 7, 2013 - link
Jarred I think I have an answer to your question. Reading your Vaio review it seemed to hint that Sony has throttled the 4400 IGP. The 4400 on the Surface might not have been throttled at all. There's your battery runtime difference, and since this was noticed on video testing then it might also be that the GPU is doing the work, otherwise the load would have been greater on the Vaio.Too bad Anand did not test the Surface as an ultrabook(which it actually is) and probably due to time constraints stopped at tablet testing. Some PC performance numbers compared with your Vaio numbers would have shed some light on this.
Nero3000 - Thursday, November 7, 2013 - link
Interesting, but I wonder how using a Metro MKV player (mobile.HD) will affect battery life. My understanding is that the application just demuxes it and sends the stream to the native windows renderer - so battery life should be comparable.Also this asks another question - how is battery life affected by browser choice, my adhoc observations are that IE11 is better for battery life than Chrome - but would be nice to have some tests around this.
radek - Thursday, November 7, 2013 - link
Jarred, you should make clear what encoding you use for both video and audio streams in the tested content. MP4 and MKV are containers and can potentially contain H.264 or MPEG-2 or MPEG-1, etc. The L4.1 profile designation suggests H.264/AVC, however "MP4 High L4.1" is arguably incorrect term.Lonyo - Thursday, November 7, 2013 - link
What would make most sense would be to put the mp4 video and audio stream into an mkv, and the mkv video and audio stream into mp4s, and then test battery life across various players to see if it's just the player/container combo that isn't working, or whether there's an underlying issue with certain files being too demanding (e.g. the integrated GPU can't manage to keep up and then needs some CPU assist, increasing load, for example).As someone already suggested, if you posted up the video files (the mkv and mp4) that you used, people would probably be happy enough to crowdsource some testing of different variables on their own systems.
JarredWalton - Thursday, November 7, 2013 - link
I mentioned the MP4 above (Oblivion); the MKV is Harry Potter 1 (Sorcerer's Stone). I really don't have the time or inclination to fiddle with demuxing and remuxing the AV streams as I am already way behind on a bunch of reviews. The battery testing is thankfully something that I can set up and run in the background, so if you have any other settings/apps you'd like me to test on the VAIO Pro 13 with the MP4 file, let me know!Lonyo - Thursday, November 7, 2013 - link
That's why you crowdsource the benchmarks!jabber - Thursday, November 7, 2013 - link
What Windows 8.1 needs to have is a PureMedia mode. Whereby the OS shuts down everything that isn't needed to play video and audio. No other services trying to ping out to the web, other stuff churning in the background etc. etc.Great for when on a flight etc. I know there have been similar BIOS level systems but its about time this was built into Windows.
geok1ng - Thursday, November 7, 2013 - link
"510Kbps 6-channel DTS audio stream". I would imagine what kind of alien ears would need this kind of Kpbs for good audio quality. Most people with money to buy a semi-decent 6channel speakers can not hear beyond 10kHz frequencies, a simple lesson on signal decoding would show that you only need to sample at twice the max frequency, hence 48Kbps is the most a human need, at any age, for perfect audio reproduction. AT is dealing with problems caused by audiots who don't know SHT about signal processing or human audio physiology and try to sell high bitrate streams as better sound experience.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.
toyotabedzrock - Thursday, November 7, 2013 - link
I have noticed that MPCHC has a hard time with 1080p mkv files. And I think evr is mandatory for gpu acceleration on MPCHC now. VLC has some acceleration built in now.Also the version of MKVMerge used to create the file can actually change how it plays in dramatic ways.
You can mux h264 and dts into and mp4 file as well.
mkozakewich - Saturday, November 9, 2013 - link
Could you run the tests with a tool that tracks wattage info from the battery, and see how accurate the reporting is? If the hardware itself is accurate over, say, an hour, you'd just need to run the test for a specific amount of time and take the average wattage. That would also reduce the skew caused over time by a wearing battery (which shouldn't be a problem on something like the Sony, but which may crop up with cheaper devices, over a couple dozen complete drains).Silma - Saturday, November 9, 2013 - link
For software it's only fair to use one given with the OS (in this case Video Metro) as it will be the most commonly used by users as well as a cross-Platform one such as VLC, although it's certainly not optimized for battery life.I am genuinly interested in how Sony optimized battery life when all components are standard and it will certainly not patch the OS.
If you really calibrate all monitors to have the same luminosity, I can think of only 2 parts playing a major role: the battery itself and the screen.
Could you test both hypothesis? e.g. switch the sony battery with say a x1 battery and normalize results according to battery size. With a little McGyver tuning it shouldn't be too hard.
Switching screens would be much harder, but could you run the tests with the screen deactivated? This would show how much of an inpact the screen has on battery usage for video.
Rishi100 - Monday, November 11, 2013 - link
Please include the test on quality of video and audio output with each software.Matthias Duyck - Saturday, December 14, 2013 - link
Hi, I did a similar comparison test between Windows 7, 8, 8.1. I hope I am allowed to link here, but you can find it at youtube.com/watch?v=BAbEkHfx8FA. I have found that 8.1 does improve in video playback battery life on my test device. If you like my content also check out madpc.be.haakaa - Wednesday, February 12, 2014 - link
I have timed battery life during video playback while measuring GPU usage on a Dell Venue Pro 11 tablet with the Video app and VLC. The Venue Pro 11 plays video for 10.5 hours with the Video app, which is phenomenal! Read the entire article: http://helgeklein.com/blog/2014/02/gpu-acceleratio...