LAV CUVID Decoder - High Quality Hardware decoding for NVIDIA

[leeperry]

righty, I'm better off waiting for the forthcoming nextgen then :)

I'll check whether my VP2/A 96SP 8800GS can do hardware double frame rate w/ less combing than YADIF on pure NTSC DVD.

[madshi]

Yeah, wait for 28nm GPUs, much better performance per watt ratio.

[nevcairiel]

LAV CUVID Decoder 0.11

0.11 - 2011/08/17
- Improved timestamp smoothing for VC-1 and MPEG4 ASP

Download: Installer (32/64-bit, CUDA 4.0+) (http://files.1f0.de/cuvid/LAVCUVID-0.11.exe) - 32-bit (CUDA 4.0+) (http://files.1f0.de/cuvid/LAVCUVID-0.11.zip) - 64-bit (CUDA 4.0+) (http://files.1f0.de/cuvid/LAVCUVID-0.11-x64.zip) -- 32-bit (Older CUDA) (http://files.1f0.de/cuvid/LAVCUVID-0.11-LegacyCUDA.zip)

There we go, another way of calculating timestamps for VC-1.
It worked quite nicely on all discs that i tried so far, but i bet there will be the occasionally totally broken file out there that fails with it. However, VC-1 is not a codec typically used by people doing encodes themself, its mostly only from Blu-rays, so i am hopeful that it will work fine. ;)

I basically borrowed some ideas from LAV Audio, completely calculating the timestamps myself, and periodically checking that they don't drift off. Works quite beautifully with all splitters.
Note that it will most likely not work with VFR material. I've never seen VC-1 VFR, but i'm sure it exists for MPEG4. If you frequently watch VFR content, i recommend another decoder - like my upcoming LAV Video.

Anyway, if you encounter sync issues or constant stuttering during playback, please report it!

[nm]

I'll check whether my VP2/A 96SP 8800GS can do hardware double frame rate w/ less combing than YADIF on pure NTSC DVD.

Yadif shouldn't leave any combing when you use mode 1. The main artifacts from yadif are smearing of fine details and shimmering. Nvidia's temporal-spatial deinterlacing smears less but shimmers more.

Note that yadif only deinterlaces, it doesn't do IVTC/pullup for telecined NTSC sources or detect cadences.

[nevcairiel]

The hardware can at least perform IVTC (but no pullup), so any content you throw at it should be artifact free.

[CruNcher]

http://www.mediafire.com/download.php?cla9ncy0m1tb89w = Black Screen
CoreAVC Cuda works

[nevcairiel]

Thats a odd file. I didn't know a NAL Size marker of 3 bytes was valid.
Anyway, its fixed.

[madshi]

It's not valid, AFAIK. Only NAL sizes of 1, 2 and 4 are allowed, to my best knowledge.

[nevcairiel]

Thats what i thought, yet this file is encoded as such, and when i allow 3, it decodes perfectly fine.

[madshi]

IIRC some early mkvtoolnix version allowed muxing with 3 byte NAL, maybe some other software allows it, too. Still, I think it's not really legal. Anyway, adding support for it probably doesn't harm, so... (Just hope that we won't see 5 byte NALs next week).

[nevcairiel]

5 is impossible, the field used to store that info in the MP4 AVC header is just 2 bits (0-3 + 1, effectively 1-4). :)

[rack04]

Can someone explain how I can setup the MPC-HC external filters priority to play content supported by LAV CUVID (H264, VC-1, MPEG-2, and MPEG-4 ASP) and then fallback to LAV Video for everything else?

[RedDwarf1]

Thank you for your work on this nevcairiel.

I have been trying it with DVBViewer and I am experiencing a problem.

When I change channels, the window resizes to the correct size but video does not display. The video only shows after I rebuild the graph. This only happens when using this decoder, ffdshow works fine and I can change channels without any problems.

Do you have any idea why it is doing this?

[pankov]

RedDwarf1,
if you wait may be around 10seconds the video might show up. At least it does for me. You could also disable "Fast Channel Switching" in Options -> TV + Radio. Sadly this will slow the channel change but will work with LAV CUVID Decoder.
A while ago I reported it to nevcairiel and offered a way for him to test it locally on his machine but sadly the discussion died out before he could fix it.
Nev, my offer stands. If you can't replicate it with your DVB source I can help you connect to my DVB Rec Service and show my DVB-C streams which always show the problem.

