Current Top 3 H.264 (AVC) Decoder Performance

[CruNcher]

Top 3 Commercial Performance H.264 (AVC) Decoder (April 2007)

AMD Athlon 64 Venice 3000+ @ 3700+ (2.4 Ghz)

Test Sample 1440x1088p 8 Mbits (low complexity) (AVG CPU Utilization 30%)
)
1. CoreAVC 1.3
2. Cyberlink 1.99.0.1405 (bugs found Look Here)
3. Mainconcept 1.0.41 (build 60818) (newer builds dxva fails)

Nvidia 7600 GS PCIE Forceware 165.01 Windows XP (VMR9)

On Screen Performance:

CoreAVC (soft)
User: 20s, kernel: 1s, total: 21s, real: 26s, fps: 76.4, dfps: 60.5

Cyberlink (dxva)
User: 14s, kernel: 2s, total: 16s, real: 27s, fps: 97.4, dfps: 58.8

Mainconcept (dxva)
User: 21s, kernel: 2s, total: 24s, real: 27s, fps: 66.7, dfps: 58.6

Raw Performance:

CoreAVC (null) : User: 21s, kernel: 0s, total: 21s, real: 21s, fps: 76.4, dfps: 75.3
Cyberlink (null) : User: 28s, kernel: 1s, total: 30s, real: 34s, fps: 53.6, dfps: 47.4
Mainconcept (null) : User: 43s, kernel: 0s, total: 43s, real: 46s, fps: 37.4, dfps: 34.7


Reference Open Source Decoder (libavcodec):

On Screen Performance:

FFDshow
User: 28s, kernel: 1s, total: 30s, real: 34s, fps: 53.5, dfps: 47.3

Raw Performance:

FFDshow (null)
User: 29s, kernel: 0s, total: 29s, real: 29s, fps: 55.6, dfps: 54.7

PS: Only Progressive capabilities where tested here for now no Interlaced (MBAFF) no CABAC no DEBLOCKING and no Special things as Mainconcept's HQ Chroma Upsampleing all this is gonna follow later :)

[Dark Shikari]

You should try it with a High Profile encode at 1080p resolution, all to the null renderer, on a dual core machine.

CoreAVC is about 2-3 times faster than FFDshow on my Core 2 Duo simply from the multithreading :)

[CruNcher]

Dark Shikari this is just a simple pre test result :) im gonna update my full test soon also with Dual Core results this time :)
http://cruncher.mufflastig.com/h264/h264-decoder.txt <- here you can find the old results with much more complex High Profile Streams

Edit: Added some bugs i found in the Cyberlink Decoder (maybe a Cyberlink Engineer is arround here and can have a look) ;) but i don't think so hehe

[Crisidelm]

Mainconcept HQ Chroma Upsample is very handy when watching French HD sat channels: without it, for example, watching a football match the green of the grass "wobbles" or better yet, it "pulses" at a costant rate. Setting the HQ Chroma Upsample On resolves this problem completely.

[gronne]

So how would the x264-decoder stand in this test?

[Dark Shikari]

So how would the x264-decoder stand in this test?
x264 is an encoder, not a decoder as far as I know; do you mean FFmpeg/libavcodec?

[CiNcH]

Anybody ever taken a deeper look into 'InterVideo Video Decoder'? I just did with GraphEdit and it seems to have a good performance as well.

[CruNcher]

@CiNcH
Im not sure but isn't VC-1 and AVC directly called via 2 dlls now from within Windvd.exe (Windvd 8) so no DS filter anymore ? "Intervideo Video Decoder" is Mpeg-2 only isn't it actually i stoped trying to test the Filter because i thought they call it directly now but mybe im wrong gonna test it also then if you say it still works from DS for AVC and VC-1 :)
And about the Mpeg-2 Decoder it was allways a weak one anyways, no Mpeg-2 Decoder can beat Nvidias PureVideo Decoder with GPU support and their Motion Adaptive Deinterlacer (in terms of speed and quality compared vs tdeint realtime 1080 30i->1080 60p conversion) not even Mainconcept/Elecards Mpeg-2 Decoder, im still waiting for Nvidias announcement to bring a PureVideo H.264 Decoder onto the Market it would definately rock everyone else (if you take the Quality of their Mpeg-2 Decoder into account here) ;)

