Intel QuickSync Decoder - HW accelerated FFDShow decoder with video processing

[nevcairiel]

You'll never get it "right". Technology evolves, stagnation is its death. You cannot develop a system that is the ultimate solution to everything.

Also, if PowerPC was so great, why is it dead? :p

But some people can find fault and reason for suspicion in everything. Its the evil companies, they develop incomplete instruction sets so they can sell you more CPUs! </tinfoil hat> You guys are hilarious. :)

[NikosD]

Please, don't be so naive!

They are not evil, just doing their job.

Do yours and I'll do mine.

It's that simple ;)

[egur]

You'll never get it "right". Technology evolves, stagnation is its death. You cannot develop a system that is the ultimate solution to everything.

Also, if PowerPC was so great, why is it dead? :p

But some people can find fault and reason for suspicion in everything. Its the evil companies, they develop incomplete instruction sets so they can sell you more CPUs! </tinfoil hat> You guys are hilarious. :)

Right!
Technology is ever changing. Also SSE was a major improvement on the 387 ISA when doing scalar floating point instructions.
Generally speaking new ISA is not always for everyone to immediately use (or even understand its need).
Some of you are forgetting that in order to cram lots of features in HW, you need die area and tons of design and validation that can put a CPU generation at high risk. New process technology and evolutionary but very advanced development of the CPU have sent PowerPC and it's RISC friends to the museum.
Back in the late 90s when I was a student at IBM research, I had the luxury of having an RS6000 IBM workstation. It cost 18K$. The same year, IT bought Intel based (dual Xeon) servers that cost 2K and where much stronger. So IBM dropped it's own RISC systems, they couldn't afford them.

[NikosD]

SSEx instructions are worst designed even than x86 instructions.
This is a major achievement of Intel!

IBM is by far No 1 in CPU design and performance and Power7 processors eat Xeons for breakfast :D

Thank God that AMD back at the good old days, insisted on x64 systems for the desktop, because Intel would be still saying that 64bit systems are useless for desktop!

No offense, I like Intel but facts are facts.

[Atak_Snajpera]

i'm sorry to say but 64 bit for most apps is useless. even x264 gets only about 5 % speed up at default settings. however the biggest advantage will always be larger address space.

[rsd78]

Eric (or anyone else),

Did you ever happen to test how/if this worked within Media Center with the Media Control plugin? I imagine it should, but would prefer if someone could confirm :) Thanks!

[CharlieCL]

The key point is:
Build it right and complete from the beginning like Apple, IBM and Motorola did with AltiVec and the PowerPC line.


Yes. That is exact what I mean.

The huge success of X86-386 32-bit instruction set is a proof
to design right and complete from beginning. Unfortunately Intel worked in the wrong way in SIMD instruction set. I have observed the evolution of SSEx instruction set. Intel walked so far who even designed a set called SSE4.1! I have expected AVX to be a complete set but it is disappoint again.

There are few business benefits to design an incomplete instruction set. Developers will not use it; processors are not compatible.

[CruNcher]

Also AMD has introduced an OpenCL extension for a zero copy mechanism on Windows systems and as I read, presumably Intel will follow once they have OpenCL and DirectCompute capable hardware - which means IvyBridge because SandyBridge has no support of OpenCL and DirectCompute.

for what is the opencl sdk then ??

i'm sorry to say but 64 bit for most apps is useless. even x264 gets only about 5 % speed up at default settings. however the biggest advantage will always be larger address space.

and security alike

[NikosD]

Intel's OpenCL SDK is for Intel CPU only, not Intel's GPU.
After Ivy, it will be for GPU too.

[CruNcher]

Right!
Technology is ever changing. Also SSE was a major improvement on the 387 ISA when doing scalar floating point instructions.
Generally speaking new ISA is not always for everyone to immediately use (or even understand its need).
Some of you are forgetting that in order to cram lots of features in HW, you need die area and tons of design and validation that can put a CPU generation at high risk. New process technology and evolutionary but very advanced development of the CPU have sent PowerPC and it's RISC friends to the museum.
Back in the late 90s when I was a student at IBM research, I had the luxury of having an RS6000 IBM workstation. It cost 18K$. The same year, IT bought Intel based (dual Xeon) servers that cost 2K and where much stronger. So IBM dropped it's own RISC systems, they couldn't afford them.