[RedDwarf1]

RedDwarf1,
if you wait may be around 10seconds the video might show up. At least it does for me. You could also disable "Fast Channel Switching" in Options -> TV + Radio. Sadly this will slow the channel change but will work with LAV CUVID Decoder.
A while ago I reported it to nevcairiel and offered a way for him to test it locally on his machine but sadly the discussion died out before he could fix it.
Nev, my offer stands. If you can't replicate it with your DVB source I can help you connect to my DVB Rec Service and show my DVB-C streams which always show the problem.
Ok, thank you, I understand.

It's a pity because apart from this, which is a big issue, it works quite nicely.

Just testing it again and it does eventually show the video after 21 seconds :eek:Waiting 21 seconds is a bit ridiculous to watch a channel IMO and makes casual browsing impossible. It will help save the LNB but won't do anything for frustration.

As you say, turning off fast channel switching does work because it does exactly what I was doing, re-building the graph on every channel change which takes time. With this it's about 4 seconds. The strange thing is it does seem to detect a channel change, or something does, because the window does resize almost instantly. It's just the video display which is very delayed.

ffdshow takes about 1.5 to 2 seconds. So it looks like I will stick with ffdshow and only use LAV CUVID as the Video Output B device.

I will test updates occasionally in case things improve. I might try it in media players but without any video brightness adjustments, it seems like a work in progress ATM.

[nevcairiel]

I will test updates occasionally in case things improve. I might try it in media players but without any video brightness adjustments, it seems like a work in progress ATM.

Its not the decoders job to adjust brightness or contrast, your renderer or graphics driver needs to do that. LAV CUVID will never offer those options.
About the delay - the CUVID decoder will not output images until it is certain that it can decode them without *any* artifact. Depending on how the stream is setup that you're watching, this can take some time.

In the future, there might be an option that allows you to control the error resilience, so that it actually outputs images earlier, if you want that.
The main problem there is that the decoding process is done by the NVIDIA driver. I only have a limited number of options to change, and cannot influence everything. More importantly, i generally have no idea why it does what it does. Its a black box.

[pankov]

nevcairiel,
please do add such option because I love LAV CUVID decoder's Deinterlacing and I'd like to use it in my everyday TV viewing.
Can you elaborate on this "until it is certain that it can decode them without *any* artifact"? I've tried CoreAVC in CUDA mode and it shows the video stream almost instantly and I haven't noticed any errors with it ... except the major one with the wrong field order but it has it with standalone files so I don't count it.
If you are in a good mood can you also explain why it works so quickly if we rebuild the graph and not when we change the channel without rebuilding. Is there anything that we can request from the authors of DVBViewer?

[nevcairiel]

http://files.1f0.de/cuvid/LAVCUVID-0.11-errorThreshold.zip

This version has the error threshold set to the highest, which means it'll decode any frames, no matter what. You can test with it if it actually makes the decoding start sooner.
The only reason for decoding not to output anything for so long would be that the stream is missing a SPS/PPS, and those only come every X seconds.

[pankov]