http://www.techpowerup.com/reviews/NVIDIA/G84_G86/images/HDVidProc.jpg

everything is on the GPU now but the most funny thing it only works on VISTA that way LOL the content industry really want's us on Vista ;)

[CiNcH]

Problem with InterVideo seems to be that applications do not detect it as H.264 decoder. However, on subtype {8D2D71CB-243F-45E3-B2D8-5FD7967EC09B}, the InterVideo Video Decoder connects to the Elecard Demuxer and decodes H.264, see attachement..

[CiNcH]

I think you are a little bit wrong about InterVideo's MPEG-2 decoder. The algorithms in software are amongst the best I have tested so far. It also supports DXVA which also queries deinterlacers within current GPU's. Also the proprietary PureVideo API for decoding H.264 is supported under XP (however, I do not know how to enable it, probably also by enabling DXVA2 within the registry).

As for the full H.264 support within GPU, I have just ordered a GeForce 8600GTS supporting it and it is already on the way.

[CruNcher]

Problem with InterVideo seems to be that applications do not detect it as H.264 decoder. However, on subtype {8D2D71CB-243F-45E3-B2D8-5FD7967EC09B}, the InterVideo Video Decoder connects to the Elecard Demuxer and decodes H.264, see attachement..

Ahhh nice :D if you say so about Intervideo ok i remember they cheated a while ago with resolutions and such i didn't test it since then that's true, but i stuck with Nvidias Decoder now wich seems perfect from Head to Toe (personal preference) :)


As for the full H.264 support within GPU, I have just ordered a GeForce 8600GTS supporting it and it is already on the way.


Also nice but somehow i don't like the idea of useing Vista only for that, it seems like im forced to use it only to be allowed to use the complete featureset that is ridiculous in my eyes Nvidia should fast integrate support in their XP Drivers for that i don't see any technical problem here realizeing it for XP, but maybe im just to paranoid.

Before this is not cleared and working on XP i won't replace my 7600 GS with it's Half (acceleration) support for H.264 the 30% utilization are almost full power of the GPU not much more could have been done it should be like 15-20% utilization with this test sample on the G84 (sure for HD-DVD and Blue-Ray it looks different CABAC and DEBLOCKING usage) im very skeptical about the usefullness of CABAC and Deblocking in overall Quality/Speed anyways ;) all my encodes done up to now never needed them and look ok.
With CABAC for example the more detail preservation it gives by lowering the avg ratefactor is in terms of visual difference small in my eyes (especialy at HD res and bitrate in the 6000 range) (it's just a more efficient way to save bits so perfect for low bitrates like Streaming or Sattelite) but is it worth the extra encoding/decoding time experts say yes i say no (to unbalanced) in my eyes FreXt (8x8 transform) is much more efficient then Cabac in overall detail preservation (and balance of encoding/decoding speed), but maybe that's again personal preference and how i see a good balanced video codec ;) )

And i slowly beginn to think that Microsoft Engineers really taken this more into account when developing VC-1 i never tested it personaly yet but i could belive they better balanced it then AVC (with the knowledge they already had from it's weak points) in terms of Encoding/Decoding/Quality (only their own consumer encoder seems to be very unbalanced (slow).

[CiNcH]

but i stuck with Nvidias Decoder now wich seems perfect from Head to Toe (personal preference)

Concerning DXVA implementation I agree with you. When it comes to software implementation, PureVideo filters are far from being competitive.

As long as there are no better pixelshaders for post processing available I will use software-only decoding with ffdshow (Greedy 2 Frame Deint. -> Lanczos 2-tap -> LimitedSharpen). And InterVideo is amongst the best for this purpose.


I think that there will be support in XP drivers (PureVideo 1 is also supported). I am also still using it, no reason for me to change at the moment...

[CruNcher]

Nvidia allready has some nice PP stuff like denoiseing, motion adaptive deinterlacing (quality better then tdeint) and IVTC and all of this works flawless on the GPU sure software will allways be on the front in terms of quality i absolutely agree :)
Haalis Renderer for example combined with CoreAVC is a nice combination for AVC @ the moment :)