Exactly and in this fundamental Material and Production Research Intel is always involved and has a lot to say see Tri Gates ;)

And imho Intel is doing good with their Drivers compared to the old Generation its a massive improvement sure they are behind Nvidia and AMD yet but they literally just started and people don't understand but there will never be a Gaming Card from Intel they just have to close the Gap @ low power Desktop and mobile and they are getting closer (most important from where they coming from is that you can see the improvements) :) sure Nvidia and Amd doesn't sleep also, btw Nvidia since a long time has 4K ready it was first though demonstrated on their Tegra lineup it would be ease for them to implement it on the Desktop if they think the time is right the same as VC-1 VLD support back then was a money question and they carefully evaluated would it make sense to have it on a Discrete Gamer Card lineup and their decision in the beginning was no and that was business wise a right decision to implement it only on the low power htpc cards and mobile level. Ivy Bridge without doubt will playback 4K without problems as Sandy Bridge already performs well not well enough but with the improvements Intel announced it would be flawless :)


Progressive 8 bit Playback efficiency 1080p 60 fps (4 girl H.264)

Arcsoft DXVA = ~2% CPU; GPU = ~20%
Cyberlink DXVA = ~2% CPU; GPU = ~20%
CoreAVC DXVA = ~4% CPU; GPU = ~20%
Intel Quicksync DXVA2 = ~12% CPU; GPU = ~23%
Nev Generic DXVA2 = ~17% CPU; GPU = ~24%
Nev Lav Video Libav = ~25% CPU; GPU = ~25%


All DXVA2 and Software results (Lav Video). Results include Parser (Lav Splitter MKV)/Audio(Lav Audio)/Renderer (EVR Custom Experimental) Overhead

[NikosD]

I did some tests today:

1) 4K playback

4K is not possible in HW due to driver's and MSDK restrictions.

The software fallback works OK with PotPlayer using both pure DXVA internal codec and QuickSync "internal" codec.
Also the fallback works OK with CoreAVC DXVA, LAV video and QS decoder, but MSDK uses slowest software decoding than ALL the others (Pot internal, LAV, CoreAVC)

So, if you play out of Intel's HW DXVA video files, AVOID the QS decoder software MSDK routines, they are not optimized as FFMpeg, CoreAVC, LAV.

MS DS/MFT doesn't provide software fallback and crashes DXVA checker.

2) CoreAVC although it says it uses MSDK, it doesn't. It's pure DXVA and very fast implementation.

3) QS decoder is faster than LAV video QS and MS DS/ CoreAVC are both a lot faster than both MSDK solutions in 60fps clips.
But MS MFT is the fastest of all, only usable in WMP12 though.

4) For normal playback PotPlayer's internal DXVA codecs work like a charm for both MPEG-2/ H.264 progressive or interlaced.
Minimum power consumtion - at least 50% down from MSDK solutions (LAV QS, QS decoder) and easy playback of all up to 1080p video files.

You only need QS decoder for VC-1, because PotPlayer is not able to utilise VC1_VLD mode, only VC1_IDCT.

[CruNcher]

1) 4K playback

4K is not possible in HW due to driver's and MSDK restrictions.

It works though it isnt stable (FPS) it fluctuates heavily most probably HW Decoder isnt capable on heavy bitrate spikes to cope with it, but it works Lav Video though is restricted and fallsback to Libav see my report here http://forum.doom9.org/showpost.php?p=1549189&postcount=398 about the 4K and QFHD Quicksync situation. After this report Nev decided to restrict Lav Video resolution wise for Quicksync though from a efficiency point of View that might be not optimal as resolution alone isn't a factor for the Decoder as Youtubes 4K complexity works more or less fine. Intel most probably made the same decision in the SDK Decoder. Everything indicates though that Ivy Bridge should support 4K flawless with IMSDK as the more power needed should have been reached (and compensated) with it from a Design Point of View.

[nevcairiel]

Its not using the hardware for 4K decoding, its falling back to Intels software decoder, which is very slow.