:(
I see absolutely no difference with this build.
So does this mean it's not it?
Nev, do you experience the problem at your PC or is it only me and the other guy?

[nevcairiel]

channel switches did seem instant for me, but i really haven't tried for quite a while

[pankov]

If you want I can PM you a way to connect to my Recording Service so we can test with the same streams?

[RedDwarf1]

Its not the decoders job to adjust brightness or contrast, your renderer or graphics driver needs to do that. LAV CUVID will never offer those options.
The graphics driver is not something that I want to change the brightness on because I don't want it affecting all video output.

None of the renders have any options to alter the brightness, it's not available in DVBViewer so I doubt it's their job.

Many other codecs have the option for brightness adjustment and other adjustments, ffdshow has it and CoreAVC has had it for quite some time. I think people have already mentioned it so I'm not the first person to ask about it. Maybe ATM, there are more important things to do, however it might be worth considering as the final piece of the jigsaw when other things have been completed. Otherwise there will always be something missing.

About the delay - the CUVID decoder will not output images until it is certain that it can decode them without *any* artifact. Depending on how the stream is setup that you're watching, this can take some time.
Most of the channels are Mpeg2 which shouldn't take up to 21 seconds to obtain enough information to display a picture without artifacts. I might expect H.264 video to take longer, but even then not 21 seconds, certainly not for Mpeg2.

In the future, there might be an option that allows you to control the error resilience, so that it actually outputs images earlier, if you want that.
ffdshow and CoreAVC both output video with video artifacts near the start of H.264 video before they have sufficient video to decode it correctly. Therefore, having the option would be a good thing to have available.

I have just tried the new build with the error change but it made no difference for me either.

The main problem there is that the decoding process is done by the NVIDIA driver. I only have a limited number of options to change, and cannot influence everything. More importantly, i generally have no idea why it does what it does. Its a black box.
I suggest you contact nVidia if there is anything that you need information on, because they can be very helpful, if Donald Graft's correspondence is anything to go by. Have a look at the notes for DGDecodeNV on his site for an example ;) You seem to have done well on your own so far but why make it hard for yourself if help is available? It could improve the decoder and you might learn something useful. ;) I read through the very long notes myself and found it quite informative.
http://neuron2.net/dgdecnv/cuda/cuda.html

[nevcairiel]

I suggest you contact nVidia if there is anything that you need information on, because they can be very helpful, if Donald Graft's correspondence is anything to go by. Have a look at the notes for DGDecodeNV on his site for an example ;) You seem to have done well on your own so far but why make it hard for yourself if help is available? It could improve the decoder and you might learn something useful. ;) I read through the very long notes myself and found it quite informative.
http://neuron2.net/dgdecnv/cuda/cuda.html

I know of those chats, but it sadly was really a unique opportunity because he was among the first to ever use the CUVID API, and therefor NVIDIA had a real interest in feedback. These days, its not easy to get a contact or a useful response.

Another question - when the change takes that long, what type of channels are that? MPEG2->MPEG2, or H264->H264, or even MPEG2->H264 (or other way around)?
Or does it always take long, no matter which codec combinations?

[pankov]

I've just done a lot of channel switching and I think going from one codec to the other is quick. When the two channels use the same codec then the change is slow.

Edit:
but I guess the reason for this is that DVBViewer is rebuilding the graph in this case

[nevcairiel]

I might actually have an idea why this happens, and will test some things tomorrow. Need to setup my DVB thing again.

[leeperry]

I'm not sure if that's expected behavior, but I've just spent an hour updating drivers and so...and on double framerate NTSC DVD, checking the "HQ DXVA" option either ends up in an instant BSOD on nv4disp, or a bunch of big squares and then the same BSOD :o

I run a 96SP 8800GS on XPSP3 BTW.

Note to myself: disable HQ DXVA :D

[nevcairiel]

The FAQ does say that the option might not be save on XP :-) (its also default off there, and on when running on 7)

[leeperry]

oh yah...well it wouldn't hurt to repeat it in the hover-on bubble :p

[madshi]

The FAQ does say that the option might not be save on XP :-)
What's the cause of that? Is it a CUDA related problem? Or DXVA? Or CUDA <-> DXVA interop? Or something else? I thought NVidia supported both CUDA and DXVA in XP?

[nevcairiel]

I don't have XP, and i never tested the option on XP, i just went by reports that showed the same symptoms. I figured it might be due to the lack of DXVA2 on XP.

[leeperry]

BTW, shouldn't the "adaptive" deinterlacing be called "Spatial-temporal" instead? So far, from my limited testing it seems to provide much better results than Bob.

[nevcairiel]

Why would you assume that BOB is higher quality to begin with? :)
The API calls it adaptive, so i call it adaptive. :d

[leeperry]

I'm a noob in deinterlacing, but that's what I found when googling: http://www.anandtech.com/show/1573/4
NVIDIA's PureVideo supposedly takes adaptive per pixel de-interlacing one step further with what they call Spatial-Temporal de-interlacing. The idea here is that normal per pixel adaptive de-interlacing uses data from fields within a single frame to essentially fill in the blanks. NVIDIA's Spatial-Temporal de-interlacing can use data from fields in other frames to improve de-interlacing quality.

This said, the DVD medium totally redeems itself to my eyes, when deinterlaced in 60fps by the nvidia drivers and displayed through mVR+SmoothLevels() + perfect gamut mapping :eek:

And indeed, I believe it looks better than what YADIF can do...I don't get a single artifact, yay! DVD's aren't so bad after all :)