PS: http://www.driverheaven.net/reviews/msibfg8600/8600gts.php <- support for XP in July *grml* i wonder how much of the video enthusiasts move because of this to Vista :P

[CiNcH]

I am really sick and tired of all this games and Vista hype...

[CruNcher]

Btw i would have rather advised you to not buy the Nvidia Card and wait for ATI's new Generation (R600) research time wise and taken the Development cycle of GPU's into account their new Generation should outperform Nvidia again (don't forget ATI is into Video Quality since it's existing Nvidia concentrated very late on this stuff, but sure made big steps in this area)

[Mutant_Fruit]

im very skeptical about the usefullness of CABAC and Deblocking in overall Quality/Speed anyways ;)
Cabac offers a higher compression ratio than CAVLC. Therefore it's better qualitywise, as you can get the exact same quality in lesser filesize, or greater quality in same filesize.

[foxyshadis]

Btw i would have rather advised you to not buy the Nvidia Card and wait for ATI's new Generation (R600) research time wise and taken the Development cycle of GPU's into account their new Generation should outperform Nvidia again (don't forget ATI is into Video Quality since it's existing Nvidia concentrated very late on this stuff, but sure made big steps in this area)

It's never the best time to buy new hardware. Meaning, there's always something better around the corner, but at some point you just have to buy based on what's available today.

And yeah, CABAC is useful when you don't have nearly unlimited space. When you do, why bother? :p I know others will probably argue it, but it seems to be the most important practical differentiator compared to VC-1. Without it, most of the vc-1 speed advantage evaporates, and so does most of the h.264 quality/size advantage. (Not entirely and proportions dependant on other settings, of course.)

[CruNcher]

And yeah, CABAC is useful when you don't have nearly unlimited space. When you do, why bother? I know others will probably argue it, but it seems to be the most important practical differentiator compared to VC-1. Without it, most of the vc-1 speed advantage evaporates, and so does most of the h.264 quality/size advantage. (Not entirely and proportions dependant on other settings, of course.)


Finaly someone who understands me *g*


btw i have something funny here look @ this

http://www.elitebastards.com/hanners/foxconn/8600gts/charts/video-1080p.png

what did they wrong or maybe they didn't do anything wrong they even used VISTA so funny ;)

Also im a believer that Apple Engineers chose the right way with the very balanced AVC settings for their (Encoder) Web Clips, useing such heavy settings as CABAC or DEBLOCKING makes no sense for Crystal Clear HD source (you just higher the complexity of the stream for almost no HVS (detail preservation gain), the only thing you do is creating a more complex stream (decode) then it should be. Also the same situation with the users here that use these funny x264 settings all the time like 16 reference frames and 8 b-frames and ah yeah RDO on the highest level (encoding) in my eyes absolute waste of energy for most sources :P

Hmm i wonder when JOMIGO is gonna release their H.264 Encoder and how balanced it will be on Encoding Speed same for the CoreCodec Encoder, Ati's Encoder is a little to heavy Balanced in the Encding Speed direction but it shows very nicely that it's possible to enhance something here without destryoing the Stream compatibility so im sure some small internal changes inside X264 and boom it would be much better balanced ah yeah and i almost forget XviD AVC how balanced will it be hmm :)

[arfster]