[CruNcher]

Oh ok so it is indeed keept secret, and you could guess its most probably capable of it but they just gonna set the bit necessary to activate it in the driver with Ivy Bridge even SB would be capable of it they wont enable it ever then :P

[nevcairiel]

That's all speculation. Fixed-function hardware could easily be designed in such a way that it has a maximum number of supported macro blocks.

In any case, its not like there is any real world 4K material besides some demo files, not to mention 4K displays.

[NikosD]

Oh ok so it is indeed keept secret, and you could guess its most probably capable of it but they just gonna set the bit necessary to activate it in the driver with Ivy Bridge even SB would be capable of it they wont enable it ever then :P

You sound a little ironic, but even if you know it or even if you don't, the post you wrote is absolutely true in my opinion.

The only way to check it out would be if Intel released next drivers for Sandy with 4K capability, in order to try 4K by ourselves.

Is it so difficult ?

[ajp_anton]

Is there any possibility to get this to decode lossless h264?

[nevcairiel]

Is there any possibility to get this to decode lossless h264?

No, the hardware only works up to High profile.

[Mixer73]

The only way to check it out would be if Intel released next drivers for Sandy with 4K capability, in order to try 4K by ourselves. Is it so difficult ?

You tell me, is it so difficult to think that maybe this platform was never designed for anything like 4k decoding? Who is going to agree to spend the engineering time and money on something that has no practical use at this time and has no sales benefit to be derived from it? I have been involved in developing video products in multi-national companies for more than 15 years and let me tell you nobody does anything unless there's a solid business case for it.

Eric has written this software for us to use and enjoy, I think the questions addressed to him need to stay directly relevant to the product at hand, he is not an Intel PR contact.

You can send all your other feedback to:
http://www.intel.com/support/feedback.htm

[NikosD]

I really can't follow you.

Have you heard of a Video processor from AMD called UVD3 ?
It can officially support 4K.

Have you heard of a Video processor from Nvidia called VP5 ?
It can officially support 4K.

Have you heard of a CPU/GPU/VPU processor from Intel called IvyBridge ?
It can officially support 4K.

Do you still believe there is no need for 4K ?

UVD3 supporting 4K was released before SandyBridge.
Even UVD2.2 "unofficially" supports 4K.

Are you following me ?

[hajj_3]

what evidence do you have that ivy bridge will support 4k?

[nevcairiel]

what evidence do you have that ivy bridge will support 4k?