[Didée]

@leeperry: that articel dates 7 years back. The speech is about the "no motion --> weave fields" principle (pixel/area adaptive). Old & basic stuff, you see. ;)

[nm]

And indeed, I believe it looks better than what YADIF can do...I don't get a single artifact, yay! DVD's aren't so bad after all :)

I'm pretty sure most of your DVDs are telecined from film, in which case the proper output framerate is 24000/1001 fps. You'd need an IVTC filter such as TFM+TDecimate instead of yadif to do the necessary processing in software.

That said, there are DVDs with truly interlaced video, and even hybrid movies with some scenes interlaced and others telecined. Nvidia's post-processing tries to detect the cadence and pick proper filtering. It might work ok, but I guess neither output framerate nor the display refresh rate gets changed according to the content, so there's judder in 24p sequences.

[nevcairiel]

There is indeed the 3:2 judder when deinterlacing IVTC material (which is far more likely on DVDs), but at least it'll be artifact free, even on mixed material (even mixed inside the same frame).

[nevcairiel]

LAV CUVID Decoder 0.12

0.12 - 2011/08/19
- Improved response time on channel changes in DVB Viewer
- Support decoding AVC1 with NALU sizes of 3 bytes

Download: Installer (32/64-bit, CUDA 4.0+) (http://files.1f0.de/cuvid/LAVCUVID-0.12.exe) - 32-bit (CUDA 4.0+) (http://files.1f0.de/cuvid/LAVCUVID-0.12.zip) - 64-bit (CUDA 4.0+) (http://files.1f0.de/cuvid/LAVCUVID-0.12-x64.zip) -- 32-bit (Older CUDA) (http://files.1f0.de/cuvid/LAVCUVID-0.12-LegacyCUDA.zip)

The change about DVBViewer made it about instant for me (maybe a second of corrupted image until everything is fine), so i sure hope it works for you too.

Not much more to tell, so have fun!

[leeperry]

:thanks: for the new build!

that article dates 7 years back. The speech is about the "no motion --> weave fields" principle (pixel/area adaptive). Old & basic stuff, you see. ;)
yep, but they already said that adaptive was old technology back then...this said, I'll look for more recent comparisons but subjectively speaking I find the double framerate sharper than YADIF and artifacts free at that. And that leaves the CPU hands-free considering that the GPU is taking care of it.

there are DVDs with truly interlaced video
I am indeed talking about truly interlaced 29.97 NTSC video material running at deinterlaced 59.94fps in 59.94Hz(w/ Reclock), not telecined whatsoever. I can't stand judder and man does 59.94fps deinterlaced stuff rocks :eek:

I don't bother w/ telecined stuff, especially considering that I'm from Europe and that PAL DVD's have a higher vertical resolution than NTSC....so in the rare cases where I watch DVD films, I just go 25fps@24fps in 48/96Hz w/ Reclock and there you go :)

[blubberbirne]

Hi nevcairiel,

great work with the decoder.
Could you check why LAV CUVID only run with highest Clocks (GPU,MEM) Speeds.

http://img546.imageshack.us/img546/4003/lacuvid.th.jpg (http://imageshack.us/photo/my-images/546/lacuvid.jpg/)
Using LAV CUVID: GPU runs with highest speed

http://img32.imageshack.us/img32/390/powerdvdh.th.jpg (http://imageshack.us/photo/my-images/32/powerdvdh.jpg/)
Using Power DVD: GPU runs with lower speed

Can you fix this?

[nevcairiel]

Which clocks are used is completely managed by the driver, if it decides to go into performance mode, then thats that.
You could try turning deinterlacing off, or toggling some of the other settings, to see if the driver allows it to go down then.

[mindbomb]

http://www.megaupload.com/?d=LAJVY9EO

this file(33mb) doesnt play in cuvid .9, but plays with dxva filters.

plays properly with .12

[RedDwarf1]

I know of those chats, but it sadly was really a unique opportunity because he was among the first to ever use the CUVID API, and therefor NVIDIA had a real interest in feedback. These days, its not easy to get a contact or a useful response.
That's a shame and not good news because providing support for developers does help sell nVidia cards. I purchased my nVidia card because of DGIndexNV otherwise I wouldn't of bothered and would of stuck with ATI.