They must have done something wrong, since all other charts show that 8500/8600 produce <5% average cpu on any h264 with dualcores (even 40mbit Bluray).

See here:

http://www.hardspell.com/english/doc/showcont.asp?news_id=385&pageid=483

Even with a 1.6ghz Sempron it's at 15%.

[shon3i]

@CruNcher IMHO Elecard now have very good balance between speed and quality. For two hour movie i need aprox eight hours to encode with mp4 cinema profile. For same quality i neèd almost double time with x264. I aslo can't wait to se new encoders especialy XviD AVC.

[CruNcher]

Problem with InterVideo seems to be that applications do not detect it as H.264 decoder. However, on subtype {8D2D71CB-243F-45E3-B2D8-5FD7967EC09B}, the InterVideo Video Decoder connects to the Elecard Demuxer and decodes H.264, see attachement..

it doesn't work here (tested with a MBAFF sample) i only see a black screen hmm wich Elecard Demultiplexer build my is 1.0.77 (build 60823) ?

@shon3i
i thought so Elecard/Mainconcept improves fast,gonna check this later :)

[Manao]

And yeah, CABAC is useful when you don't have nearly unlimited space. When you do, why bother?Why bother to encode the video at all ? Unlimited space is a myth. Whenever the disk size increases, the data to store increases too.

Anyway, whatever the space you've got, CABAC over CAVLC means 10% more data at the same quality. So when you can decode it, there's no reason not to use it.

[foxyshadis]

I presume cruncher is one of those rare lucky people who feel no compulsion to collect movies until everything fills to the bursting. :D Since most people feel the space crunch, I'm not arguing, totally with you.

The only time I'd consider using CAVLC for main profile is for HD, if profiling showed that the decoder could handle more than 15% higher bitrate than in CABAC (because of a badly optimized decoder or whatever), and then only for temporary recompressions. Otherwise it's never worth the tradeoff to me.

[Sagittaire]

Also im a believer that Apple Engineers chose the right way with the very balanced AVC settings for their (Encoder) Web Clips, useing such heavy settings as CABAC or DEBLOCKING makes no sense for Crystal Clear HD source (you just higher the complexity of the stream for almost no HVS (detail preservation gain), the only thing you do is creating a more complex stream (decode) then it should be. Also the same situation with the users here that use these funny x264 settings all the time like 16 reference frames and 8 b-frames and ah yeah RDO on the highest level (encoding) in my eyes absolute waste of energy for most sources :P


Well it's false I think ...

1) Like say Manao CABAC over CAVLC means 10% more data at the same quality (quality here is bytes to bytes identical)

2) Inloop is perhaps useless for high quality encoding (aka low constant quantizer encoding like q10) but certainely not for medium/high quantizer encoding. Don't forget that HDDVD or BD have Rate Control constraints and can have potentialy very high quantizer variability.

3) umh + trelli 2 + rdo 7 vs hex + trelli 1 + rdo 6 mean more than 5% bitrate save for the same quality (quality here is PSNR). It's not useless to use best possible setting in this case ...

4) Now if you campare slowest RDO + CABAC + inloop vs fast or desactived RDO + CAVLC + desactived inloop then the quality difference will be very high in all case for the same bitrate ...

[CruNcher]

I presume cruncher is one of those rare lucky people who feel no compulsion to collect movies until everything fills to the bursting. :D Since most people feel the space crunch, I'm not arguing, totally with you.

The only time I'd consider using CAVLC for main profile is for HD, if profiling showed that the decoder could handle more than 15% higher bitrate than in CABAC (because of a badly optimized decoder or whatever), and then only for temporary recompressions. Otherwise it's never worth the tradeoff to me.

You gonna lough, i just bought a 500 GB drive some weeks ago (space left 150 GB) ;)