Intel announced that at the IDF 2011 (http://www.anandtech.com/show/4838/ivy-bridge-gpu-to-support-resolutions-of-up-to-4096x4096)
More importantly, they will support 4K output, which is still somewhat of a problem with every setup.

Anyhow, the main point is that SNB does not support 4K, and i'm 99% certain that Intel would not simply disable that in the driver, because that makes no sense, no way how you look at it.

[hajj_3]

I wonder if we'll get 23.976fps in ivy bridge, its a shame we still don't have it even though other gpu's have had it for years.

[nevcairiel]

You get 23.973 or so with SNB, which is already close enough for ReClock usage, and Intel already said that they improved the clock in the 7 series chipset for IVB.
Its a common problem among all GPUs, because the clocks used in PCs are usually based on 10-based clocking, which is not really well suited to build a accurate 23.976 clock.

[hajj_3]

While 4K video support is impressive, Intel hasn’t completely fixed the 24fps issue that some people noticed in Sandy Bridge. By not quite getting the frame rate of video playback for this format of video, movies can appear to stutter.

When asked about this, Dr Hong Jiang, senior principal engineer and chief media architect for Intel, said that ‘we’ve improved the clock for Ivy Bridge, so that issue is much reduced. Compared to Sandy Bridge, it’s a major step forward.’ Tom Piazza, Intel senior fellow, chipped in, adding that ‘it’s significantly reduced – you’d have to look real hard to catch it.’

Looks like it still won't support 23.976fps :(

Source: http://www.bit-tech.net/hardware/cpus/2011/10/10/all-about-ivy-bridge/6

[nevcairiel]

No current GPU gets it 100% perfectly right, its impossible because of the clocking used in PCs, like i explained above.

Right now its 23.973 with Intel, the target is 24/1.001 (= 23.976024...), anything in the range of 23.9759-23.9762 is close enough to be unnoticeable.
"much reduced" and "major step forward" make it sound good, so just wait with judgement until you see it. I for one didn't expect them to get it 100% spot on, because thats not required, and incredibly hard. Just get it as close as possible, 23.9760 would be nice, but 23.9762 works too.

Getting it to 23.975-23.977 is as close as all the other GPUs are, hitting the target perfectly is just that hard.
Just use ReClock, it can fix the issue even when you run it at 24.000. :p

[egur]

Version 0.23 beta is out with the following changes:
* Added multithreaded decoding.
* Optimized multithreaded code.
* Fixed VC1 decoder seeking issues.
* Minor bug fixes.
* FFDShow rev4251

Download from SourceForge home page (http://sourceforge.net/projects/qsdecoder/)

[CruNcher]

Sandy Bridge's GPU supports only resolutions of up to 2560x1600, so this is a huge jump since 4Kx4K has over four times more pixels.

But there is only talked about Resolution of the GPU not exactly resolution of the Decoder, theoretically this would mean you could allready feed the SB Decoder upto 2560x1600 and the Hardware should handle it though what does the IMSDK say about decodable resolution limit ?

@Eric

hehe just in time :)


CrowdRun_1080p50.x264.CRF23.mkv

ffdshow Quicksync = 178 fps
Lav Video Quicksync = 149 fps

4.Girls.YoonYoon-1080p60fpsRef5-21Mbps.mkv

ffdshow Quicksync = 290 fps
Lav Video Quicksync = 226 fps


cd.ts

ffdshow Quicksync = 278 fps
Lav Video Quicksync = 226 fps

300-VC1.m2ts

ffdshow Quicksync = 250 fps
Lav Video Quicksync = 220 fps

[nevcairiel]

To be honest, multi-threaded decoding is just asking for trouble for no advantages.

The GPU is internally threaded, and only one thread can access the device at any given time - it'll block any other threads. You only need to feed it enough data and enough output surfaces, and it'll happily decode away.
I actually tried that just recently for my DXVA2 decoder, and it didn't make a bit of difference, but was so complicated that i was really happy that i could remove it again.

Not everything benefits from multithreading.
Did you actually see any difference?

I usually prefer the simpler and less error prone route if there are no crucial factors to consider - and even if its 5% faster with your new code, heck, the thing is fast enough as it is. Keep it simple. ;)

PS:
That LAV Video is slower is probably just because i have multi-threaded frame copying off. I only optimize for playback, i don't really care for tests. :p

[egur]

But there is only talked about Resolution of the GPU not exactly resolution of the Decoder, theoretically this would mean you could allready feed the SB Decoder upto 2560x1600 and the Hardware should handle it though what does the IMSDK say about decodable resolution limit ?

@Eric

hehe just in time :)


CrowdRun_1080p50.x264.CRF23.mkv

ffdshow Quicksync = 178 fps
Lav Video Quicksync = 149 fps

Nev isn't using the new MT features yet, he's careful :D

The MSDK limits HW decode resolution to 1080p. If either width or height are more than 1080p it falls back to SW.
If the bitrate is low enough (e.g. HW decoder isn't the bottleneck) ffdshow QS can output ~800 1080p frames (on my i7-2600/1333Mhx DDR3). That's ~1600 mega pixel per second.
So, in theory, there's enough bandwidth to output 4K@60 which translates to 480 mega pixel per second.

I didn't test this on a IvyBridge yet, too much to do these days... Anyway, I can't report performance numbers until launch.

[egur]

To be honest, multi-threaded decoding is just asking for trouble for no advantages.

The GPU is internally threaded, and only one thread can access the device at any given time - it'll block any other threads. You only need to feed it enough data and enough output surfaces, and it'll happily decode away.
I actually tried that just recently for my DXVA2 decoder, and it didn't make a bit of difference, but was so complicated that i was really happy that i could remove it again.

Not everything benefits from multithreading.
Did you actually see any difference?

I usually prefer the simler and less error prone route if there are no crucial factors to consider - and even if its 5% faster with your new code, heck, the thing is fast enough as it is. Keep it simple. ;)