Another question - when the change takes that long, what type of channels are that? MPEG2->MPEG2, or H264->H264, or even MPEG2->H264 (or other way around)?
Or does it always take long, no matter which codec combinations?
It's only when there is no graph re-build so Mpeg2-->Mpeg2 and H.264-->H.264 takes from 14 to 21 seconds and sometimes never completes. In which case I have to force a graph rebuild or no channel using the same codec will display.

My Satellite card shows 100% quality on all these channels so it's not a quality problem. My satellite driver only shows 100% when any errors are fully recoverable, it only shows the true quality for example 72%, when there are uncorrectable errors in the stream.

The latest build 0.12 still doesn't work for me so it could be my system that is to blame. It is getting old and due a re-install because a few things don't work correctly. It's like an old shoe, almost exactly how I like it, except for the few things not working. Spending hours re-installing is time I could better spend. However, it's unavoidable and has to be done in the next few days :( I do have other windows installs available on my main PC but most of those are older.

I'm not sure if that's expected behavior, but I've just spent an hour updating drivers and so...and on double framerate NTSC DVD, checking the "HQ DXVA" option either ends up in an instant BSOD on nv4disp, or a bunch of big squares and then the same BSOD :o

I run a 96SP 8800GS on XPSP3 BTW.

Note to myself: disable HQ DXVA :D

That sounds very familiar. I had a similar problem when trying to update from 197.xxx, which had been working fine, to a much more recent driver which was one or two versions back.

After doing so, I could not use any form of hardware decoding, either CUDA or DXVA. If I tried my system, which is also XP SP3, would either instantly hard lock or BSOD.

It turns out that nVidia drivers, especially on XP, don't like updates because they don't remove the previous driver remnants.

I had to uninstall them and then do use a driver cleaner to remove everything before re-installing. I now mostly works. CUDA appz work fine, DXVA works fine in MPC HC but doesn't work in LAV CUID because the video playback is partly corrupt. However there are not any BSOD's or system lockups :)

Screenshot showing corruption (http://www.zaslike.com/files/z2xekl6a6wisossmo4na.jpg)

Therefore I recommend that you uninstall and use a driver cleaner before re-installing.

[SamuriHL]

And dump XP for a more modern OS. ;)

[RedDwarf1]

And dump XP for a more modern OS. ;)

This is very off topic.

You can keep *7 with it's eye candy. I will stick to the tried and trusted XP thank you. It works far better for me than *7 ever could and I have tried *7 and didn't like it one bit.

[SamuriHL]

It is offtopic, but, I'll leave you with this thought. It's all well and good to say you'll stick with "tried and trusted XP." But, more and more things will not work on it going forward because they'll be written with W7, and soon W8, in mind. Just because some people choose to cling to ancient OS' doesn't mean the rest of the world does. Sure it "works" but when you do encounter problems, are you going to expect developers to work on fixing them? Right now that's not such a crazy idea, but, going forward, it's really going to be a waste of developer's time to try and keep supporting a 10 year old OS. Just something to think about. I'm certainly not trying to start a debate or flame war or anything like that. If you're happy with your OS, that's all good as far as I'm concerned. But, you're likely to see less and less support going forward. It's to be expected as tech evolves.

[leeperry]

That sounds very familiar. I had a similar problem when trying to update from 197.xxx, which had been working fine, to a much more recent driver which was one or two versions back.

After doing so, I could not use any form of hardware decoding, either CUDA or DXVA. If I tried my system, which is also XP SP3, would either instantly hard lock or BSOD.
[..] I recommend that you uninstall and use a driver cleaner before re-installing.
Well, I was one WHQL version behind and that's what happened...I spent an hour uninstalling via driver cleaners/setting my custom res again and running more tests....CUDA has always worked fine, but whatever I'd do "HQ DXVA" would always BSOD. I've learned my lesson, but I think it'd be more user-friendly to clearly state it in the hover-on bubble than in the tiny FAQ of the second OP of this thread. Or gray it down completely if XP is detected. Adaptive is artifacts-free, I don't see how it could look any better either way :p

[6233638]

Hi nevcairiel,

great work with the decoder.
Could you check why LAV CUVID only run with highest Clocks (GPU,MEM) Speeds.

http://img546.imageshack.us/img546/4003/lacuvid.th.jpg (http://imageshack.us/photo/my-images/546/lacuvid.jpg/)
Using LAV CUVID: GPU runs with highest speed