@Manao & Sagittaire
yes i understand your constraints but how does a 10% bitrate save looks like in motion same for the 5% save compared to the much higher encoding/decoding time (you invest for it). If it just means a little more details per frame what is the gain here ? sure if it changes the overal quality so prevents heavy artifiacts (blocking,smearing or preserves the Film Grain) it's nice but else is it usefull ?, in my eyes it's not if the gain is lower as the lose on the other two sides.

[Manao]

Cabac & deblocking certainly doesn't increase the encoding time noticably. As for the decoding time, I don't care to decode at 150fps, what I want is realtime. 30fps is enough for me.

I would however agree than deblocking indeed tends to remove the grain, though the answer there isn't to disable deblocking but to add grain afterwards, imho. And cabac sure won't touch that grain of yours :)

[CruNcher]

It will be very interesting with what ATI comes up with UVD in the preperation for my new Decoder test i found out that Nvidia is enhancing their Motion Adaptive Per Pixel Deinterlacer in new driver revisions starting with 97.92 it's even be able to pass all HQV deinterlacing tests (realtime SD) tdeint nor yadif are able to achive that yet (software), but it also seems as older GFX cards aren't be able to handle that in HD Realtime anymore (now it doesn't suprise anymore why 93.81 is the latest beta driver for Geforce 7 Cards with Purevideo support hehe) my 7600GS (G72) PCI-E can only achive SD, with the new Driver and 1440x1080i i just get 13 fps (VMR9 Windowed) :P with the old Driver wich passes 2 of the 3 diagonal filter angle tests of HQV i get 50 fps without problems :P (yadif is able to pass 2 angles also, tdeint fails)
I think it has todo with the Shader Performance of the (7600GS G72) (overclocking should help here, didn't test that yet) GPU in Realtime (HD) should be possible on the next Generation Chips like the G80 or G84 and for sure also ATI's new Chip will have something equal, we just need a way now to get those frames out of the GPU onto the HDD, im doing this @ the moment by captureing the VMR9 surfface, but it's not optimal you need a very fast PC this way for HD wich is melting the realtime win quiet fast, something like a texture streamer that saves a stream of textures, that you then convert into png but then again you would need monster space ;)

[CruNcher]

CPU: X2 4200+ Toledo TDP (85W)
GFX: 8800 GT 512mb Forceware 180.70 (Nvidia G92)
OS: Win XP SP3
Results: 1080p Progressive (X264 med complexity, HVS balanced)
Power measuring: +-10W

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : avc1
Duration : 2mn 26s
Bit rate mode : Variable
Bit rate : 5 918 Kbps
Maximum bit rate : 7 116 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16/9
Frame rate mode : Variable
Frame rate : 23.968 fps
Minimum frame rate : 11.988 fps
Maximum frame rate : 29.976 fps
Original frame rate : 29.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.119
Stream size : 104 MiB (99%)



Null

CoreAVC = User: 5s, kernel: 0s, total: 5s, real: 31s, fps: 702.2, dfps: 110.9, Memory: 50
DivX = User: 6s, kernel: 0s, total: 6s, real: 37s, fps: 505.4, dfps: 93.3, Memory: 50
ffdshow-mt = User: 7s, kernel: 0s, total: 7s, real: 55s, fps: 454.5, dfps: 63.0, Memory: 52
Arcsoft = User: 0s, kernel: 0s, total: 0s, real: 58s, fps: 9800.3, dfps: 60.0, Memory: 161
Cyberlink = User: 13s, kernel: 0s, total: 13s, real: 58s, fps: 268.3, dfps: 60.2, Memory: 115
MPC VideoDecoder = No measuring possible (doesn't start rendering) also not if DXVA is disabled

VMR7 (low to none kernel activity)

CoreAVC = User: 7s, kernel: 0s, total: 8s, real: 58s, fps: 436.8, dfps: 59.9, Memory: 56
Arcsoft = User: 1s, kernel: 0s, total: 1s, real: 58s, fps: 2398.0, dfps: 60.0, Memory: 157
Cyberlink = User: 11s, kernel: 1s, total: 12s, real: 58s, fps: 281.8, dfps: 60.7, Memory: 250
DivX = User: 8s, kernel: 1s, total: 9s, real: 59s, fps: 366.5, dfps: 58.8, Memory: 56
ffdshow-mt = User: 8s, kernel: 0s, total: 9s, real: 64s, fps: 378.2, dfps: 54.8, Memory: 56
MPC VideoDecoder = User: 8s, kernel: 1s, total: 9s, real: 79s, fps: 359.5, dfps: 44.2, Memory: 40

Overlay (GPU) (0-1.4x% CPU,low to none kernel activity)

MPC VideoDecoder = User: 0s, kernel: 0s, total: 1s, real: 61s, fps: 3087.8, dfps: 57.4, Memory: 31
Arcsoft = User: 0s, kernel: 0s, total: 0s, real: 72s, fps: 22540.8, dfps: 48.5, Memory: 60
Cyberlink = No measuring possible falls back to CPU

VMR7 (GPU) (0-1.4x% CPU,low to none kernel activity)

MPC VideoDecoder = User: 0s, kernel: 1s, total: 2s, real: 61s, fps: 1720.7, dfps: 57.3, Memory: 82
Arcsoft = User: 0s, kernel: 0s, total: 0s, real: 72s, fps: 17339.1, dfps: 48.3, Memory: 109
Cyberlink = No measuring possible falls back to CPU

VMR9 (GPU) (0-2.x% CPU, kernel activity peaking)

MPC VideoDecoder = User: 0s, kernel: 1s, total: 2s, real: 61s, fps: 1720.7, dfps: 57.3, Memory: 85 (heavy kernel peaking up to 12%)
Arcsoft = User: 0s, kernel: 0s, total: 0s, real: 78s, fps: 8348.4, dfps: 45.0, Memory: 94
Cyberlink = No measuring possible falls back to CPU


GPU = 100W (CPU idle 1.1 GHz, 1.1v)
CPU = 175W (GPU Idle + CPU Load 2.5 GHz, 1.35v)

Hmm Arcsoft and Cyberlink behave different (GPU) benchmarking with timecodec (Cyberlink uses 100% CPU) it seems Cyberlink falls back to CPU rendering running within timecodec

PS: Arcsofts Decoder renders definitely more files successful in GPU Mode (outside timecodec) then Cyberlink does using VMR 7 (stays black a lot of times with Cyberlinks Decoder)
MPC - Video Decoder (DXVA) has especially problems with Broadcast Related Bitstreams (for Progressive it seems the most efficient) except under VMR9 here MPC Video Decoder shows up some really bad performance in Kernel times (Win XP)

CoreAVC vs GPU is a easy answer (for playback) especially for people with older CPUs and already installed next Gen GPU it makes no sense to use CoreAVC as the Power Saving can be very big in this situation up to 75W (depends on CPU efficiency but even with a very efficient CPU it makes no difference if you have GPU capabilities use them)

[ajp_anton]

Can you really compare CoreAVC 111fps 175W with DXVA 57fps 100W? Or did you measure power usage while watching it in real-time?

[Betsy25]

Sorry fo this noob question, but those anyone know where I could get that CoreAVC decoder please ? :)

[CruNcher]

Can you really compare CoreAVC 111fps 175W with DXVA 57fps 100W? Or did you measure power usage while watching it in real-time?

You are right sorry i mixed up Results with the (Transcoding) workload


Realtime Playback (+ Audio ffdshow Audio (HE-AAC))

CoreAVC = 30W
MPC Video Decoder DXVA = 3W


This is important for average Joe :) (and dont forget with more complex Blu-Ray the Power Usage (Video) stays the same where for CoreAVC it gets higher)
the interesting question is now how would it look with a Core2, Core7, Phenom II it's over 10x the Power Efficiency on the VP2 i doubt CPU's are there yet especially CABAC seems to take the most cycles here on the CPU (compared to the working DSP logic inside the G92,G200) :) this logic inside the GPU im also pretty sure Powers Nvidias Tegra Platform http://www.youtube.com/watch?v=U7R90A7ZqLU, http://www.youtube.com/watch?v=XXYshhuJzh4 :)