PS:
That LAV Video is slower is probably just because i have multi-threaded frame copying off. I only optimize for playback, i don't really care for tests. :p

Yes, I saw a difference, not a big one.
Making the frame copy work in parallel to decoding has a very clear impact.
The decoding itself, if done on another thread gives the decode worker thread more time to run. Without this, the decode thread time is split between the splitter, decoder, post processing and the renderer. Now the HW decoder can work more achieving higher fps.
For normal playback, if the HW decoder is fast enough, then there's no need for it as it spends a little more power.

The MT frame copy function which is helpful when bitrate is low and a lot of frame copying is going on. This is done to reduce the wall time spent within my decoder's code on the decode thread (the thread that drives the decoder and the renderer).

If i wasn't clear, the HW decoder works exactly the same as before, it's just handled from more than one thread. Decode calls are sequential in nature. I don't thing the HW decoder will like me feeding him bitstreams before he's ready with the previous bitstream.

[nevcairiel]

But the HW decoder doesn't block the calling thread. You feed it data, it accepts it, and works in the background. At least thats how DXVA2 works, i doubt Intel is much different, its just based on it.
What will block is the accessing of the surface. If you try to LockRect the surface while the decoder is still writing on it, it'll block until its done - which is why you should queue a number of surfaces for it to finish writing on before you start copying them (for nvidia/ati 2 seems enough, for intel 8 seems to be the sweet spot). I don't know if thats done internally in the MSDK or you have control over it - i don't know the MSDK API that well. I could imagine they do it internally.

Anyhow, even if you have a threaded approach, it'll probably have a small queue of stuff to access, which will eventually be full, and then you still wait on that, don't you? :)

Anyway, i doubt i'll be enabling that, excessive threading is never a good idea. ;)

[CruNcher]

Yeah i wonder if i would encode with ffdshow quicksync and compare that to lav video quicksync what actually would be better @ playback there is no real difference but @ encoding it could become visible though the decoder (GPU/CPU) and encoders (CPU) multithread code fighting with each other i wonder it that can cause problems same if pushing that back to the Quicksync Encoder (GPU/CPU) ;) ?

Nev isn't using the new MT features yet, he's careful :D

The MSDK limits HW decode resolution to 1080p. If either width or height are more than 1080p it falls back to SW.
If the bitrate is low enough (e.g. HW decoder isn't the bottleneck) ffdshow QS can output ~800 1080p frames (on my i7-2600/1333Mhx DDR3). That's ~1600 mega pixel per second.
So, in theory, there's enough bandwidth to output 4K@60 which translates to 480 mega pixel per second.

I didn't test this on a IvyBridge yet, too much to do these days... Anyway, I can't report performance numbers until launch.

If that is really the case then you should better prefer Libav for this fallback like Nev does it in Lav Video as the Intel Software Decoder looks less efficient (just fast enough to handle it without any rendering going on 4 cores I5-2400)


HD.Club-4K-Chimei-inn-50mbps (QFHD @ 29.970 fps)

Lav Video Quicksync = 58 fps (Libav SW fallback)
DivX = 55 fps
CoreAVC = 54 fps
ffdshow Quicksync (Libav) = 54 fps
Arcsoft = 49 fps
ffdshow Quicksync = 31 fps (Intel SW fallback)

[clsid]

Eric,
I want to add some detection to the installer to only install the QS plugin on compatible systems.
Detecting Intel CPU is easy. But I was thinking to additionally check the CPU model number. For example, my i7 2600K is a model 42. Do you perhaps have access to a list of model numbers for all compatible Sandy (and upcoming Ivy) Bridge CPUs?

Edit: from what I could find all SB have model 42, except for the 3xxx ones, which are model 45 and are lacking integrated graphics.

[NikosD]

The MSDK limits HW decode resolution to 1080p. If either width or height are more than 1080p it falls back to SW.


So, in theory, there's enough bandwidth to output 4K@60 which translates to 480 mega pixel per second.


Any particular reason for Intel, that you are allowed to share with us, not enabling 4K in SNB ?

And more important...
From all the inside information you can get and share, is Intel going to support ever 4K in SNB ? Even after Ivy's launch ?
Because drivers & IMSDK for Ivy will enable 4K.

Maybe that time - with new Ivy drivers/ IMSDK - will be the suitable moment for Intel to extend 4K support to SNB.

[CruNcher]

Wow i found something interesting with WVC1 when in Potplayer and selecting Arcosfts decoder directly it will use YUY2 as output for WVC1 and so average out @ 20% cpu utilization (no DXVA @ all) though if you select Cyberlinks Decoder it wont use it but it will call the VC-1 Adapter filter and then Arcsofts Decoder and suddenly it is full VLD and CPU usage is around @ 2% (same overhead as for H.264 bitstreams)
Yep with the VC1 Adapter filter you can get the VLD Decoding for every format .wmv .ts .m2ts .evo from Arcsofts new Decoder http://forum.doom9.org/showpost.php?p=1551696&postcount=2121

[egur]

Yeah i wonder if i would encode with ffdshow quicksync and compare that to lav video quicksync what actually would be better @ playback there is no real difference but @ encoding it could become visible though the decoder (GPU/CPU) and encoders (CPU) multithread code fighting with each other i wonder it that can cause problems same if pushing that back to the Quicksync Encoder (GPU/CPU) ;) ?