http://img32.imageshack.us/img32/390/powerdvdh.th.jpg (http://imageshack.us/photo/my-images/32/powerdvdh.jpg/)
Using Power DVD: GPU runs with lower speed

Can you fix this?I have just been looking into this today, after measuring the power consumption of my system.

It's not an ideal solution, but Nvidia Inspector (http://blog.orbmu2k.de/tools/nvidia-inspector-tool)'s Multi Display Power Saver tool (right-click the "show overclocking" button to access it) allows you to force the GPU into the lower clocked P8 (Video) power state rather than going into the P0 (Full 3D) power state with CUVID.

It's a less-than-ideal tool to be using, but works for now, cutting my power consumption by 7W compared to CPU decoding.


Hopefully Nevcariel can figure out why CUVID is kicking the GPU into the Full 3D P0 power state rather than the Video P8 power state.

EDIT: Actually, this tool is awesome!
Rather than adding mpc-hc.exe to the P8 Applications list, I have set it to activate the P8 state by VPU usage, and set that to 40%. (may need to experiment with this)

With the HD videos I have tried so far, the lowest VPU usage for decoding has been around 45%, so this ensures it is not switching states in use. (that causes severe video stuttering)

However, it lets the GPU run in the extra-low-power 2D mode (P12) with less demanding videos (e.g. MP4 off the web) which has dropped my power consumption with them to 92W compared to 103W in P8. For reference, my system idles at 90W.

[RedDwarf1]

Well, I was one WHQL version behind and that's what happened...I spent an hour uninstalling via driver cleaners/setting my custom res again and running more tests....CUDA has always worked fine, but whatever I'd do "HQ DXVA" would always BSOD. I've learned my lesson, but I think it'd be more user-friendly to clearly state it in the hover-on bubble than in the tiny FAQ of the second OP of this thread. Or gray it down completely if XP is detected. Adaptive is artifacts-free, I don't see how it could look any better either way :p
I don't think it really matters what update you do, it still has problems, however I don't know whether it is specific to XP.

I was getting BSOD's and lockups when using any form of accelerated decoding on any player or application so it was nothing to do with LAV CUVID, it was only the nVidia drivers at fault. The FAQ only mentions corruption for XP which is what I experience when using it. It doesn't cause BSOD's! If you fix your drivers it won't happen. ;)

It is recommended that you reboot into safe mode to do the cleaning.

[RedDwarf1]

I have just been looking into this today, after measuring the power consumption of my system.

It's not an ideal solution, but Nvidia Inspector (http://blog.orbmu2k.de/tools/nvidia-inspector-tool)'s Multi Display Power Saver tool (right-click the "show overclocking" button to access it) allows you to force the GPU into the lower clocked P8 (Video) power state rather than going into the P0 (Full 3D) power state with CUVID.

It's a less-than-ideal tool to be using, but works for now, cutting my power consumption by 7W compared to CPU decoding.


Hopefully Nevcariel can figure out why CUVID is kicking the GPU into the Full 3D P0 power state rather than the Video P8 power state.

A similar thing happens on my GT240. Even for SD Mpeg2 it is still the same.

I have just checked DGIndexNV and it's the same with that. With nothing else using the GPU, the clocks are all low, however by just opening DGIndexNV the clocks all jump to maximum, even with no video opened. Therefore it must be something to do with accessing CUDA that bumps the clocks to maximum. Not even doing any actual decoding affects them.

[6233638]

...it must be something to do with accessing CUDA that bumps the clocks to maximum. Not even doing any actual decoding affects them.That was what I suspected. Please check my updated post above regarding the use of this tool.

It activates the P8 (Video) power state with HD videos, but for SD videos, it keeps it in the P12 (2D) state, which is just enough with my GTX 570 to let madVR perform the scaling I like (90% GPU load) dropping my power consumption a further 8W below DXVA.

92W with forced P12, MadVR/CUVID & SD video.
100W with EVR-CP/DXVA (P8) & SD/HD video.
103W with forced P8, MadVR/CUVID & HD video.
147W with standard P0 and MadVR/CUVID & SD/HD video.

Before I also started throttling my CPU, my system's power consumption was almost 180W today, so I have almost halved my power consumption in some situations. (CPU was also going to full clockspeed on playback previously)