For a Transcoding workflow it's very interesting as this left Energy can be put into the Encoding see DgAVCDec NV :) (results soon)

same also applies i guess 1to1 for ATI (R&D wise they for sure also use similar DSP logic as Nvidia (just with full VC-1 support) DSPs will be a integral Part of the next mobile PC architectures especially Netbooks,Cellphones,Mobile consoles are gonna use them heavily for Multimedia and already do :)

[J_Darnley]

Sorry fo this noob question, but those anyone know where I could get that CoreAVC decoder please ? :)
:search:
The first hit from Google takes you to the right place:
http://www.coreavc.com/

[Betsy25]

:search:
The first hit from Google takes you to the right place:
http://www.coreavc.com/

DOH!
Thanks Darnley ! :)

[CruNcher]

Btw in reallity i can say that if you really use your PC only for Video watching even a HTPC you really throw away a lot of energy for nothing better get a Cheap DSP based player it's gonna save you a lot of money, and you help our enviroment :)

[KoD]

This kind of statistics are not sufficient without another bit of info:

a. amount of h264 files that can be played with a software decoder such as CoreAVC = almost all
b. amount of h264 files that can be played with a GPU hardware decoder = when you're lucky

[DrNein]

In practice, only bad re-encodes are likely to be problematic with GPU decoding. Thankfully, CyberLink and ffmpeg are capable of both GPU and CPU decoding. Also, modern GPU image quality is unsurpassed.