If that is really the case then you should better prefer Libav for this fallback like Nev does it in Lav Video as the Intel Software Decoder looks less efficient (just fast enough to handle it without any rendering going on 4 cores I5-2400)
The various optimizations I do are switchable (can be disabled) and the host DS filter can choose to use them or not. so a feature is not welcome for any reason, the owning DS filter can choose to kill it.
I do not plan to integrate libav or any other SW decoder into my code for deployment efficiency. My decoder is not a standalone product it will always be hosted under a DS filter or part of a player. The host filter/app should take care of SW fallback. Writing a full blown DS decoder filter is out of my scope and completely unnecessary, LAV and FFDShow are both doing a great job.

Eric,
I want to add some detection to the installer to only install the QS plugin on compatible systems.
Detecting Intel CPU is easy. But I was thinking to additionally check the CPU model number. For example, my i7 2600K is a model 42. Do you perhaps have access to a list of model numbers for all compatible Sandy (and upcoming Ivy) Bridge CPUs?
I don't think looking at the model numbers is the right way. You can instantiate the decoder (see commented out code in function TvideoCodecQuickSync::check). I disabled this check from within ffdshow because it too slow for playback (a few hundred ms), but for an installer it's OK.

Any particular reason for Intel, that you are allowed to share with us, not enabling 4K in SNB ?

And more important...
From all the inside information you can get and share, is Intel going to support ever 4K in SNB ? Even after Ivy's launch ?
Because drivers & IMSDK for Ivy will enable 4K.

Maybe that time - with new Ivy drivers/ IMSDK - will be the suitable moment for Intel to extend 4K support to SNB.

Look, I'm not an official Intel PR person (with respect to media). Any confidential information I give is potentially violating my contract.
I know you and are others are curious about future features whether in HW or SW but I can't answer them.
So you'll just have to wait for IvyBridge launch and see for your self.
I will (try) to support new features as soon as they are available in public drivers.
BTW I don't need to support 4K explicitly, I don't look at the image size, the Media SDK will tell me if it can decode the stream in HW or SW.

[nevcairiel]

Any particular reason for Intel, that you are allowed to share with us, not enabling 4K in SNB ?


You still seem to be convinced that its just a software limit, which is nonsense. There is no practical reason to limit it in software if the hardware is capable.

Just because in theory it has enough speed to do it doesn't mean the fixed function hardware is actually capable of 4K decoding. Such hardware is drastically different to how a software decoder works, and it cannot just scale for higher resolutions.
I doubt SNB will ever support more then it supports now, because they cannot change the hardware!

[NikosD]

Eric,

I'm not particularly interested in future releases of HW or SW.
I like technology and I like the things to move on and change, but I care more for backward support, of "older" products.