[Sagekilla]

For most people who convert their own material, they generally (if they're targeting DXVA ;)) won't use settings that would break DXVA so they won't have much to worry about. `Also, for refs, most people don't use absurd numbers because high refs are usually too slow, so another thing most people won't need to worry about.

[Hellworm]

Realtime Playback (+ Audio ffdshow Audio (HE-AAC))

CoreAVC = 30W
MPC Video Decoder DXVA = 3W



The interesting part is wether this comes from gpu being very efficient (=taking no power to decode) or from being very inefficient (= taking always much power even when idling). You don't mind ripping out the gpu and posting the result on idle desktop and with coreavc?
Though if you need a gpu anyway (gaming, CAD, ...) this is of course irrelevant.

[CruNcher]

The interesting part is wether this comes from gpu being very efficient (=taking no power to decode) or from being very inefficient (= taking always much power even when idling). You don't mind ripping out the gpu and posting the result on idle desktop and with coreavc?
Though if you need a gpu anyway (gaming, CAD, ...) this is of course irrelevant.

That's why the GPU if inside should always be used (especially older models) do OS GUI Animation stuff with it so you don't throw away that idle Power for nothing (though i didn't tried that yet for example how Aero consumes the Power, if it runs on the GPU does it consume idle power or needs additional 3D (Shader) Power ? which i measured for my system can be as much as 250W (Far Cry 2) under full load (CPU (all related devices) + GPU - Monitor), and yes for now i just belive the 3W consumption here are coming from only the Video Decoding Logic (-Audio CPU).
Though you right it's hard to say if those estimated 50-60W idle aren't already including the activation of that logic, but looking @ Tegra i doubt it :) and yes i gonna also measure the PC without any GPU being idle on the Desktop @ 1.1v, i didn't yet as im still doing work on it but i swear i will :), i also have a old PCI GFX (S3 Trio64V+) here that i can measure against with CoreAVC if necessary, though i guess only SD im pretty sure i wont get a 720p surface with it (those where DCI times not DirectX) and also RAM is to limited (for the NULL measurement it would work) :)

GFX: Max TDP = 110W (idle = 60W ?)
CPU: Max TDP = 89W (idle = 40W ?)