That's why I insist on supporting 4K in "previous" generation QS HW - I mean SandyBridge as previous generation.

Of course I wouldn't "push" you to violate any contract.

It is publishy known and available information by Intel that IvyBridge will support multiple 4K streams simultaneously and 4K x 4K resolution.

My main concern and will is SandyBridge implementation and 4K support in SandyBridge.

[NikosD]

You still seem to be convinced that its just a software limit, which is nonsense. There is no practical reason to limit it in software if the hardware is capable.


Grow up!

[nevcairiel]

Ahahah, he runs out of arguments and resorts to insulting, classic internet troll. :)

[hajj_3]

there is reason why not to add support for 4k to sandy bridge - to get people to upgrade to ivy bridge! Look at nvidia/ati, they constantly don't add support for things but have the hardware capability to. They didn't add HD audio support for ages even though their older cards could technically do it. Companies want you to buy their new products to get new features.

It would be very nice if 4k support was added in a driver update for sandy bridge but i think its pretty unlikely. I've got a 1st gen core i5 so it won't help me anyway.

[NikosD]

My card (6)750 is a Frankenstein card.
It's a 5750 with 6750 BIOS.

That change made my (6)750 the fastest UVDx of the world! because it allows me to put the card during DXVA playback at maximum 3D clocks.

If you change manually your clocks in BIOS to either 5750 or 6750, you can't go to the performance mode I go in with my (6)750.

Do you want any other proof ?

@Nevcariel
Grow up, fast!

[wanezhiling]

http://we.pcinlife.com/data/attachment/forum/201201/15/181753bh40bfb664of44cb.gif

[egur]

Let's have a little poll.
What should be the next big feature?
* HW Video processing: deinterlacing, film detection (3:2, 2:2 pulldowns, etc), noise reduction, sharpness, scaling, etc.
* Output native DXVA surfaces (hybrid setups will not be supported)
* Other - please specify.

[nevcairiel]

Deinterlacing would be great, i don't care for noise reduction or other of these so called "image enhancements". :p

[wanezhiling]

deinterlacing, enough.;)

[hajj_3]

deinterlacing

[STaRGaZeR]

Let's have a little poll.
What should be the next big feature?
* HW Video processing: deinterlacing, film detection (3:2, 2:2 pulldowns, etc), noise reduction, sharpness, scaling, etc.
* Output native DXVA surfaces (hybrid setups will not be supported)
* Other - please specify.

Video processing, all the HW can offer ;) :D

[CruNcher]

* Output native DXVA surfaces (hybrid setups will not be supported) + Deinterlacing + IVTC, though i guess i would say Deinterlacing is more important the current one seems a total mess compared to lav videos (though without being fully auto, manualy switching between film/video is also not ideal). Or do you mean with Deinterlacing actually implementing the VP directly not the quality of the ffdshow detection itself ? though i guess no matter what you will have to improve the (auto) detection first anyways (unless you can implement it the same way it's being utilized from the driver in EVR, fully adaptive). Though under normal EVR it seems to function anyways no matter what it detects Intels Adaptive Deinterlacer and IVTC seems to handle it, but indeed who uses normal EVR these days anymore ? (except when hes bound to it WMC, WMP) :)

So yeah Intels IVTC and Deinterlacing Magic on every renderer sounds like the way to go, though it already pressures the GPU from the renderer side a native copy back version most probably will be even more pressure on both sides CPU/GPU but if it works efficiently and on every renderer it could be still more efficient then Yadifs (CPU) pressure.

Thoug i guess no one yet compared Intels Deinterlacing algorithm Quality vs Yadif in terms of Quality Yadif @ least is comparable to where Nvidia currently is with GPU Deinterlacing (though we are @ the edge to the next GPU generation so the next GPU Deinterlacing improvements should arrive soon, i doubt though Ivy Bridge will have improved much on this part as it seems efficient enough all ready for General Purpose use, but who knows if Intel Engineers where fully happy with it and maybe want to show they can reach comparable QTGMC http://forum.doom9.org/showthread.php?t=156028 quality some day in Realtime which would practicaly also mean having some Scaling comparable to NNEDI3 in pure Hardware, GPU or both realized ;) ).