Intel QuickSync Decoder - HW accelerated FFDShow decoder with video processing

[egur]

Updated June 22nd 2013
Hi,
My name is Eric Gur and I've taken upon myself a side project at my Intel position to make the Intel SandyBridge (or newer) hardware accelerated video decoding technology freely accessible to everyone.
The project name is Intel QuickSync Decoder.

To do so, I decided to embed the Intel QuickSync technology introduced in SandyBridge into the widely popular FFDShow video decoder filter.
Nowadays, the Intel QuickSync Decoder is officially integrated in FFDShow, LAV Video Decoder and PotPlayer.

Main features
* HW decode using Intel's high performance QuickSync engine.
* Decodes H264, MPEG2, VC-1, WMV9. DVD playback not supported.
* HW deinterlacing -auto or forced, with half or full (50/60p) output rate
* HW denoise and detail filters
* Soft 3:2 pulldown on marked streams.
* Support variable frame rate streams.
* Support headless iGPU (Intel GPU disconnected from display) on Windows 8 and newer.

If your system meets the requirements, I'd appreciate stability feedback with assorted quality and sources of video content.
To report a bug report or feature request, please post in this thread.

If something is broken, please provide me with a detailed report including (after reading the known issues section below) :
1. Hardware (CPU, GPUs)
2. Software (OS, driver version, player, splitter, etc.)
3. Access to the offending content. Share via your favorite file share sites. Limit content to <100MB.

Requirements:
1. SandyBridge (2nd Generation Core i3/i5/i7/celeron/pentium) or newer. Older platforms will not work and no plans to support them.
2. Latest Intel graphic drivers. Intel GPU must either be the primary GPU, extended display or use Lucid Virtu.
3. Windows 7 (32/64) or newer OS. Should work in Vista but I can't test this.

Known Issues:
* Jumpy playback or heavy corruption on many clips are the result of drivers obtained from Windows Update. Download drivers from your OEM website or directly from Intel's download center (http://downloadcenter.intel.com/). Some versions of Lucid Virtu will cause video playback in 64 bit player to display frames out of order.
* Frame rate is wrong or incorrect aspect ratio: Haali Media Splitter is sending corrupt time stamps or aspect ratio. LAV splitter is recommended.
* After a seek in a TS file, a corruption is seen for a few frames. LAV splitter known issue.
* Resolutions greater than 1080p aren't supported in SandyBridge.

Installation:
1. An ffdshow installer is supplied.
2. Open FFDShow configuration dialog and select 'Intel Quicksync' from the codec page for the desired formats (H264/VC1/MPEG2).

Version 0.45 is out with the following changes:
* Bugfix - frames were sometime treated as interlaced.
* Bugfix - time stamps are passed 'as is' when TS manipulation is off.
* Bugfix - time stamps handling was causing A/V delay.
* Changed: AnnexB type packets (AVC in TS files) is not pre-processed and sent to the HW decoder directly. May break a broken clip or two but save many others.
* Sync with MSDK 2014 files.
* FFDShow: r4531

Downloads
* For the latest cutting edge FFDShow builds download my builds Intel QuickSync Decoder SourceForge home page (http://sourceforge.net/projects/qsdecoder/)
* FFDShow-tryout site (http://ffdshow-tryout.sourceforge.net/download.php)
* LAV Splitter builds (http://forum.doom9.org/showthread.php?t=156191)

[Guest]

Welcome to the forum, Eric! And thanks for your contribution. I haven't got a SandyBridge but I'm sure you will get a lot of testers here.

[Eliminateur]

egur, this is very good to know, i have some questions:
1) Does SB have specific problems with DXVA interfaces what it needs specific quicksync support?, it's known to crash MPC-HC and ffdshow DXVA as well
2) What about the Pentium Gxxx series?, since they don't have quicksync...

[egur]

egur, this is very good to know, i have some questions:
1) Does SB have specific problems with DXVA interfaces what it needs specific quicksync support?, it's known to crash MPC-HC and ffdshow DXVA as well
2) What about the Pentium Gxxx series?, since they don't have quicksync...

1) I'm not aware of any specific DXVA issues. QuickSync implementation is done with DXVA and further abstracted by the Intel Media SDK which I've used to create this FFDShow version. Using the DXVA interface directly isn't trivial and needs quite a few workarounds, the Media SDK takes care of some them. I had trouble myself with FFDShow-DXVA using both Intel graphics and an AMD Radeon 6950. Currently I managed to play dosens of HD (and non HD) movies well but I don't think the SW is at production level. I haven't tested with MPC-HC yet but I will.
2) Regarding the Pentium brand, I don't know. If someone has it, please let me know.

[kirakami]

What is Sandy Bridge?
will Intel Pentium 4 CPU built in year 2001 support?
& Geforce 4 mx

[egur]

What is Sandy Bridge?
will Intel Pentium 4 CPU built in year 2001 support?
& Geforce 4 mx

SandyBridge is the codename for Intel's latest generation CPU. Also called "2nd Generation i3/i5/i7 Core Processor".
SandyBridge has 2-4 cores an integrated GPU, integrated memory controller and integrated PCIe controller.
Pentium 4 doesn't have the HW needed and will definitely not work. My build of FFDshow might work on Core 2 Duo/Quad and i3/i5/i7 if and only if there's an Intel integrated GPU (can be found in many laptops and low end desktops). This wasn't tested though.
It will not work on AMD processors either as they do not have compatible HW.

My build should work on future processors with Intel graphics such as IvyBridge and Haswell.

[namaiki]

My build of FFDshow might work on Core 2 Duo/Quad and i3/i5/i7 if and only if there's an Intel integrated GPU (can be found in many laptops and low end desktops). This wasn't tested though.
Unfortunately doesn't seem to work on my i5 with Intel HD graphics (Arrandale).
Tested on Windows 7 (64-bit) in MPC-HC (32-bit).

[CruNcher]

Nice work Eric though i guess it wont do any better then Intels own Decoder sample in IMSDK 3 ?
@ least for Mpeg-2 it seems questionable if the hassle with different setups is worth it from my meassuring it saves somewhere 1W on my Core I5-2400 compared to ffmpegs decoder, though you will have all the hassle with Mpeg-2 Studio 4:2:2 switching as the Intel Decoder is same as Nvidias also not capable of doing this with DXVA :)

Of course it looks totally different for H.264 (there is the biggest save compared to the Worlds most Performant Software Decoders, but again if we come to the 10 Bit 4:2:2 and 4:4:4 or Lossless area everything fals apart again)
but also VC-1 im not sure at least WMV3 seems not to perform much better on Quicksync then again Libavcodecs decoder on the CPU :)

http://forum.doom9.org/showthread.php?p=1523685#post1523685

a follow up on that terminating overhead further

http://forum.doom9.org/showthread.php?p=1523692#post1523692


though it's cool that you (Intel) now also want to optimize based on samples like Nvidia did in the early days :)

first thing you should look @ this sample http://forum.doom9.org/showthread.php?p=1523293#post1523293

i tried alot but i don't get it stable with EVR and Intels Decoder (it doesn't matter which splitter the tree pan doesn't get smooth hardware decoded also with Microsofts DTV-Decoder no go, the only solution for this sample is the Lav based Framework on EVR it gets perfectly smooth then perfectly telecined)

and then there is my issue with my sample.ts (also telecined though H.264) on EVR custom but im not so sure if this is a Intel fault though Software decoding again works fine but Hardware fails with EVR Custom see a Video of this issue http://mirror05.x264.nl/CruNcher/mpc-hc/ (Btw made with Quicksync ;) ) <- Fixed with FFdshow for Quicksync :)

Intel Driver is = 8.15.10.2476 (Windows 7 64 bit)

Im trying your decoder now with all this

PS: You should mention that it's 32 Bit in your post ;)

Superb news my sample.ts (H.264) (EVR Custom) issue is history with this, perfect telecined 23.976 :)

Perfect awesome it doesn't allow Mpeg-2 Studio Profile connection and so fallbacks like it should be :)

This is the most awesome Decoder for Quicksync currently (except overhead being not DXVA2 Native is huuuge depending on stream see here after bugs http://forum.doom9.org/showthread.php?p=1523906#post1523906) :)

Though the correct telecine to 24.30 (evil_tree Mpeg-2 1080i 29.970 sample) is problematic also with it on EVR it does 0.30 fps to much it seems (interlace flags off) :(

http://img26.imageshack.us/img26/47/eviltreeffdshowquicksyn.png

Really tricky :D

this is what it should look like in the end (works only on EVR normal);)

http://img3.imageshack.us/img3/3503/smoothmotion.png

else you wont get the tree pan smooth ;)

Default Telecine works perfect even on EVR Custom :)

http://img18.imageshack.us/img18/8587/defaulttelecineperfect.png

It also likes to crash with several *.ts files in combination with Lav Splitter (those crashy ones work fine with the Internal MPC-HC ts splitter) http://forum.doom9.org/showthread.php?t=156191 Yep it crashes a lot with Lav Splitter :(

No Vsync no Exclusive mode nothing just Aero and Quicksync (again you can nicely see the jitter the Stats and Graph Rendering causes current EVR Custom OSD overhead) :D

http://img706.imageshack.us/img706/8000/novsyncjustaeroquicksyn.png

[CruNcher]

Major issues with VC-1 in *.ts either Sync problems or Rendering issues (different VC-1 Interlace encoding mixed modes) :(

Sync Issues:

http://img405.imageshack.us/img405/1606/vc1syncissuesffdshowqui.png

Rendering Issues: (This Problem Nvidia fixed ages ago ;) )

http://img851.imageshack.us/img851/7111/vc1interlaceproblemsffd.png


It also crashes for both with Lav Splitter had to switch to MPC-HC Internal Splitter ;)

Incorrect Telecine again :(

Lav-Splitter->Lav-Audio->FFdshow quicksync : (Incorrect)

http://img822.imageshack.us/img822/4110/mpeg2lavsplitterffdshow.png

MPC-HC Internal->Lav-Audio->FFdshow quicksync : (Correct)

http://img827.imageshack.us/img827/4647/mpeg2mpchcffdshowquicks.png



Though i slowly wonder if this is DXVA2 hardware Playback also because MPC-HC doesn't show any DXVA2 information (or more something like Nvdias NVcuvid API own Intel API but even for that it would be heavy overhead, just for Playback purpose ??) as i get much much lower CPU utilization with Microsofts DTV-Decoder (DXVA2) on H.264 streams ???? (lets see 4 girls is coming ;))


Yeah really heavy that overhead on this small HD2000 compared to Microsofts DXVA2 :)

ffdshow-quicksync overhead:

http://img835.imageshack.us/img835/4941/ffdshowquicksyncomgover.png


Native DXVA2 is still the way to go (imho we just need a better optimized playback framework for Quicksync and not only for it ;) ) :)

http://img834.imageshack.us/img834/7083/msdtvdxva2yoonyoon.png

Though will be really interesting to compare vs Nvcuvid overhead :)


Known Issues:
1. Higher CPU usage on low bitrate clips.

No comment :D

[Blight]

The major issue here is the overhead the driver adds for memory copies.

John Carmack (ID Software) wrote about it in this interview (http://www.pcper.com/reviews/Editorial/John-Carmack-Interview-GPU-Race-Intel-Graphics-Ray-Tracing-Voxels-and-more).

The topic of the GPU hardware race came up early in our talk and the response Carmack gave us was pretty interesting. Stating “I don’t worry about the GPU hardware at all, I worry about the drivers” seemed to be a reiterated point. This became very apparent to id Software while developing RAGE where even though the PC had truly an order of magnitude more horsepower than the consoles, it struggled to keep up with the “minimum latency”, get feedback here, update data there, etc and do it all to maintain a 60 Hertz frame rate. DirectX 11 and multi-threaded drivers might have helped things but he still claims that they are far from the solution he envisions: direct surfacing of the memory system. The process of updating a textures on the PC is on the order of “tens of thousands of times slower” than on the Xbox 360 and PS3. AMD did implement a “multi-texture” update specifically for id Tech 5 which should help, but from the interview you can tell that Carmack really does want more done on this topic.

One interesting side effect of this talk – Intel’s integrated graphics actually has impressed Carmack quite a bit and the shared memory address space could potentially fix much of this issue. AMD’s Fusion architecture, seen in the Llano APU and upcoming Trinity design, would also fit into the same mold here. He calls it “almost a forgone conclusion” that eventually this type of architecture is going to be the dominant force. You might remember our discussion of this topic with Josh’s analysis of AMD’s Fusion System Architecture – it would appear that AMD has a potential ally on its side if they are paying attention.


The same situation applies here too. Basically, the Intel GPU driver provides virtual GPU memory that in reality resides in the system ram.
But... you can't get direct access to that memory. The way the driver provides access to this memory is 1000's of percent slower than if the driver were able to point to the real memory address and let you just copy the image directly.

[nevcairiel]

The main problem here is actually copying stuff back from the GPU memory to the CPU/System memory, which only NVIDIA seems to have really managed to optimize properly for CUDA. Its not a task a game needs, which is why AMD never really cared to invest in it (and therefor is really slow with it). Intel doesn't seem to get that much performance either on the GPU -> CPU copys.

Its probably true that drivers are holding back the true potential of the current and next gen hardware.

[egur]

CruNcher:
First, thanks a lot for your analysis. That's the best way to get my little SW running properly...

I'd like to explain what I did in FFDShow.
I used the Intel Media SDK v3 beta 3 Direct Show filters sample code. Stripped most of it, fixed several bugs, cleaned it up, some refactoring, put some inline documentation and created a DLL that exports an interface.
My code doesn't use any secret APIs or secret driver GUIDs and doesn't contain any algorithms. It's quite simple and not very big.
Intel's Media SDK uses DXVA1/2 to communicate with the driver/HW (that's what I've heard anyway). What it does is somewhat abstract the horrible DXVA API making this task easier (but not easy!) and use less code.
The (relatively) high CPU usage is caused by one thing - memory copying from the GPU to system memory. I'll try to reduce this by trying to do VPP (DXVA/MSDK video post processing) to a system memory buffer. Hopefully the driver will do the copy faster than memcpy().

My idea with FFDShow is to have a 1 stop decoder that's low on power and high on quality. I want to abstract the HW acceleration and hopefully don't lose too much because of the above frame copying.

I used a profiler to check where the CPU spends its time and most of the time is copying the frame to system memory. A large chunk (25-50%) goes into the renderer's code somewhere. No clue as to why.

Just using DXVA to decode isn't trivial as different splitters behave differently and give different data and maybe the HW decoders aren't following the various specs to the letter. Microsoft's documentation isn't clear enough on how to write things properly. Theoretically they could have created a DXVA decoder themselves, but they didn't. Same goes to Intel/AMD/Nvidia.

My own CPU usage analysis shows that on low/medium bitrates, libavcodec uses less CPU than my implementation, but when bitrates are high (I have only one 26Mbps clip) the CPU usage stays about the same in my decoder and rises in libavcodec.

BTW, if someone know how to copy a frame from the GPU quickly I'd like to know. Since there's no PCIe traffic going on a solution is bound to be found.

[nevcairiel]

Microsoft's documentation isn't clear enough on how to write things properly. Theoretically they could have created a DXVA decoder themselves, but they didn't.

Oh, but they did. For H264 its called Microsoft DTV-DVD Video Decoder, and ships with Vista/7.
They also have one for VC-1, the WMVideo Decoder DMO, but for some reason this one only uses DXVA in WMP, it must be locked down somehow.

Of course their decoders are "pure" DXVA, which means they don't copy stuff back from the GPU, it remains in there until it is displayed - avoiding the memcpy problem.

[egur]

...

Its probably true that drivers are holding back the true potential of the current and next gen hardware.

If that was done on purpose then they (Intel/AMD/NVidia) could sell a premium part for more money that doesn't have this limitation and calling it a feature. Most likely a low priority issue that no one wants to spend resources on it (HW or SW).

The reason for the slowness as far as I've heard (aside from the PCIe latency and BW) is that the GPU stores surfaces differently than the CPU. A GPU in many cases needs to work on blocks or tiles (e.g. 8x8 16x16, etc.) and if those pixels are sequential in physical memory then they are read/written much faster and provide higher cache hits as well as efficient cache prefetching. So when a CPU tries to read several bytes each time (inner loop of memcpy) there's a lot of address translations and the memory controller needs to set up the DDR again and again for different pages.

[CruNcher]

The major issue here is the overhead the driver adds for memory copies.

John Carmack (ID Software) wrote about it in this interview.
Quote:
The topic of the GPU hardware race came up early in our talk and the response Carmack gave us was pretty interesting. Stating “I don’t worry about the GPU hardware at all, I worry about the drivers” seemed to be a reiterated point. This became very apparent to id Software while developing RAGE where even though the PC had truly an order of magnitude more horsepower than the consoles, it struggled to keep up with the “minimum latency”, get feedback here, update data there, etc and do it all to maintain a 60 Hertz frame rate. DirectX 11 and multi-threaded drivers might have helped things but he still claims that they are far from the solution he envisions: direct surfacing of the memory system. The process of updating a textures on the PC is on the order of “tens of thousands of times slower” than on the Xbox 360 and PS3. AMD did implement a “multi-texture” update specifically for id Tech 5 which should help, but from the interview you can tell that Carmack really does want more done on this topic.

One interesting side effect of this talk – Intel’s integrated graphics actually has impressed Carmack quite a bit and the shared memory address space could potentially fix much of this issue. AMD’s Fusion architecture, seen in the Llano APU and upcoming Trinity design, would also fit into the same mold here. He calls it “almost a forgone conclusion” that eventually this type of architecture is going to be the dominant force. You might remember our discussion of this topic with Josh’s analysis of AMD’s Fusion System Architecture – it would appear that AMD has a potential ally on its side if they are paying attention.
The same situation applies here too. Basically, the Intel GPU driver provides virtual GPU memory that in reality resides in the system ram.
But... you can't get direct access to that memory. The way the driver provides access to this memory is 1000's of percent slower than if the driver were able to point to the real memory address and let you just copy the image directly.

Also when we are about the talk on GPU/CPU Efficiency we have to come to the OS itself and it's current Driver architecture and WDDM 1.1 is just the start of this Process the next Windows is going to bring the next step until we some day reach WDDM 2.0 :)
We already had a similar Discussion on Beyond3d and nobody really want's to go to Assembler Style Code the GPU directly anymore, so yeah it's up @ Microsoft and the Vendors to improve this ;)


The (relatively) high CPU usage is caused by one thing - memory copying from the GPU to system memory. I'll try to reduce this by trying to do VPP (DXVA/MSDK video post processing) to a system memory buffer. Hopefully the driver will do the copy faster than memcpy().

:)


My idea with FFDShow is to have a 1 stop decoder that's low on power and high on quality. I want to abstract the HW acceleration and hopefully don't lose too much because of the above frame copying.

Nvidia was very successful with this :)


Just using DXVA to decode isn't trivial as different splitters behave differently and give different data and maybe the HW decoders aren't following the various specs to the letter. Microsoft's documentation isn't clear enough on how to write things properly. Theoretically they could have created a DXVA decoder themselves, but they didn't. Same goes to Intel/AMD/Nvidia.

Yeah true many ISVs know that and some do better then others in those regards, having more open and better documented APIs like Nvcuvid,Open Video and Intel Media SDK are great and hopefully will make this more easy for Devs Lav Cuvid and ffdshow-quicksync are nice examples though Nvidia is still in the lead here and both AMD and Intel came late into the Game. :)
Also it makes it much easier to adapt to new Renderer that doesn't support DXVA and use full capabilities without being limited :)

[egur]

CruNcher:
Regarding the "evil trees" clip. I get very strange results from different splitters. The LAV splitter reports 59.94 fps while haali and the Gabest MPEG splitter report 29.97.
All splitters produce a cadence of P B T P B .... (progressive, bottom first, top first) and all of them start past the zero time stamp (something like 4 missing frames). I'll dig into this to make sure I behave properly on all of them.

I need a VC1 clip that crashes - like you reported, currently I don't have crashing content. Also, what source filters are used for VC1 (.wmv), the WM ASF Reader freezes too much (regardless of decoder).
I've fixed the seeking issue and now seeks are instantaneous without artifacts.
I also fixed MPEG2 sequence header initialization which will seek corruption.

I'll release a new build in a day or two.

[Superb]

Not trying to get you down or anything, but why integrate it into ffdshow while LAV Video & LAV CUVID Decoder are the new rising stars around the neighborhood?
Nev (the developer) said he's planning to integrate the two one day (which makes sense; like CoreAVC), and I think it would be wonderful if he'll have a patch available adding SB acceleration as well. It will make it the best video decoder hands down.
What I'm trying to say: think ahead. forward. ffdshow is slowly fading w/ each step LAV Filters take.
I believe the day where codec packs use LAV Filters (instead of Haali & ffdshow) is not that far away.

Or maybe I'm the only one who has noticed it?

[pandy]

BTW, if someone know how to copy a frame from the GPU quickly I'd like to know. Since there's no PCIe traffic going on a solution is bound to be found.

AFAIR from old PCI times (seems that PCIe is only extension to PCI) reading from PCI device to memory was much slower than writing from PCI device to memory - if there is chance to make PCIe device transaction initiatior and order that PCIe device will write to system memory should IMHO faster than reading from device.

[egur]

Not trying to get you down or anything, but why integrate it into ffdshow while LAV Video & LAV CUVID Decoder are the new rising stars around the neighborhood?
Nev (the developer) said he's planning to integrate the two one day (which makes sense; like CoreAVC), and I think it would be wonderful if he'll have a patch available adding SB acceleration as well. It will make it the best video decoder hands down.
What I'm trying to say: think ahead. forward. ffdshow is slowly fading w/ each step LAV Filters take.
I believe the day where codec packs use LAV Filters (instead of Haali & ffdshow) is not that far away.

Or maybe I'm the only one who has noticed it?

My work has very little on FFDshows own code. I created a separate DLL that doesn't link with FFDshow or any of its components. FFDshow works very well (that I've noticed anyway) and it was a good start point to me as it doesn't change all the time (actually it does change but with very short merge times on my part). Porting to LAV should be easy, but one thing at a time.

[Superb]

That's great news. Btw, you might wanna look at VLC's git repository (http://git.videolan.org/?p=vlc.git;a=tree)... They use DXVA2 acceleration and copy the frames back too. (under modules\codec\avcodec\dxva2.c)

[CruNcher]

@Egur
samples coming, those that crash explicitly with Lav Splitter only (much more but i guess most of those crashes come from the same issue)

http://www.mediafire.com/?94f02bvzqhask37 <- Crash on Load with Lav Splitter
http://www.mediafire.com/?aocp4j26pj6i2qw <- Crash in the middle of playback

Here is something else (not so explosive but should be looked @ anyways):

http://www.mediafire.com/?7ob1wsdt1aon1ou <- Sync issue with Lav Audio

though please don't fix those if that could potentially mean problems for other splitter (or if you think it could) but talk with nevcairiel then first :)

[Gser]

Well it seems this isn't supported on core i7 860 as the gfx driver won't install.

[nevcairiel]

though please don't fix those if that could potentially mean problems for other splitter (or if you think it could) but talk with nevcairiel then first :)

Since basically all other codecs play fine, its doubtful at best.

I do things the way i think they are meant to work, not how old stuff was done. Its the only way to break the cycle of old bugs being re-introduced in every new component, just because they took something old as a template.
By doing this, i can play alot more files that just fail on other splitters. If that means ruffing some feathers on some codecs, so be it. :p I provide my own audio and video codecs anyway. :)

With CPUs getting ever so much faster and efficient, the time of hardware video decoders in PCs is nearly over, imho.
The only thing missing really is a good way to use the GPU for deinterlacing without relying on EVR. Thats basically the only reason i still use LAV CUVID myself, for the deinterlacing (and interlaced VC-1 decoding)

[Blight]

nev:
I agree that it's more important for videos to play correctly than to support buggy code. This is especially true when dealing with new decoders that the dev. is still active.
With regards to CPU vs. Hardware Accel, you're only right on the desktop. With laptops/tablets/cellphones, hardware acceleration allows for a longer battery life.

[sneaker_ger]

Well it seems this isn't supported on core i7 860 as the gfx driver won't install.

Core i7-860 has the old Lynnfield architecture, not Sandy Bridge, so it was to be expected.

[nevcairiel]

With laptops/tablets/cellphones, hardware acceleration allows for a longer battery life.

With tablets and cellphones that may be true, however for laptops i'm not 100% sure. Maybe in this generation thats still true, but for the future....

For CPUs, one key factor is also getting more efficient, while GPUs are apparently always going for power. On a desktop PC, the power usage difference today between DXVA2 and a software codec isn't all that big to begin with, so if the CPU gets faster and more efficient at the same time, there might be a point where the power argument is invalid (on PC/Laptop parts - SoC parts for tablets and phones are still far away from that).

Anyhow, i have quite some hope for Intels future CPUs, the Tri-Gate Transistors will be quite a nice boost both in performance and efficiency.

[CruNcher]

With tablets and cellphones that may be true, however for laptops i'm not 100% sure. Maybe in this generation thats still true, but for the future....

For CPUs, one key factor is also getting more efficient, while GPUs are apparently always going for power. On a desktop PC, the power usage difference today between DXVA2 and a software codec isn't all that big to begin with, so if the CPU gets faster and more efficient at the same time, there might be a point where the power argument is invalid (on PC/Laptop parts - SoC parts for tablets and phones are still far away from that).

Anyhow, i have quite some hope for Intels future CPUs, the Tri-Gate Transistors will be quite a nice boost both in performance and efficiency.

~5W (SB Decoder) vs ~12-15W (the best software decoders) is a difference also for normal Blu-Ray Playback where you would have to add the whole Player overhead (Java,Decryption tasks (not the decryption itself)) too it it adds up :)
And yep Tri-Gate will push that further down nearer to Soc Decoder :)

[egur]

New version released!

Download version 0.11 alpha:
32 bit http://www.multiupload.com/FCBQAAARUI
64 bit http://www.multiupload.com/6O3BXXXPAC

Revision history:
v1.11:
* Fixed skipping issues. Seeks are now instant.
* Fixed handling of sequence header for all supported formats. Fixes image corruption in some clips.
* Created 64bit version. Very limited testing was done with this one.

[egur]

CruNcher, I'll look into the crashes tomorrow. Thanks a lot for your help:thanks:

[egur]

...
The only thing missing really is a good way to use the GPU for deinterlacing without relying on EVR. Thats basically the only reason i still use LAV CUVID myself, for the deinterlacing (and interlaced VC-1 decoding)

I've considered adding HW deinterlacing to the decoder, it's not too complicated. But the extra copying I'll have to do, renders this solution a bad one (ATM).
If you want, I can export the D3D surface w/o copying and apply some post processing on it including DI. Enabling video post processing is high on my list after root causing the current bugs.

CruNcher, I'll look into the crashes tomorrow. Thanks a lot for your help:thanks:

[CruNcher]

@egur
the 64 bit version doesn't work it falls back to other decoder in the directshow chain if ffdshow-quicksync is selected for the format (libavcodec works)

Here is another stream that has problems with ffdshow-quicksync

http://www.mediafire.com/download.php?cla9ncy0m1tb89w <-stops @ start no playback possible

[egur]

@egur
the 64 bit version doesn't work it falls back to other decoder in the directshow chain if ffdshow-quicksync is selected for the format (libavcodec works)

I did very limited testing - only graph edit and it worked for a few clips. I'll try mpc-hc x64. Any other players to test? BTW, what was the setup (filters, content,etc) so I can reproduce quickly?

BTW, I reproduced the crashes with LAV splitter on your samples but didn't have the time to debug yet.

[CruNcher]

MPC-HC 64 Bit 3704
MPC-HC splitter standalone 64 bit (not internal, though should be the same as MPC-HC 3704 internal)
Lav Splitter 0.35 64 bit
Lav Audio 0.35 64 Bit
Renderer: Stability testing EVR (default)
Renderer: Shader Processing tests: EVR-CP

MPC-HC 64/32 3704 + standalone filters (binaries) can be found here http://xhmikosr.1f0.de/index.php?folder=bXBjLWhj

ffdshow 64 bit i used to replace your quicksync components with was http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/64-bit%20builds/ffdshow_rev3978_20110825_clsid_x64.exe/download

Most important dshow players are based on these components anyways ;)

you could also test with ongoing AVsplitter http://avsplitter.avmedia.su/en it's like lav splitter based on libavformat (uni*), MPC-HC is native windows based code ;)

Nothing connects to the ffdshow-quicksync 64 bit Decoder via MPC-HC 64 bit internal and standalone 64 bit filters (container doesn't matter format either) :(

32 bit same framework no connection issues


Btw here is a result from Intels MFT Decoder (copy overhead):

Renderer: Enhanced Video Renderer (Media Foundation)
Decoder: Intel® Hardware H.264 Decoder MFT
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: ProgressiveDevice
Time: 00:05.685
Average FPS: 177,130
Min/Max FPS: Min: 170 Max: 178
CPU Usage (%): Avg: 36 Min: 33 Max: 38

In compare no Copy overhead DXVA2:

Renderer: Enhanced Video Renderer (Media Foundation)
Decoder: Microsoft H264 Video Decoder MFT
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:02.238
Average FPS: 367,161
Min/Max FPS: Min: 343 Max: 386
CPU Usage (%): Avg: 09 Min: 07 Max: 12

in direct compare to Cyberlinks DXVA2:

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CyberLink Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:02.655
Average FPS: 379,183
Min/Max FPS: Min: 368 Max: 383
CPU Usage (%): Avg: 03 Min: 02 Max: 04

Current ffdshow-quicksync (copy overhead):

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: ffdshow Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:22.403
Average FPS: 44,948
Min/Max FPS: Min: 44 Max: 45
CPU Usage (%): Avg: 24 Min: 23 Max: 25

egur you should ask the guys that made the mft decoder (i guess they are part of the driver team and or sdk) how they optimized the performance @ the little higher overhead, though i would say this is currently the farest you could get in Performance optimization with ffdshow-quicksync .


in comparison here is the Libavcodec decoder efficiency on the 4 cores :)

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:03.456
Average FPS: 291,299
Min/Max FPS: Min: 285 Max: 285
CPU Usage (%): Avg: 83 Min: 83 Max: 83

[iwod]

CruNcher is an SNSD Fans :eek::eek::eek::eek::eek:

And What movie is test.ts ?? :cool:

[egur]

Hi CruNcher,

I've fixed some of the problems and I'll release a new version tomorrow.
• 64bit version is working. The 64 bit version was built wrong - fixed and now it works in MPC-HC x64 (using latest version which is older than yours, BTW).
• Optimized CPU usage (faster copying from GPU to CPU). Changed memcpy to an SSE4.1 implementation - much faster, but I don't have numbers yet (now it's faster then libavcodec or an average 720p movie).
• More stable with LAV splitter. Previous version crashed on several MPEG2 transport with AVC1 (H264) video. AVC header parsing is more robust (Media SDK bug or LAV filter bug).
• Added time stamp stabilizing (transport stream issues).
• Added adaptive inverse telecine (29.976 --> 23.97) when stream reports it. And fall back to the original frame rate when the content is "normal" (no repeating fields). This works great on the smple you've sent.

BTW, using Shader/GPGPU video processing is asking for trouble with the HD2000/3000. It's not comparable to the mainstream or high end cards. Even the simple Haali Video Renderer produces 7(!) fps (720p to a little higher resolution) on my laptop regardless of decoder.

If you can point me to some VC1 clips, I'd appreciate it.

[egur]

That's great news. Btw, you might wanna look at VLC's git repository (http://git.videolan.org/?p=vlc.git;a=tree)... They use DXVA2 acceleration and copy the frames back too. (under modules\codec\avcodec\dxva2.c)

Thanks!
I looked at the VLC code and found out they use an SSE4.1 instruction to copy from the GPU memory. I had to rewrite using SSE4 intrinsics so 64 bit compilations would work. Results are nice, Now I'm always faster then libavcodec on 720p (and north) videos.

[ajp_anton]

What exactly does this do?
With all this talk about copying frames from GPU to main memory, I get the impression that it's kind of like Nvidia's "CUDA" decoding, but it doesn't seem to be working properly.

CPU usage on a ~30Mbit 1080p video (i7-2600K):
"Quicksync": 10%
ffdshow (libavcodec): 7%
LAV: 6%
DXVA (MPC-HC): 0%

[nevcairiel]

Thanks!
I looked at the VLC code and found out they use an SSE4.1 instruction to copy from the GPU memory. I had to rewrite using SSE4 intrinsics so 64 bit compilations would work. Results are nice, Now I'm always faster then libavcodec on 720p (and north) videos.

Yeah that SSE 4.1 instruction is great for this task. Intel really knows what they're doing. :)

[Blight]

anton:
This is exactly what this is, the Intel sandybridge equivalent of nvidia's "CUDA" decoding.
It's an initial build, things will get better as more content is tested.

[nevcairiel]

I've been thinking about this thing today, and i've been wondering - what exactly does the Media SDK offer over a DXVA2 decoder (assuming you copy the frame back into system ram as well) ?
I'm only interested in actual user visible advantages, i realize coding might be simpler with the SDK, but then DXVA2 works with more GPUs. ;)

PS:
Its not the same as CUDA decoding, CUDA is handled quite differently. As i understand it, the MSDK is just a "wrapper" around DXVA2, hence my question.

[egur]

I've been thinking about this thing today, and i've been wondering - what exactly does the Media SDK offer over a DXVA2 decoder (assuming you copy the frame back into system ram as well) ?
I'm only interested in actual user visible advantages, i realize coding might be simpler with the SDK, but then DXVA2 works with more GPUs. ;)

PS:
Its not the same as CUDA decoding, CUDA is handled quite differently. As i understand it, the MSDK is just a "wrapper" around DXVA2, hence my question.

As far as I know it should be a more user friendly wrapper. Maybe cleanup stream errors, etc. You know that using DXVA naively doesn't work well.

DXVA is the implementation underneath. Maybe some day, DXVA will be replaced or Media SDK will be enabled on other platforms so using a wrapper speeds porting as well as writing an application. There's also the chance that DXVA will be too limited compared to the HW capabilities and media SDK will wrap another API (I'm guessing here).

There's very little programmable code that runs in the Intel GPU, most of the decoding/emcoding/VPP is done by ASIC (fixed function HW). That's why its so fast even when compared to a 250W GPU.

[CruNcher]

There's very little programmable code that runs in the Intel GPU, most of the decoding/emcoding/VPP is done by ASIC (fixed function HW). That's why its so fast even when compared to a 250W GPU.

Hmm though according to another Intel Engineer (Francois Piednoel , Senior Performance analyst at Intel Corp Santa Clara) there should have been a possibility to use these functions (execute on them) outside in your own Encoder Code for example (not using the whole Intel Quicksync Encoder @ all) :)
X264 could have benefited from that (direct acceleration on the ASIC) but it never happened to bee sadly.

This "Intel guy" disappeared after Dark Shikari asked him about low level QuickSync API.

Since the original Intel failure, I have learned quite a bit more about the lower-level details, and I'd quite love to explain more, but unfortunately I am now deep into NDA territory. If this means people are going to blame x264 for QuickSync's failings, well, unfortunately there's not much I can legally do about it anymore.

does that mean you are now technically able to allow some parts of x264 encoding to be done by quicksync? If so is this support going to be added?

Maybe yes, probably not. There are some pretty devastating technical limitations.


This could have been a big hit for Intel now AMD seems to be more open and taking the chance of giving full support which is not really surprising seeing they have nothing like Quicksync yet (which @ least can reach x264 superfast quality) (or not confirmed) and only their GPU Encoder which wouldn't be up against it :D


Egur here are the VC-1 samples:

http://www.mediafire.com/download.php?4m9cb10oms48bv1 <--Frame Interlaced/Progressive VC-1
http://www.mediafire.com/download.php?1uc5b42u55ue280 <-- Field Interlaced VC-1

Both sync problems (MPC-HC Splitter) the Field Interlaced also shows decoding issues. (was before the silent updates rechecking with 0.12)

Nice evil trees.ts plays wonderful smooth even without manually correcting it and with auto interlaced flags send (perfectly telecined) from ffdshow on EVR Custom (so other streams get properly double framerate deinterlaced).
Thats something no current DXVA Decoder can do on EVR Custom ;) (not without losing double framerate deinterlacing)
With Lav Splitter it fails on EVR custom though works only with MPC-HC Splitter for now :(

[egur]

New and improved version. Zip files contain documentation, please read.

Download version 0.12 alpha:
32 bit http://www.multiupload.com/5L5NL03997
64 bit http://www.multiupload.com/41UGJ3TQMI

Revision highlights:
v1.12:
* 64bit version is working.
* Optimized CPU usage (faster copying from GPU to CPU)
* More stable with LAV splitter. Previous version crashed on several MPEG2 transport with AVC1 (H264) video.
* Added time stamp stabilizing (transport stream issues).
* Added inverse telecine when stream has the right flags.

[CruNcher]

@egur

the MC.ts is still problematic (wrong decoded)

the CD.ts is fine also sync wise :)

http://www.mediafire.com/?37kyc94d6n22tkf <- stops @ start


also i have a sample (very bad condition one) where i don't understand why Deinterlacing doesn't work on EVR Custom with ffdshow-quicksync but works fine on EVR (as if something adaptive would work on EVR (no flags needed) that's not being used on EVR Custom)

Upload of that one in progress (playback btw is fine for how corrupted this is only the Deinterlacing EVR Custom failing is what makes me wonder, several others shows this behavior too, though bitstream wise all are correct flagged though still sometimes EVR Custom Deinterlacing works sometimes it fails, when i look directly @ it and compare it seems for Mpeg-2 it always works but for H.264 it seems to fail interesting)

Does it mean Adaptive Deinterlacing works only on EVR and is it maybe possible to make it usable (from within Intels Drivers to work for other Renderer like EVR Custom as well ????)

Ahh seems the Problem is in ffdshow-quicksyncs MBAFF handling :)

Yep normal Interlaced Streams get correctly Deinterlaced on EVR Custom (Interlaced(PAFF))
MBAFF streams fail and only get correctly Deinterlaced on EVR

(hmm not sure yet but it seems the telecine fails on smooth cuts (fades) doesn't feel right on EVR Custom @ least)

Yep again EVR results are much better


ffdshow-quicksync telecine Mpeg-2 EVR:

http://img855.imageshack.us/img855/707/ffdshowquicksynctelecin.png

ffdshow-quicksync Telecine Mpeg-2 EVR Custom (fail):

http://img97.imageshack.us/img97/707/ffdshowquicksynctelecin.png

I guess that will be interesting to compare vs Nvidia :)

[egur]

CrunNcher:
I have a small bug in the memcpy function on 32 bit. You'll see a corruption on the right side (less than 128 pixel wide stripe on the rightest side).
I also improved the speed a little bit so I'll release again soon.
I'll check the new clips.
I saw that one of them was heavility corrupted (MC.ts). One played fine (CD.ts).

Do you have any info on MBAFF that can help me?

Aslo regarding invserse telecine, what do you mean by slow fades? I don't perform image analysis, just look at the flags.
If a few frames pass and there's no "repeat field" flag, than I drop out of IVT back to hte original frame rate.
I think I'm missing some code that deals with format change during playback. I'll add that too.

[tetsuo55]

Hello Eric,

First of all i want to say i am happy to see a release of a more stable dxva decoder for sandybridge and higher gpu's.
Also i cannot wait for the source to be released so this code can be integrated in arguably superior codecs.

I am a little bit confused though. Historically Intel has been working with Casimir of MPC-HC for integration of its DXVA codecs, has anything changed in this regard?

[nevcairiel]

LAV Video will get support for decoding through Intels Media SDK sooner or later, be it with Erics help or without.
Like Eric said, he didn't use any magic, he just implemented a decoder based on the publicly available SDK.

[egur]

Hello Eric,

First of all i want to say i am happy to see a release of a more stable dxva decoder for sandybridge and higher gpu's.
Also i cannot wait for the source to be released so this code can be integrated in arguably superior codecs.

I am a little bit confused though. Historically Intel has been working with Casimir of MPC-HC for integration of its DXVA codecs, has anything changed in this regard?

This work is my own initiative and it's aligned with Intel's interests as well as the users.
BTW, 100,000 people work at Intel and I don't know most them (or Casimir)...
Several groups support companies and open source projects, I'm awareof only a handful of people. I myself work in OEM support for the CPU but this is irrelevant to my little project here.

Source code will be sent if requested. It's meant for everyone to see, modify and use for free in either open or closed source projects.
I think it's a little early to send the source cose as it changes quite a bit due to feedback. But if you want it, I can send it to you.

[tetsuo55]

Thanks for the reply's.

I'm not in a rush to see the sourcecode, but as an open-source project manager i would like to see your work on a source management platform and licenced with GPL as soon as possible.

You can choose any site that you like; github, google code, etc...

Personally i tend to follow the commitlog for projects more than forum chat, as it is more condensed and to the point, plus i get to review the actual code changes. This will also give you the possibility to have people open tickets and attach small samples, etc...

Thanks in advance and good luck with this project!

Do you think this code will at some later point in any way help older DXVA implementations of pre-sandy-bridge hardware?

[squid_80]

Since ffdshow is licensed under the GPL and you are distributing modified builds of it, I think you are required to make the source available regardless of anyone requesting it or not. At least that's the point of view a certain moderator on this forum took with my work in the past.

[Superb]

I believe it's not the moderator's view... It's the license's view...

[egur]

Since ffdshow is licensed under the GPL and you are distributing modified builds of it, I think you are required to make the source available regardless of anyone requesting it or not. At least that's the point of view a certain moderator on this forum took with my work in the past.

I didn't contact CLSID (ffdshow's admin) about when and if I can integrate my ffdshow changes into the ffdshow source control in SourceForge.
BTW, the changes to ffdshow itself are small and trivial - just add a new decoder and assign it H264/MPEG2/VC1.
The majority of my code (a decoder DLL) should be on its own and I'm not sure what's the best way to post it's code. The most generic solution would be to create a separate project in SourceForge or another depository and have ffdhsow use it as an external lib (like it uses other decoders).
I'd like the decoder DLL to be LGPL not GPL so it can be used in any project (open or closed source).

ATM, it's much easier for me to have a single VC2010 solution and develop on it. The entire ffdshow source code is ~60MB zip and it's a little big to post, so I don't post it. My DLL's source code is ~130K and I have no problems sending it to anyone.

I'm not an expert in these matters and I'd be happy to get suggestions on the matter - both technical and legal.

[tetsuo55]

I didn't contact CLSID (ffdshow's admin) about when and if I can integrate my ffdshow changes into the ffdshow source control in SourceForge.
BTW, the changes to ffdshow itself are small and trivial - just add a new decoder and assign it H264/MPEG2/VC1.
The majority of my code (a decoder DLL) should be on its own and I'm not sure what's the best way to post it's code. The most generic solution would be to create a separate project in SourceForge or another depository and have ffdhsow use it as an external lib (like it uses other decoders).
I'd like the decoder DLL to be LGPL not GPL so it can be used in any project (open or closed source).

ATM, it's much easier for me to have a single VC2010 solution and develop on it. The entire ffdshow source code is ~60MB zip and it's a little big to post, so I don't post it. My DLL's source code is ~130K and I have no problems sending it to anyone.

I'm not an expert in these matters and I'd be happy to get suggestions on the matter - both technical and legal.The best thing you can do right now is open a new project, you can use GIT trickery to link to ffdshow at compile time and then patch from your own tree (that way you do not need to copy all of ffdshow).

Here is some extra info http://www.joelonsoftware.com/articles/fog0000000043.html

(P.S. Make sure to keep the LGPL and GPL code in seperate sub-projects)

[BetaBoy]

I'd like the decoder DLL to be LGPL not GPL so it can be used in any project (open or closed source)
LGPL is not great for closed source as it would raise more concerns then what I think you're trying to accomplish. I would propose a BSD based license.

Alternatively make it licensed under all 3: GPL, LGPL, BSD to satisfy everyone.

[Blight]

I second it, BSD is better than LGPL for closed source applications.

[egur]

Then BSD license it is.
Next build will Tomorrow (Monday).

[egur]

Thanks for the reply's.
Do you think this code will at some later point in any way help older DXVA implementations of pre-sandy-bridge hardware?

Technically (MSDK docs), it should work on Core 2 Dou with Intel graphics. But no one reported success yet. And the real world is not aligned with MSDK docs :(
I'll try to make it work on a Penryn laptop and report back

[egur]

New and improved version. Zip files contain documentation, please read.

Download version 0.13 alpha:
32 bit http://www.multiupload.com/Z284JFR06X
64 bit http://www.multiupload.com/1YFGXD786C
Source Code http://www.multiupload.com/ZVMCN124A0

Revision highlights:
v1.13:
* Optimized memory copy even further. Memory copy has 2-6% overhead (out of process CPU usage).
* Fixed bug in memory copy when frame width wasn't mod128.
* VC1 playback is more stable. Still corruption on some clips.
* Fixed some small memory leaks.
* Compatibility with 2509 driver.
* Bug fixes & cleanup.
* Tested with driver versions 2509 and 2372.

[CruNcher]

Egur for Performance and behviour testing also of the MSDK parts you should really take WAC,WPR,WPA from the new ADK into your Dev chain (though i guess Intel is using it already longer time then we are aware now of it since Build, and this massive usability changes of it) i can really recommend it to use it's damn powerful down to the stack and much easier know then Xperf was when it started with NT 6, this is for every Windows Developer a must use in Application Development/Assessment :)
Like Valgrind is for *nix Devs :D

http://img52.imageshack.us/img52/457/powerfulz.png

Argh


* Tested with driver versions 2509 and 2372.

I wasn't aware of a new version unfortunately the news about new Intel Drivers aren't spreading as fast as for example Nvidia or AMD driver releases :(

also you have inside knowledge coud you please explain the release cycle difference and numbering sheme difference between the Platform Drivers and the Mainboard Driver release and the difference between them ?

So the difference currently between the 2 branches (also in terms of MSDK integration)

8.15.10.2476

15.22.50.64.2509


http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=20334&ProdId=3283&lang=eng&OSVersion=Windows%20Vista%2064*&DownloadType=Treiber

http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=20391&ProdId=3319&lang=eng&OSVersion=Windows%207%20Ultimate*%2C%2064-Bit-Version&DownloadType=Treiber

Has it just todo with testing and Certification for the correct functioning on the Intel Mainboards or for what are those 2 different in CPU driver categories ?

[egur]

also you have inside knowledge could you please explain the release cycle difference and numbering sheme difference between the Platform Drivers and the Mainboard Driver release and the difference between them ?

So the difference currently between the 2 branches (also in terms of MSDK integration)

8.15.10.2476

15.22.50.64.2509

Has it just todo with testing and Certification for the correct functioning on the Intel Mainboards or for what are those 2 different in CPU driver categories ?

I'm as clueless as you are on driver version numbers and release dates :(
The last driver released to the public was in April. The new one is about a week old.
I didn't notice any positive changes about the new driver. It broke parts of my code and I have opened a thread on the MSDK forum. VC1 corruption is still there.
I also have a laptop with an engineering sample SNB processor that has an April driver. I use the two systems to produce code that works on both.
Some MSDK functions fail using one driver and succeed on the other and vice versa.

BTW, do you mind if I share the clips you're posted here to the MSDK team?

[CruNcher]

Sure you can share them so the MSDK Devs become aware of these issues and fix them in Driver, this is the goal of such a collaboration improving by sharing problems so the whole Ecosystem can leverage from it from ISVs, Vendors to Consumers in the End :)

[BetaBoy]

New and improved version. Zip files contain documentation, please read.

egur... thank you for this and your continued work on it.

[CruNcher]

Btw Egur this is also something that interests myself http://software.intel.com/en-us/forums/showthread.php?t=86355&o=a&s=lr :)
In the Documention it says there needs to be a Display connected @ least so in theory it should work with a Discreet Card inside and connected if another Monitor is also connected to the IGPU (or maybe a Dongle is enough to make Windows and the Driver and so the MSDK in believing a Monitor is connected ;) ) I really could guess suddenly you would get a answer back that doesn't say unsupported anymore, though maybe Intel now decided to remove it completely after the Lucid Logix Partnership ;)

Especially im interested how to leverage the DSP Encoder without needing 3rd party software for framebuffer copying like Lucid Logix in such a scenario (if a dongle is enough it would be perfect i didn't tried it yet, im still testing the full capabilities of Intels GT1 alone especially in Power Consumption, but obviously i keep a backup of every SDK and Driver to check if something dramaticaly changed or has been removed on purpose) :)

Im a little sad that my Mainboard manufacture didn't decided to give this capability to their customers for free especially early adopters but Intel did so so in the end they gave their users something for the Chipset Disaster for free (but if it should come out that it's possible without 3rd party software to leverage Quicksync alone on a multi GPU system then it would have been just a clever marketing step for both Intel and Lucid Logix) i wished other Vendors would have gone the same way but they made it a feature for Higher Class SKUs ;)

So im really interested in the answer you gonna get myself ;)

[egur]

Im a little sad that my Mainboard manufacture didn't decided to give this capability...
FYI, I had to update my BIOS to get Virtu working on my Intel DH67GD motherboard. New BIOS had other enhancements like a much smarter fan control and fast boot (1-2s POST).

I think that with Viru you actually use the 2 GPUs, but you'll need 2 processes. Each process will use a different GPU (add one of them to Virtu's app list) and data needs to be copied to shared memory (memory mapped file). This is a little complex setup and I don't have the resources to explore it. At least I've proven that copying the data from the Intel GPU isn't too bad. Latest benchmarks for a 243 frame clip 1920x816 took 110ms (for all the frames) according to VTune Amplifier 2011.
I'll report in this thread if there's anything new on the matter.

[egur]

egur... thank you for this and your continued work on it.

10x, I appreciate it.

[CruNcher]

Egur i expected that Marketing Answer and im not happy with it @ all ;)

[egur]

Egur i expected that Marketing Answer and im not happy with it @ all ;)

What marketing answer?

[CruNcher]

What marketing answer?

Eric,

This feature is only supported for systems with switchable graphics. More details can be found here:

http://www.intel.com/support/graphics/sb/CS-031103.htm

Details about how to set this up can be very system specific. We're hoping to add some clarifications to the documentation in the future.

Regards,

Jeff

That one ;)

[egur]

I've ran a few vtune sessions to optimize my code. New version (0.14) will be slightly faster than 0.13.
Test platform:
* Windows 7, 64 bit
* Core i7 2840 @2.4GHz (45W)
* MPC-HC (current version)
* A 10s clip. H264/AVC1, 1920x816, 243 frames

Vtune showed that the latest sse4_memcpy took 112ms for the entire clip. That's less than 0.5ms per frame (almost 1080p).
CPU usage was in the low single digits ~5%.
My DLL's code contributed 1/50 of that 5%.
A more important thing is the the CPU frequency went down to 800MHz, the lowest frequency SNB-mobile will go to for the entire clip. This is about 1/3 of the stock frequency and ~1/4 of max turbo.

[Eliminateur]

i'm really looking forward to see your decoder implemented in mpc-hc!(if it's possible at all), since right now dxva decoding is broken for SNB on MPC-HC

[egur]

i'm really looking forward to see your decoder implemented in mpc-hc!(if it's possible at all), since right now dxva decoding is broken for SNB on MPC-HC

It works with MPC-HC (32/64 bit).
MPC-HC is my only test platform for 64 bit BTW.
Using EVR in MPC-HC is very solid, except for several VC1 clips which are under inverstigation and only libwmv9 can play properly.
It's still work in progress, but things are quite stable and I'd appreciate more testers.
In MPC-HC just uncheck the internal filters for MPEG2/H264/VC1 in the "options->Internal Filters" dialog. Add ffdshow to the external filter list, configure it to use IntelQuickSync and you're set to go.
Latest version is always availble on the 1st page.

Comments are welcome.

Next release will come as an FFDshow installer like the standard builds.

[Eliminateur]

what i meant was working as in "integrated" into the internal filters, not as part of ffdshow separate installation.
When i get a new Pentium Gxxx machine built here in the shop i'll test if it works with that series

[egur]

what i meant was working as in "integrated" into the internal filters, not as part of ffdshow separate installation.

It's on my TODO list.

[CruNcher]

Yep it got amazing fast now and CPU overhead is in the range of Lav Cuvid now for Yoon Yoon it was a dramatic improvement from that heavy utilization @ the beginning to 18% and now only 7-8% pretty good (for non DXVA) :)
It would now even make sense to try it in a Quicksync based Framework and see how it does their :D inlcuding the Encoder inside ffdshow also looks like a good idea :)
Yeah the decoding issue with the MC.ts bitstream is still a problem it's funny that also Nvidia had problems in the beginning of their API with this i wonder why this bitstream type was overlooked by Nvidia and Intel now ;).
Also i might have found another H.264 issue but i have to isolate this first it happened in a pretty normal playback scenario.

I also tested Intels PP system but it's fairly weak (Denoise,Sharpening) are pretty basic implementations currently

Also Deinterlacing and IVTC work only Efficient on EVR with EVR-CP MBAFF Deinterlacing and IVTC are failing currently, though not much of a big deal as Shader based PP are usable on both and with Aero on tearing is history anyways (for my weak GT1 6 EU it works still pretty reliable and i still have clock headroom to improve higher res input) :) :(

PS: I see that a Dummy works like expected from the Documentation very nice no need for the Lucid solution :D though that you have no reference what for P-States the GT1 is using i wonder how much power it draws if in this headless mode i guess as much as with a real display though, maybe a little lower depends on how the DSP is weaved together with the rest of the GPU and CPU and the efficiency of the Power Management Intel implemented :)

Now i slowly getting there todo a complete framework test between Nvidia and Intel :D

[nevcairiel]

Nice to see the performance improvements, that'll surely make it much more usable in the future.
Luckily SSE4.1 is available since Penryn, so any recent Intel iGPU will be able to use it. :)

Looking forward to working on integrating it in LAV Video when i'm done integrating CUVID properly (and maybe wmv9, depending on what i decide to do first).

PS:
Regarding "integrating into MPC-HC", the MPC-HC integrated decoders are overall outdated, the only thing useful they offer is the DXVA decoder which works better then ffdshows (which is based on the same code, but never was truely maintained)
I've always aimed to replace those decoders with a equally simple and easy to use, yet modern, decoder, which is exactly what my LAV Audio & Video are providing.

[egur]

Yep it got amazing fast now and CPU overhead is in the range of Lav Cuvid now for Yoon Yoon it was a dramatic improvement from that heavy utilization @ the beginning to 18% and now only 7-8% pretty good (for non DXVA) :)

We need some a method for measuring CPU usage. ffdshow-quicksync CPU usage (your example) went down from 18%@3.1GHz to 7-8%@0.8GHz.
Maybe a normalized formula is needed:

NormalizedCpuUsage = CpuUsage * NumPhysicalCores * Freq

Regarding power - SNB reduced voltage at 800MHz to about 0.7V-0.75V. In turbo it's ~1.2V. That's a major power drop.

It would now even make sense to try it in a Quicksync based Framework and see how it does their :D inlcuding the Encoder inside ffdshow also looks like a good idea :)
I think its a good idea too. But not feasible in the short term. BTW, there're encoders in MSDK, but I know nothing about them.

Yeah the decoding issue with the MC.ts bitstream is still a problem it's funny that also Nvidia had problems in the beginning of their API with this i wonder why this bitstream type was overlooked by Nvidia and Intel now ;).

I gave the MC.ts clip to the MSDK team to check out.
There’s something wrong with it. My AMD Radeon 6950 DXVA crashes on it, libavcodec doesn’t work. Only WMV9 works well.

Also i might have found another H.264 issue but i have to isolate this first it happened in a pretty normal playback scenario.
I’m aware of the following bug (not root caused yet) :
Open an MKV/AVC1 clip in MPC-HC using with EVR-CP as renderer --> crash.
But… if you open another file first and then open the crashing clip it will not crash!
Also not crash with normal EVR. Very strange and very repeatable. Crash is within ffdshow.ax but before my constructor is called. In ZoomPlayer it never happened (no EVR-CP).

I also tested Intels PP system but it's fairly weak (Denoise,Sharpening) are pretty basic implementations currently
I get more detail using EVR in the IGP then my AMD card. I guess a matter of taste.
Please post images for comparison. Also the IGP scaling is much better (I designed it :) )

Also Deinterlacing and IVTC work only Efficient on EVR with EVR-CP MBAFF Deinterlacing and IVTC are failing currently,…
Please explain. I don’t fully understand.

PS: I see that a Dummy works like expected from the Documentation very nice no need for the Lucid solution :D though that you have no reference what for P-States the GT1 is using i wonder how much power it draws if in this headless mode i guess as much as with a real display though, maybe a little lower depends on how the DSP is weaved together with the rest of the GPU and CPU and the efficiency of the Power Management Intel implemented :)
P states should be high (my guess) – a lot of memory traffic but the EUs should be idle. They don’t do much.

Now i slowly getting there todo a complete framework test between Nvidia and Intel :D
Excellent – this would be good for everyone. Someone needs to replace HQV with something more professional.

Nice to see the performance improvements, that'll surely make it much more usable in the future.
Luckily SSE4.1 is available since Penryn, so any recent Intel iGPU will be able to use it. :)
It works on Penryn (I have a Penryn laptop T400 Thinkpad), but poorly :(. The HW isn’t the same as SNB…

Looking forward to working on integrating it in LAV Video when i'm done integrating CUVID properly (and maybe wmv9, depending on what i decide to do first).
Excellent! I’m gathering requirements now. Please send them to me.

PS:
Regarding "integrating into MPC-HC", the MPC-HC integrated decoders are overall outdated, the only thing useful they offer is the DXVA decoder which works better then ffdshows (which is based on the same code, but never was truely maintained)
I've always aimed to replace those decoders with a equally simple and easy to use, yet modern, decoder, which is exactly what my LAV Audio & Video are providing.
I don’t have the bandwidth to create a standalone DirectShow decoder. The MPC-HC devs will have to it themselves, I guess. What I can do is create a standalone decoder with a C++ interface that’s not dependent on anything. This is BTW very close to where I’m now. I’m missing interface requirements to make integration a smooth process (<1 week)

[nevcairiel]

I gave the MC.ts clip to the MSDK team to check out.
There’s something wrong with it. My AMD Radeon 6950 DXVA crashes on it, libavcodec doesn’t work. Only WMV9 works well.


Its interlaced VC-1, of course libavcodec won't work - interlaced VC-1 is not supported at all, sadly.
As far as i am aware, CUVID decoders on NVIDIA work fine with it, though. Sadly i don't have a copy of that file to check it out, and it appears no-one ever linked it publicly in this thread, or i was too blind to find it.


Excellent! I’m gathering requirements now. Please send them to me.

I'll get back to you on that. I don't really have a set of requirements defined, as most of the time as a developer of these components i just have to adapt to the APIs i have, be it CUDA/CUVID, the WMV9 decoder, DXVA2 or the Intel MSDK.

All i really need is some API at which i can throw compressed frames, and it somehow gives me back the decoded frames, including all necessary metadata.
Then again, there is timestamp handling, which will never work out of the box, so defining requirements for that is non-trivial. H264 and MPEG2 are easy, VC-1 is hard.

I'll think some about that.
If anything, your code will be a great template to build upon.

[CruNcher]

I get more detail using EVR in the IGP then my AMD card. I guess a matter of taste.
Please post images for comparison. Also the IGP scaling is much better (I designed it )

Nice :) yes im gonna do some also the PP stages and differences to what is basically available to consumer including a pretty basic comparison to thinks like SimHD which imho is overrated entirely to basic Shader PP in it's current incarnation @ least :)

This H.264 problem is not directly related to ffdshow-quicksync but another popular 3rd Party component that makes use of the Decoder via DXVA, though im still checking this.

[egur]

Sadly i don't have a copy of that file to check it out, and it appears no-one ever linked it publicly in this thread, ...

For MC.ts & CD.ts see CruNcher's post with links:
http://forum.doom9.org/showthread.php?p=1526099#post1526099

CD.ts plays fine and it's VC1 interlaced. CruNcher said in the post , that the MC.ts is field interlaced and the CD.ts is frame interlaced. Something is completely screwed with the MC clip, I don't know what yet. It was sent to the MSDK guys for a solution.

Update
wmv9 (from ffdshow 3978) - reports clip as progressive (wrong). No block artifacts. No deinterlacing.
Intel decoder - clip is interlaced (TFF). EVR deinterlaces OK. Strong block artifacts in decoder at the macro block level. No idea why.

[nevcairiel]

Field interlacing is rather rare for VC-1, however i've run across another clip that uses this just a short while ago - but i've never seen it before that. :)

Edit:
I can confirm that MC.ts plays fine with my CUVID decoder. :)

[Blight]

cruncher:
When eric said he designed the the scaler, he should have given a bit of background.
Prior to Intel, he worked on scaling algorithms (noise reduction as well if I remember correctly) at a company that designed image processing chips.
The company was bought out by Intel and the scaler algorithm work was integrated into future Intel chips.
A few years later... and now it's part of Sandy Bridge :)

[CruNcher]

So the Scaler inside the first Atoms is also from Eric :D ?
they also bough in the beginning of the year Silicon Hive to improve most probably the power consumption part of future Atoms (and maybe even allready Ivy Bridge or @ least Haswell) :D

Silicon Hive processors save tremendous area and power by moving almost all control from run-time to compile time.

In a statement Intel said that the acquisition would bring better still-imaging and multimedia video processor technology, compilers and software tools to the Atom processor portfolio. "The Silicon Hive capabilities will aid in the delivery of more differentiated Atom-processor based SoCs as multimedia and imaging grow in importance across the mobile smart device segments," Intel said.


Ahh i see Oplus Technologies Inc is the Deinterlacing Oplus Pixel-Entropy Deinterlacing ?

hehe

Image enhancement filter - enhances images and provides spatial noise reduction
Color transition improvement - improves picture sharpness by emphasizing color transitions
3D motion noise reduction filter
Motion adaptive de-interlacing
Color control - providing independent saturation and luminance control per color compounent
Skin tone enhancement - providing detection and improvement of skin tones
Adaptive contrast enhancement - dynamically adjusts the contrast curve, enhancing image detail
Pixel mode recognition algorithm - enables seamless 3:2 (NTSC) and 2:2 (PAL) reverse pulldown, at the pixel level, of TV-adapted film material.

Image detection, adjustment and positioning
High-quality, patented, linear and non-linear scaling
Patented keystone correction algorithm for high-quality electronic correction for projectors
Flexible windowing technology supporting any combination of video and graphics or video and HDTV, with size, position and order control.



At least i know what im comparing here ;)

So basically the equivalent of HQV from Israel

hehe have to find that patent ;)

hehe thats cool what he done with his Skin tone Research :D

Segman examined thousands of photos of people
with different skin tones. “The aim was to establish
if a certain skin color could indicate illness. Could a
certain skin tone, for example, be influenced by liver
problems? He uncovered a relationship between skin
colors that indicate normal health or illness.
Segman found that when people are tense, their skin
tone changes. “
The first trials of Cnoga’s technology will soon be
tested at Bnei Zion Hospital in Haifa, supervised by
Prof. Eli Zuckerman.

[egur]

So the Scaler inside the first Atoms is also from Eric :D ?
No, It's a completely GPU, I'm not familiar with the details on the Atom...

[egur]

...Also Deinterlacing and IVTC work only Efficient on EVR with EVR-CP MBAFF Deinterlacing and IVTC are failing currently...
Can you upload failing clips?

[CruNcher]

Can you upload failing clips?

http://www.mediafire.com/?4gcnazd6y78c9yp
http://www.mediafire.com/?wlnkh80oaou827h

Sure works fine on EVR only EVR-CP is the Problem :(

It really seems there are only 2 ways to use the Adaptive Deinterlacing either using EVR or EVR-CP + DXVA Decoder

PS: I got Desktop Capturing to work via Quicksync trying to capture though 60 fps on DWM with BitBlt seems not really that efficient :D

http://img148.imageshack.us/img148/7202/thisiscool.png

Performance droop with Firefox is Extreme here on both sides IE is much better doing, obviously drooped frames in the EVR but not as bad as with Firefox :) (they are still far away from Microsofts D2D Engine Performance)


http://img20.imageshack.us/img20/7202/thisiscool.png

[egur]

Ahh i see Oplus Technologies Inc is the Deinterlacing Oplus Pixel-Entropy Deinterlacing ?
Before 2005 (when Oplus was bought), the technology went into video processors for flat panel TV and projectors.
The SNB algorithms where done when Oplus was already owned by Intel almost 2 years later. Segman was one of the Oplus founders and he invented the algorithms for the early Oplus video processors, a little before my time and I don't want to comment on his work. He didn't get along with Intel and left very quickly after the acquisition. He got a few million dollars from the sale like all the founders and now he pursues his exotic algorithms elsewhere...

I had a bug with identifying the interlace flag correctly, hence the sample-mbaff.ts clip didn't deinterlace. fixed.
The other clip telecine-test.ts plays fine (EVR).

Regarding EVR-CP. Most video clips will not show video using this on a GT1. I think GT2 works, I'll recheck on Sunday when I come to work.
Almost all renderers disable Aero when MPC-HC starts playback (EVR doesn't :) ).
Does anyone have a solution for this?
Why is this happening?

[CruNcher]

No such problems (though i know that black frames also like to happen if a bitstream is wrong marked for example as High 5.1, some decoder in the past didn't liked that) though my Win 7 is very Virgin and i didn't yet installed some optional updates that have todo with the D2D subsystem.

And please look carefully @ the telecine one, the problem happens @ the fade (the cut after the man gets dragged out of the frame by the bodyguard and the camera switches back to her on stage) its almost invisible but the difference between EVR and EVR-CP in that fade is visually recognizable.

[nevcairiel]

Almost all renderers disable Aero when MPC-HC starts playback (EVR doesn't :) ).
Does anyone have a solution for this?
Why is this happening?
Its a option. You probably applied some settings preset which included this option.

Check the renderer options in the right-click menu.

[CruNcher]

ouhh yeah that nasty thing i totally ignored that, since i first turned it off don't wanna remember it ;)

[Blight]

I know that at least with MadVR, the reason for the option to disable Aero with fullscreen exclusive mode is that it makes the switch between exclusive/window mode faster.
Which is good and fine if you're running a standalone HTPC which never sees the desktop.

Cruncher:
I'm interested to see a visual comparison between SNB DeInterlacing and the NVIDIA/ATI/Software modes.
I believe the eric's plan is to look into adding the hardware deinterlacing support after the decoding is fully stable :)

egur:
What other PP does the SNB support? Denoise? Sharpen? Weren't you talking about facial color correction a while back?

[egur]

The various EVR CP clack screen issues were solved by resetting the renderer to its default settings.

EVR CP give a jitter or 7-8ms and an offset of ~8ms very constantly. I have no clue why, changing the EVR buffer count doesn't change anything. If someone has an idea, let me know.
CruNcher:
Regarding the IVTC drop (telecine-test.ts) – I can’t reproduce in my current version. I’ve placed a breakpoint in the code that drops IVTC and it doesn’t trigger. BTW IVTC isn’t activated on the first frame, I look for a field doubling flag and only when I see one I activate IVTC. The IVTC dropping heuristic is to count 4 frames from the last frame that had the field doubling flag. After 4 frames the 3:2 cadence is broken and IVTC is dropped. If someone has a better way of doing this, don’t be shy.

SNB video processing blocks are:
*Motion Detection based deinterlacer
*Film cadence detection (for interlaced content) – works on raw video not part of decoder
* Denoise (temporal and spatial)
* Context adaptive sharpening
* Context adaptive 8 tap polyphase scaler. Supports Non Linear Adaptive Scaling (4:3 -> 16:9)
* Total Color Control – something like digital vibrance .
* Automatic Contrast Enhancement
*Skin tone correction
*Color space conversion
* Surface conversion (e.g. YUY2 -> NV12)
* Frame rate conversion.
Note that most are pure ASIC implementation and do affect CPU or EU utilization.
Other algorithms might have been added via kernels (shaders)

[CruNcher]

Egur i see it seems there is indeed a deinterlaced frame that doesn't got flaged as such and the adaptive deinterlacing catches it on EVR
yep that Latency i guess has something todo with the nature of EVR-CP there is a lot going on you could try Jan's current test builds and see if it lowers the latency.

Blight from the first looks just from the experience of it with different interlaced content it does a very good job also look @ what it does to this telecine clip http://forum.doom9.org/showthread.php?p=1526139#post1526139 :) where it catches that 1 fade very accurately of course as it is blended it's very hard to get that right.

Egur yeah that is the big + vs Nvidia/AMDs shader implementations having most important performance taking PP stuff aside of decoding/encoding Natively and adaptive :)

Though my first test with * Context adaptive sharpening didn't looked so good versus SharpenComplex2 PS implementation though obviously SharpenComplex2 almost kills the GT1 with High Resolution content but with SD (and for me i use it very unlikely anyways with HD content) it does a good job and the GT1 survives it easily there, the results from Intels Hardware Sharpening via the Control Panel doesn't look as good on the first sight with Heavy compressed streams (even pushing the slider to the edge) but obviously it does much better when you push it a not so compressed image then what SharpenComplex2 does then with it ;)

[egur]

CruNcher:
I looked closer at the problematic telecine-test.ts clip. Indeed it has several interlaced frames right where you said it has.
The fix isn't easy and I don't know if it will be in the next release. At least I root caused the problem. My fix will include a much quicker switch from telecined to non telecined material.
There' also the PAL telecining 24->25 frames by repeating the 24th frame, but it's low priority now.

I'm having issues with time stamps. Several clips produce out of order time stamps. Currently I take the 1st good (non garbage) time stamp and use it as a reference. Following time output stamps are derived from that first one. This isn't perfect and I'd like to know if anyone has a good (bulletproof) solution for this.

[nevcairiel]

I've never had any real issues with H264 or MPEG2 timestamps, they usually are rather consistent. (VC-1 is another matter, different splitters give different results, but there are luckily only 2 ways they do it)
If you just look at the incoming timestamps, they will of course be out of order, because those are presentation timestamps. They belong to the frame they are attached to, and frames are delivered in decode order, not in presentation order.

Any specific clip that gives you trouble?

[CruNcher]

I know that at least with MadVR, the reason for the option to disable Aero with fullscreen exclusive mode is that it makes the switch between exclusive/window mode faster.
Which is good and fine if you're running a standalone HTPC which never sees the desktop.

Cruncher:
I'm interested to see a visual comparison between SNB DeInterlacing and the NVIDIA/ATI/Software modes.
I believe the eric's plan is to look into adding the hardware deinterlacing support after the decoding is fully stable :)

egur:
What other PP does the SNB support? Denoise? Sharpen? Weren't you talking about facial color correction a while back?

Blight lets start with what the user currently sees and has direct access to, that are 7 types of Output configurations.

Color
Denoise
Sharpening
Telecine
Skin tone
Adaptive Contrast
Scaling


in that order the Denoise and Sharpening have a automatic setting and a manual one. Telecine has like the others (AMD/Nvidia) only a on/off (fully adaptive)

they are in the Media section with 3 different subsections in the UI (Color,Picture,Scale) and Deinterlacing being fully Adaptive like Telecine and only 1 Quality therefore is not configurable as well and not mentioned @ all in the UI (makes perfect sense).

Color:
http://img842.imageshack.us/img842/7931/colorie.png

Picture:
http://img716.imageshack.us/img716/950/pictureqo.png

Scale:
http://img840.imageshack.us/img840/4071/scaler.png

Everyone of these 3 Sections has 2 Preview Pictures to chose from (basic still picture)

CruNcher:
I looked closer at the problematic telecine-test.ts clip. Indeed it has several interlaced frames right where you said it has.
The fix isn't easy and I don't know if it will be in the next release. At least I root caused the problem. My fix will include a much quicker switch from telecined to non telecined material.
There' also the PAL telecining 24->25 frames by repeating the 24th frame, but it's low priority now.


Nice can't wait to see this in action :)

[egur]

I've never had any real issues with H264 or MPEG2 timestamps, they usually are rather consistent. (VC-1 is another matter, different splitters give different results, but there are luckily only 2 ways they do it)
If you just look at the incoming timestamps, they will of course be out of order, because those are presentation timestamps. They belong to the frame they are attached to, and frames are delivered in decode order, not in presentation order.

Any specific clip that gives you trouble?

The DC.ts is a good example:
Time stamps are fine when LAV's "Enable VC1 timestamp correction" is checked. Out of order otherwise (including the default 'auto' option) or when using MPC internal splitter. Haali splitter is also fine (although MPC-HC refuses to use it for mpeg2 transport for some reason).

I don't have access to the DShow graph from within my DLL to query the connected filters and from a design point of view I think it's a terrible idea to patch my code according to the connected filters. Ill behaved filters should be handled by the DShow decoder filter if at all. I'll do a more deep scan of my clips to see if non VC1 formats behave well enough.

nevcairiel:
BTW LAV Splitter produces incorrect (or inconsistent with other splitters) frame rates, interlaced or telecined clips receive 59.97 AvgTimePerFrame in the initial VIDEOINFOHEADER. This is very confusing.

[CruNcher]

The DC.ts is a good example:
Time stamps are fine when LAV's "Enable VC1 timestamp correction" is checked. Out of order otherwise (including the default 'auto' option) or when using MPC internal splitter. Haali splitter is also fine (although MPC-HC refuses to use it for mpeg2 transport for some reason).

I don't have access to the DShow graph from within my DLL to query the connected filters and from a design point of view I think it's a terrible idea to patch my code according to the connected filters. Ill behaved filters should be handled by the DShow decoder filter if at all. I'll do a more deep scan of my clips to see if non VC1 formats behave well enough.

nevcairiel:
BTW LAV Splitter produces incorrect (or inconsistent with other splitters) frame rates, interlaced or telecined clips receive 59.97 AvgTimePerFrame in the initial VIDEOINFOHEADER. This is very confusing.

Egur are these inconsistencies vanishing if you run it in Source mode ? so instead of the default File Source Async way ?
That is still a big difference to how the Internal MPC-HC splitter works and i saw major differences here especially with partly broken streams.
That also got fixed when running Lav Splitter in Source Mode instead of going through "File Source Async" first, especially with evil trees.ts.

[nevcairiel]

nevcairiel:
BTW LAV Splitter produces incorrect (or inconsistent with other splitters) frame rates, interlaced or telecined clips receive 59.97 AvgTimePerFrame in the initial VIDEOINFOHEADER. This is very confusing.

The information in that header is really not interesting.
Its usually just taken from the container, if its stored there. If not, it'll try to measure it. I would never assume that its 100% reliable with any splitter. Its more of a "hint" then a reliable source of information. Decoding must work without it, a media type is perfectly valid with it set to 0.
The measured values can be off, depending on how its encoded. But luckily, its only measuring it on MPEG-TS and similar formats, but MPEG-TS is tightly timestamped, so that the value is not needed to calculate missing timestamps.

MKV might contain timestamp gaps, but it does include a proper fps header in the container instead.

It never was a problem before for me.

PS:
Filters are not "ill behaved", there is just two ways to handle VC1. I believe i explained that in a PM before. There is PTS and DTS timestamps. MPC-HCs MPEG Splitter outputs PTS, Haali outputs DTS, LAV can output both, depending on which decoder is connected (and ffdshow expects PTS)
PTS timestamps would look out of order if you don't handle them properly, thats perfectly normal and valid. H264 and MPEG2 always use PTS.

To top the VC1 problem off, VC1 in MKV or in WMV only contains DTS, while MPEG-TS contains both DTS and PTS.

[egur]

CruNcher:
I use LAV/Haali/MPC splitters only as source filters.
BTW, I doubt if I can decode both evil_trees.ts and telecine-test.ts using a common logic. Both clips stop marking the frames as telecined (field doubling) mid playback. evil_trees.ts looks best if I don't drop out of IVTC immediately and telecine-test.ts looks bad no matter what I do, but only for a fraction of a second, almost impossible to notice. Even if i switch correctly back to interlaced, the renderer doesn't handle this well and shows the same frame 3 times and then 2-3 frames that should have been interlaced but have not.
Since both clips have identical behavior (same flags on the decoded frames) it's impossible to tell them apart. DGindex reports that evil trees is 12% interlaced, 88% film...
I'd like to hear your opinion on this.

nevcairiel:
How can I tell if get DTS or PTS, missing time stamps. Sounds like hell :)
Is there code for dealing with this some where?
To avoid license problems (is there a problem?), I can put the time stamp normalizing code in ffdshow, not in my DLL.
BTW expecting a valid value for AvgTimePerFrame is legit. A zero value might mean I need to measure (need a few frames to do so), but a wrong value is misleading. Microsoft's documentation doesn't say you can ignore this value.

[nevcairiel]

Even if its legit, its not required. Just use the timestamps you get from the source filter, thats what they are for! :)

Zero AvgFrameTime means it could as well be variable frame rate, which sounds like your code would crash and burn with.
The fun about VFR is that it will most likely not be 0, it'll probably be whatever frame rate the first segment is.

@timestamps in general:

I'm sure the MSDK offers an ability to handle timestamps by itself. This will probably be fine with all PTS timestamps. At least thats the case with NVIDIAs API and DXVA2.
Just for DTS timestamps, you need to manually map the incoming times to the outgoing frames. Since the number of frames coming in and going out is usually the same, that shouldn't be much of a problem. I have that implemented in LAV Video using a FIFO buffer for the CUVID decoder (because i don't know its exact processing delay), and a fixed circular buffer in the avcodec decoder (because there i know its exact decoding delay).

[egur]

@timestamps in general:

I'm sure the MSDK offers an ability to handle timestamps by itself. This will probably be fine with all PTS timestamps. At least thats the case with NVIDIAs API and DXVA2.
Just for DTS timestamps, you need to manually map the incoming times to the outgoing frames. Since the number of frames coming in and going out is usually the same, that shouldn't be much of a problem. I have that implemented in LAV Video using a FIFO buffer for the CUVID decoder (because i don't know its exact processing delay), and a fixed circular buffer in the avcodec decoder (because there i know its exact decoding delay).

First, I really appreciate your help. Thanks.
Is there a 1:1 relation between samples coming in and frames coming out?
e.g. is every media sample a single frame, or a frame can be divided into an arbitrary number of samples. This will make mapping time stamps impossible.

[nevcairiel]

In theory, both is possible, to some extend.

In reality, VC1 and H264 are usually always one sample=one frame, MPEG2 might be split over multiple data samples.

[egur]

New and improved version. Zip files contains installer documentation, please read.

Download version 0.14 alpha:
32 bit http://www.multiupload.com/LPX2JXB06S
64 bit http://www.multiupload.com/8H7ZPV5XKC
Source code http://www.multiupload.com/AXET69LL3P

Revision highlights:
v1.14:
* Created ffdshow installer. Installer will default to enabling the Intel QuickSync decoder on new installations.
* More speed optimizations. CPU is at its lowest frequency during playback with very low utilization. 2-3% on desktop and 5-6% on mobile. Mobile lowest frequency is half of desktop (800/1600).
* Fixed handling of interlaced content which is encoded as progressive frames.
* More robust and faster codec initialization

[Atak_Snajpera]

Are you going to merge your code with official builds? I'm asking because there is zero movement at the moment in ffdshow :( Only libav is currently being updated. That's all.

[egur]

Are you going to merge your code with official builds? I'm asking because there is zero movement at the moment in ffdshow :( Only libav is currently being updated. That's all.

That's the idea. I wanted to get a minimum feature set working and I'm very close to it. clsid was very skeptic I could pull this off because of the memory copying involved, but this part is now solved :)
I'll contact clsid again and push things forward.

BTW, did you try my build? It should improve Avisynth performance when ffdshow is used as a decoder.

[millercentral]

I know this effort has been focused around ffdshow, but does anyone know of any similar efforts to enhance the ffmpeg encoding library for QuickSync? I would love to see this for transcoding improvements...

[Blight]

millercentral:
Eric said he'll wrap this up in a nice DLL.
From there, ffmpeg coders should be able to integrate with little effort.

[clsid]

Hi Eric,
I haven't tested your build yet, but here are a few questions:
- How are multiple instances of the decoder handled? I assume the HW can only handle a certain amount of streams at once. Will ffdshow simply fail graph connection for instance N+1, will it fall back to software mode (libavcodec), or will it crash and burn?
- This only work on Sandy Bridge, and future similar CPUs?
- Does it work if a mobo doesn't use the integrated GPU? Or if disabled in BIOS? Or if no monitor is attached?

I can give you SVN access if you want. Then you can commit it when deemed stable and also perform updates and fixes.

[ajp_anton]

How can I make the QS decoder ignore unsupported streams (10bit, 4:4:4 chroma, lossless etc) and let for example LAV take care of it?

[egur]

- How are multiple instances of the decoder handled? I assume the HW can only handle a certain amount of streams at once. Will ffdshow simply fail graph connection for instance N+1, will it fall back to software mode (libavcodec), or will it crash and burn?
There should not be a (practical) limit. I can modify ffdshow to revert to libavcodec if initialization fails. Most likely that the platform will run out RAM before this happens.

- This only work on Sandy Bridge, and future similar CPUs?
Correct, that’s guarantied. It might work on small core processors in the future (Atom), no promises.
The user has the option to use this decoder or not via the standard ffdshow config. Just like other decoders (e.g. wmv9).
- Does it work if a mobo doesn't use the integrated GPU? Or if disabled in BIOS? Or if no monitor is attached?
BIOS must enable the IPG as the driver will not load. IGP driver must be loaded and enabled. This is not a problem. My own system has an AMD 6950 Radeon on an h67 chipset MB.
DirectX will not enumerate the IGP if a screen is not connected to it (it enumerate only the displays).
Current version needs to have either the IGP connected to a screen or have switchable graphics or Lucid Virtu is installed and configured to bind the media players to the IGP.
A VGA dummy can also be used.
I’m in the process of enabling the HW acceleration without the above hacks.

I can give you SVN access if you want. Then you can commit it when deemed stable and also perform updates and fixes.
That would be great! Please send me instructions by mail if there’s any kind of procedures I’m required to follow.

[egur]

How can I make the QS decoder ignore unsupported streams (10bit, 4:4:4 chroma, lossless etc) and let for example LAV take care of it?

The QS decoder will fail to initialize on such streams. The idea is to have ffdshow fallback to libavcodec and that fails to notify the graph/player on connection failure. The player can then load another filter (e.g. LAV). That's the most elegant way to do it as far as I can see.
Future HW might (or not) support these stream types.
It would help if you pointed me to such streams for testing purposes, or to a guide on how to transcode to these formats.

[gvaley]

Reading the news in AnandTech really raised my hopes but they were to quickly plunge after I read egur's full post.

Not to say this initiative isn't commendable, but what I (and the rest of the world) would like to see is a true open source port of the SDK available to all OSes. This would enable the ffdshow, mplayer, VLC, you name it guys to build both encoding and decoding code into their projects and really put QuickSync to good use.

[jakmal]

The QS decoder will fail to initialize on such streams. The idea is to have ffdshow fallback to libavcodec and that fails to notify the graph/player on connection failure. The player can then load another filter (e.g. LAV). That's the most elegant way to do it as far as I can see.
Future HW might (or not) support these stream types.
It would help if you pointed me to such streams for testing purposes, or to a guide on how to transcode to these formats.

Eric,

You can find a 10b H264 file at this location:

http://dl.dropbox.com/u/15890479/480p_H264.mkv

Regards
Ganesh

[egur]

Reading the news in AnandTech really raised my hopes but they were to quickly plunge after I read egur's full post.

Not to say this initiative isn't commendable, but what I (and the rest of the world) would like to see is a true open source port of the SDK available to all OSes. This would enable the ffdshow, mplayer, VLC, you name it guys to build both encoding and decoding code into their projects and really put QuickSync to good use.

Agree, but before an open source SDK, you'll need driver support. BTW I'm not an expert on the driver, most of my knowledge is public knowledge.
* Linux has a very basic driver. I'm not aware of a video acceleration API (like DXVA).
* Mac OS X driver is developed by Apple not Intel (with Intel support of course and probably full disclosure of Windows driver code). Apple controls the driver API and functionality, because they own the OS (like Microsoft owns D3D & DXVA APIs).

Making a cross platform video acceleration SDK without a proper VA API is probably possible but would require bypassing the DXVA API and communicating in an alternative way with the driver. This usually requires a consent from the OS vendor (Microsoft & Apple) - not an easy task.
The best solution would be to have an open standard for video acceleration that would be accepted by all OS vendors (like OpenGL, OpenCL).

I believe the media SDK will be ported to other OSes in the future, so my code will be a good start point for understanding how to utilize it. My only "Windows" specific code is dealing with the memory GPU allocations, but this can be abstracted by the SDK.

Having an open source SDK is not really a must. The Intel Media SDK is free to use and you also have a large company backing it up. The SDK abstracts the HW enough so that the code is future proof.

[nevcairiel]

Funny that you would say "VA API"

Linux has a API which is supported by Intel, its called simply "VA API (http://en.wikipedia.org/wiki/Video_Acceleration_API)". It was designed by Intel initially, but AFAIK you can get adapters to run hwaccel through VAAPI on other GPUs as well these days.

[egur]

Eric,

You can find a 10b H264 file at this location:

http://dl.dropbox.com/u/15890479/480p_H264.mkv

Regards
Ganesh

Thanks

[nm]

Agree, but before an open source SDK, you'll need driver support. BTW I'm not an expert on the driver, most of my knowledge is public knowledge.
* Linux has a very basic driver. I'm not aware of a video acceleration API (like DXVA).

The current driver is much more than basic. As nevcairiel pointed out, Intel supports hardware-accelerated decoding on Linux through VAAPI: http://intellinuxgraphics.org/h264.html

There's also initial encoding support through libva, but I haven't heard anyone outside Intel having tested it yet.

[clsid]

The QS decoder will fail to initialize on such streams. The idea is to have ffdshow fallback to libavcodec and that fails to notify the graph/player on connection failure. The player can then load another filter (e.g. LAV). That's the most elegant way to do it as far as I can see.
Future HW might (or not) support these stream types.
It would help if you pointed me to such streams for testing purposes, or to a guide on how to transcode to these formats.
Have a look at ffglobals.cpp. There is SPS parsing code there that is currently used for checking if a stream is supported. Maybe you can also fix the code to no longer depend on the libavcodec golomb stuff.

Send me a PM with your SourceForge username and I can give you commit rights.

[egur]

The current driver is much more than basic. As nevcairiel pointed out, Intel supports hardware-accelerated decoding on Linux through VAAPI: http://intellinuxgraphics.org/h264.html

There's also initial encoding support through libva, but I haven't heard anyone outside Intel having tested it yet.

Good to know. I'm currently trying to make a good Windows based decoder that's easy to integrate. Cross platform code will be available once Media SDK supports it.

[CruNcher]

This issue might be not easy to find egur, currently ffdshow-quicksync has a tendency to silently selfdestruct :( after a lot of streams continuously loaded in MPC-HC it dies and MPC-HC falls @ the next stream then back to another Decoder :( ffdshow-quicksync wont load anymore after until MPC-HC is restarted it isn't a specific stream it seems already changing streams fast without unloading them can trigger this, like in MPC-HC drag & drop while another stream is still loaded.
Another problem though here is MPC-HC cant cleanly unload dshow filter when a file is closed the filter is still acquired not sure though if that has something todo with ffdshow-quicksync currently braking after a while. Though maybe it's also a memory leak i didn't looked into that yet.


http://www.mediafire.com/download.php?ri4sdpjlafxxrry <- hangs (@ the cat) when the lion scene should follow (with both lav splitter and mpc-hc).

Btw the 4:2:2 Mpeg-2 Fallback already works perfectly in combination with Lav Video :)
Only High10, High422 and X264 losless fail

[vivan]

Some problems when choosing russian language in installer:
http://2.firepic.org/2/images/2011-10/01/mauicafzgk79.png
http://2.firepic.org/2/images/2011-10/01/vzuvye7g62o1.png
http://2.firepic.org/2/images/2011-10/01/t5vo2z4dznm3.png
But with regular ffdshow everything is ok...

[jmone]

Well done egur, I have had good success testing this on my i7-2600K and it worked pretty well with little issues on dropping frames etc with madVR. I did not have a good result however with interlaced HD material when compared with LAV CUVID. LAV CUVID would output frame doubled material that looks great at both 50 and 59.94 where as the intel version is pushing out 25 and 29.97 frames respectively and the interlaced fields as easily visible. Also on one VC-1(i) clip (Eagles Farewell Tour muxed to M2TS) there were also bouts of video corruption that seemed to be related to scene changes.

Great start!
Thanks
Nathan

[nevcairiel]

It does not deinterlace at all yet, thats why you see the interlacing artifacts, and only get 25/29.97 fps. :p

[jmone]

That would explain it! I'll be very intersted to see if the IGP is fast enough to handled 50/60fps in madVR when/if deinterlacing works as the rendering times already look high(ish) compared to the 550Ti.

[ajp_anton]

Did some speed testing on a Blu-ray video (Pixar's Day&Night).
i7 2600K. CPU at 4000MHz, GPU at 1700MHz
I also looked at the CPU power draw readings, don't know how accurate they are, and they are fluctuating a bit...


decoder speed(fps) power(W)
ffdshow (QuickSync) 460.4 33**
LAV video 326.1 90
ffdshow 287.0 86
LAV video (1 thread) 67.9 48
ffdshow (1 thread) 66.6 48

ffdshow (QuickSync) 24 12*
LAV video 24 15*
ffdshow 24 15*

** CPU at 1600MHz, GPU at 1700MHz
* CPU at 1600MHz

[egur]

decoder speed(fps) power(W)
ffdshow (QuickSync) 460.4 33**
LAV video 326.1 90
ffdshow 287.0 86
LAV video (1 thread) 67.9 48
ffdshow (1 thread) 66.6 48

ffdshow (QuickSync) 24 12*
LAV video 24 15*
ffdshow 24 15*

** CPU at 1600MHz, GPU at 1700MHz
* CPU at 1600MHz


These are very good numbers. I didn't have the time to measure power yet. I think power would be better if the GPU wasn't overclocked so high, but 20% savings on 1080p@24 is a good start point.
Interlaced content should provide better results (than SW implementations) when using the EVR as it uses the HW deinterlacer.

Well done egur, I have had good success testing this on my i7-2600K and it worked pretty well with little issues on dropping frames etc with madVR. I did not have a good result however with interlaced HD material when compared with LAV CUVID. LAV CUVID would output frame doubled material that looks great at both 50 and 59.94 where as the intel version is pushing out 25 and 29.97 frames respectively and the interlaced fields as easily visible. Also on one VC-1(i) clip (Eagles Farewell Tour muxed to M2TS) there were also bouts of video corruption that seemed to be related to scene changes.

Great start!
Thanks
Nathan

Thanks.
As nevcairiel pointed out, LAV Video decoder doesn't deinterlace the video. I also do not deinterlace, it's the job of the renderer. If I incorrectly flag a clip as progressive, please share it to help me fix the problem.
EVR uses HW deinterlacing and produces 50-60fps. That's the most stable renderer ATM.
MadVR compatibility is on my TODO list.
VC1 is a little problematic and I've seen corruption in some clips. I do not know the root cause of the problem (HW, driver, media SDK) but it's being dealt with by the Media SDK team. I hope a solution will come promptly. If you provide/share a short sample of the corrupted scene it would help.

I want to thank everyone for providing valuable feedback, this is the highway to a stable product and a good reference for other products.

[leomax]

Keep up the great job egur.
Would it be possible to use this in a notebook with switchable graphics (optimus)?

[egur]

This issue might be not easy to find egur, currently ffdshow-quicksync has a tendency to silently selfdestruct :( after a lot of streams continuously loaded in MPC-HC it dies and MPC-HC falls @ the next stream then back to another Decoder :( ffdshow-quicksync wont load anymore after until MPC-HC is restarted it isn't a specific stream it seems already changing streams fast without unloading them can trigger this, like in MPC-HC drag & drop while another stream is still loaded.
Another problem though here is MPC-HC cant cleanly unload dshow filter when a file is closed the filter is still acquired not sure though if that has something todo with ffdshow-quicksync currently braking after a while. Though maybe it's also a memory leak i didn't looked into that yet.

I managed to reproduce the drag & drop causing a freeze to MPC-HC. ffdshow.ax stay resident in memory but my decoder DLL is unloaded. Looks like some kind of race condition. Almost impossible to debug a this doesn't occur if I place breakpoints :(
I couldn't reproduce with ZoomPlayer, maybe MPC-HC is handling the loading differently. If I knew how, I could find a solution. Unless I'm wrong here, this is a low-medium priority bug. If an MPC-HC developer can give a hint that would help.
I scanned for memory leaks and fixed them (for next release). They were minor and didn't affect anything.


http://www.mediafire.com/download.php?ri4sdpjlafxxrry <- hangs (@ the cat) when the lion scene should follow (with both lav splitter and mpc-hc).

Btw the 4:2:2 Mpeg-2 Fallback already works perfectly in combination with Lav Video :)
Only High10, High422 and X264 losless fail
The crash/hang is actually a critical bug in my code - fixed.

Regarding the various H264 formats I now filter them within ffdshow and fallback to libavcodec silently.

[egur]

Keep up the great job egur.
Would it be possible to use this in a notebook with switchable graphics (optimus)?

One report said it works. I don't have a system to check myself.
Please try and let me know.

[CruNcher]

I managed to reproduce the drag & drop causing a freeze to MPC-HC. ffdshow.ax stay resident in memory but my decoder DLL is unloaded. Looks like some kind of race condition. Almost impossible to debug a this doesn't occur if I place breakpoints :(
I couldn't reproduce with ZoomPlayer, maybe MPC-HC is handling the loading differently. If I knew how, I could find a solution. Unless I'm wrong here, this is a low-medium priority bug. If an MPC-HC developer can give a hint that would help.
I scanned for memory leaks and fixed them (for next release). They were minor and didn't affect anything.


The crash/hang is actually a critical bug in my code - fixed.

Regarding the various H264 formats I now filter them within ffdshow and fallback to libavcodec silently.

I asked Jan if he might have an idea, about the fallback so it's falling back to the Internal ffdshow libav not to the dshow chain right, could you maybe add a switch to let the user chose if he prefers internal/external in such a fallback case ?

[jmone]

Here is the first 1:20 of the VC(i) clip with showing the corruption that comes and goes --> http://www.megaupload.com/?d=40NY4V2C

Deinterlacing: For me the great benefit of LAV CUVID is not the decoding as much as that you get the best deinterlacing I've ever seen (for supported formats). It really is very very good and puts to shame anything that EVR or FFDSHOW/YADIF can do. Are you saying that access to GPU deinterlacing will not be part of the Intel GPU Video Decoder?

Integration with LAV Video: I know that nevcairiel has hinted that your project may be accessible from LAV Video (as an alternative to FFDSHOW) or am I reading this incorrectly? & if not any timeline?

Thanks again.

[Blight]

jmone:
I believe deinterlacing and other PP effects will be added once general-playback is considered stable.

[CruNcher]

jmone
Yes as egur stated already your issue is known and it's up to the Driver and Media SDK team @ Intel now to fix it and hopefully it is fixable @ all but also Nvidia fixed it so it seems to be doable without any ASIC replace, especially these Asics aren't so basic as they where years ago they are partly programmable nowdays, or like Nvidia did for a Mpeg-2 implementation bug just using the EUs to workaround the " hardware bug" in the hardest case (though Intels action space is smaller for this EU workarounds, being not so powerful).
But im very confident the Intel Engineers gonna find a way to fix this Problem one or another way :)

Also im sure Intel knows about this problem since some time now, as it hardly can be that none of the Top 4 ISVs (Mainconcept, Arcsoft, Cyberlink, Corel) gave that feedback already from their customers that experience this issue to Intel, just the pressure gets higher the more reports flowing in about this :)
Btw It took Nvidias Engineers 1 Driver cycle to fix this back then ;)

[egur]

jmone:
I believe deinterlacing and other PP effects will be added once general-playback is considered stable.

Correct. One thing at a time.

[pulbitz]

I'm sorry. I don't speak English very well.

sample files
http://www.mediafire.com/?sem1jx36pnnae2i or http://www.multiupload.com/VJPU41ELBI

file: slow video.20100518.직캠.서울시립대학교 축제.아이유(IU) - Boo.flv
file: slow video.20110516.S-OIL.TV-CM.즐거운 세상 만드는 좋은기름 1리터의 힘.20초.아이유(IU).RAiN.ts
quicksync is slow motion. libavcodec is OK.

file: can't decode.20101006.직캠.숭실대 얼Ssu!.6.아이유(IU) - 멘트.mkv
quicksync can't decode video(720x1280).
if HW can't decode it, then need fallback to libavcodec.

[egur]

file: slow video.20100518.직캠.서울시립대학교 축제.아이유(IU) - Boo.flv
file: slow video.20110516.S-OIL.TV-CM.즐거운 세상 만드는 좋은기름 1리터의 힘.20초.아이유(IU).RAiN.ts
quicksync is slow motion. libavcodec is OK.

file: can't decode.20101006.직캠.숭실대 얼Ssu!.6.아이유(IU) - 멘트.mkv
quicksync can't decode video(720x1280).
if HW can't decode it, then need fallback to libavcodec.

Issue 1: Slow decode (Boo.flv). Root caused to several splitters not sending frame rate (defaulting to 24fps) - will be fixed in next release (I'm working hard on stabilizing the time stamps and identify frame rate :( ).
Unfortunately, I haven't locks on a good algorithm that takes care of all the corner cases. LAV decoder's solution for time stamp handling is working according to nevcairiel but I don't want to use it as it involves querying the filter graph and needs some meta data I don't have. I want to make a standalone algorithm independent from DirectShow - rely only on the time stamps given at input and outputted by the Media SDK decoder API. I may release a less than perfect implementation in order for other fixes to surface.

Issue 2: Slow decode (Oil TV.ts). The clip has inverse telecine flags at the beginning of the clip. Due to a bug, the QS decoder stays locked at 23.97. This fix will be solved with issue 1.

Issue 3: Can't decode. A duplicate bug reported by CruNcher. Already fixed in my code. Will be in next release - hopefully this week.


pulbitz - thanks a lot of the feedback!

[egur]

CruNcher:
The CPU utilization seems a little high.
During my testing on both desktop and laptop CPUs, during playback the CPU frequency would drop to a minimum (1600MHz for desktop and 800MHz for mobile) with single digit CPU utilization.
It's obvious that (unnecessary) surface conversion is going on not sure why. Did you use the standard EVR?

[CruNcher]

It cant drop lower because im using High Performance to keep overall system latency low as possible (but you right @ the beginning i used Balanced) :) and nope this is EVR-CP (Deinterlacing completely lost but different capabilities for Higher Quality output) and im not sure whats going on especially that YUY2 conversion seems to hit (its using in both cases billinear 2.0 ps for the scaling) still it does better then @ the beginning so that progress i wanted to visualize but still config stuff changes :P Though that the OSD for MPC-HC main gets differently rendered (blur) im not sure what causes this (could be either one of the Microsoft D2D or Intel Driver update)

Also my experience is SB is so efficient itself that clock changing doesn't impact power consumption much @ all and not very useful for a Desktop, we aren't in the early days of C&C and Speedstep anymore where you could save tons of watts, the whole Power Management from the lowest (cpu,chipset), middle (bios) up to the highest (OS) level is already efficient even running @ High Performance ;)

PS: Also keep in mind i didn't compared yet EVR-CP (Bicubic PS 2.0) vs the Hardware Scaling used on EVR by Intels Driver yet (i got a quality idea of the Deinterlacing, IVTC and Sharpen PP so far but not how the Adaptive Scaling off different content works out compared to a hardcoded Bicubic PS approach running over the EUs).


Ok here is the current state 32 bit (Balanced) :)

ffdshow-quicksync 0.14 Alpha

http://img27.imageshack.us/img27/7227/rocks32bitffdbicgpu.png

Cyberlink DXVA (Worlds most efficient DXVA Decoder)

http://img849.imageshack.us/img849/6203/rocks32bitdxvabicgpu.png

Please dont ask why the OSD is so blurred i have no idea what changed this (it's the same build and settings as the first day test of ffdshow-quicksync, just the system around changed Driver and Subsystems and also the Scaling is by default now Bicubic PS 2.0 im not sure anymore what i used on the first day test, but it is in now way responsible for the blur) (Microsoft Optional D2D Patches for fixing problems with IE9) that could cause this) :(
Feel free to tell if you have any idea or have this same issue with the OSD currently on Intel Graphics and the Main MPC-HC builds with EVR-CP :)

So this is how ffdshow-quicksync started its a big improvement :)

http://img835.imageshack.us/img835/4941/ffdshowquicksyncomgover.png

[egur]

...
PS: Also keep in mind i didn't compared yet EVR-CP (Bicubic PS 2.0) vs the Hardware Scaling used on EVR by Intels Driver yet (i got a quality idea of the Deinterlacing, IVTC and Sharpen PP so far but not how the Adaptive Scaling off different content works out compared to a hardcoded Bicubic PS approach running over the EUs).

Bicubic is not good enough when scaling factors are high (>2), the image is a little blurry. Bilinear shouldn't be used for anything as it creates horrible scaling artifacts.
The SNB HW scaler has the capability to downgrade to Lanczos4, Lanczos3, Lanczos2 and all the bicubic variants. I'm not sure if the driver supports any of these modes though, but I'll check. It makes sense to utilize it in any case.

A few questions for everyone:
* Does the EVR have an interface to configure the scaler quality?
* Is the EVR-CP the same one supplied with Media SDK 4.0b4 (they have the same file name)?
* A tough one - does anyone know how to create a virtual adapter - so DXVA can enumerate a GPU not connected to a screen?

[CruNcher]

Btw i also lost Microsofts DTV Decoder for this file im also not sure yet why but it doesn't connect anymore, anyways for DXVA Cyberlink is the best choice so i added this to have a compare vs DXVA (it showed me that a lot of times in the past even in very picky situations where others DXVA implementations fail it keeps stable and performant throughout different DSPs, and just recently on a NT 6 test it showed again superior results when testing CoreCodecs new Implementation) :)

Egur all of these are very good questions :)
1. Somehow their must be else how should the driver have the possibility to manipulate EVR directly in terms of IVTC, Deinterlacing and Sharpen :P though i guess from the lower level it's not really documented @ all, so most probably only from the Driver Kernel Level ?
2. In theory Intel could have borrowed MPC-HCs version for their samples indeed ;)
3. Yea there must be a way, though im not sure if this was done for security reasons too in terms of the Protected Media Path, hmm if Lucids Virtu is in dgpu mode though Quicksync can be still used also can't it ? so they must have found a way (or does encoding work only in igpu mode ?) :D

[JanWillem32]

I managed to reproduce the drag & drop causing a freeze to MPC-HC. ffdshow.ax stay resident in memory but my decoder DLL is unloaded. Looks like some kind of race condition. Almost impossible to debug a this doesn't occur if I place breakpoints :(
I couldn't reproduce with ZoomPlayer, maybe MPC-HC is handling the loading differently. If I knew how, I could find a solution. Unless I'm wrong here, this is a low-medium priority bug. If an MPC-HC developer can give a hint that would help.I'm quite familiar with the MPC-HC graph builder and related parts. There are several initialization problems. I'm currently evaluating two fixes for problems that are indeed causing race conditions (and a scaling bug for DVD menus). I'm also looking at possibilities for seamless playback. The default settings for debugging MPC-HC are okay for a quick checkup on a project, but not for core debugging of renderers, profile-guided optimization, assembly checkup, et cetera.

Bicubic is not good enough when scaling factors are high (>2), the image is a little blurry. Bilinear shouldn't be used for anything as it creates horrible scaling artifacts.
The SNB HW scaler has the capability to downgrade to Lanczos4, Lanczos3, Lanczos2 and all the bicubic variants. I'm not sure if the driver supports any of these modes though, but I'll check. It makes sense to utilize it in any case.

A few questions for everyone:
* Does the EVR have an interface to configure the scaler quality?
* Is the EVR-CP the same one supplied with Media SDK 4.0b4 (they have the same file name)?
* A tough one - does anyone know how to create a virtual adapter - so DXVA can enumerate a GPU not connected to a screen?The basic VMR and EVR property pages can be called when the appropriate DLL files are registered for it (proppage.dll and evrprop.dll, separate versions exist for x86 and x64).
For reading the additional EVR-CP mixer settings, querying the mixer interface is required. The same rule applies for applying most settings. As for the scaling quality, I've simply assumed it's always bilinear coming out of the scaling by VMR and EVR judging by the type of square or rectangular scaling artifacts and blur.

As for the variants of custom renderers, MPC-HC has one. It's completely shared between the VMR-9 r., EVR-CP, RealMedia DX9 and Quicktime DX9 mixers. EVR Sync contains a nearly 1:1 copy of that code. It evolved from the DirectX 7, then 8 renderer that was there before it. I never liked it.

When I decided that I could come up with something better, I dumped the renderer core and started developing: http://forum.doom9.org/showthread.php?t=161047 .
In the beginning, the renderer wouldn't work properly at all, but I'm slowly making progress over time. Once I've finally figured out how to receive the raw bits from a DirectShow pin (or if anyone would help with that part), I'll also add a custom mixer in time to replace the "borrowed" mixers. I'm already trying to disable all possible built-in filters of the mixers and making implementations of useful filters in the custom renderer core. That includes all resizing options (currently doesn't always work for disabling chroma filtering, though). The handling of deinterlacing at the mixer level is an abomination, by the way.

A few virtual DirectX 9 COM pointer functions can be derived from a DirectX 10/11 device, but that's for expert-level DirectX programmers. The resource management is difficult.
For DirectX usage without a screen, look into DirectX 10.1 and 11 DirectCompute. Else, just ignore the implicit swap chain completely and set the window handle to invisible.

I can assist with debugging. I can upload a full source code of what I'm working on, explain the debug methods for some parts and help with other things in my field of expertise.

[CruNcher]

Something is strange im trying ffdshow-quicksync with MPC-HC test and their is some strange thing going on with the Internal OSD not the one of MPC-HC but the one of ffdshow and Colorspaces, if the OSD is off the output from ffdshow-quicksync is NV12 as it should be and if i enabled the OSD while playback it stays @ NV12 but if i leave the OSD on now and reopen the file the output from ffdshow-quicksync changes to YV12 ?????

Happens also with the normal MPC-HC so it seems to be a ffdshow thing.


Open the OSD while playback:

http://img829.imageshack.us/img829/6356/firstcall.png

OSD still enabled on next file open:

http://img692.imageshack.us/img692/3042/nextcalls.png

[JanWillem32]

Both NV12 and YV12 are valid types for transporting progressive Y'CbCr 4:2:0 video, but it's indeed a bit odd that the type changes on re-opening. The mixer input format is a bigger problem: "YUY2" indicates format conversion to an incompatible type.
Can you take a look at the output pins of the video parts in the "Play", "Filters" menu? Neither EVR or VMR-9 should ever use a YUY2 input pin if NV12, YV12, IYUV or I420 is offered. A problem factor can be insertion of the color space converter filter.
You can get a full graphic overview of the DirectShow playback chain with GraphEdit. Simply use "Connect to Remote Graph...". You might be able to find out things easier when using that interface.
For an overview of all supported video decoder and processor types, with and without deinterlacing, see DXVAChecker. If there are no compatible processor types for Y'CbCr 4:2:0 video, we will have to take a look at the options for color space conversion to a more proper type than YUY2.

[CruNcher]

Hmm it remembers me that ffdshows NV12 implementation might be buggy anyways if your mixer cant recognize it there where some heavy issues with it's NV12 when put into a full Hardware decoding chain without any conversions (it crashed the whole rendering) of Nvidias Nvcuvid it's a little problematic to repeat that test with the Quicksync Decoder though as ffdshow is now a part of it ;)

http://forum.doom9.org/showthread.php?p=1501021&highlight=ffdshow#post1501021


PS: I cant connect to the remote graph tried both with Elevated Admin rights (Graphstudio 64, MPC-HC Tester 64) but it doesn't connect, i see the Graph but it wont connect nothing happens if i push connect the Graph isn't loaded.
And with Graphedit 64 from the Windows SDK it doesn't even shows any Graph to connect to @ all :(

http://img21.imageshack.us/img21/6775/hmmcantconnect.png


Here it is (this is a mockup i wish MPC-HC would be finally able to do this window multitasking without interrupting its workflow ;))

http://img847.imageshack.us/img847/2908/evrcpffdshow.png

[nevcairiel]

ffdshows problem is with raw NV12 input, and the problem is quite obvious if you get it.

[egur]

ffdshow has issues with NV12 - libavcodec bug actually. It crashes when copying NV12 surfaces in some cases. ffdshow has an alternative method which works fine - that's what I used.
Regarding the connection issues with MPC-HC. It should be fixed for the next release. I'm almost done with the time stamp code fix so a release is very close. Probably last release before integration with ffdshow's official code base.

[egur]

A few virtual DirectX 9 COM pointer functions can be derived from a DirectX 10/11 device, but that's for expert-level DirectX programmers. The resource management is difficult.
For DirectX usage without a screen, look into DirectX 10.1 and 11 DirectCompute. Else, just ignore the implicit swap chain completely and set the window handle to invisible.


Thanks for the explanations, but I need a DirectX adapter to be enumurated for a screen less adapter. Otherwise the Media SDK will not initialize.
Do you know why the EVR CP drops frames? There's plenty of compute headroom and it falls to ~30fps, dropping about half the frames.

[CruNcher]

@jan

is it possible to keep this active by default for EVR-CP (or selectable via the EVR-CP config tab,or even better directly in the Menu Options bound to the stop graph call it needs) ? it works but it disables itself after a close and you have to enable it again (would be much easier to have access via the normal menu for on demand usage) :(

http://img267.imageshack.us/img267/826/evrpropkeepactive.png

That seems to be Intels Hardware Deinterlacer

And this Intels IVTC

http://img845.imageshack.us/img845/9980/intelivtc.png


The Deinterlacer depending on the Interlaced frames config though fails sometimes in terms of motion results (i wonder if it does any frame analyzing @ all as it shows NumForwardRefSamples = 0 NumBackwardRefSamples = 0) but better then nothing if no flag is available combined with the flag call from the decoder, it seems a nice combo, and it doesn't really seem to hit the progressive frames :)

I wonder if its possible to get access to the Denoiser (NoiseFilterTechnology) and Sharpener (DetailFilterTechnology) also via this DXVA2 interface it suggests so :)

[JanWillem32]

Thanks for the explanations, but I need a DirectX adapter to be enumurated for a screen less adapter. Otherwise the Media SDK will not initialize.
Do you know why the EVR CP drops frames? There's plenty of compute headroom and it falls to ~30fps, dropping about half the frames.If you're trying to use the internal VSync and/or flush functions, you'll see that the GPU will be doing nothing about half of the time. These functions are made to flush the command cue, hold the GPU and the paint thread (on the CPU) inactive until the estimated next VBlank period, and then call a present. After the present call, the paint sequence for the next frame is stalled for a while, until the scheduler is sure that the next frame won't be presented early. In that time the presenter thread and GPU are idle.
A normal renderer never flushes and rarely stalls, except for reset and world transition situations. It's pretty normal to allow up to about 3 fully rendered frames in a queue.
The trunk MPC-HC build renderer also can't properly queue even basic drawing sequence commands, let alone queue entire frames.
For the first question, are you looking for the IDirect3D9 adapter functions? http://msdn.microsoft.com/en-us/library/bb174300%28v=VS.85%29.aspx
When creating a DX9 or DX9Ex device, the default adapter is always given the number 0. Don't forget to give a private HWND input pointer if you intend to make the window invisible (don't use the one of the main window). An ignored swapchain will generally be 1×1 in size, and have a single back buffer, that is never used. Not creating an implicit swap chain is not allowed under DirectX 9.
I'm looking forward to your fixes, I'll keep an eye on this thread to see if I can help with anything.

@CruNcher: Video processor devices are registered by the display driver and are also handled by the display driver in the external EVR mixer phase, as a black box to the video application. There are some options the video application can set, but most items are are vendor-specific and many settings are simply ignored when initializing the external mixer. Graphics drivers should have a tab for video options in their control panel.
I was already not amused by setting up the color controls for EVR on the Miscellaneous page. These sort of controls won't ever work for RGB input types, are a duplicate of those in most recent control panels and most importantly, are not transparent to the user what software is responsible for executing this filter (not the video player itself in this case). That's why I'm against integrating these sorts of controls in MPC-HC.
In the pictures you see the debug window for the loaded EVR filter. It doesn't keep settings. It's the graphics driver's job to write out defaults and settings to the registry, and in the the case of interlacing types, even for several scenarios. Remember that the vanilla EVR also doesn't come with a regular settings panel for these sorts of things, too.

[egur]

If you're trying to use the internal VSync and/or flush functions, you'll see that the GPU will be doing nothing about half of the time. These functions are made to flush the command cue, hold the GPU and the paint thread (on the CPU) inactive until the estimated next VBlank period, and then call a present. After the present call, the paint sequence for the next frame is stalled for a while, until the scheduler is sure that the next frame won't be presented early. In that time the presenter thread and GPU are idle.
A normal renderer never flushes and rarely stalls, except for reset and world transition situations. It's pretty normal to allow up to about 3 fully rendered frames in a queue.
The trunk MPC-HC build renderer also can't properly queue even basic drawing sequence commands, let alone queue entire frames.
For the first question, are you looking for the IDirect3D9 adapter functions? http://msdn.microsoft.com/en-us/library/bb174300%28v=VS.85%29.aspx
When creating a DX9 or DX9Ex device, the default adapter is always given the number 0. Don't forget to give a private HWND input pointer if you intend to make the window invisible (don't use the one of the main window). An ignored swapchain will generally be 1×1 in size, and have a single back buffer, that is never used. Not creating an implicit swap chain is not allowed under DirectX 9.
I'm looking forward to your fixes, I'll keep an eye on this thread to see if I can help with anything.

Thanks for the explanations; they should come in handy in the future. Unfortunately, the MSDK initialization (educated guess) queries the IDirect3D9 interface for available adaptors via calls to GetAdapterCount and GetAdapterIdentifier and look for an Intel GPU. When the Intel GPU is not connected to a monitor, it will not enumerate in the above calls. My home setup has a Radeon connected to screen. If the monitor is connected to the Radeon, the Intel GPU will be hidden. It will show in Windows device manager, but not accessible from DirectX.
The big question is how do I force DirectX to enumerate it?
Is there a way to programmatically connect the disconnected GPU to a virtual monitor?

[JanWillem32]

A virtual monitor driver is new to me. I've seen functions to force enable an analog "tv" output, though. It installs a standard VGA monitor on an adapter and forces it to output.
You can try something else first. If the combination of GetAdapterCount and GetAdapterIdentifier doesn't return the adapter you are looking for, EnumAdapters1 probably will (although I've never used it before): http://msdn.microsoft.com/en-us/library/ff471336%28v=VS.85%29.aspx . I don't know if the DXVA helper function can work on a DXGI-derived device. I've never tried to derive one for functions like that.

[CruNcher]

hmm maybe this can be somehow helpfull http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-217T http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-220C ? though these talks are more targeted @ Windows 8 and it might be better to look @ the PDC 2008 talks and the introduction of 7 though only these talks are interesting multimedia wise http://channel9.msdn.com/Events/PDC/PDC08/PC04 http://channel9.msdn.com/Events/PDC/PDC08/PC05 http://channel9.msdn.com/Events/PDC/PDC08/PC07 though only the 2011 talks go deep into the WDDM and virtual display driver.

[egur]

New and improved version. Zip files contains installer and documentation, please read.

Download version 0.15 alpha:
32 bit http://www.multiupload.com/SW88AXIEAR
64 bit http://www.multiupload.com/3QH5R6N6CD
Source code http://www.multiupload.com/GQBEQ161DB

Revision highlights:
v1.15:
* Rewrote time stamp handling code. Decoder now calculates frame rate if missing, corrects for splitters reporting double frame rate for interlaced content. Handles PTS and DTS time stamps. Broken streams that alternate frequently between telecined and interlaced frames are not handles perfectly (yet!).
* Handled unsupported H264 formats by reverting to libavcodec silently within ffdshow. HW acceleration is limited to H264 simple, main and high profiles. Previous version would crash on unsupported formats.
* Added support for WMV3 (part of the VC1 HW decoder).
* Various bug fixes and better decoder error handling. As reported by various users for the 0.14 release.
* Cleaned up minor memory leaks.

[CruNcher]

Egur nice :) also some progress on my QuickSync Decode/Transcode Capture Framework (this is really the nicest piece of Hardware i ever used, Z510 and US15W was already impressive to work with but this kills everything, just thinking about ivy bridge and haswell and more performance @ lower watt geez) :)

http://www.mediafire.com/?fitumy3c9qf3p31

[egur]

I succeeded in running the QS decoder on the Intel GPU and EVR on a discrete GPU (Radeon HD6950).
Steps to reproduce:
* Connect discrete card to monitor.
* Connect IGP to a second input on the same monitor, wait for the driver to recognize it (might need to manually switch the monitor input on the monitor itself). Win7 extends the desktop the "new" monitor.
* Switch back to the main input.
* Play video.
* Test setup by messing with controls on the discrete GPU control panel (e.g. lower saturation to zero).

This survived a reboot so it's a one time setup.
Both control panels for the GPUs are now functional.
I'll test this with MadVR today and update my post.

v0.15 is not compatible with this setup (bug - couldn't test this :( ), but next version will support it.
If it's very important, I'll release it ASAP.

[nevcairiel]

There is one really annoying thing with that setup though. There is no longer a mouse boundary, as your desktop permanently expands to the second screen, even if its not selected as an active input.

[egur]

There is one really annoying thing with that setup though. There is no longer a mouse boundary, as your desktop permanently expands to the second screen, even if its not selected as an active input.

True - an ugly hack. Until a SW solution is found, this can be good for testing/evaluation.

[ajp_anton]

But what about falling back to another decoder (not just libavcodec within ffdshow) for unsupported streams?
ffdshow can't output some of them directly so it converts them to RGB. LAV video works better there, and is also faster.

[egur]

But what about falling back to another decoder (not just libavcodec within ffdshow) for unsupported streams?
ffdshow can't output some of them directly so it converts them to RGB. LAV video works better there, and is also faster.

My decoder only outputs NV12 and decodes several types of streams. If it fails to initialize for any reason ffdshow will choose the default internal decoder - usually libavcodec.
Output conversion (raw video) has nothing to do with my code, it's negotiated with the filter connected downstream. The downstream filter decides the raw format.
What do you mean by LAV is faster? What scenario?

[nevcairiel]

He wants to use LAV for 10bit H264 and other formats not compatible with hardware decoding, because ffdshow has some limitations decoding those
My short answer would be to wait until LAV supports Intel MSDK as well..... :)

[CruNcher]

egur like i said before make it switchable so the user can decide to either fallback to libav or the dshow chain directly (just ignore the connection if switch is set) ;)

[ajp_anton]

My decoder only outputs NV12 and decodes several types of streams. If it fails to initialize for any reason ffdshow will choose the default internal decoder - usually libavcodec.
Output conversion (raw video) has nothing to do with my code, it's negotiated with the filter connected downstream. The downstream filter decides the raw format.
What do you mean by LAV is faster? What scenario?What I'm after:
Quicksync compatible? Use it.
Not compatible? Don't use ffdshow at all, use LAV instead.

Why?
With 10-bit video, LAV video is faster, and ffdshow can't output either 10-bit or 4:4:4 without going to 8-bit or RGB.

QS in LAV when? =)

[egur]

What I'm after:
Quicksync compatible? Use it.
Not compatible? Don't use ffdshow at all, use LAV instead.

Why?
With 10-bit video, LAV video is faster, and ffdshow can't output either 10-bit or 4:4:4 without going to 8-bit or RGB.

QS in LAV when? =)

Now, it's clear. I'll add a checkbox option for ffdshow's codec page to decline a connection in such cases. Default behavior will be fall back to libavcodec or other internal decoder.
Does this have any relevance to other formats (VC1, MPEG2)?

[CruNcher]

Now, it's clear. I'll add a checkbox option for ffdshow's codec page to decline a connection in such cases. Default behavior will be fall back to libavcodec or other internal decoder.
Does this have any relevance to other formats (VC1, MPEG2)?

For the Mpeg-2 Studio Profile fallback :)

[kieranrk]

For the Mpeg-2 Studio Profile fallback :)

Such a thing does not exist.

[CruNcher]

Such a thing does not exist.

in layman terms it does anyways 4:2:2 High Level ;)

[egur]

in layman terms it does anyways 4:2:2 High Level ;)

Can you supply a short clip MPEG2 4:2:2 clip for testing?

[TPoise]

I saw the earlier post about VC1 video corruption. Just wanted to add my two cents along with a sample file and pic.

Using the v0.15 alpha version.

Intel HD3000 (Core i7-2600QM)
Windows 7 SP1
Intel Display Driver v8.15.10.2342 (the latest according to Dell)



Link to a clip (http://www.megaupload.com/?d=RS22AQBF)

http://www.legacygeeks.com/images/florida_corrupt.png

[nevcairiel]

AVC1 is not VC1 .. MS really used a confusing name there. :)

[TPoise]

AVC1 is not VC1 .. MS really used a confusing name there. :)

Do I have a legitimate issue then? AVC1 is what shows up for any H.264 source I use. I am obviously a newbie.

[nm]

Do I have a legitimate issue then? AVC1 is what shows up for any H.264 source I use. I am obviously a newbie.

It may be a legitimate issue, but not the VC-1 problem that was described earlier. H.264 (sometimes signaled by fourcc AVC1) is not VC-1.

[CruNcher]

@Egur
im a little confused i got a I5-2400 shouldn't that be a GT1 ?

http://gpuz.techpowerup.com/11/10/15/2g2.png

lot of these data seems to make no sense also the clocks seem wrong detected :(

Tough it has a GPU usage display for Sandy Bridge now i wonder if it's though the same as the OS (Vista/7) is using from DWM or a Intel Driver Supplied one :)

Looks different (almost half more utilization, compared to the OS sensor) does the Sensor include the DSP Decoding ?
Nvidia for example is strictly differentiating here between GPU and VPU load i guess would be good if Intel does it as well:
So if the GPU load on DWM is GPU only then it would mean the DSP is loaded round about 30% or is that Sensor pure GPU EU load (Bicubic PS scaling is at work here) ?

http://img811.imageshack.us/img811/2912/gpuusage.png

Correct GPU Clock:

http://img511.imageshack.us/img511/5748/correctgpuclock.png


@Egur

is it possible to update only the GPU Bios part directly via the IME ?

[egur]

I saw the earlier post about VC1 video corruption. Just wanted to add my two cents along with a sample file and pic.

Using the v0.15 alpha version.
...
Intel Display Driver v8.15.10.2342 (the latest according to Dell

I couldn't reproduce the corruption on v0.15 or my not yet released dev build. Tried 64 and 32 bit.
Maybe it the old driver. I test on 2509 (latest) and 2372 (April) drivers.
You can try installing the latest generic Intel driver (2509 or newer) from the Intel website. I'm not sure what's the difference between the standard driver and the Dell driver, but it's usually quite safe to upgrade. If new driver is not working well, reinstall Dell's driver.

[TPoise]

I couldn't reproduce the corruption on v0.15 or my not yet released dev build. Tried 64 and 32 bit.
Maybe it the old driver. I test on 2509 (latest) and 2372 (April) drivers.
You can try installing the latest generic Intel driver (2509 or newer) from the Intel website. I'm not sure what's the difference between the standard driver and the Dell driver, but it's usually quite safe to upgrade. If new driver is not working well, reinstall Dell's driver.

I did the upgrade to the generic 2509 driver. Still see the corruption. One more thing that I failed to say in my original post--this laptop has a discrete Nvidia GT525M, so it uses NVidia Optimus. I have the Global Settings set to use "Integrated Graphics" and I can confirm the GPU usage on the discrete Nvidia card is at 0%.

[egur]

I did the upgrade to the generic 2509 driver. Still see the corruption. One more thing that I failed to say in my original post--this laptop has a discrete Nvidia GT525M, so it uses NVidia Optimus. I have the Global Settings set to use "Integrated Graphics" and I can confirm the GPU usage on the discrete Nvidia card is at 0%.

I've frame stepped at the 3 times the Florida logo appears in the clip, and no corruption. I tried two different splitters as well...

I've noticed AVC1 corruption on ts files during seeks or at the start of the clip, but this clip doesn't show any of these artifacts.

Can anyone else confirm the corruption?

[egur]

im a little confused i got a I5-2400 shouldn't that be a GT1 ?


GT1 it is. The process is 32nm not 45 and it doesn't support DirectX 11 (GT supports DX10.1). Also it says it doesn't support OpenCL and I'm quite sure it does.


Looks different (almost half more utilization, compared to the OS sensor) does the Sensor include the DSP Decoding ?
Nvidia for example is strictly differentiating here between GPU and VPU load i guess would be good if Intel does it as well:
So if the GPU load on DWM is GPU only then it would mean the DSP is loaded round about 30% or is that Sensor pure GPU EU load (Bicubic PS scaling is at work here) ?


Not sure what you mean exactly, but HW decoding and most of the post processing are in fixed function and don't register as GPU load. Also, I'm not sure how accurate these measurements are.

@Egur

is it possible to update only the GPU Bios part directly via the IME ?

Don't know and probably not a good idea unless it's specifically supported. The BIOS image is made out of many parts that get validated as a whole. Do you have VBIOS issues that a new VBIOS version corrects?

[CruNcher]

I've frame stepped at the 3 times the Florida logo appears in the clip, and no corruption. I tried two different splitters as well...

I've noticed AVC1 corruption on ts files during seeks or at the start of the clip, but this clip doesn't show any of these artifacts.

Can anyone else confirm the corruption?

Nope no issues or corruption besides this stream is awful quality to begin with and totally over inlooped ;)

GT1 it is. The process is 32nm not 45 and it doesn't support DirectX 11 (GT supports DX10.1). Also it says it doesn't support OpenCL and I'm quite sure it does.

Yeah lot of issues other do it much better then Wizzard currently ;) ill post a bug report


Not sure what you mean exactly, but HW decoding and most of the post processing are in fixed function and don't register as GPU load. Also, I'm not sure how accurate these measurements are.

Yes i know but the load should be measurable there also shouldn't it, especially i have doubts that no one @ intel need those load data for almost live playback measurements ;) ?
What would you suggest to measure the different GT1/2 states (GPU,DSP,Memory) ?
Im gonna ask Wizzard where he gets those measurement from but i guess it's a NDA thing (well see)


Don't know and probably not a good idea unless it's specifically supported. The BIOS image is made out of many parts that get validated as a whole. Do you have VBIOS issues that a new VBIOS version corrects?

Nope just asked though i also didn't find any Dump of a Intel GT1 bios yet :P
And indeed i would also see no reason to update i mean this Windows Intel system is more stable then anything i used before ever :)

I also did a small test to confirm the GPU-Z measurements

http://img7.imageshack.us/img7/7927/gpuzcorrect.png

looks more accurate indeed (as the feeling here is the PS is pushing the GT1 over the top and it crawls to it's feet @ 1080p) i wonder why the headroom though for the OS DWM measurement is exactly somewhere 50% more :D somehow i guess if i get that too 100% it's latency gonna explode and Aero is gonna error or turn off ;)

Overloading the GT1 has a effect on the overall Performance, but the OS DWM measuring doesn't seem to change anymore even with more load ? :)

No load = 6 seconds

http://img249.imageshack.us/img249/7703/noengine1t.png

ffdshow-quicksync + PS (EVR-CP PS Bicubic) + Pre-Resize Sharpen Complex 2 @ 1080p = 12 seconds

http://img851.imageshack.us/img851/8388/renderperformancedrop.png

:devil:

http://img822.imageshack.us/img822/1278/moreload.png

So could be Engine 1 the fixed function load ?

Yup Engine 1 seems to be the fixed function Decoder load, turning it off gives you the same measurement as GPU-Z for the EUs only load :)

Though that turning of the PS offloads the load somewhat to Engine 1 seems strange, why should the Decoder load get lower with PS on ?

http://img690.imageshack.us/img690/4716/fixedloadchange.png


Can you supply a short clip MPEG2 4:2:2 clip for testing?

Sorry missed that http://www.megaupload.com/?d=V93PLAO2

Try also that your ffdshow when falling back for Mpeg-2 Studio to libmpeg2 priority is the native YUY2 output to keep CPU load as low as possible @ Playback :D (ffdshows colorspace conversion aren't optimal in performance, and if they can be avoided why forcing something like YV12 or NV12 like it's currently being done) currently it does by default YUY2->YV12 which seems crazy and only eats Performance :(
You are optimizing for a Intel Framework here so if the Renderer does a better job why do a extra (slow) conversion (NV12,YV12) where it isn't needed ;)

If you do it like said it would also beat the current Lav Video (at least in Power Consumption) in native YUY2 :)

Of course there is also the Hard way to optimize the Colorspace Conversion ASM for Intel SB entirely (to gain really the last drop) :D

Mainconcept:

YV12 = 154 FPS (~9% @ 59.95 fps)

Lav Video:

YV12 = 118 FPS (~13% @ 59.95 fps)
YUY2 = 150 FPS (~12% @ 59.95 fps)

FFdshow-Quicksync (libmpeg2):

YV12 = 96 FPS (~13% @ 59.95 fps)
YUY2 = 110 FPS (~10% @ 59.95 fps)

FFdshow-Quicksync (libavcodec):

YV12 = 134 FPS (~15% @ 59.95 fps)
YUY2 = 145 FPS (~13% @ 59.95 fps)

interesting libmpeg2 seems more efficient in power consumption compared to libavcodec which is tough higher performance ?

[TPoise]

I've frame stepped at the 3 times the Florida logo appears in the clip, and no corruption. I tried two different splitters as well...

I've noticed AVC1 corruption on ts files during seeks or at the start of the clip, but this clip doesn't show any of these artifacts.

Can anyone else confirm the corruption?

Does anybody have a laptop that can confirm (or deny) the corruption? I wonder if it is a NVidia Optimus issue. I'm not privy to the full details of how it Optimus works, but if it intercepts direct calls to either the HD3000 GPU or the Nvidia GT525M GPU then could it possibly cause the corruption that I'm seeing?

FYI, when I switch to DXVA using the the HD3000 GPU (not Ffdshow), just the basic DXVA hardware rendering as part of Media Player Classic, I see no corruption. Not only do I see no corruption, but my CPU usage is very low (around 1-2%) as well as temps/voltages are low when measured using CoreTemp.

I also see no corruption when using libavcodec when using the ffdshow filters from egur.

I'm using MPC, 64-bit edition v1.5.2.3456

[CruNcher]

Optimus also has Compression capabilities of PCI-E transfers though not sure if that might interference here (its proprietary stuff) to enhance the Performance it only works on x1 connections. http://forum.notebookreview.com/gaming-software-graphics-cards/418851-diy-egpu-experiences-123.html#post6542661
I hope we hear something soon from what happened to Synergy for Desktops http://vr-zone.com/articles/nvidia-to-launch-desktop-optimus--synergy-at-computex/11946.html :(

And yes sure DXVA is going to less stress your system then ffdshow-quicksync does and when maximum Power Consumption is your goal it should be preferred for Playback, if for any reason flexibility is or something else then ffdshow-quicksync might be a good solution. You shouldn't just use it because you want to you should know your goals, of course if your goal is to help improve it that's great :)

[vivan]

I have acer 3830TG (i5-2410M + nVidia 540M = Optimus).
I'm using 32-bit (since there is no sense in using x64 version) versions of MPC-HC and decoder from here - can't reproduce your problem. I even installed x64 versions - everything is still ok...

So, as for me, everything works perfectly. The only problem I'm experiencing is with video with variable framerate - audio/subs are out of sync :(

[egur]

I'm using MPC, 64-bit edition v1.5.2.3456
Any special reason to use 64 bit?
Can you try the 32 bit version? My decoder will be a little faster in 32bit as I've optimized the copy function in ASM. 64 bit use intrinsic functions but the compiler isn't 100% efficient using them.

[Boltron]

What performance monitor utility are you using that shows Summary, CPU, Memory GPU and also the GPU Engine History?

[LoRd_MuldeR]

ProcessExplorer? (http://technet.microsoft.com/en-us/sysinternals/bb896653)

And, if you want a more detailed analysis on how many CPU cycles have been spent in each function, you could have a look at Code Analyst:
http://developer.amd.com/tools/CodeAnalyst/pages/default.aspx

(Although it is an AMD tool, it works on Intel CPU's just as well. Just make sure you use it with a Debug build, if you want function names!)

[Boltron]

Wow, ProcessExplorer sure looks different from the last time I used it. This is so cool. Thx!

[TPoise]

Any special reason to use 64 bit?
Can you try the 32 bit version? My decoder will be a little faster in 32bit as I've optimized the copy function in ASM. 64 bit use intrinsic functions but the compiler isn't 100% efficient using them.

Used 32-bit and get the same video corruption.

[egur]

I managed to solve the multi GPU problem without cables. You'll need v0.16 or newer to make this work.
1) You need to set up another (fake) screen. Right click on desktop->screen resolution.
2) Click the Detect button. Unconnected screens will appear.
3) Extend desktop to a VGA connection on the Intel GPU (screen 2 in the image).
4) Drag the 2nd screen to the corner of the primary screen so the mouse boundaries of the primary screen will remain (almost) the same.
5) Click OK/Apply. A reboot is recommended.
http://img14.imageshack.us/img14/6519/displaysettings.png
6) Open your favorite player and select MadVR or other GPU demanding renderer for to test the setup. You can test further by selecting EVR as renderer, open the control panel for your AMD/Nvidia GPU and override the color settings (e.g. kill the saturation).
Here's a working setup
http://img832.imageshack.us/img832/3551/zpffdshowquicksyncmadvr.png

[CruNcher]

awesome i just love NT6 now we can mix input output like crazy without needing any 3rd party solutions great work egur :)
i wonder though is DXVA also working or does the decoder need specifically to support this ?
And what happens if you open a DXVA session and where does it get rendered ?

[nevcairiel]

i wonder though is DXVA also working or does the decoder need specifically to support this ?
And what happens if you open a DXVA session and where does it get rendered ?

You can't easily transfer GPU textures between devices, so if you use DXVA, it needs to be rendered on the same device that decoded it.

Besides, if you already use DXVA, why not use the DXVA of your primary video card? :p

[egur]

New and improved version. Zip files contains installer and documentation, please read.

Download version 0.16 alpha:
32 bit http://www.multiupload.com/Z4PX2UFGB4
64 bit http://www.multiupload.com/QH5ZZXINCQ
Source code http://www.multiupload.com/06IZWGH4T0

Revision highlights:
v1.16:
* Support multi GPU setups. Now the decoder can run on separate HW then the renderer. Even without connecting the Intel GPU to a screen. See Multi GPU below for details.
* This version will be the first version on SourceForge.
* Updated to ffdshow build 3996.
* Some fixes to the timestamp code. Now supporting streams with no frame rate.
* Fixed several aspect ratio issues.
* Very initial support for DVD playback. Menus are not displayed right yet. WIP. Recommend not to use except for testing purposes.
* Changed mechanism for handling flush & seek event. Code is faster and more robust. A critical stage for playing DVDs.
* Added a new callback for FFDShow’s internal decoders – EndFlush. This is needed for DVD playback. Other decoders do not need to implement it.
* Enhanced FFDShow’s code with a faster memcpy function (SSE2 based). This replaces calling memcpy. The original source code would use ffmpeg to do it, but it crashes on NV12 images.

[egur]

awesome i just love NT6 now we can mix input output like crazy without needing any 3rd party solutions great work egur :)
i wonder though is DXVA also working or does the decoder need specifically to support this ?
And what happens if you open a DXVA session and where does it get rendered ?

DXVA connections will not cross HW boundaries. Maybe there's a tricky way to do it, but I doubt it's worth the trouble.

My decoder is mostly aimed at low power, but it was a nice problem to solve. I'm not aware of similar solutions.

Since I copy the frames from the GPU to the CPU very quickly, it makes sense in using it with your favorite SW setup. The pipeline is File->CPU->GPU1->CPU->GPU2->Screen.

This opens up a way for fast HW decoding with super strong programmable video processing on a discrete GPU.

I wish Windows 7 was easier to use in sense of utilizing the various HW resources.

[Atak_Snajpera]

Quicksync in official ffdshow r4000 would epic :)

[ajp_anton]

Now, it's clear. I'll add a checkbox option for ffdshow's codec page to decline a connection in such cases. Default behavior will be fall back to libavcodec or other internal decoder.
Does this have any relevance to other formats (VC1, MPEG2)?What happened?

[egur]

What happened?

This part wasn't ready for this release. Currently it falls back to libavcodec if the platform can't support QuickSync or for H264 unsupported formats.
If something else is unsupported ffdhsow will decline the connection.
I'll fix this for next release. Hopefully after I integrate into the main ffdshow trunk in sourceforge.

[pulbitz]

I'm sorry. I don't speak English very well.

audio/video unsync (with Gabest Splitter) sample files.

(2011.09.28) Hyun Young 조현영 _A_ @ Gachon University Festival Celebration Fancam(720p_H.264-AAC).mp4
http://o-o.preferred.fra02s05.v5.lscache1.c.youtube.com/videoplayback?sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Csource%2Cratebypass%2Ccp&fexp=904539%2C914032%2C903119%2C900221&itag=22&ip=121.0.0.0&signature=8C7C37527E0C230FA0A01CFAE0620BFA923D7B6E.8EA9A67F9D7C0A227858F78B0DFBF2ADE9A5CF1B&sver=3&ratebypass=yes&source=youtube&expire=1319148000&key=yt1&ipbits=8&cp=U0hQTlFPVl9FSkNOMF9JSVpBOk12b085N3JnWmY4&id=1089491d982d9386

(2011.10.06) Hyun Young 조현영 _Mach_ @ Gyeonggi University of S&T Festival Fancam(720p_H.264-AAC).mp4
http://o-o.preferred.fra02s05.v7.lscache8.c.youtube.com/videoplayback?sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Csource%2Cratebypass%2Ccp&fexp=904539%2C914032%2C903119%2C900221&itag=22&ip=121.0.0.0&signature=5F64ED712E76CE6F1A91E8CB333257FA14091F93.9D07A528297624A90D5979D530452CFEF44787AE&sver=3&ratebypass=yes&source=youtube&expire=1319148000&key=yt1&ipbits=8&cp=U0hQTlFPVl9FSkNOMF9JSVpBOk12b085N3JnWmY4&id=2130d6979f680c4c

QuickSync = 30.303fps
libavcodec = 29.97xfps

please improve your timestamp code more. :)

[JanWillem32]

DXVA connections will not cross HW boundaries. Maybe there's a tricky way to do it, but I doubt it's worth the trouble.

My decoder is mostly aimed at low power, but it was a nice problem to solve. I'm not aware of similar solutions.

Since I copy the frames from the GPU to the CPU very quickly, it makes sense in using it with your favorite SW setup. The pipeline is File->CPU->GPU1->CPU->GPU2->Screen.

This opens up a way for fast HW decoding with super strong programmable video processing on a discrete GPU.

I wish Windows 7 was easier to use in sense of utilizing the various HW resources.DMA access to GPU memory has been around since forever. (http://en.wikipedia.org/wiki/Direct_memory_access for those that are interested.)
Allocating a buffer explicitly in the video memory has always been possible. Proper memory resource management is even a key feature to any graphics rendering engine.
Sharing resources trough the DirectX API is relatively new: http://msdn.microsoft.com/en-us/library/windows/desktop/bb219800%28v=vs.85%29.aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/ee913554%28v=vs.85%29.aspx . The usual DXVA helper device for EVR uses a shared handle system to give the main rendering device access to DXVA output surfaces. The extra device runs mostly asynchronously from the main device.
File->CPU->GPU1->GPU2->Screen is completely allowed, but I don't know what would be faster, a render target on GPU1's memory or on GPU2's memory. Making GPU1 render to system memory or doing an extra copy operation from video memory to system memory will most certainly slow things down.
It's actually not the copy operation itself that's an issue. It's usually the wait for the lock operation. Scheduled transfers without locking surfaces/textures in video memory are a lot more efficient.

[CruNcher]

I got Cyberlink HAM working on Intel it's basically nothing else then a Renderless DXVA (not bound to the renderer) that also Potplayers DXVA Decoder makes use of.
The big questions is do we really need APIs from every vendor for NT6 if Microsofts integrated the possibility to use DXVA Renderless from the beginning, and why integrate every each vendor ones if 1 for all exists (in terms of interoperability) ?

DXVA Renderless (supports everyone)
AMD OpenVIdeo (supports AMD)
Intel MediaSDK (supports Intel)
Nvidia Nvcuvid (supports Nvidia)

Is there really such a big Performance difference that would justify implementing each vendors own (or is there even a performance lose doing so wrapping from a to b), for the specific hardware case ?

[egur]

I'm sorry. I don't speak English very well.

audio/video unsync (with Gabest Splitter) sample files.

(2011.09.28) Hyun Young 조현영 _A_ @ Gachon University Festival Celebration Fancam(720p_H.264-AAC).mp4
http://o-o.preferred.fra02s05.v5.lscache1.c.youtube.com/videoplayback?sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Csource%2Cratebypass%2Ccp&fexp=904539%2C914032%2C903119%2C900221&itag=22&ip=121.0.0.0&signature=8C7C37527E0C230FA0A01CFAE0620BFA923D7B6E.8EA9A67F9D7C0A227858F78B0DFBF2ADE9A5CF1B&sver=3&ratebypass=yes&source=youtube&expire=1319148000&key=yt1&ipbits=8&cp=U0hQTlFPVl9FSkNOMF9JSVpBOk12b085N3JnWmY4&id=1089491d982d9386

(2011.10.06) Hyun Young 조현영 _Mach_ @ Gyeonggi University of S&T Festival Fancam(720p_H.264-AAC).mp4
http://o-o.preferred.fra02s05.v7.lscache8.c.youtube.com/videoplayback?sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Csource%2Cratebypass%2Ccp&fexp=904539%2C914032%2C903119%2C900221&itag=22&ip=121.0.0.0&signature=5F64ED712E76CE6F1A91E8CB333257FA14091F93.9D07A528297624A90D5979D530452CFEF44787AE&sver=3&ratebypass=yes&source=youtube&expire=1319148000&key=yt1&ipbits=8&cp=U0hQTlFPVl9FSkNOMF9JSVpBOk12b085N3JnWmY4&id=2130d6979f680c4c

QuickSync = 30.303fps
libavcodec = 29.97xfps

please improve your timestamp code more. :)

I know I need to improve the time stamps. Fixed a few things in the v0.16 but there's still more work to do...

The links you've posted are not working - "access denied" for both. You can share very quickly on http://www.multiupload.com

[egur]

DXVA Renderless (supports everyone)
AMD OpenVIdeo (supports AMD)
Intel MediaSDK (supports Intel)
Nvidia Nvcuvid (supports Nvidia)

Is there really such a big Performance difference that would justify implementing each vendors own, for the specific hardware case ?

There's a difference in features (mostly related to video processing) and DXVA is very complex and not high level enough.
Hopefully this chaos will converge to a single API at some point. A user friendly API that abstracts enough details while remaining high performing.
Performance is a very important issue in the mobile world - battery life. Every minute of video playback is worth a lot of R&D, validation and enabling resources.
The architecture "war" with ARM (starting with Windows 8) will probably help to push HW acceleration forward on many fronts so small devices can compete with ARM based SOCs.
Nvidia plays both sides of the fence in this war (GPU for x86 platforms as well as ARM CPU maker) so one can expect them to fork out a cross platform API for HW acceleration. This would probably be the best kind of API - abstract the HW completely - no need to be a DirectX expert to do complex stuff.

[egur]

DMA access to GPU memory has been around since forever. (http://en.wikipedia.org/wiki/Direct_memory_access for those that are interested.)
Allocating a buffer explicitly in the video memory has always been possible. Proper memory resource management is even a key feature to any graphics rendering engine.
Sharing resources trough the DirectX API is relatively new: http://msdn.microsoft.com/en-us/library/windows/desktop/bb219800%28v=vs.85%29.aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/ee913554%28v=vs.85%29.aspx . The usual DXVA helper device for EVR uses a shared handle system to give the main rendering device access to DXVA output surfaces. The extra device runs mostly asynchronously from the main device.
File->CPU->GPU1->GPU2->Screen is completely allowed, but I don't know what would be faster, a render target on GPU1's memory or on GPU2's memory. Making GPU1 render to system memory or doing an extra copy operation from video memory to system memory will most certainly slow things down.
It's actually not the copy operation itself that's an issue. It's usually the wait for the lock operation. Scheduled transfers without locking surfaces/textures in video memory are a lot more efficient.

I haven't seen anything like this - two DXVA devices from different GPUs passing surfaces from one to the other?

I can take your word for it but it's probably extremely complicated to accomplish.

In the Intel GPU, I don't think there's any DMA going on when copying surfaces back and forth to the CPU. It's the same memory sitting on the same memory controller. A special SSE4 instruction was introduced in Penryn to address the complex mapping to solve the speed issues.

[CruNcher]

I just recorded my first 3D Gaming with my Low Latency H.264 Quicksync Encoder Framework it runs rather smooth in the 3D Engine (ID tech 5) at least playable. Entirely on GT1 (Playing + Recording) :D

[pulbitz]

I'm sorry. I don't speak English very well.

audio/video unsync (with Gabest Splitter) sample files.

(2011.09.28) Hyun Young 조현영 _A_ @ Gachon University Festival Celebration Fancam(720p_H.264-AAC).mp4
http://o-o.preferred.fra02s05.v5.lscache1.c.youtube.com/videoplayback?sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Csource%2Cratebypass%2Ccp&fexp=904539%2C914032%2C903119%2C900221&itag=22&ip=121.0.0.0&signature=8C7C37527E0C230FA0A01CFAE0620BFA923D7B6E.8EA9A67F9D7C0A227858F78B0DFBF2ADE9A5CF1B&sver=3&ratebypass=yes&source=youtube&expire=1319148000&key=yt1&ipbits=8&cp=U0hQTlFPVl9FSkNOMF9JSVpBOk12b085N3JnWmY4&id=1089491d982d9386

(2011.10.06) Hyun Young 조현영 _Mach_ @ Gyeonggi University of S&T Festival Fancam(720p_H.264-AAC).mp4
http://o-o.preferred.fra02s05.v7.lscache8.c.youtube.com/videoplayback?sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Csource%2Cratebypass%2Ccp&fexp=904539%2C914032%2C903119%2C900221&itag=22&ip=121.0.0.0&signature=5F64ED712E76CE6F1A91E8CB333257FA14091F93.9D07A528297624A90D5979D530452CFEF44787AE&sver=3&ratebypass=yes&source=youtube&expire=1319148000&key=yt1&ipbits=8&cp=U0hQTlFPVl9FSkNOMF9JSVpBOk12b085N3JnWmY4&id=2130d6979f680c4c

QuickSync = 30.303fps
libavcodec = 29.97xfps

please improve your timestamp code more. :)

I know I need to improve the time stamps. Fixed a few things in the v0.16 but there's still more work to do...

The links you've posted are not working - "access denied" for both. You can share very quickly on http://www.multiupload.com

I upload files. Please try again.

http://www.mediafire.com/?jql2qu8xj22c2ar
http://www.mediafire.com/?ye6oudmltypr7ey

[egur]

I upload files. Please try again.

http://www.mediafire.com/?jql2qu8xj22c2ar
http://www.mediafire.com/?ye6oudmltypr7ey

Got the files.
The newest version (to be released soon) seems to play them well. They are have constant frame rate of 29.97 which stays well for the entire clip.

Other than audio/video sync issues, are there any other problems?

BTW, do you know what camera produced these clips?

I want to thank all you guys for helping me make this a better product by testing and providing clips :)

[JanWillem32]

I haven't seen anything like this - two DXVA devices from different GPUs passing surfaces from one to the other?

I can take your word for it but it's probably extremely complicated to accomplish.

In the Intel GPU, I don't think there's any DMA going on when copying surfaces back and forth to the CPU. It's the same memory sitting on the same memory controller. A special SSE4 instruction was introduced in Penryn to address the complex mapping to solve the speed issues.DMA just means getting valid pointers to memory outside of regular system memory. It's just a matter of pointer logic between two DirectX 9 devices and giving direct access, without invoking a copy operation on an entire texture. As far as I know, DXVA uses rather normal render targets. Sharing a texture would look like this:HANDLE SharedHandle = NULL;// uninitialized
D3DDevice1->CreateTexture(Width, Height, 1, D3DUSAGE_RENDERTARGET, SurfaceType, D3DPOOL_DEFAULT, &RTTexture1, &SharedHandle);// handle is initialized, texture is created on deivice 1
D3DDevice2->CreateTexture(Width, Height, 1, D3DUSAGE_RENDERTARGET, SurfaceType, D3DPOOL_DEFAULT, &RTTexture2, &SharedHandle);// handle is used, no extra texture is created, the COM pointer RTTexture2 will be usable only to D3DDevice2This way device 2 will have read/write access to that texture hosted in device's 1 memory. Ownership will stay with device 1, so when quitting, release RTTexture2 before it becomes invalid by releasing RTTexture1. (The same old story as with "new" and "delete", get rid of additional pointers first before destroying the object itself.)
The helper function for DXVA on EVR does a similar thing (although usually on the same adapter). Shared handles are also used when you want to access textures from a DirectX 9 to a DirectX 11 device.

[pulbitz]

Got the files.
The newest version (to be released soon) seems to play them well. They are have constant frame rate of 29.97 which stays well for the entire clip.

Other than audio/video sync issues, are there any other problems?

BTW, do you know what camera produced these clips?

I want to thank all you guys for helping me make this a better product by testing and providing clips :)

No other problems.

Probably Samsung HMX-S10. (I found it difficult. :p)

Thanks for the fix!

P.S. Not related QuickSync decoder. But can you look at this bug? http://communities.intel.com/thread/24972

[markanini]

P.S. Not related QuickSync decoder. But can you look at this bug? http://communities.intel.com/thread/24972

Not sure if related but I'm seeing similar poor chroma upsampling on flash video.

[egur]

P.S. Not related QuickSync decoder. But can you look at this bug? http://communities.intel.com/thread/24972

Not sure if related but I'm seeing similar poor chroma upsampling on flash video.

I only use the decoder part of QuickSync ATM. The post processing comes from the renderer.

The video processing pipeline, which I'm very familiar with doesn't care about surface format, what matters is that both are 4:2:0. If different results arise from NV12 and YV12, it looks like a driver bug.

[CruNcher]

Wow i just realized (testing ffdshow-quicksync) some vendor DXVA implementations can avoid Ref Frame issues on EVR :D CoreAVC and Arcsoft are one of them without loosing hardware playback or need to fallback to Software very impressive :)

[egur]

Wow i just realized (testing ffdshow-quicksync) some vendor DXVA implementations can avoid Ref Frame issues on EVR :D CoreAVC and Arcsoft are one of them without loosing hardware playback or need to fallback to Software very impressive :)

Can you explain, what's the Ref Frame issue with EVR? And what I did better then the others?

BTW, my decoder can fallback to SW under certain conditions. WMV3 isn't HW accelerated at all and clips with height OR width larger than 1080p also fallback to SW.
This is noticeable by a significant change in CPU usage.

In a future version I'll notify the app (ffdshow in this my case) that no HW acceleration is available and the app can choose whether to use Intel's SW implementation or use another SW decoder.

Update:
CPU usage is very high for Intel SW implementation because I keep using the D3D surfaces as frame buffers. This (of course) is far from optimal but will be addressed in the next release.
So head to head benchmarks between Intel's SW implementation and libavcodec/libwmv9 will have to wait till then.

[vivan]

CoreAVC-dxva (the same applies to the mpc-dxva, ffdshow-dxva and mirillis splash player) + 1080p with 16 ReFrames:
http://2.firepic.org/2/images/2011-10/22/mv9yqyb9f86m.png
But with your decoder everything is perfect :)

P.s. another one sample with vfr (at least mediaInfo says so), that causes a/v desync: http://www.mediafire.com/?d54fscbebq2p4ag
And this one is with real vfr (60/30): http://akross.info/guest/[akross.ru]_Artofeel_-_Minimalistique_alt.mkv

[egur]

CoreAVC-dxva (the same applies to the mpc-dxva, ffdshow-dxva and mirillis splash player) + 1080p with 16 ReFrames:
http://2.firepic.org/2/images/2011-10/22/mv9yqyb9f86m.png
But with your decoder everything is perfect :)

P.s. another one sample with vfr (at least mediaInfo says so), that causes a/v desync: http://www.mediafire.com/?d54fscbebq2p4ag
And this one is with real vfr (60/30): http://akross.info/guest/[akross.ru]_Artofeel_-_Minimalistique_alt.mkv

Thanks for the clip, I'll check it out.
CoreCodec are free to use my code as reference or 'as is' if they want to. Hence the BSD license.
If they do, another goal has been met at some level - improve SW that use the QuickSync technology.

If someone has a clip that demonstrates this failure, please share. Don't be shy.

[CruNcher]

egur look @ http://forum.doom9.org/showthread.php?t=159486 i tested with the oceanic samsung x264 encode and CoreAVC 3.0.1 and Arcsofts DXVA2 survive it :) and i confirmed that they don't fallback to Software decoding either (some implementations do that after a bitstream check)

Vivan strange i tested several over ref frames clips from several x264 builds and it seems CoreCodec at least found a workaround the same as Arcsoft did, its impressive other solutions either switch to Software or error per frame areas :D

egur this though isn't a problem that should interest you as you don't use DXVA your decoder will not suffer from this :)

Cyberlinks DXVA has really to fight with this erroring out every frame with core 56 bitstreams

[egur]

egur this though isn't a problem that should interest you as you don't use DXVA your decoder will not suffer from this :)


Actually, my decoder uses the Intel Media SDK which uses DXVA2. So indirectly I'm using DXVA...

[CruNcher]

yup im not sure but it seems only DXVA1 implementations are affected and Cyberlink seems to be still DXVA1 both Arcsoft and CoreAVC are DXVA2 implementations and don't suffer from it, though CoreAVC even plays some more test bitstreams then Arcsoft does :)

[vivan]

egur look @ http://forum.doom9.org/showthread.php?t=159486 i tested with the oceanic samsung x264 encode and CoreAVC 3.0.1 and Arcsofts DXVA2 survive it :) and i confirmed that they don't fallback to Software decoding either (some implementations do that after a bitstream check)even mpc-dxva plays it well, I guess it just doesn't use so much reframes.

Vivan strange i tested several over ref frames clips from several x264 builds and it seems CoreCodec at least found a workaround the same as Arcsoft did, its impressive other solutions either switch to Software or error per frame areas :DMaybe their implementations are a bit better, but they still are far from this decoder.
E.g. with this sample (http://www.mediafire.com/?id7cd8aujnmwslf), coreavc shows mess for about 2/3 of time, mpc-dxva - 9/10, but mirillis splash player have only few artifacts (so ~1/30 of time).
At least on my i5-2410M with intel HD 3000.

[CruNcher]

thx for the sample going to check, and yes sure fffdshow-quicksync is more robust the same as nvidia cuvid is though also under XP (NT5) that intel doesn't support anymore for valid reasons :)
But the Ref problem is one of the major issues people change from DXVA to other solutions and the upcoming 10 bit and 4:2:2 wave (though problem on the Hardware support level) obviously at least under NT 6 it's much better in terms of flexibility when mixing different inputs (subbtitles, interactive layers (guis), different content, pp systems(shader,cpu,compute)) also in terms of editing via the copy and transfer between GPU (memory) capabilities though not many make use of this currently :)
My work on my High Efficiency DWM Desktop (DirectX,OpenGL) Capture and Transcode framework leverages all of this (except compute currently) mixing it in near realtime (latency of H.264, still testing different efficiency scenarios because of GPU/CPU dependency) im confident i can do even better then Mirillis with Action http://mirillis.com/en/products/action.html (and their FIC codec) does in the End on supported systems :D

PS: Yep Vivan that bitstream is hardcore (Anime exaggerated Encoding style ;) ) Arcsoft DXVA freezes straight @ the start Cyberlinks goes Hi wire only CoreAVCs DXVA can produce something with your shown errors from here to their :) though amazing how CoreCodec compensates even this level lower levels seem no problems to fix for them entirely (might be also the reason it's not up to the performance of Cyberlinks DXVA which fails even @ lower levels) :)
Mirillis really pushes the boundary here once again wow as you said ultra low CPU ultra low GPU and only 1 issue their custom Renderer and Decoder is really efficient as hell (these polish guys really fascinate, they are on the super right track)
Action is definitely gonna beat Fraps hands down i give you my word for it these guys know what they do :)
Though we should be also true these Bitstreams are rare ;) they exist but they are still rare (mostly old x264 encoder libx264 used via ffmpeg in the commercial space without any idea from the user what he actually does) though it's good to know that somebody cares about efficiency behind specs ;) (Vivan be also advised im no fan of this exaggerated Anime Encoding style as i find it useless in most cases, it's just not worth for every pixel quality to brake specs which will be hardly visible @ all,also in Power Consumption terms and yeah im no fan of Placebo either ;))

[egur]

Does anyone have an idea if I should correct 1440x1080 with aspect ratio of 4:3 to an aspect ratio of 16:9?
I've noticed some clips that have this wrong AR and thus displayed wrong.

The wrong aspect ratio of 4:3 exists in both the media type as well as the PPS (h264).

[nevcairiel]

If the stream is flagged improperly, dont touch it. It could as well be meant to be 4:3, you will never know.

The only correction i do automatically is crop a height of 1088 to 1080, because in 99.99% of all cases, thats correct. (Just missing the cropping flags in the bitstream)

[Blight]

I would add an optional check-box.
I've seen quite a few 1440x1080 clips and they were all 16:9.
I have never seen one at 4:3.

[nevcairiel]

I have never seen a 1440x1080 that was wrongly flagged and playing as 4:3 eventhough it is 16:9, tbh.
One would imagine that in all this time, someone would've posted such a sample as a bug report.

[egur]

If the stream is flagged improperly, dont touch it. It could as well be meant to be 4:3, you will never know.

The only correction i do automatically is crop a height of 1088 to 1080, because in 99.99% of all cases, thats correct. (Just missing the cropping flags in the bitstream)

I have never seen a 1440x1080 that was wrongly flagged and playing as 4:3 eventhough it is 16:9, tbh.
One would imagine that in all this time, someone would've posted such a sample as a bug report.

Totally right, it tuned out to be bug in the splitter (Haali). With LAV splitter AR is correct. The clip was test.ts posted by CruNcher a while back on this thread.

[nevcairiel]

Ah, Haalis "feature" that replaces all AR definitions in the stream with the container defined AR. Too bad a TS file does not have a container AR. ;)

[Blight]

egur/nevcairiel:
Was this reported to Haali?

[nevcairiel]

Its a feature in his book, because CoreAVC didn't have a option to ignore the Stream AR, so instead of adding that option in the decoder, Haali just overwrites the Stream AR with the container-defined AR. For MKV that might make sense, for any other format thats just terrible.

Anyhow, i have never seen him give any feedback whatsoever on issue reports on HMS.

[egur]

I get image corruption right after seeks on quite a few h264 TS clips.
After some testing, I've found out that Haali Media Splitter doesn't cause the corruptions. LAV and MPC do.
The first NALU after a seek with Haali is an SEI then a SLICE. The rest provide a SLICE NALUs without anything else.
Before posting a bug report (or feature request) to nevcairiel, does anyone have an idea on the differences?

Also, it seems that Haali is significantly faster at seeks or at least my decoder as well libavcodec produce a frame much faster. The difference is instant vs 1-2 seconds.

Can someone explain this behavior difference? Possible workaround?

[nevcairiel]

Its not a splitter "bug", its just not perfect behavior. You either ignore it, or you take steps to not show an image until its artifact free.
TS is not a format that was designed with seeking in mind, which means it does not carry any metadata about keyframes or such to make seeking easier.

Its already being tracked as an enhancement to try to find a key frame before delivery from the splitter, so the decoder has an easier job.

PS:
How does "nav" get into peoples minds when they read my name?

[egur]

Its already being tracked as an enhancement to try to find a key frame before delivery from the splitter, so the decoder has an easier job.
Very well, the snappy and clean seeks are worth the effort.
PS:

How does "nav" get into peoples minds when they read my name?
It means people are too tired when writing a post - corrected :)

[nevcairiel]

It means people are too tired when writing a post - corrected :)

I don't mind "nev", just i dont get where people get the a from, you're not the only one. :p

[HeadlessCow]

nev(cairiel) + LAV = nav

Probably.

[egur]

New and improved version. Zip files contains installer and documentation, please read.

Download version 0.17 alpha:
32 bit http://www.multiupload.com/I6XHZWQP2Y
64 bit http://www.multiupload.com/OUR6SXPVT1
Source code http://www.multiupload.com/J8X9WPAKXM

Revision highlights:
v1.17:
* Support variable frame rate video.
* More stable time stamps (audio sync issues).
* Fixed FFDShow’s frame rate measurement to better view frame rate changes.
* Better Media SDK initialization.

[vivan]

With new version QS decoding doesn't work on any video o_O
ffdshow is prefered decoder, so on older versions it works perfectly. But with 1.17 mpc-hc is using next decoder (lav decoder, in my case). If I change QS decoder (in ffdshow settings) to libavcodec - ffdshow works as it should (but, obviously, without QS).
I've rolled back to older version - everything behave as it should. Than updated to new version - QS is not working again. So, problem is not in the system settings...
SW: MPC-HC 1.5.2.3456, nVidia driver - 285.62, intel driver - .2509. W7 HP x64
HW: i5-2410M + GT540M.

[egur]

With new version QS decoding doesn't work on any video o_O
ffdshow is prefered decoder, so on older versions it works perfectly. But with 1.17 mpc-hc is using next decoder (lav decoder, in my case). If I change QS decoder (in ffdshow settings) to libavcodec - ffdshow works as it should (but, obviously, without QS).
I've rolled back to older version - everything behave as it should. Than updated to new version - QS is not working again. So, problem is not in the system settings...
SW: MPC-HC 1.5.2.3456, nVidia driver - 285.62, intel driver - .2509. W7 HP x64
HW: i5-2410M + GT540M.

Just reinstalled 32 and 64 bit using the installers (they also register the filters) and no prb on mpc-hc 32 and 64 (same build as yours). All DLLs exist, double checked with dependency walker to make sure the debug builds didn't escape.
Even deleted the files in program files and reinstalled again, still works.
Does anyone else have issues?

[JEskandari]

well ,when I want to use this as decoder for potplayer I receive this error
"Unhandled exception occurred [0xc0000005@0x6EEA545A] at
IntelQuickSyncDecoder.dll
Additional exception information has been stored locally
and this application will be terminated"

and when I use mpc-hc it crash with this error report
Problem signature:
Problem Event Name: APPCRASH
Application Name: mpc-hc.exe
Application Version: 1.5.2.3456
Application Timestamp: 4e29d332
Fault Module Name: IntelQuickSyncDecoder.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4ea5f220
Exception Code: c0000005
Exception Offset: 0000545a
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


by the way the system I yried this on have a core I3 2310m and
no discrete gpu only hd3000 and I have installed the latest Intel
driver

[egur]

well ,when I want to use this as decoder for potplayer I receive this error
"Unhandled exception occurred [0xc0000005@0x6EEA545A] at
IntelQuickSyncDecoder.dll
Additional exception information has been stored locally
and this application will be terminated"


I've found a strange issue with potplayer - the HW vc1 decoder fails to play interlaced VC1 clips that mpc-hc and ZoomPlayer play well. This is a splitter difference. Using Haali or LAV splitters solve the issue. I'll look into the matter further.

Regarding MPC-HC I didn't have a single issue. I need more information:
* All videos crash or a specific clip? If a single clip, please share.
* Driver version
* splitter used.
* Renderer used.
* Other non default setting for player
* Clip has subtitles or not. Which filter renders the subs.

Did you try other splitters?

[egur]

New and improved version. Zip files contains installer and documentation, please read.

Download version 0.18 alpha:
32 bit http://www.multiupload.com/VWSVG172HQ
64 bit http://www.multiupload.com/AR3VDNBA6P
Source code http://www.multiupload.com/UQEUJB4WST

Revision highlights:
v1.18:
* Fixed FFDShow’s H264 sequence header parsing crash. A lot of users reported crashes with the last build. This was a long standing FFDShow issue that affected specific clips.
* Added black borders to images with non 16 modulo width. Retaining non standard width can cause downstream filters to crash (dvobsub/vsfilter).

[vivan]

With new version my problem was fixed. Thanks!

[egur]

With new version my problem was fixed. Thanks!

Great!

BTW, Potplayer's internal splitter is still not supported. So is WMC full screen. For the latter I have no clue as to why ffdshow is not loaded and since it's fullscreen exclusive it's impossible to debug with a single screen :(. If someone has any insight on this let me know.

[boliver10]

I have an I7 2600k processor and two monitors (with two HDMI from the motherboard directly: no separate videocard)

My test is 4:2:0 interlaced PAL mkv MPEG2 file.

But when I run your FFDShow (with Intel selected for all MPEG2) I still get libavcodec running. And I have interlacing lines...

I'm using MPC-HC and am sure FFDShow is being used.

What can I do?

Note, I also get interlace lines with Microsoft's DTV codec.

[egur]

I have an I7 2600k processor and two monitors (with two HDMI from the motherboard directly: no separate videocard)

My test is 4:2:0 interlaced PAL mkv MPEG2 file.

But when I run your FFDShow (with Intel selected for all MPEG2) I still get libavcodec running. And I have interlacing lines...

I'm using MPC-HC and am sure FFDShow is being used.

What can I do?

Note, I also get interlace lines with Microsoft's DTV codec.

Deinterlacing is (usually) performed by the renderer.
Try the following setup:
Select EVR as a renderer (in MPC-HC press "O" then "output").
In ffdshow configuration uncheck the deinterlacing check box.

Note that some renderers do not perform deinterlacing.

If you still see interlace lines (lack of deinterlacing), I'll need to see the clip myself. Maybe the clip is flagged wrong. Please share it (or a portion of it). A large clip will take time to download. www.multiupload.com is the easiest way to go.

[CruNcher]

Egur finally having the capability to do this http://www.mediafire.com/download.php?6uhkiqiajnak5c4 a side by side compare of ffdshows-quicksync (left PID:6276) overhead vs cyberlink native dxva (right PID:7524) :)

[egur]

Egur finally having the capability to do this http://www.mediafire.com/download.php?6uhkiqiajnak5c4 a side by side compare of ffdshows-quicksync (left PID:6276) overhead vs cyberlink native dxva (right PID:7524) :)

Relatively high cpu usage, what are the details (resolution, CPU type, output surface format, etc.)

[egur]

SourceForge homepage:
http://sourceforge.net/p/qsdecoder
Currently only useful for source control (SVN).

FFDshow code changes where merged to FFDshow's code trunk. Will be part of next official FFDshow release (very similar to 0.18 alpha).

Next on my task list (v0.19):
* Create configuration to enable/disable certain features as asked by several developers for easy integration.
* Fix fullscreen problem in WMC (not loading ffdshow for some reason).
* Export D3D surfaces (DXVA2 samples) instead of system memory buffers. Will provide DXVA speed without actually dealing with DXVA...

If all goes well, version 0.20 will add video postprocessing (deinterlacing, film cadence correction, noise reduction, sharpness, etc.)

[rsd78]

Hi Eric,

Very interested by your work here! Will definitely check it out once the WMC fullscreen issue is fixed since I'm a WMC only user. One question I did have is since this is using ffdshow, will using the Mediacontrol plugin continue to work as well? Mediacontrol is huge for me (easy sub/audio stream control and ff/rew), so I'm hoping so.

Thanks for your great work!

[nevcairiel]

I just looked over your ffdshow changes, and for the record: Its always much nicer to keep changes separated amongst multiple commits. For example, the bug fixes and the addition of the QS decoder should've at least been two commits, or more. Just sayin', its not my project or anything. :)

One thing i noticed though. Your sse2 memcpy seems superflous. If ffdshow is configured to use function intrinsics, the MS compiler will already use a optimized memcpy using sse2 if available. I did some testing along those lines recently, and a custom sse2 memcpy was actually not faster.
In addition to that, i don't think ffdshow had a hard dependency on sse2 before.

[egur]

I just looked over your ffdshow changes, and for the record: Its always much nicer to keep changes separated amongst multiple commits. For example, the bug fixes and the addition of the QS decoder should've at least been two commits, or more. Just sayin', its not my project or anything. :)
Usually, yes, but it was hard to separate everything since a lot have changed.

One thing i noticed though. Your sse2 memcpy seems superflous. If ffdshow is configured to use function intrinsics, the MS compiler will already use a optimized memcpy using sse2 if available. I did some testing along those lines recently, and a custom sse2 memcpy was actually not faster.
In addition to that, i don't think ffdshow had a hard dependency on sse2 before.
Maybe VS2010 got it right :) I just copied the function from an another program that was compiled on vs2005. Back then, it was 2x faster (on Core2Duo and P4).
SSE2 implies a Pentium 3 or early 4 if I remember correctly. Not a crazy dependency :)

I'll run a few more tests and kill it if performance is not gained.

[egur]

Hi Eric,

Very interested by your work here! Will definitely check it out once the WMC fullscreen issue is fixed since I'm a WMC only user. One question I did have is since this is using ffdshow, will using the Mediacontrol plugin continue to work as well? Mediacontrol is huge for me (easy sub/audio stream control and ff/rew), so I'm hoping so.

I'll try the Media Control plugin, shouldn't be a problem as I didn't change the ffdshow API. I'll probably fix the WMC issue soon. Been busy lately.

Thanks for your great work!
10x

[CruNcher]

Relatively high cpu usage, what are the details (resolution, CPU type, output surface format, etc.)

Video: NV12 1920x1080 59.94fps, Intel Core I-5 2400

General
Complete name : G:\WipEout_HD_English_1080p.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 171 MiB
Duration : 1mn 11s
Overall bit rate : 19.9 Mbps
Encoded date : UTC 2008-08-01 17:57:37
Tagged date : UTC 2008-08-01 17:57:43

Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.2
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1mn 11s
Bit rate : 19.8 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.159
Stream size : 169 MiB (99%)
Language : English
Encoded date : UTC 2008-08-01 17:57:05
Tagged date : UTC 2008-08-01 17:57:43
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 1mn 11s
Bit rate mode : Constant
Bit rate : 144 Kbps
Nominal bit rate : 160 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 1.25 MiB (1%)
Language : English
Encoded date : UTC 2008-08-01 17:57:04
Tagged date : UTC 2008-08-01 17:57:43
Material_Duration : 71851
Material_StreamSize : 1314528

interesting with Cyberlinks Decoder i get additional the Line 21 Decoder 2 loaded ? wasn't line 21 a Analog thing ?

This gets loaded on EVR Input 1 with Cyberlink DXVA

Filter: Line 21 Decoder 2
Pin: XForm Out

- Connection media type:

Video: AI44 720x480 29.97fps 82861kbps

Hmm the Filter is in quartz.dll so it's coming from Microsoft i never saw this one on XP

ffdshow-quicksync though doesn't load it

http://msdn.microsoft.com/en-us/library/windows/desktop/dd390642%28v=vs.85%29.aspx

yep it's the analog line that was used to transmit different types of data back in the Analog days (videodat,captions) seems Cyberlink loads it by default with some data strange or there is some hidden analog data in this Sony stream :P.

Filter : CyberLink Video Decoder (PDVD11) - CLSID : {9699092D-91FC-4DA1-8A63-112D865EB1D2}

- Connected to:

CLSID: {E4206432-01A1-4BEE-B3E1-3702C8EDC574}
Filter: Line 21 Decoder 2
Pin: XForm In

- Connection media type:

Unknown

AM_MEDIA_TYPE:
majortype: MEDIATYPE_AUXLine21Data {670AEA80-3A82-11D0-B79B-00AA003767A7}
subtype: MEDIASUBTYPE_Line21_GOPPacket {6E8D4A23-310C-11D0-B79A-00AA003767A7}
formattype: FORMAT_None {0F6417D6-C318-11D0-A43F-00A0C9223196}
bFixedSizeSamples: 1
bTemporalCompression: 1
lSampleSize: 200
cbFormat: 0

- Enumerated media type 0:

Set as the current media type

Seems indeed Cyberlink opens it by default now, i get it loaded for every stream :D (never experienced this before seems to be new behavior)

PS: Egur i checked more carefully into the overhead and it seems without Quick Sync Recording the CPU usage is 10% @ playback with ffdshow quicksync and it increases it to 20% while Recording also Cyberlink DXVA Cpu usage increases while Recording but not by such a heavy amount just 2% more from 1 to 3%. So Recording with Quick Sync @ the same time currently seems to lower the efficiency of the Decoder somehow expected that also recording time critical stuff (D2D Browser Demos) shows a slowdown (low latency recording helps here a little).
Yup it seems there are more GPU resources allocated to the Recording that get lost for the Decoding and so CPU usage inreases :)

[egur]

PS: Egur i checked more carefully into the overhead and it seems without Quick Sync Recording the CPU usage is 10% @ playback with ffdshow quicksync and it increases it to 20% while Recording

That's more aligned to what I see for 1080p@60.
BTW, when I'll add HW deinterlacing, this is the expected performance (for outputting 1080p@60).

I can live with this level of performance but maybe driver improvements can lower CPU usage - more than half the CPU usage within my decoder DLL (not in FFDSHOW) goes into locking the D3D surface - slower than copying the surface back to system memory...

[egur]

Current version has a limitation that was exposed by Windows Media Center.
It can't initialize in full screen exclusive mode.
The D3D surfaces are allocated through a D3D9 device created with IDirect3D9::CreateDevice(). It's not used to display anything.

Only in full screen exclusive mode (which WMC seem to use) CreateDevice fails.

Does anyone have a workaround?

[nevcairiel]

What you could try is ask the EVR for the device. Part of the whole DXVA APIs is a Interface to get the device from the renderer.

Luckily for me, CUVID also functions without a D3D device, so i have never had to try (yet).

Edit:
Specifically this: http://msdn.microsoft.com/en-us/library/windows/desktop/ms704727(v=vs.85).aspx

[JanWillem32]

Indeed, that's the regular DXVA helper. Note that it's not actually an EVR object. It inherits from DXVA2.dll, and calls mfplat.dll. typedef HRESULT (WINAPI *DXVA2CreateDirect3DDeviceManager9Ptr)(__out UINT *pResetToken, __out IDirect3DDeviceManager9 **ppDXVAManager);
DXVA2CreateDirect3DDeviceManager9Ptr pfDXVA2CreateDirect3DDeviceManager9;
m_hDXVA2Lib = LoadLibrary(L"dxva2.dll");
if (m_hDXVA2Lib) pfDXVA2CreateDirect3DDeviceManager9 = reinterpret_cast<DXVA2CreateDirect3DDeviceManager9Ptr>(GetProcAddress(m_hDXVA2Lib, "DXVA2CreateDirect3DDeviceManager9"));
else {
_Error += L"Could not find dxva2.dll\n";
hr = E_FAIL;
return;}edit:
If you're using a device passed to DXVA2CreateVideoService (http://msdn.microsoft.com/en-us/library/windows/desktop/ms704721%28v=VS.85%29.aspx), make sure that the HWND pointer used when creating the device isn't linked to a monitor that will be used for exclusive mode.

[egur]

Problem is that my decoder is not connected to the renderer, it's unaware of the graph. I can redesign
Currently I create my own device but it fails in fullscreen (only when decoder is instantiated during fullscreen)

[nevcairiel]

Its the only way. In FSE Mode you cannot create a new device, you have to use the one the EVR gives you.

[egur]

Its the only way. In FSE Mode you cannot create a new device, you have to use the one the EVR gives you.

Thanks.
Can you point me to the relevant reading material? I didn't see this anywhere.

Update:
I was referred to this article:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb147220(v=vs.85).aspx

Basically this mean I can create a device when these conditions are met:
* They are created by the same Direct3D object that created the device that is full-screen.
* They have the same focus window as the device that is full-screen.
* They represent a different adapter from any full-screen device.

So nevcairiel is right :( . I need to postpone decoder initialization after the graph is connected which is a little ugly for current use cases and requires a shotgun surgery in ffdshow's code. Future use cases (output DXVA samples) will enjoy this design change as I'll be able to know how many surfaces are queued in the renderer.

[Blight]

CruNcher:
Line21 still exists in digital format (see DVDs or M2TS content grabbed from DTV streams), mainly for Closed Captions.

[egur]

If you're using a device passed to DXVA2CreateVideoService (http://msdn.microsoft.com/en-us/library/windows/desktop/ms704721%28v=VS.85%29.aspx), make sure that the HWND pointer used when creating the device isn't linked to a monitor that will be used for exclusive mode.

Thanks for your help but I'm not sure this is a viable option in all cases:
* When there's just 1 GPU and one screen.
* Even in multi GPU setups I don't know how to do this :(

My home setup has 2 GPUs Intel + AMD. The screen is connected to the AMD and I still can't create the device on the Intel GPU.
Maybe I send an HWND that's associated with the AMD-connected monitor. But I don't know how to create an generic HWND on the other monitor that will actually result in a functioning d3d device...

[dukey]

EVR sets things up like this
creates a window 1x1 pixels in size

D3DPRESENT_PARAMETERS pp;
ZeroMemory(&pp, sizeof(pp));

pp.BackBufferWidth = 1;
pp.BackBufferHeight = 1;
pp.Windowed = TRUE;
pp.SwapEffect = D3DSWAPEFFECT_COPY;
pp.BackBufferFormat = D3DFMT_UNKNOWN;
pp.hDeviceWindow = hwnd;
pp.Flags = D3DPRESENTFLAG_VIDEO;
pp.PresentationInterval = D3DPRESENT_INTERVAL_DEFAULT;

doesn't use that for rendering. It creates addition swap chains which it renders into, and presents when they are done. Don't know if that helps.

[JanWillem32]

That points out the hwnd handle nicely. Creating the window handle window handle with WS_MINIMIZE|WS_POPUP and possibly WS_DISABLED should work. http://msdn.microsoft.com/en-us/library/windows/desktop/ms632679%28v=VS.85%29.aspx
If creating it minimized is a problem, using CloseWindow should also do the trick of minimizing it. http://msdn.microsoft.com/en-us/library/windows/desktop/ms632678%28v=VS.85%29.aspx
Also, structs can be assigned on creation. Using ZeroMemory is more something for class members (and also only if you can't zero them on class initialization).
D3DPRESENT_PARAMETERS pp = {1, 1, D3DFMT_X8R8G8B8, 1, D3DMULTISAMPLE_NONE, 0, D3DSWAPEFFECT_DISCARD, hWnd, TRUE, FALSE, D3DFMT_UNKNOWN, 0, 0, D3DPRESENT_INTERVAL_IMMEDIATE};

[nevcairiel]

For readability, everyone should always favor the syntax as dukey posted it. For complex structs like that, using the inline initializers is just asking for trouble.

[JanWillem32]

That would most certainly extend the size of the renderers I'm working on considerably (the color management section declares dozens of various structs). Also, I often declare structs like this as static const. Using ZeroMemory might inhibit making elements "rommable" (a syntax of: D3DPRESENT_PARAMETERS pp = {0}; is illegal in this case). I usually just add comments to mark the interesting bits (most elements of this type of struct are 0 or 1). In this case only the hWnd parameter is worth noting, the rest just describes parameters for a 1×1 pixel backbuffer without extras.

[nevcairiel]

If the code is already too long, using these things to "shorten" it is the worst idea ever. It'll just make already long code even harder to read/understand.

[dukey]

the point i was trying to make was EVR creates and renderers into additional swap chains, it doesn't depend on the window really, as the size of the back buffer for the window created was only 1x1.

[egur]

That points out the hwnd handle nicely. Creating the window handle window handle with WS_MINIMIZE|WS_POPUP and possibly WS_DISABLED should work. http://msdn.microsoft.com/en-us/library/windows/desktop/ms632679%28v=VS.85%29.aspx
If creating it minimized is a problem, using CloseWindow should also do the trick of minimizing it. http://msdn.microsoft.com/en-us/library/windows/desktop/ms632678%28v=VS.85%29.aspx


Doesn't work :( I created the hWnd like you specified, tried offscreen coordinates (9999,9999), minimized, etc. Will not work in FS only in windowed mode.

If you've verified that it works in your system (in FSE), please send the me the device creation code starting from hWnd creation up to the call to CreateDevice.

Thanks!

[vivan]

Added black borders to images with non 16 modulo width. Retaining non standard width can cause downstream filters to crash (dvobsub/vsfilter).Is it possible to remove this "feature"?
1) There are a lot of people who are not using such... filters. For them it makes things only worse - e.g. 712x400 is 16:9, if you add 8pix border it would be 720x400 and you will have to enjoy top, right and bottom black borders on 16:9 display.
2) ffdshow already has such feature - resize & aspect filter - "expand to next multiple of 16".

[egur]

Is it possible to remove this "feature"?
1) There are a lot of people who are not using such... filters. For them it makes things only worse - e.g. 712x400 is 16:9, if you add 8pix border it would be 720x400 and you will have to enjoy top, right and bottom black borders on 16:9 display.
2) ffdshow already has such feature - resize & aspect filter - "expand to next multiple of 16".

Nev has already asked for this removal and I agreed.
What I plan to do is enable/disable this feature via config. This way the DS filter can control what's going on. I hope this will make everyone happy.
I personally use vobsub and it's quite common - that's why I implemented it in the first place.

The default will be to enable mod16 width because stability overrides quality.

BTW, ffdshow will copy the image with a significant performance penalty so it's not a good option.

[CruNcher]

Egur this is really cool http://www.mediafire.com/download.php?d0bg6khk2lk8bjl due to the vsync background noise completely gone you can immediately see what the Broadcast Encoder did wrong (without needing to look @ the bitstream) :) it happens @ every keyframe :)

I tried to get the same resolution with ffdshow-quicksync but it shows strange peakings and get a lock sometimes @ 25 fps
the nicetest scene shows extreme jitter also 16ms


Peaking wrong lock issue (telecine mpeg-2):

http://www.mediafire.com/?gauc931m49hya51

Heavy jitter issue (H.264 Interlaced):

http://www.mediafire.com/?x2crc2tuoq9il29

Interesting disabling Deinterlace auto flag output in ffdshow-quicksync fixes both of these issues but obviously no Deinterlacing anymore (which though is only really problematic for the Interlaced H.264 stream)

Though there is still strange peaking periodically going on for the telecined stream and jitter changes from 0.4xxms upto 2ms very strange, ahhh it loses the lock on the next keyframe again :) :(

Lock Lost issue (telecine mpeg-2):

http://www.mediafire.com/?tii7ytnm7di6ck4

[egur]

Egur this is really cool http://www.mediafire.com/download.php?d0bg6khk2lk8bjl due to the vsync background noise completely gone you can immediately see what the Broadcast Encoder did wrong (without needing to look @ the bitstream) :) it happens @ every keyframe :)

I tried to get the same resolution with ffdshow-quicksync but it shows strange peakings and get a lock sometimes @ 25 fps
the nicetest scene shows extreme jitter also 16ms


Peaking wrong lock issue (telecine mpeg-2):

http://www.mediafire.com/?gauc931m49hya51

Heavy jitter issue (H.264 Interlaced):

http://www.mediafire.com/?x2crc2tuoq9il29

Interesting disabling Deinterlace auto flag output in ffdshow-quicksync fixes both of these issues but obviously no Deinterlacing anymore (which though is only really problematic for the Interlaced H.264 stream)

Though there is still strange peaking periodically going on for the telecined stream and jitter changes from 0.4xxms upto 2ms very strange, ahhh it loses the lock on the next keyframe again :) :(

Lock Lost issue (telecine mpeg-2):

http://www.mediafire.com/?tii7ytnm7di6ck4

I'm on a business trip this week, so I'll take a look at it when i return. Thanks!

[JanWillem32]

Doesn't work :( I created the hWnd like you specified, tried offscreen coordinates (9999,9999), minimized, etc. Will not work in FS only in windowed mode.

If you've verified that it works in your system (in FSE), please send the me the device creation code starting from hWnd creation up to the call to CreateDevice.

Thanks!That's too bad. Let's first try something else. What errors does the DirectX debug runtime give in a tracing debug session? (Don't forget to define D3D_DEBUG_INFO globally in the project and enable the Direct3D debug runtime in the "Microsoft DirectX SDK (June 2010)\Utilities\bin\x64\dxcpl.exe" or "Microsoft DirectX SDK (June 2010)\Utilities\bin\x86\dxcpl.exe" utility.)
I hope you'll enjoy your trip, and hear from you later on.

[skingery]

I used to use LAV for splitting, audio and video. Recently I rebuilt my HTPC with a Sandybridge processor so I thought I'd give this build a try for video.
For a renderer, what are people generally using EVR, EVR CP or madVR?

[kwlee]

Hi,
I'm a newbie here, and testing about limitation issue...
There should not be a (practical) limit. I can modify ffdshow to revert to libavcodec if initialization fails. Most likely that the platform will run out RAM before this happens.


I am testing about h264 & DVXA2 by ffdshow to see how many applications(graphstudio.exe) can playback at the same time.

The maximun number is 6, the 7th graphstudio will fail. I have tested on both nVidia GT430 and AMD Radeon 6900 series...

Is that the limitation of ffdshow? and will the limitation same as this intel project ?

Thanks!

[egur]

Hi,
I'm a newbie here, and testing about limitation issue...


I am testing about h264 & DVXA2 by ffdshow to see how many applications(graphstudio.exe) can playback at the same time.

The maximun number is 6, the 7th graphstudio will fail. I have tested on both nVidia GT430 and AMD Radeon 6900 series...

Is that the limitation of ffdshow? and will the limitation same as this intel project ?

Thanks!

I gave up after 12 graph studios. GPU RAM is probably the bottleneck, if you play multiple instances of an H264, full HD, with lots of reference frames, a lot of GPU RAM is used, limiting the amount of instances. BTW, if you've lowered the amount of RAM the GPU uses (BIOS setup) than the instance count will be lower.

[egur]

The first official build of ffdshow with Intel QuickSync decoder can be downloaded from the ffdshow's download page at:
http://ffdshow-tryout.sourceforge.net/download.php

Same QuickSync decoder as v0.18, ffdshow itself contains changes mostly for subtitles.

This thread will continue to supply ffdshow builds for continuous testing of my decoder's versions.

[kwlee]

I gave up after 12 graph studios. GPU RAM is probably the bottleneck.
Ya, If I test ffdshow by libavcodec, It can easy up to 12 graph studios with 1080P avi files.

If I test ffdshow by DXVA2, even by smaller h264 video files,
the graph studio limitation is still 6, no idea why :(

My purpose is for TV wall...

[kwlee]

Hi, A programming issue about progressive frame flag,

In QuickSync.cpp
mfxU32 CQuickSync::PicStructToDsFlags(mfxU32 picStruct)

if (picStruct == MFX_PICSTRUCT_PROGRESSIVE)
{
return AM_VIDEO_FLAG_WEAVE; --> Is it better to use "AM_VIDEO_FLAG_INTERLEAVED_FRAME" ?
}

[egur]

Hi, A programming issue about progressive frame flag,

In QuickSync.cpp
mfxU32 CQuickSync::PicStructToDsFlags(mfxU32 picStruct)

if (picStruct == MFX_PICSTRUCT_PROGRESSIVE)
{
return AM_VIDEO_FLAG_WEAVE; --> Is it better to use "AM_VIDEO_FLAG_INTERLEAVED_FRAME" ?
}

This is done to insure that a deinterlacer will not run on this frame. AM_VIDEO_FLAG_INTERLEAVED_FRAME means that both fields exist. Do you see any issues with this?

[nevcairiel]

AM_VIDEO_FLAG_WEAVE is the right flag for progressive. AM_VIDEO_FLAG_INTERLEAVED_FRAME actually has the value 0, and is therefor always set. Most images we deal with here always have two interleaved fields - singe fields are rather uncommon.

[kwlee]

This is done to insure that a deinterlacer will not run on this frame. AM_VIDEO_FLAG_INTERLEAVED_FRAME means that both fields exist. Do you see any issues with this?
During my test it's no problem(TBF, I don't have too many
test sample files)

http://msdn.microsoft.com/en-us/library/windows/desktop/dd373499(v=vs.85).aspx

AM_VIDEO_FLAG_WEAVE "This flag applies only when there are two fields per sample. " As MSDN explains..

Maybe someone can help to explain more..:)

[nevcairiel]

A progressive frame contains two "fields", you're just not supposed to handle them separately.

[egur]

a video frame can basically come from two sources - interlaced or progressive.
In the former, the 2 fields (called top/bottom or odd/even) are from different times. Each field has half the lines of the original frame. Due to the different time stamps, they should be interpolated (several methods exist) to a full frame (e.g. deinterlaced).
In a progressive frame, there's no notion of fields, the image has all the lines and no deinterlacing is needed.

A special case is what's called "film". A video that was shot in progressive and later artificially split into fields (mostly TV broadcast and DVDs). In "film" content, the fields share the same time stamps and need to processed as progressive frames. A deinterlacer and/or a decoder will usually have a film detector mechanism of some sort as a standard deinterlacer will produce horrible artifacts for some content.

There's also the matter of how CbCr is stored (4:2:0 only). If the frame is progressive, CbCr values are stored for two consecutive lines. For interlaced content, it's stored for two consecutive lines of a specific field. Simply weaving the lines will produces color artifacts even if there's no motion.

[egur]

Version 0.19 is out with the following changes:
* Added limited support for WMC full screen exclusive mode:
- Renderer must be connected to the decoder directly - no intermediate filters.
- Screen is connected to the Intel GPU (decoder shares device with renderer).
- Might only work on single monitor setups.
* Decoder has exposed its configuration options GetConfig/SetConfig - must be called before initialized.
* Padding the image to mod16 width is now off by default. Works with vobsub.
* Decoder can be tested for compatibly with media types via the TestMediaType method
* FFDShow rev4126

Download from SourceForge home page:
http://sourceforge.net/p/qsdecoder

[haruhiko_yamagata]

Thanks a lot for the update.
Can I ask several questions and requests? Please excuse me for not reading all of this thread. I read several pages. I do not have sandy bridge and can not test your decoder.
I would like to ask you to add an entry to our wiki (http://ffdshow-tryout.sourceforge.net/wiki/video:codecs) and answer these questions. I think most of my questions are FAQ.
Version 0.19 is out with the following changes:
* Added limited support for WMC full screen exclusive mode:
- Renderer must be connected to the decoder directly - no intermediate filters.
- Screen is connected to the Intel GPU (decoder shares device with renderer).
- Might only work on single monitor setups.

Can ffdshow output other color spaces than NV12?
Can ffdshow resize?
If screen is not connected to the Intel GPU, and the renderer is not the WMC full screen, does your decoder work?

* Padding the image to mod16 width is now off by default. Works with vobsub.

Are the strides aligned? ffdshow exhibit its bugs and heavy loss of performance for several features if the strides are not aligned. I may able to fix the bugs, but not the performance issue.

Additional FAQ for the wiki:
How fast is this?
For what kind of video is this useful?
Which profiles of H.264 does this support?
Can this output 10/12-bit formats?

[nevcairiel]

For what kind of video is this useful?
Which profiles of H.264 does this support?
Can this output 10/12-bit formats?

- It supports the same formats as DXVA, so only 8-bit 4:2:0 (MPEG2, H264 and VC1)
- H264 High profile, no 10-bit or 4:2:2/4:4:4
- See above, only 8-bit. Output is always NV12.

[egur]

Thanks a lot for the update.
Can I ask several questions and requests? Please excuse me for not reading all of this thread. I read several pages. I do not have sandy bridge and can not test your decoder.
I would like to ask you to add an entry to our wiki (http://ffdshow-tryout.sourceforge.net/wiki/video:codecs) and answer these questions. I think most of my questions are FAQ.

If I have permissions, I'll add the following questions to the Wiki. No prb.

Can ffdshow output other color spaces than NV12?
Can ffdshow resize?
If screen is not connected to the Intel GPU, and the renderer is not the WMC full screen, does your decoder work?
Are the strides aligned?
How fast is this?
For what kind of video is this useful?
Which profiles of H.264 does this support?
Can this output 10/12-bit formats?

* HW Decoder only outputs NV12, but ffdshow converts the output to what was agreed with the downstream filter.
* ffdshow can perform all of it's post processing as long as they work well with NV12 input. swscale had issues with NV12->NV12 copies so I changed ffdshow's code to use a nother copy method. Now I didn't see any issues and none where reported to me on the matter.
* With the exception of WMC FS, multi GPU setups are working (I personally have this setup AMD Radeon HD6950). I'm working on fixing WMC FS with multi GPU setup - partial success.
* Strides are always 16 byte aligned.
* How fast? Worst case scenario is ~2x faster than libavcodec (low bitrate clips). Speed difference is greater for high bitrate clips. CPU frequency stays at LFM (800MHz mobile/ 1600MHz Desktop) for the duration of playback. CPU overhead is usually related to image resolution and frame rate and not birate since I copy the frames to system memory.
* Decodes H264 up to and including high profile. MPEG2 - all expect the 4:2:2 profile. VC1 - advanced profile in HW, MP&SP in SW. Future HW will support more video formats.
* Unfortunately, HW only decodes 8 bit 4:2:0 formats ATM :(. The decoder only outputs only NV12. This might change in the future. I can't commit on this.

[haruhiko_yamagata]

Thank you very much for reply.
You can register to the wiki here (http://ffdshow-tryout.sourceforge.net/wiki/video:codecs?do=register). Please note that the wiki cannot sent any e-mails, even if it says it would. For example, password retrieval through e-mail is not available.

[Esperado]

Hi, Egur.
I have tried last FFdshow with QuickSync in DvbViewer. I wonder why it eats more CPU than CoreAVC, with my Radeon HW acceleration (DXVA) for example.
Don't it is supposed to use only Hardware?
I do not see any difference if i pluga monitor in the intel VGA output or not. And, if not, and if i start DVBViewer by Virtu, it eats more CPU..
Thanks for your sharing and you work, anyway.
I wonder why Intel does not provide codecs using directly the Sandy Bridge acceleration ?
Best regards.

[egur]

Hi, Egur.
I have tried last FFdshow with QuickSync in DvbViewer. I wonder why it eats more CPU than CoreAVC, with my Radeon HW acceleration (DXVA) for example.
Don't it is supposed to use only Hardware?
I do not see any difference if i pluga monitor in the intel VGA output or not. And, if not, and if i start DVBViewer by Virtu, it eats more CPU..
Thanks for your sharing and you work, anyway.

It uses HW for decoding but the frame are copied back to CPU memory for further processing, hence the non zero CPU usage.
Make sure you selected Intel QuickSync as the decoder in ffdshow's codec tab for h264,mpeg2,vc1.

I wonder why Intel does not provide codecs using directly the Sandy Bridge acceleration ?
Best regards.
Actually decoders are shipped with the driver.
BTW Microsoft's DVT-DVD decoder also uses HW acceleration - when connected to an EVR renderer but it fails on some types of clips - but will work on most content.
Using a pure DXVA playback pipeline is very restrictive - decoder must connect directly to a special renderer, decoder output can't be modified by the renderer, etc.
My solution of copying the images comes at a price but it's much more versatile.

[haruhiko_yamagata]

Egur, thank you very much for the wiki (http://ffdshow-tryout.sourceforge.net/wiki/video:codecs).
Now we have a good summary for our new decoder.
fastplayer, thank you for the update.

[Esperado]

It uses HW for decoding but the frame are copied back to CPU memory for further processing, hence the non zero CPU usage.
My solution of copying the images comes at a price but it's much more versatile.
As it cost *more* CPU than other ordinary hardware accelerated codecs, and i do not see any much better quality in real time TNT decoding (specially about De-interlacing), i believe i will forget the graphics from my Sandy Bridge to save some power and temp.
The interest, for me -and the reason why i was interested in those Sandy Bridge- was to can watch TNT on my PC with no CPU load. Some kind of TV/Monitor set.
Make sure you selected Intel QuickSync as the decoder in ffdshow's codec tab for h264,mpeg2,vc1.Of course i did. And tried everything. Monitor connected on motherboard VGA or not (no changes), Virtu or not (It eats more CPU, launching DvbViewer with Virtu, and no noticeable quality change...)



Actually decoders are shipped with the driver but they are not very good. This is something I'm trying to improve behind the scenes.You made a very nice work. Shame it is unofficial.
In fact, i found no Intel Codecs registered for Direct show on my computer after Install, and i only found your thread after a long research on Google. I'm very disappointed with Intel position, in that matter, marketing announces effects, and nothing usable for real time decoding, apart your personal work in fact ? Unbelievable from such a big company.

[egur]

As it cost *more* CPU than other ordinary hardware accelerated codecs, and i do not see any much better quality in real time TNT decoding (specially about De-interlacing), i believe i will forget the graphics from my Sandy Bridge to save some power and temp.
The interest, for me -and the reason why i was interested in those Sandy Bridge- was to can watch TNT on my PC with no CPU load. Some kind of TV/Monitor set.
Of course i did. And tried everything. Monitor connected on motherboard VGA or not (no changes), Virtu or not (It eats more CPU, launching DvbViewer with Virtu, and no noticeable quality change...)


The frame copying paradigm allows decode flows unavailable to DXVA decoders - avisynth acceleration, multi-GPU setup (decoder on SNB + high-end renderer like MadVR on dGPU). The performance price is small.

Virtu isn't needed with my decoder. It would be useful with a DXVA decoder.

You made a very nice work. Shame it is unofficial.
In fact, i found no Intel Codecs registered for Direct show on my computer after Install, and i only found your thread after a long research on Google. I'm very disappointed with Intel position, in that matter, marketing announces effects, and nothing usable for real time decoding, apart your personal work in fact ? Unbelievable from such a big company.

One can always use Microsoft's DTV-DVD decoder which ships with Win7. But this decoder isn't 100% working on my test suite... But it works on most content.

[CruNcher]

Internally I'm pushing for better HW enablement (SW, docs, sample code) - for both end-users and independent developers. My work has created a lot of positive noise within Intel and it's one step forward towards high quality enablement.

Great news hope those responsible @ Intel see the chance like Nvidia did right from the VPx start way back then, it's to sad to see a lot of times such engagement smashing @ the big chairs for whatever stupid reasons, though i have to say Intels Ecosystem around it's hardware is much better from the start compared to how catastrophic it was with AMDs taking themselves years of time and then come up with something that no one really likes to implement ;)
Not that i didn't expected Intels SB support for all classes to be awesome from the start ;) but i was skeptical after the ATI disaster that only Nvidia might have realized the chance about such a strong community Ecosystem from Devs to End users :)
Though since my move back from AMD to Intel i wasn't yet disappointed (ok the bad B2 stepping thing was a big disaster itself but fast fixed without compromise, personally i decided i don't need the B3 anyways ;) )

Btw Eric are you and Blight related to each other family wise or is the surname match just a coincidence :) are you maybe brothers would make sense somehow as he also knew something about your past work i wondered ?

[haruhiko_yamagata]

In ffdshow's codecs configuration page, IntelQuick Sync Decoder is listed for MPEG-1, but is this working? Because it is not listed in TglobalSettingsDecVideo::c_mpeg1, I suspect it is not working. Can I remove MPEG-1 support?

[egur]

In ffdshow's codecs configuration page, IntelQuick Sync Decoder is listed for MPEG-1, but is this working? Because it is not listed in TglobalSettingsDecVideo::c_mpeg1, I suspect it is not working. Can I remove MPEG-1 support?

Yes, my mistake, please remove.
Maybe the decoder supports mpeg1 but for such low resolution clips, there no point to do HW acceleration. FFDShow's support for mpeg1 is already very good.

[egur]

...

Btw Eric are you and Blight related to each other family wise or is the surname match just a coincidence :) are you maybe brothers would make sense somehow as he also knew something about your past work i wondered ?

Yes, we are brothers. Good catch :)

[egur]

Version 0.20 is out with the following changes:
* Fixed support for WMC full screen exclusive mode:
- Works with multi-GPU setups. Video decoding is HW accelerated using QuickSync. Renderer can be on a different GPU.
- WMC's background thumbnail creation is done in SW
* FFDShow rev4149

Download from SourceForge home page:
http://sourceforge.net/p/qsdecoder

[Blight]

CruNcher:
Yes, we're bros :P
Eric's wanted to do something like this for years, but now he's in a good position to do so and I've been helping here and there to move things along.
Hopefully, the good people @Intel are watching... He's doing them a heck of a service, both technical and promotional.

[hhb97b]

Hi

I have been so lucky to borrow a acer aspire 7750g for a day, which has an i7 2670QM cpu and a amd radeon HD6650m gpu.
This was my opportunity to try out your decoder. It worked without a problem, but there is one thing I don't understand.
I had choosen quick sync decoder in the decoder tab and choose resize, sharpen, blur and a avs script as the configuration to test. The reason for all
the post processing was to generate as much processing instructions as possible. I used version 0.20 for intel quicksync decoder and mpc hc 1.5 as testbed.

My expectations was that quicksync decoder would handle this load better than the with the libavcodec decoder, but this is not what I saw.
My experience was that I couldn't playback a 1080P video with a bitrate of 10500 kbps at normale speed. The pikes was around 52ms/127 % for "Time on ffdshow", which means it decode slow that the movies FPS.
However when I used the same configuration with libavcodec the results was 38ms/90%. Was my expectation wrong or what could cause this experience?

[CruNcher]

the latency issue most probably comes from the memory path (main memory gpu memory copy + post processing stress on the CPU)though it's faster then with a discrete card or @ least should be dynamic frequency switching and so latency changes of the main memory can also have a impact you shuffling quiet a lot of data around @ 1080p with the additional post processing though my tests with my Quicksync recording Framework showed that it's really application dependent of what in the current task is more efficient to use a good rule of thumb i guess is the more GPU resource the main application needs the better it is to use the CPU for any other task and vice versa (trying to keep both in balance is the key to the optimum, especially with DWM and Aero it becomes more complex handling this) the more CPU resources a application uses the better it is to use the GPU finding the right balance and a dynamic way to distribute it (efficient resource scheduling) though isn't easy and very Framework dependent, though the major culprit here is the OS and the Driver itself something very rare persons have the possibility todo major changes on (see preemptive changes in WDDM 1.2 Win8) ;)

Another rule of thumb If you really need time critical performance that beats Software in most cases their is no way around native DXVA Microsoft did a excellent job on it, or you need a very strong overall system so it doesn't surprise in your case try to disable power saving and see how that impacts the latency :)

If you really need the last drop of Performance (Power Saving) on those regards in Playback with a good post pro try Mirillis Splash Player it's really excellent in Performance (very well usage of what Microsoft supplies to ISVs in the Directx API on really every level UI, Renderer (own Direct 3d based one, supporting deinterlacing and subtitles), Subbtitle Renderer (own) + very efficient usage of their own decoders DXVA + Shaders in that combination :)
It was absolutely designed with 1 goal in mind drawing and manipulating (post pro) videos on the screen as fast as possible without a lot of resources (power efficient,sheduling GPU/CPU as good as possible for the tasks) utilizing what Microsofts Provides ( i havent seen any better yet and i know a lot maybe only 1 player currently comes near that from Asia though still misses features and relies partly on other peoples code (ffmpeg vobsub lot from mpc-hc) that would be Potplayer )

[egur]

Hi

I have been so lucky to borrow a acer aspire 7750g for a day, which has an i7 2670QM cpu and a amd radeon HD6650m gpu.
This was my opportunity to try out your decoder. It worked without a problem, but there is one thing I don't understand.
I had choosen quick sync decoder in the decoder tab and choose resize, sharpen, blur and a avs script as the configuration to test. The reason for all
the post processing was to generate as much processing instructions as possible. I used version 0.20 for intel quicksync decoder and mpc hc 1.5 as testbed.

My expectations was that quicksync decoder would handle this load better than the with the libavcodec decoder, but this is not what I saw.
My experience was that I couldn't playback a 1080P video with a bitrate of 10500 kbps at normale speed. The pikes was around 52ms/127 % for "Time on ffdshow", which means it decode slow that the movies FPS.
However when I used the same configuration with libavcodec the results was 38ms/90%. Was my expectation wrong or what could cause this experience?

I managed to reproduce similar results but I haven't root caused the problem.
Several options exist:
* Memory bus is saturated like Cruncher said.
* FFDshow's video processing algorithms are not optimized for NV12 surfaces (don't know need to check).
* Maybe there's a color space conversion to YV12.

I'll need to run a profiler among other things to get to the bottom of this, but it it looks interesting. I'll report back.

With pure DXVA you get the best performance + power savings but video processing becomes tricky usually done in the renderer. The frames outputted by the decoder are used by it as reference frames and mustn't be modified. Copying the frames is an option, but that's very similar to what I do. Writing video processing (like FFDshow have) using shader language (or CUDA) isn't easy at all as can be seen by their rarity. Although I think it's possible to create a DXVA video processor filter, I'm not aware of one existing.

[hhb97b]

I believe that you are both correct

* Memory bus is saturated like Cruncher said.
I think this is the case in some situation because I couldn't use all of the cpu power even when I only used libavcodec. The cpu usage was only at 50% before the "time on ffdshow" was over 41 ms

* Maybe there's a color space conversion to YV12
I have set the "input colorspace" to yv12 under the avscript tab . I'm using the script rgb3dlut/t3dlut from tritical as colour management system. The input colorspace for the script are yuy2, rgb24, and rgb32. This means that in test-setup there would have been a colorspace-convertion like this

? -> nv12(decoder) -> yv12(avs tab) -> yuy2(script) -> rgb(script) -> output

Will the QuickSync decoder support other colorspace than nv12 or is this a limitation of the hardware?

[egur]

I believe that you are both correct

* Memory bus is saturated like Cruncher said.
I think this is the case in some situation because I couldn't use all of the cpu power even when I only used libavcodec. The cpu usage was only at 50% before the "time on ffdshow" was over 41 ms

* Maybe there's a color space conversion to YV12
I have set the "input colorspace" to yv12 under the avscript tab . I'm using the script rgb3dlut/t3dlut from tritical as colour management system. The input colorspace for the script are yuy2, rgb24, and rgb32. This means that in test-setup there would have been a colorspace-convertion like this

? -> nv12(decoder) -> yv12(avs tab) -> yuy2(script) -> rgb(script) -> output

Will the QuickSync decoder support other colorspace than nv12 or is this a limitation of the hardware?

I ran a profiler to find the problem and here's what I've found:
* ffdshow's internal video processing code runs at about the same speed.
* No color space conversion occurs (I didn't use avisynth) but your use case "enjoys" the extra conversion.
* The CPU time spent within the HW decoder + driver is extremely small. But wall-time may pass - I don't know how much. Wall time doesn't register anywhere but it adds to the decode latency.
* ffdshow doesn't use threads to do video processing (seems that way anyway) so it's not using the 8 threads my i7-2600 has. At most i got it to use <2 cores (up to 15% utilization in task manager).
* Time is spent locking the D3D surface within my decoder. I don't know how to optimize this operation.

As a quick conclusion, I see that I need to perform the frame copying on another thread (simple fix) maybe even the decode itself (not so simple).
This will cut down the wall time the decode thread stays within my decoder and as a result - cut down ffdshow's latency allowing more code to run.

This is especially useful for full speed decoding (e.g. transcoding use case).

If no horrible bugs were introduced in the last version, I'll start working on it.

Regarding HW support, NV12 is the only supported format. There's no point in adding support for surface conversions in my decoder. NV12 is the most HW friendly format and I think all GPUs use it. NV12 use only 2 "pointers" - one for Y and one for UV. Usually color operations work on both U and V so cache hits are much better. This is actually true for SW as well. Y is separated because many operations work on Y alone. It's also the format recommend by Microsoft. Although not supporting 4:2:2/4:4:4 or bit depth greater than 8bit, 99.99% of the video content can be represented as NV12.

The modern renderer which uses HW acceleration also like this format as it saves another format conversion.

[hhb97b]

I ran a profiler to find the problem and here's what I've found:
* ffdshow's internal video processing code runs at about the same speed.
* No color space conversion occurs (I didn't use avisynth) but your use case "enjoys" the extra conversion.
* The CPU time spent within the HW decoder + driver is extremely small. But wall-time may pass - I don't know how much. Wall time doesn't register anywhere but it adds to the decode latency.
* ffdshow doesn't use threads to do video processing (seems that way anyway) so it's not using the 8 threads my i7-2600 has. At most i got it to use <2 cores (up to 15% utilization in task manager).
* Time is spent locking the D3D surface within my decoder. I don't know how to optimize this operation.

As a quick conclusion, I see that I need to perform the frame copying on another thread (simple fix) maybe even the decode itself (not so simple).
This will cut down the wall time the decode thread stays within my decoder and as a result - cut down ffdshow's latency allowing more code to run.

This is especially useful for full speed decoding (e.g. transcoding use case).

If no horrible bugs were introduced in the last version, I'll start working on it.

Regarding HW support, NV12 is the only supported format. There's no point in adding support for surface conversions in my decoder. NV12 is the most HW friendly format and I think all GPUs use it. NV12 use only 2 "pointers" - one for Y and one for UV. Usually color operations work on both U and V so cache hits are much better. This is actually true for SW as well. Y is separated because many operations work on Y alone. It's also the format recommend by Microsoft. Although not supporting 4:2:2/4:4:4 or bit depth greater than 8bit, 99.99% of the video content can be represented as NV12.

The modern renderer which uses HW acceleration also like this format as it saves another format conversion.

Well this was also my expectation regarding the colorspace question, but I just wanted you to confirm it. Thanks for the detailed post to your both.

[linzki]

I have i5-2500k, gtx460, P8H61-M LX.

With these can i get intel quick sync decoder to work with lucid virtua and ffdshow?

I use my acer H5360 projector as monitor. Does it work if gtx460 is connected to projector or is it must to have igpu vga connected too. I'm asking this because the hdmi cable coming from my projector is connected to my gtx460 with hdmi-dvi adapter. I don't have vga cable so i can't connect directly to the igpu.

So can i get this working with only having hdmi cable going to my gtx460, without any cable in igpu and how?

[egur]

I have i5-2500k, gtx460, P8H61-M LX.

With these can i get intel quick sync decoder to work with lucid virtua and ffdshow?

I use my acer H5360 projector as monitor. Does it work if gtx460 is connected to projector or is it must to have igpu vga connected too. I'm asking this because the hdmi cable coming from my projector is connected to my gtx460 with hdmi-dvi adapter. I don't have vga cable so i can't connect directly to the igpu.

So can i get this working with only having hdmi cable going to my gtx460, without any cable in igpu and how?

Yes, you can make it work. In fact you can have 2 setups:
1) Renderer uses iGPU (HD2000/3000) - must use Virtu to redirect the display. Connect display to the GTX460, add your player to Virtu's application list. Use EVR as renderer for best quality.
2) Hybrid GPU setup - renderer uses dGPU HW - decoder uses QuickSync. You need a short setup as explained in a previous post:
http://forum.doom9.org/showthread.php?p=1532786#post1532786
EVR will use NVidia's video processing, but such a strong dGPU can also use MadVR with it's highest settings. Try both and see which is more to your liking.
BTW, there's no need for setting Virtu. The player must be directed to output to the dGPU (e.g. gtx460).
I only validate Windows 7. I'm not sure the trick trick works on older versions of Windows.

BTW Virtu works very good for 32 bit playback but I had issues with the 64 version (v1.06).

You'll get different quality from wither setup, it's up to you to decide what's best for you.

[linzki]

I tried to install lucid virtu driver 1.2.11 (64-bit) on windows 7 64-bit. I get: "This chipset is not supported for this version of "Virtu" setup will now exit.

Is it my cheap motherboard that is not supported by lucid virtu, or is there other version somewhere that supports my MB?

Edit: tried option nr 2 also. what ever i try it always uses libavcodec instead intel quicksync decoder.

[egur]

I tried to install lucid virtu driver 1.2.11 (64-bit) on windows 7 64-bit. I get: "This chipset is not supported for this version of "Virtu" setup will now exit.

Is it my cheap motherboard that is not supported by lucid virtu, or is there other version somewhere that supports my MB?

Personally I don't buy the cheapest boards because they are made from the cheapest components and die faster.
Virtu might install after a BIOS update - check your motherboard manufacturer if an update exists. My board was recognized by Virtu only after an update. It installed fine but was working in evaluation mode. If your MB manufacturer bought a license from Virtu, it will work.

For playback using practically all players, you can use my decoder with the hybrid GPU setup in the previous post. BTW, it's a one time setup.

[TPoise]

BTW, I installed the lastest x2559 Intel drivers and that fixed my video corruption issues. Glad things work now.

Slightly Off-topic, but I had a few questions about QuickSync in general:


1. Would it ever be possible to hardware-decode VP8 (WebM) video? (Whether or not WebM actually takes off is a different question...)
2. Any update on integrating the ENCODER into x264? There was a lot of back-and-forth with the x264 guys on whether it was possible to use the hardware in QS to accelerate x264 (without using the "out-of-the-box" QuickSync transcoder) and I think there was an Intel engineer that was going to end up doing it.
3. Is there a program to monitor the LFM for a specific process? I use CoreTemp which measures total voltage across the entire system, but I didn't know if you could verify that the QS decoder is using only 800Mhz for laptops.

[egur]

BTW, I installed the lastest x2559 Intel drivers and that fixed my video corruption issues. Glad things work now.

Slightly Off-topic, but I had a few questions about QuickSync in general:


1. Would it ever be possible to hardware-decode VP8 (WebM) video? (Whether or not WebM actually takes off is a different question...)
2. Any update on integrating the ENCODER into x264? There was a lot of back-and-forth with the x264 guys on whether it was possible to use the hardware in QS to accelerate x264 (without using the "out-of-the-box" QuickSync transcoder) and I think there was an Intel engineer that was going to end up doing it.
3. Is there a program to monitor the LFM for a specific process? I use CoreTemp which measures total voltage across the entire system, but I didn't know if you could verify that the QS decoder is using only 800Mhz for laptops.

I can't answer all of your questions. It's not my place to reveal future features of HW/driver/SDK. There are official forums for these topics. Since most of it is confidential, don't get your hopes up...

1. I'm not aware of any public announcement on the matter. Usually new features are exposed close to the launch date.
2. I'm not familiar with the encoder enough myself. It's a little out of my scope. I think the Intel Media SDK allows setting some encoder parameters on the fly so a SW encoder can become a high level encoder. E.g. tell the HW encoder when to create a I/B/P and decide the quantization parameters. Maybe someone is working on it within Intel like you said but I don't know who it is or which group he belongs to. Intel has 100K employees...
3. The CPU frequency is global to the entire CPU - all cores run at the same specific frequency. This frequency maybe above stock frequency (turbo) or below it. In Turbo mode some cores may not run at all "giving" their power budget to other cores. LFM is the low frequency mode and it's also global to the CPU's cores. The frequency doesn't change as a result of process context switch so CoreTemp will measure the only thing there is to measure - CPU frequency (all cores are the same) + package power (cores + system-agent + graphics). So if CoreTemp is showing 800Mhz when QS is being used, than that's it.
BTW, CPU utilization is heavily affected by core speed. Reduce the frequency by 50% and the utilization will double for the same program.

I hope this helped.

[hajj_3]

Will you be adding support to this for Ivy Bridge once that is released?

[egur]

Will you be adding support to this for Ivy Bridge once that is released?

It will work on Ivy Bridge as well.

[hoborg]

Hi.
I have Intel Core i5-2400S + Radeon 6750 + Win7 x64 in my system.
If i try to install Intel GPU drivers, i got a error message that my system doesnot meet the minimum.

What trick need to be done ? :)

[wanezhiling]

Hi egur

Could it support Pentium G620 and Celeron G530? They are both SandyBridge.

[vivan]

http://ark.intel.com/products/53480
http://ark.intel.com/products/53414
Intel® Quick Sync Video - No
=> No.

[wanezhiling]

http://ark.intel.com/products/53480
http://ark.intel.com/products/53414
Intel® Quick Sync Video - No
=> No.

Thx.

This's dxva checker G620 (http://we.pcinlife.com/data/attachment/forum/201111/12/094547v8hjmtttph2p1hxp.png)
How to explain it?:confused:

[hajj_3]

Thx.

This's dxva checker G620 (http://we.pcinlife.com/data/attachment/forum/201111/12/094547v8hjmtttph2p1hxp.png) How to explain it?:confused:

this just see's if the cpu can hardware decode video which those processors can. Quicksync is for encoding video, that is something different.

Those intel links are correct, quicksync is only on core i3, i5, i7 sandy bridge.

[egur]

A few clarifications.
QuickSync is the name of HW video acceleration for decode, video processing and encode.
The Intel QuickSync Decoder uses only the decode part which is available on Pentium (and probably celeron) versions of SandyBridge. Users have already confirmed that it works.
If one wants HW encode - very fast transcoding he/she should buy at least an i3.

[egur]

Hi.
I have Intel Core i5-2400S + Radeon 6750 + Win7 x64 in my system.
If i try to install Intel GPU drivers, i got a error message that my system doesnot meet the minimum.

What trick need to be done ? :)

You should enable the GPU in BIOS. The default BIOS behavior is to disable the iGPU if an external GPU exists. If the iGPU is enabled in BIOS, it will appear in the device manager (right click on "computer", manage, device manager). If a screen isn't connected to the iGPU you will not be able open its control panel.
Add a fake display to enable hybrid GPU support - see this link http://forum.doom9.org/showthread.php?p=1532786#post1532786

[hoborg]

You should enable the GPU in BIOS. The default BIOS behavior is to disable the iGPU if an external GPU exists. If the iGPU is enabled in BIOS, it will appear in the device manager (right click on "computer", manage, device manager). If a screen isn't connected to the iGPU you will not be able open its control panel.
Add a fake display to enable hybrid GPU support - see this link http://forum.doom9.org/showthread.php?p=1532786#post1532786

Thank you for info, but i didn't found such option in BIOS. Maybe it is not supported by Gigabyte PH67-UD3-B3 mother board.

[CruNcher]

A few clarifications.
QuickSync is the name of HW video acceleration for decode, video processing and encode.
The Intel QuickSync Decoder uses only the decode part which is available on Pentium (and probably celeron) versions of SandyBridge. Users have already confirmed that it works.
If one wants HW encode - very fast transcoding he/she should buy at least an i3.

Though we can be sure that it's disabled on die but physically existent its most probably just disabled for some reason like "we cant afford 2 productions streets just disable it on the IME level (1 bit and support is gone see upgrade possibility) or it was just malfunctioning (production error and because of that disabled either hardware level "laser cut or IME (uefi,bios))) or it will become part of Intels hardware by software lock upgrade programm (for some more money you can buy it additionally get a code (protected by the cryptographically part of Intels silicon) for the bios open up this 1 bit and boom you got support for xx$) that's where intel is heading to anyways 1 silicon upgradable into every stage of the line with just 1 highly hardware protected key system Maximum Profit with low effort, though much better for resource usage but if you guess its being done because we need to protect our world and try to use less resources unfortunately that's not the main reason rather than china starting the next phase of their economical WarGame ;)

[egur]

Thank you for info, but i didn't found such option in BIOS. Maybe it is not supported by Gigabyte PH67-UD3-B3 mother board.

The board has the right chipset (h67) according to Gygabyte's website but it looks like a typo.
it behaves a like a P67 chipset motherboard. It has OC (H67 doesn't have) and lacks processor graphics support (which h67 should have) - there's no graphics connector of any kind on the back panel. Here are the spec from Gygabyte's website http://www.gigabyte.com/products/product-page.aspx?pid=3767&dl=1#ov. There's a photo of the back panel.
The manual doesn't reference the processor graphics anywhere.
Looks like a P67 board to me. So no video from the processor.

Does your board's back panel have graphics connectors (dvi/vga/hdmi/dp)?

[egur]

Though we can be sure that it's disabled on die but physically existent its most probably just disabled for some reason like "we cant afford 2 productions streets just disable it on...

That's not quite accurate. I'd like to give a general explanation on how multiple versions of a chip are made. This isn't specific to Intel, it's across the entire semiconductor industry.

Disabling features is how there's a large selection of CPUs to choose from. Some will only want the cheapest, some will put a few more dollars or euros for a better one (more features), some will pay more than 1000$ for an extreme edition and some will buy a $6000 Xeon based workstation with two sockets and 64GB of RAM. It makes no sense to create 30 versions of processors (some very similar) due to the enormous validation costs. So if Intel (and probably all semiconductor companies) would go and create many different dies, they would loose money or the products will cost double (probably a lot more than double). It makes sense to produce different dies if and only if there's a significant die area reduction (die area == $$$) and the expected sales are high enough (recover the validation costs as well increased manufacturing costs).

[wanezhiling]

A few clarifications.
QuickSync is the name of HW video acceleration for decode, video processing and encode.
The Intel QuickSync Decoder uses only the decode part which is available on Pentium (and probably celeron) versions of SandyBridge. Users have already confirmed that it works.
If one wants HW encode - very fast transcoding he/she should buy at least an i3.

:thanks:

So what about previous generation Desktop Processors(i3/i5/i7..)?

[egur]

:thanks:

So what about previous generation Desktop Processors(i3/i5/i7..)?

The decoder will work on previous generation but at much lower efficiency due to different memory architecture (integrated memory controller) as well as different decode HW. Even Core 2 Duo machines will work (with GMCH graphics). I don't test these setups because of that. Better to use pure SW (similar performance to my decoder) or pure DXVA (faster but limited).
Fortunately, future generations (IvyBridge,...) will have the same performance as SandyBridge - probably much better. So my work isn't targeting a single generation.
Same goes for OS support - I'm officially testing only on Windows 7, although Vista should work fine. Windows 8 will be supported as well when it's released.

[wanezhiling]

:thanks:I got it.

[pulbitz]

I'm sorry. I don't speak English very well.

ffdshow video decoder configuration | Output | Stream settings
Check "Set interlaced flag in output media type"

- libavcodec
perfect smooth playback of 1080i content. (double framerate)

- Intel QuickSync
motion is steppier. (poor)

Is this a bug? Or QuickSync decoder limitation?
You need a SandyBridge (or newer) to enjoy the HW acceleration used in the QuickSync decoder.
Please specify which renderer was use as well other setup (driver version, OS version, 32/64 bit, player, display is connected to iGPU or dGPU, etc). If you can post a part of the clip (10-20 seconds) that would help development.
This thread is very busy so please report issues at the QuickSync decoder thread:
[ur]http://forum.doom9.org/showthread.php?t=162442[/url]

CPU: i5-2500 with HD Graphics 2000 (I don't use external GPU)
OS: Windows 7 Ultimate x64
Driver: 2559 (15.22.52.64.2559)
Renderer: EVR (not custom EVR)
Player
1. The KMPlayer(3.0.0.1441) http://cdn.kmplayer.com/KMP/Download/KMPlayer_EN_3.0.0.1441_R2.exe
2. PotPlayer(2011.12.26. beta) http://get.daum.net/PotPlayer/Beta/PotPlayerSetup.exe

sample file(1080i60) http://www.multiupload.com/2JMT9SLZQI

P.S. PotPlayer with built-in QuickSync decoder is OK. (Unlike ffdshow QuickSync decoder)

[egur]

CPU: i5-2500 with HD Graphics 2000 (I don't use external GPU)
OS: Windows 7 Ultimate x64
Driver: 2559 (15.22.52.64.2559)
Renderer: EVR (not custom EVR)
Player
1. The KMPlayer(3.0.0.1441) http://cdn.kmplayer.com/KMP/Download/KMPlayer_EN_3.0.0.1441_R2.exe
2. PotPlayer(2011.12.26. beta) http://get.daum.net/PotPlayer/Beta/PotPlayerSetup.exe

sample file(1080i60) http://www.multiupload.com/2JMT9SLZQI

P.S. PotPlayer with built-in QuickSync decoder is OK. (Unlike ffdshow QuickSync decoder)

I've reproduced/confirmed the issue on another player. Still root causing it.
BTW, PotPlayer seems to use a DLL (quicksync.dll) that has very similar export functions as well as file size, do they use an older version of my DLL or built their own? (either way is fine BTW).

[clsid]

PotPlayer/KMPlayer are notorious for stealing code from open-source projects (MPC and ffdshow in particular) and violating the GPL.

[NikosD]

Hello.

I did some benchmarking with QS and I put my results here:
http://forum.doom9.org/showthread.php?t=163110

After the whole experience I have some questions that I would like to ask you.

1) After the installation of latest driver Intel 15.22.52.2559 I found 3 MFT decoders by Intel at C:\Program Files\Common Files\Intel\Media SDK\s1\2.0\

The names are Intel Hardware H.264/MPEG-2/VC-1 Decoder MFT.

But during the enumeration of available codecs in DXVA Checker when I try to benchmark a video file, those decoders never show up.

Why?

Also in their properties they don't seem to have a DXVA option (enable/disable)

2) Your work of QS Decoder is it possible to be installed without FFDShow ?
Because I don't want to install the package of FFDShow just to have your QS decoder.

3) After the installation of your QS decoder through FFDShow and the appropriate configuration to use QS for AVC, VC-1, MPEG-2, during the enumeration of available codecs FFDShow most of the times didn't show up.
And when it was available for benchmarking, it wasn't working at all.

My setup was a little different from what you recommend.
I didn't use Lucid Virtu or Virtual displays.

I just put two different cables of my two different GC (HD 2000 and GT440) at the same time on my two input display and automatically the driver got into Extended mode.
The QuickSync worked OK that way.

4) Why Intel restricts such a POWERFUL DECODER like QS for 1920x1080 only?

I think that the driver's team should "open" the driver up to 4K x 2K that QS could handle with ease.

And of course your decoder and every other decoder using QS must be updated too, to include 4K x 2K.

5) The video file number 9 has some issues (artifacts) during the last 3-4 seconds.

Thanks

[egur]

Hello.

I did some benchmarking with QS and I put my results here:
http://forum.doom9.org/showthread.php?t=163110

After the whole experience I have some questions that I would like to ask you.

1) After the installation of latest driver Intel 15.22.52.2559 I found 3 MFT decoders by Intel at C:\Program Files\Common Files\Intel\Media SDK\s1\2.0\

The names are Intel Hardware H.264/MPEG-2/VC-1 Decoder MFT.

But during the enumeration of available codecs in DXVA Checker when I try to benchmark a video file, those decoders never show up.

Why?

Also in their properties they don't seem to have a DXVA option (enable/disable)


I don't know - I'm not part of the Media SDK dev team nor the graphics driver team. I'll forward your question.
2) Your work of QS Decoder is it possible to be installed without FFDShow ?
Because I don't want to install the package of FFDShow just to have your QS decoder.
My decoder is not a DirectShow filter. It's a DLL with a simple API that allows decoding - an abstraction layer (with enhancements) above the Intel Media SDK API. This is why it's bundled with FFDShow. It can be integrated into other DS filters quite easily but I started with FFDShow because it's very popular. Now it's part of the official FFDShow builds. This site will allow people to test the newest cutting edge versions.

3) After the installation of your QS decoder through FFDShow and the appropriate configuration to use QS for AVC, VC-1, MPEG-2, during the enumeration of available codecs FFDShow most of the times didn't show up.
And when it was available for benchmarking, it wasn't working at all.

My setup was a little different from what you recommend.
I didn't use Lucid Virtu or Virtual displays.

I just put two different cables of my two different GC (HD 2000 and GT440) at the same time on my two input display and automatically the driver got into Extended mode.
The QuickSync worked OK that way.
Your setup seems fine. Please tell me what's not working in greater detail.

4) Why Intel restricts such a POWERFUL DECODER like QS for 1920x1080 only?

I think that the driver's team should "open" the driver up to 4K x 2K that QS could handle with ease.

And of course your decoder and every other decoder using QS must be updated too, to include 4K x 2K.
See answer #1. My guess would be that it made the HW more expensive and not worth the cost. I'll forward the question.

5) The video file number 9 has some issues (artifacts) during the last 3-4 seconds.
I'll check it out and report back.

[NikosD]

Your setup seems fine. Please tell me what's not working in greater detail.


From the whole range of clips from 1 to 10, only a few gave me the option to benchmark FFDshow.
I mean that only for a few clips the FFDshow codec appeared red which means DXVA2 capable codec ready for benchmarking with a suitable decoder device and codec.
Most of the times it was grey, available only for DXVA1.
And the few times that it was red, when I tried to benchmark FFDshow the only thing happened was to open the benchmark window and stuck there.
The clip wasn't moving at all.
If you haven't met that situation before, never mind.
I'll search it myself next time.


My guess would be that it made the HW more expensive and not worth the cost.


I mean the hardware as is - the QuickSync first generation - seems more than capable of 4K x 2K decoding.
I believe it's a matter of appropriate drivers and codecs to unleash the power.
I know that Intel advertises that the second generation of QS inside Ivy is capable of not only 4K x 2K, but of mulltiple streams of 4K x 2K and 4K x 4K - square resolution.
I think a simple 4K x 2K is feasible by first generation QS too

Waiting for your feedback.

Thanks

[egur]

3) After the installation of your QS decoder through FFDShow and the appropriate configuration to use QS for AVC, VC-1, MPEG-2, during the enumeration of available codecs FFDShow most of the times didn't show up.
And when it was available for benchmarking, it wasn't working at all.


DXVA checker will only check DXVA - it loads FFDShow-DXVA which doesn't use the Intel QuickSync decoder.
Try benchmarking using GraphStudio, it's very easy to use. (menu->view->decoder performance). There you can select decoder and renderer (or NULL renderer).
BTW, I'm having a hard time downloading the clips since I don't have a rapidshare account. Please share them on www.multiupload.com, it's the easiest way to share files for free as it currently doesn't impose limitations (it allows concurrent downloads with download managers).

[NikosD]

From your answer I can understand now that I was looking at a wrong direction.

Your dll appears as a CPU codec not a DXVA codec, that's why you told me to benchmark it with GraphStudio.
Of course it's a CPU codec using DXVA through Intel Media SDK!

I have used GraphStudio and Timecodec at the past in order to benchmark CPU codecs, but after DXVA Checker I use it - DXVA Checker - for all kind of codecs, even CPU.
DXVA checker can use all kind of codecs (CPU, DXVA, CUDA etc)

So I will try again with DXVA Checker and FFDShow CPU codec and not FFDShow DXVA codec, when I'll have access again at the Core i5 system.

Maybe a good idea for Nevcariel could be to include the QS decoder in his LAV Video along with his pure CPU codecs and CUVID codecs, if it's OK by you.

BTW, I found the artifacts at 9th clip during playback with Potplayer and its default QuickSync.dll and then I replaced it and renamed your latest dll and still the artifacts were there.
You don't have to download everything, just clip 9.
I will try to reupload it to mediashare which is like multiupload, I think.

[NikosD]

One more thing...

There are a lot of minor issues regarding HD Graphics and QuickSync.

I couldn't find a desktop gadget to see the status of the graphics card (clocks, GPU usage, memory).
Even latest GPU-Z reports HD 2000 GC of Core i5 as GT2 at 45nm! and 12 GU, but reports GPU load.

QS is even harder to get info.

No gadget, no program no sign when it's used, no load.

Also DXVA checker disables CPU and GPU usage during playback and benchmarking with QS.

Because of the nature of GC and QS - inside the processor - I don't know if Intel can think a way of "separating" the operations of Graphics Card and QS from the "rest" of the CPU and monitor the activity and features of each component.

[egur]

One more thing...

There are a lot of minor issues regarding HD Graphics and QuickSync.

I couldn't find a desktop gadget to see the status of the graphics card (clocks, GPU usage, memory).
Even latest GPU-Z reports HD 2000 GC of Core i5 as GT2 at 45nm! and 12 GU, but reports GPU load.

QS is even harder to get info.

No gadget, no program no sign when it's used, no load.

Also DXVA checker disables CPU and GPU usage during playback and benchmarking with QS.

Because of the nature of GC and QS - inside the processor - I don't know if Intel can think a way of "separating" the operations of Graphics Card and QS from the "rest" of the CPU and monitor the activity and features of each component.

There's this tool for analysis:
http://software.intel.com/en-us/articles/vcsource-tools-intel-gpa/

It's mostly used by developers.
BTW, the 9th clip plays fine using ffdshow-quicksync, I'll test the other clips for issues and performance (using graph studio).

[CruNcher]

Huh it's free now ? wasnt it @ the beginning for Game Studios under NDA only ?
anyway this is really cool :)

http://software.intel.com/file/40560

much better then to just use Microsofts Generic stuff (WPA,WPR) which also goes deep but not so specific on the GPU (DSP) parts :D

also some very interesting information about the Motion Estimation part (and how turbo boost relates to it) :D http://software.intel.com/sites/landingpage/vcsource/frame.php?u=http%3A//software.intel.com/en-us/articles/using-intel-graphics-performance-analyzer-gpa-to-analyze-intel-media-software-development-kit-enabled-applications

also this is showing the problematic with the lock/unlocking of the frame (copy back)


There are two reasons: first, the compressed frame is smaller in size as compared to uncompressed frame, and second, the Intel Media SDK utilizes an optimized data copy with a combination of MOVNTDQA and MFENCE instructions.

ahh and we are @ beta 5 now http://software.intel.com/en-us/articles/vcsource-tools-media-sdk-beta/


Transcode enhancements
Increased performance
Enhanced quality
Easier usage with opaque memory
Abstraction of system buffer and DirectX* surface
Simplified memory between CPU and Intel® Processor Graphics
MVC encode and decode - stereoscopic 3D
Improved videoconferencing extensions
Dynamic bit rate control
Improved robustness (error resilience)
Improved error detection and reporting
Lower latency: Improved responsiveness
Improved long-term reference frame control
New samples
Decoding and stereoscopic 3D rendering sample
Videoconferencing usage sample
OpenCL™ parallel programming sample*



anything specific in information here about the improvements compared to beta 4 (especially on which level where the quality improvements, and how that shows in metric measurements) ?

I love Intel :)

http://software.intel.com/sites/landingpage/vcsource/frame.php?u=http%3A//software.intel.com/en-us/articles/introducing-the-intel-gpa-advisor

you really doing it the right way :)

[egur]

Version 0.21 beta is out with the following changes:
* Performance boost (~20%) + lower latency decoding by using a worker thread to perform post-decode work (mostly frame copy).
* FFDShow rev4216

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

[NikosD]

There's this tool for analysis:
http://software.intel.com/en-us/articles/vcsource-tools-intel-gpa/

It's mostly used by developers.
BTW, the 9th clip plays fine using ffdshow-quicksync, I'll test the other clips for issues and performance (using graph studio).

Happy New Year.

I tried the software and I really loved GPA Monitor.
Very easy to use and see the utilization of both GPU and QS in a beautiful and informative way.

I updated my results to include performance of your QS FFDshow v0.20. Unfortunately I didn't expect you to work today and release a new version!

From what I see from my results here http://forum.doom9.org/showthread.php?t=163110, there is a big penalty by using DXVA through Intel Media than DXVA directly.
It's two times slower in low bandwidth clips!
But in high bitrate clips from 7 to 10, the speed is the same.

I started to monitor MFX performance (QS) with GPA Monitor v4.3 and I found out that during benchmarking QS FFDShow was using from 65% - 75% of QS decoding hardware and QS DXVA was using 96% - 98% of QS decoding hardware.

Also during the monitoring of the benchmarking process, I found out that although QS FFDshow put the CPU in Turbo mode of 3.2GHz in contrast to QS DXVA that put the CPU at a frequency range of 1.6GHz - 2.1 GHz the QS utilization was only slightly lower in QS FFDShow despite the twofold CPU frequency.
Probably because of the lower utilization of QS in general by QS FFDShow I mentioned above.

But the main problem in my opinion is the CPU usage of QS FFDshow.
During playback in both WMP12 and PotPlayer using DXVA, the CPU was at lowest point 1.6GHz for most of the clips, most of the time.
During playback with DXVA checker and PotPlayer with your QS FFDShow dll, the CPU went very high in Turbo mode of 3.2GHz in all 1080p60fps clips!
For the rest of the clips, even the "tough" ones like from 7 to 10 the CPU frequency went from 1.6GHz to 3.1GHz

PotPlayer in DXVA mode couldn't play clips 2 and 3 - it falls back to software mode.
WMP12 plays fine in DXVA mode from clip 1 to 10 as PotPlayer with QS FFDshow.

I INSIST ON writing you that during playback of clip 9 (Ducks Take off) with both DXVA checker and PotPlayer using QS FFDShow I see ARTIFACTS at the last few seconds with version 0.20.

I know nothing about version 0.21.
I'll try it when I go to Core i5 system again.

[egur]

Happy New Year.
Happy new year to you too :)

I tried the software and I really loved GPA Monitor.
Very easy to use and see the utilization of both GPU and QS in a beautiful and informative way.
Very nice.

I updated my results to include performance of your QS FFDshow v0.20. Unfortuantely I didn't expect you to work today and release a new version!
Well, most of the work was done in '11.

From what I see from my results here http://forum.doom9.org/showthread.php?t=163110, there is a big penalty by using DXVA through Intel Media than DXVA directly.
It's two times slower in low bandwidth clips!
But in high bitrate clips from 7 to 10, the speed is the same.
There's a performance penalty which is low during normal playback. When going full speed, the CPU utilization goes up because of the memory copying (GPU->CPU). The CPU stays at LFM (1.6GHz) for the duration of playback.
FYI, QuickSync is part of the GPU not the CPU so it operates on the GPU frequency (650-1350GHz). The GPU frequency is determined by dynamically. There's a nice overview on SandyBridge's architecture from AnandTech.

Regarding performance, I'm not a magician, DXVA will always be faster and use less power. But it's not good for everyone due to it's many restrictions. Actually the hassles of DXVA are abstracted by my code as well the Media SDK. The Media SDK add practically zero overhead. Copying the frames to system memory so all plays can enjoy HW acceleration is the main feature of the Intel QuickSync decoder.
It's also has features like using a different GPU for rendering.

You should try v0.21 which is the first beta. It's faster and will probably get even faster once I finish tuning the code in a week or two.

BTW, DXVA is fast buy it's not always working well for me (and others).

Regarding corruption, sometimes it's a matter of what splitter is used.
The best to date are: LAV and Haali.
None of them is perfect but they are very good. Haali has aspect ratio issues and LAV doesn't seek as well on broken TS streams (slow seek+corrupted frames). I had little issues with MPC's splitter as well. With PotPlayer I got crashes I don't know how to fix.

I played clip #9 using ZoomPlayer (32 bit) and Windows Media Center (64 bit) and no corruption.

Another thing, when benchmarking using Graph Studio, the first run is always slower for some reason, so you should either omit it or run 10 passes. It looks like the graph init time (happens only on the 1st run) gets into the stats.

[egur]

Setup:
* GraphStudio, 10 passes, NULL renderer.
* 10 clips from http://forum.doom9.org/showthread.php?t=163110
* FFDShow rev4216 (QS 0.21) 32 bit.
* Windows 7 Ultimate 64 bit, Aero on.
* Intel driver: v2559.
* Lucid Virtu: not installed.
* CPU: i7-2600 (3.4GHz), power management on. HD 2000 (GT1) iGPU.
* DDR3 @1333MHz (nothing fancy)
* Score are lowest/avg/highest frame rates for the entire clip.
* Note - the first pass was always slower due to graph contruction time which affects short clip benchmarks. The most interesting results are the highest FPS as the median score is very close to them.
1.Twinpeaks1080p30fpsRef2-27Mbps.mov
264/297/303

2.Samsung.Demo.Oceanic.Life-1080p30fpsRef16-40Mbps.mkv
240/260/263

3.Basketball-1088p60fpsRef8-10Mbps.mkv
310/315/319

4.Girls.YoonYoon-1080p60fpsRef5-21Mbps.mkv
298/307/310

5.Birds_1080p60fpsReF2-30Mbps.mp4
283/294/298

6.Cat-1080p60fpsRef4-25Mbps.m2ts
291/290/301

7.Vortexx_1088p24fpsRef3-109Mpbs.mp4
119/134/140

8.Birds_1080p24fpsRef4-112Mbps.mkv
122/134/137

9.Ducks.Take.Off.1080p30fpsRef5-108Mbps.mkv
147/154/156

10.Crowd.Run.1080p25Ref4-116Mbps.mkv
115/126/128

[NikosD]

Thanks for the info.

Next time I will try to check the GPU speed, but I think that GPA Monitor doesn't provide this, I'm not sure.

I think GPU-Z can help, although it's reporting wrong HD 2000 features.

[CruNcher]

Happy New Year everyone :)

@Egur
did you benchmark how the glass shader of aero is hurting performance i did some tests and it seems quiet heavy compared to all other effects disabling it gives me a rather big boost and also lowers GPU usage without losing Aeros V-Sync :). Im also experimenting how the GPU Frequency impacts Performance currently my Motherboard is capable overclocking the HD 2000 (GPU overclocking bits enabled) :)

Also it seems that actually the CPU is never staying @ the same Frequency but always changing it even with a High Performance Profile it constantly switches over here see with http://www.mediafire.com/?kwrwnj41428lzzg coded on Intel Specs very great work (capable of changing multiplier on the fly if bios allows it)

@NikosD
Hwinfo32 is a great tool sensoring GT1 frequency and power consumption for free it also shows correct data compared to GPU-Z

[egur]

Happy New Year everyone :)

@Egur
did you benchmark how the glass shader of aero is hurting performance i did some tests and it seems quiet heavy compared to all other effects disabling it gives me a rather big boost and also lowers GPU usage without losing Aeros V-Sync :). Im also experimenting how the GPU Frequency impacts Performance currently my Motherboard is capable overclocking the HD 2000 (GPU overclocking bits enabled) :)

These are preliminary test that will serve as a performance benchmark mostly for development purposes - I want to be able to get the maximum out of the code and I think I can do a little better.
It's best that "official" benchmarks are produced by others for objectivity sake :)
Also when you have an 8 thread CPU (i7-2600), SW decoders can perform very well. Especially on low bitrate clips.
I also didn't test with faster memory, my new HTPC setup will have an i7-2600K with 1600MHz DDR3. My aging Core 2 Duo + Nvidia 7600 is having a hard time pushing a Full HD TV...

[CruNcher]

Egur im gonna bench this new version as well against the DXVA2 generic frame copy no MSDK competition ;)

[NikosD]

@NikosD
Hwinfo32 is a great tool sensoring GT1 frequency and power consumption for free it also shows correct data compared to GPU-Z

I didn't find power consumption in Hwinfo32.

I found this tool from Intel which works for SandyBridge and later processors only.
I haven't tried it yet, but it looks promising and most accurate, but for the whole CPU (no separate components)

http://software.intel.com/en-us/articles/intel-power-gadget/

Looking for a Windows Desktop gadget to support GPU load, clocks, memory for Intel HD Graphics (GT1, GT2)

[nevcairiel]

Hi Eric,

I've been looking into adding your QuickSync decoder to LAV Video, because the API is so trivial that i really cannot go wrong with it.
Without having tested this stuff yet, i have a few questions/concerns:

1) I'm really not a big fan of your timestamp interpolation logic. There are so many cases where i'm not sure it would work properly.
I've been trying to fully understand the timestamp code, and i am still wondering why you don't just use timestamps provided by the source, if present. Trying to calculate the average framerate and re-calculating all timestamps based on that seems dangerous, considering applications like live TV where there could easily be gaps.

Anyway, i guess what i'm asking is an option to disable all your fancy logic and just give me back the timestamps i put in, just re-ordered by the decoder (PTS timestamps). I can take care about gaps and whatnot in the timestamps myself.
Would you consider this, maybe if i provide a patch?

2) How is the new multi-threading handled, specifically is it "transparent" to the caller?
More specifically, which thread calls the deliver callback? Is it the worker thread, or the thread of the caller? I'm a bit cautios of exposing different threads to directshow, and i would prefer that always the callers thread is used to deliver frames.
From looking at the code, it seems like its doing it the way i hope it does, but i just want to make sure.

Are there any reasons i would not want your worker thread (considering you added an option)?

3) How is the memory in the QsFrameData structure handled?
Do i have to free the structure and the y/u/v pointers? Or is it re-used on the next frame automatically, so i should copy it into another buffer?
Also, considering its NV12 data, the names are not choosen all that wisely, i would've gone with a planes[4] array or something (for future proofing), instead of 3 named parameters. :)

[CruNcher]

I didn't find power consumption in Hwinfo32.

I found this tool from Intel which works for SandyBridge and later processors only.
I haven't tried it yet, but it looks promising and most accurate, but for the whole CPU (no separate components)

http://software.intel.com/en-us/articles/intel-power-gadget/

Looking for a Windows Desktop gadget to support GPU load, clocks, memory for Intel HD Graphics (GT1, GT2)

Yep problem with it you need F8 unsigned driver workaround @ bootup (for NT6 64 bit) Throttlestops used ring0 driver should be as low latency and doesn't need F8 and the unsigned driver bootup :)
Hwinfo32 should be able to read the Power consumption information (Watt) of both CPU/GPU as well it has a Gadget (i prefer inclusion into the almost excellent (some design issues with the monitoring options) rivatuner sensoring framework (shared memory) though instead of a heavy gadget)

http://img265.imageshack.us/img265/6975/hwinfo32cpugpupower.png

Though the Drawback Hwinfo32 has only a max sample resolution of 100ms where Intel can go as low as 25ms (impressive thx to HPET) Throttlestop though can be much lower latency then Hwinfo32 using the "More Data" option.
Though to low sampling resolution isn't always a good idea under a non RTOS such as Windows it can have big impact on Performance if done wrong and especially Hwinfo32 wasn't made for to low sampling resolutions it's sensoring monitor is causing a lot of stress to the system updating very fast (always be careful measuring on the software side time critical stuff with so low latencies).



1) I'm really not a big fan of your timestamp interpolation logic. There are so many cases where i'm not sure it would work properly.
I've been trying to fully understand the timestamp code, and i am still wondering why you don't just use timestamps provided by the source, if present. Trying to calculate the average framerate and re-calculating all timestamps based on that seems dangerous, considering applications like live TV where there could easily be gaps.

Yep this already showed up on different (craziest one was the asian i guess ts commercial record (girl sings about a petrol brand :D ) gone totally out of sync) samples i guess also my last (lost lock problem on mpc-hc after finding the auto deinterlacing option problems) report (some pages back) http://forum.doom9.org/showpost.php?p=1538481&postcount=265 is caused by this. Though i have to recheck with the new version maybe its fixed :)

[egur]

I've been looking into adding your QuickSync decoder to LAV Video, because the API is so trivial that i really cannot go wrong with it.
Excellent :)

Without having tested this stuff yet, i have a few questions/concerns:

1) I'm really not a big fan of your timestamp interpolation logic. There are so many cases where i'm not sure it would work properly.
...
I'll add a disable bit. No problem. In fact the the time stamp logic took too much effort and should probably be handled in the DS filter.

2) How is the new multi-threading handled, specifically is it "transparent" to the caller?
More specifically, which thread calls the deliver callback? Is it the worker thread, or the thread of the caller? I'm a bit cautios of exposing different threads to directshow, and i would prefer that always the callers thread is used to deliver frames.
From looking at the code, it seems like its doing it the way i hope it does, but i just want to make sure.

Are there any reasons i would not want your worker thread (considering you added an option)?
The decode thread will receive samples and output samples. The worker thread will do processing in the background. I think EVR doesn't like it any other way.
There's an option to disable multithreading if it's not stable enough. I've tested it quite a bit and it works great. But since I can't guaranty 100% functionality, I've added the chicken bit. When disabled the worker thread will not be created. Like all settings, this must be set before calling the Init function.
The downside is that more system memory is used - ~3 extra frames.

3) How is the memory in the QsFrameData structure handled?
Do i have to free the structure and the y/u/v pointers? Or is it re-used on the next frame automatically, so i should copy it into another buffer?
Also, considering its NV12 data, the names are not choosen all that wisely, i would've gone with a planes[4] array or something (for future proofing), instead of 3 named parameters. :)

The buffers are reused so you shouldn't free them. I currently use aligned_malloc but this can change. Also the addresses of y/u/v do not point to the allocation address. They are at an offset for faster GPU-CPU copying.
The buffers are also writable (currently) - you can modify their content (I'll never read from them). There's a bool in the QsFrameData that specifies this.
The buffer is a single allocation (stride * height). If you need the buffer to be larger (e.g. for in-place format conversion), let me know.

Regarding pointer names, NV12 is the only supported format ATM, but this may change (don't know if and when). Regarding a forth channel (you meant alpha?), I can add it for completeness.
Usually when I deal with images, I use unions for clarity:

union{
char* red; //RGB colorspace
char* y; //YCbCr colorspace
char* luma; //HSL colorspace
};

So I'll add the unions, it's clearer than a vague pointer array.

[egur]

Yep problem with it you need F8 unsigned driver workaround @ bootup (for NT6 64 bit) Throttlestops used ring0 driver should be as low latency and doesn't need F8 and the unsigned driver bootup

:confused:

[CruNcher]

oops i see it got updated and has a signed kernel driver now hehe :D

btw http://software.intel.com/en-us/blogs/2011/03/31/accessing-intel-power-gadget-from-intel-energy-checker-sdk/ you could implement it into the ffdshow OSD (would be cool, to see it realtime @ video playback their would be other ways over the directx surface but directly encoded into the video would be also nice for several tasks, how much ~power consumed a frame to decode in the framework) and additionally directly into mpc-hcs osd ;), Though i guess it wont be that High Resolution with all the latency to exactly pinpoint 1 frames decoding power consumption, but a rough estimate per gop could be also interesting (of course to be useful @ all you need the system to be background noise free when measuring anything specific) ;)

[NikosD]

I tried Hwinfo32 in my system with Core2Duo and I didn't see power usage.

From what I saw of your pictures and Egur's reply it's not clear if I run it on a Win 7 SP1 x86 - Core i5-2400 system without any tricks, if could I see power usage ?

What is the procedure to activate power usage if it's not on by default ?

I'm planning to run some tests again on Friday or Saturday on SandyBridge.

[CruNcher]

Power Consumption measuring is only available on Sandy Bridge and up


Known Limitations/Issues

Only works on 2nd Generation Intel® CoreTM processor family (Sandy Bridge) or later
Use 32-bit installer only on 32-bit OS


Not sure but actually i think this feature came from Atom :) Sandy Bridge combines a lot of the low power stuff that was started with Atom :)

[nevcairiel]

Hey Eric,

how did you ever manage to compile a release build of the decoder? :D

1>d:\dev\multimedia\lavfsplitter\intel qs\qsdecoder\intelquicksyncdecoder\quicksyncdecoder.cpp(643): error C2220: warning treated as error - no 'object' file generated
1>d:\dev\multimedia\lavfsplitter\intel qs\qsdecoder\intelquicksyncdecoder\quicksyncdecoder.cpp(643): warning C4715: 'CQuickSyncDecoder::SetD3DDeviceManager' : not all control paths return a value

[CruNcher]

@ Egur
Good news the Lock Problem is history :) crazy its noise less as the DXVA now, i can see the same peaking on the keyframes now as i could with Cyberlinks DXVA decoder (without any other background noise in the graph) :)
No lock lost problem on that sample anymore perfectly telecined smooth as butter with MPC-HC Splitter as well as Lav Splitter :D

Really good work :) the peaks are even lower now then what Cyberlink Produces, most results are same with MPC-HC and Lav Splitter though Arcsofts Decoder doesnt like Lav Splitter @ all, Mainconcepts DXVA is either broken or tuned for their framework exclusively :D


Test Setup:
Win7 Aero
MPC-HC TS Splitter (Source)
Lav Audio (Sync Correction)
EVR Custom dfr3882i (Experimental by JanWillem32)

Cyberlink Peaks (GPU)

http://img46.imageshack.us/img46/2943/cyberlinkdxvapeaks.png

FFdshow Quicksync Peaks (GPU)

http://img718.imageshack.us/img718/2454/ffdshowquicksyncpeaks.png

Lav Video Peaks (CPU)

http://img810.imageshack.us/img810/3343/lavvideopeaks.png

Mainconcept SDK 9 Peaks (GPU)

http://img269.imageshack.us/img269/1192/mainconceptsdk9dxvapeak.png

Mainconcept SDK 9 Peaks (CPU)

http://img856.imageshack.us/img856/7070/mainconceptsdk9cpupeaks.png

Arcsoft Peaks (GPU)

http://img18.imageshack.us/img18/3952/arcsoftdxvapeaks.png

Arcsoft Peaks (GPU) (LAV Splitter) out of sync to fast complete disaster audio is way behind (though it seems to be able to get those keyframes correct)

http://img683.imageshack.us/img683/73/arscoftpeaksdxvalavspli.png

2ms is really wow (with those peaks without it's really in the range of the best DXVA implementations 0.4xx ms) Egur :)

Though initially i just wanted to make sure the lock lost issue is history and jep it is that was a big problem experience wise, i gonna continue and report if i find other issues :)

[egur]

Thanks CruNcher :thanks:
Can you explain what we're seeing here?
Are you referring to the low render latency?

[egur]

Hey Eric,

how did you ever manage to compile a release build of the decoder? :D

1>d:\dev\multimedia\lavfsplitter\intel qs\qsdecoder\intelquicksyncdecoder\quicksyncdecoder.cpp(643): error C2220: warning treated as error - no 'object' file generated
1>d:\dev\multimedia\lavfsplitter\intel qs\qsdecoder\intelquicksyncdecoder\quicksyncdecoder.cpp(643): warning C4715: 'CQuickSyncDecoder::SetD3DDeviceManager' : not all control paths return a value

In the ffdshow codebase there's a different project file, that for some reason got lowered to level 3 warnings and removed the "treat warnings as errors".

update
SVN rev12 fixes the compilation issue as well as contain your requested features.
ffdshow was updated to rev4218.
I will not release a build since the functionality difference is zero (in ffdshow).

[nevcairiel]

I found something odd.

I did a very basic integration of your decoder now, and when i feed it some 1920x1080 movies, it reports to me that they are 1919x1079.
This happens for example with the files 7-10 from that DXVA test set earlier.

Any idea whats going on?
Doubt i could've broken something, there isn't really any screws to turn. :)
I did not give it any configuration yet, just running with thatever it has for defaults.

PS:
Thanks for the changes!

[CruNcher]

Thanks CruNcher :thanks:
Can you explain what we're seeing here?
Are you referring to the low render latency?

Jep :) on that clip with the lock lost issue it was crazy (see video recording of previous result) :D

[egur]

I found something odd.

I did a very basic integration of your decoder now, and when i feed it some 1920x1080 movies, it reports to me that they are 1919x1079.
This happens for example with the files 7-10 from that DXVA test set earlier.

Any idea whats going on?
Doubt i could've broken something, there isn't really any screws to turn. :)
I did not give it any configuration yet, just running with thatever it has for defaults.

PS:
Thanks for the changes!

The output rects are according to Windows standard (the way you pass dimensions to Win32 API):
So you 1919,1079 is the bottom right pixel.
This allows simple conversion to CRect, etc.
If it's confusing, I'll add a comment in the struct's code.

[nevcairiel]

So, i can assume that width/height are always +1? :d
For the record, i have never seen a rect used that way, the rects in the DShow media type say 0,0,1920,1080

Edit:
Checked the code, so yeah, always +1.

[CruNcher]

Egur

started testing in Progressive mode (forcing every Interlaced content to be displayed as such) and so far on the .ts part i found 1 sample that behaves rather strange with a very high latency but only @ the beginning (looks crazy) 6ms for a 30 1080i stream and audio sync issues but whats really crazy with this is as soon as i change the player size (let jans renderer do a refresh) it gets sync ;) i separated that stream for now for further testing (very interesting never saw a stream causing something like this with the renderer) might be another locking issue :(

found 2 other streams 1 causing a black screen and the other even a hang of ffdshow or mpc-hc closing doesnt unloads it (have to kill it) and the good old beyonce tssplit is also failing with audio only :(

also the just recently posted stream by someone experiencing strange behavior on android and ipad with it dongle_3 http://forum.doom9.org/showthread.php?t=163695 gets unsync from the start with ffdshow quicksync (mpc hc splitter and lav audio)

MC.ts still fails i guess we can slowly say it's a Hardware issue and wont be fixed ? (see starting of this thread the VC-1 special interlace case) sad thing seeing that Nvidia was capable supporting it very fast 1 driver release after the report to donald it was supported :)

ok finished the MPC-HC splitter go trough now continuing with a Lav Splitter round and comparing issues :) then make some tests and post samples and issues and then test the deinterlacing part of things :)

[egur]

Egur
started testing in Progressive mode (forcing every Interlaced content to be displayed as such) and so far on the .ts part i found 1 sample that behaves rather strange with a very high latency but only @ the beginning (looks crazy) 6ms for a 30 1080i stream and audio sync issues but whats really crazy with this is as soon as i change the player size (let jans renderer do a refresh) it gets sync ;) i separated that stream for now for further testing (very interesting never saw a stream causing something like this with the renderer)
Strange, never saw such a thing. Please (multiupload please)

found 2 other streams 1 causing a black screen and the other even a hang of ffdshow or mpc-hc closing doesnt unloads it (have to kill it) and the good old beyonce tssplit is also failing with audio only :(

also the just recently posted stream by someone experiencing strange behavior on android and ipad with it dongle_3 http://forum.doom9.org/showthread.php?t=163695 gets unsync from the start with ffdshow quicksync (mpc hc splitter and lav audio)
Please share the problematic clips.

ok finished the MPC-HC splitter go trough now continuing with a Lav Splitter round and comparing issues :) then make some tests and post samples and issues :)
Great! Your problematic clips sometimes find hard-to-find bugs in my code. It really help.

[CruNcher]

WOW im baffled almost my entire test database (205 tests) work with Lav Splitter (TS part) + ffdshow quicksync actually it comes not from nothing i booged nev hard with samples and cases ;) but i really feel that was worth it great job nev great job libav/ffmpeg team great job egur :)

Yep gonna upload the 3 problems i found and think might be fixable and fail on both MPC-HC and Lav Splitter one is hard unsync issue but its a corrupt stream and i already tested a VideoRedoed version that works flawless also Mplayer itself gets sync fast same for Lav Video (though obviously it would be a big bonus if you could get it working without hurting the current overall stability which is excellent in combination with .ts and Lav Splitter 0.43 EVR Custom currently) :)

Though the other issue makes me more nervous, it seems to be a H.264 x264 decoding error :( that doesn't happen with Software or another DXVA decoder

anyway preparing 3 smaller samples that show the issues im not sure with the refresh issue which could be a encoder error (maybe that logo animation is the cause ?) as this switch in framerate looks strange (it seems to switch from 30 (unsync state) to 29 fps (sync state) it takes a while to recover though refreshing or seeking can force it faster it seems :)

So here we go

Decoding Error = http://www.mediafire.com/?rld8gnlh52f03ud (not good) (Cyberlink DXVA = Fail, CoreAVC DXVA = OK, CoreAVC = OK, Arcsoft DXVA = OK, ffdshow-quicksync = Fail, Lav Video = OK, Mainconcept DXVA = Fail, Mainconcept = Fail, Microsoft DTV = Fail, DivX = Fail, Mirillis = Fail, Potplayer DXVA = OK)
Refresh Lock Problem = http://www.mediafire.com/?8u0sn24cfggx6dq (that is the strange behaving one, we might need jan here also involved as refreshing the experimental renderer also locks the what seems correct fps 29.97 seeking though seems to have the same effect i wonder if its related to the corrupt unsync issue)
Sync issue = http://ibc.cdngc.net/Avidan/dongle_3.ts (Sync can be forced by seeking)

Hehe the sync issue dubilev stream is suffering from i guess is the same cause as mine his sample should it be fixed should fix mine too i already found out its hard to get such a sample as mostly all the time you cut you can create a new hard unsync that cant sync @ seek anymore or you fix it entirely (depending on the muxer) ;)

So here is another sample of the unsync issue additionally = http://www.multiupload.com/QL5F0FRM7O (Sync can be forced by seeking)

[egur]

@CruNcher,
I'll take a look at the clips in the following days and root cause the individual problems. I'll report back.

[nevcairiel]

I did some more tests, and it looks like i get the progressive flag on every frame of some interlaced H264 streams.

Seems to only affect H264 so far, and from the looks of it, the files i tested are MBAFF.
PAFF seems to be sporadically wrong (it has interlaced flags for a while, and then not, and then again)
"Normal" interlaced is fine.

MBAFF: http://files.1f0.de/samples/Test_clip_avc.1080i59.94.ac3.5.1.mkv
PAFF: http://files.1f0.de/samples/premiere-paff.ts

Sorry if this was discussed before, i remember vague mentions of such problems, but nothing conclusive. :
Seems like a bug in the Media SDK APIs to me.

For the record, NVIDIA had similar issues at the beginning of their CUDVID API, but they worked it out pretty good.

[CruNcher]

Jep also reported these MBAFF issues once but i currently not try to focus on deinterlacing but more stability as a whole first next step again is the whole line of deinterlace issues, though with such issues in a interlaced stream as the refresh lock problem imho it makes no sense to test deinterlacing as it will give a failing result anyway until the main issue is fixed :)

[hhb97b]

@ Egur
Good news the Lock Problem is history :) crazy its noise less as the DXVA now, i can see the same peaking on the keyframes now as i could with Cyberlinks DXVA decoder (without any other background noise in the graph) :)
No lock lost problem on that sample anymore perfectly telecined smooth as butter with MPC-HC Splitter as well as Lav Splitter :D

Really good work :) the peaks are even lower now then what Cyberlink Produces, most results are same with MPC-HC and Lav Splitter though Arcsofts Decoder doesnt like Lav Splitter @ all, Mainconcepts DXVA is either broken or tuned for their framework exclusively :D


CruNcher: do you know what the green and red line represent in the graph? I can't find a definition anywhere.

[egur]

I did some more tests, and it looks like i get the progressive flag on every frame of some interlaced H264 streams.
...

I'll take a look.
The flagging issue was something i was working on that shouldn't have been comitted :(
I want to report that although the image is interlaced, it is packed as a progressive frame.
The DS flags are a bit confusing with this regard - I didn't see an option to report this.
Please sync to latest revision (14).

Unfortunately, I'm very short on time for proper testing, so if this breaks something, comment the following code in QuickSync.cpp (line 668)

// Frame has progresive structure but might be film type as well
else if (picStruct & MFX_PICSTRUCT_PROGRESSIVE)
{
flags |= AM_VIDEO_FLAG_WEAVE;
}

[CruNcher]

CruNcher: do you know what the green and red line represent in the graph? I can't find a definition anywhere.

http://www.ostrogothia.com/?page_id=1218

though i leave the whole syncing to Aero it does a great job so most of this isnt valid for Aero if both lines match eatch other you have the best sync anything that causes interferences will become immediately visible as peaks be it issues from outside or inside, though the OSD itself needs some time if you just need the sync graph then you can completely disable the updating realtime statistics this will improve the whole playback a tad depending on the configuration. :)
If you change something you also get peaks as the experimental renderer is refreshing after some msec (this is the biggest drawback from current trunk every change becomes a small interruption in playback also shown as a peak)

[nevcairiel]

I'll take a look.
The flagging issue was something i was working on that shouldn't have been comitted :(
I want to report that although the image is interlaced, it is packed as a progressive frame.
The DS flags are a bit confusing with this regard - I didn't see an option to report this.
Please sync to latest revision (14).

You're right, there are no options for this, which is why most algorithms just work on the assumption that its interlaced chroma, which works OK (but not perfect) for progressive, and doesn't screw up on interlaced.

Anyhow, r14 seems to be working properly. Progressive streams are still interlaced 0, and interlaced streams look good.

Thanks for the fast fix. :)
Seems to be a odd setup in the Media SDK to combine these flags into one, but oh well. :)

[egur]

You're right, there are no options for this, which is why most algorithms just work on the assumption that its interlaced chroma, which works OK (but not perfect) for progressive, and doesn't screw up on interlaced.
Great.
Now you have the option know which way is optimal to convert to RGB (or 4:2:2 or 4:4:4) within LAV decoder. But probably most people will have LAV output 4:2:0 YCbCr so it doesn't matter...
Did you finish the integration?
Please tell me how long it took you. My goal was <1 work week integration (5 days).

[nevcairiel]

Did you finish the integration?
Please tell me how long it took you. My goal was <1 work week integration (5 days).
Its not completely finished, some improvements to be done, but it took less then a work day so far. Granted, my architecture was already meant to be able to plug in different decoders, and i had some experience with the CUVID decoder which works somewhat similarly.

I do plan to include it in LAV 0.44 though, which should be done "soon".

[egur]

Its not completely finished, some improvements to be done, but it took less then a work day so far. Granted, my architecture was already meant to be able to plug in different decoders, and i had some experience with the CUVID decoder which works somewhat similarly.

I do plan to include it in LAV 0.44 though, which should be done "soon".
Very well.
A few pointers you need to check:
1) A D3D device (QuickSync) needs a D3D device manager from the renderer to work in full screen exclusive. Look at the proxy class (TVideoCodecQuicksync within ffdshow) on how to extract the device manager. Passing the device manager improves init time but it's not critical in other cases.
2) WMC will call your decoder to create thumbnails without providing the D3D device manager. You will need to use SW fallback. In ffdshow, I looked at the GUID of the renderer for this purpose (TffdshowDecVideo::CompleteConnect). If you have a more elegant solution. Let me know.
3) The ffdshow proxy class checks the ability for the decoder to tun (see the check function). I may improve it in the future to make it quicker (e.g. not load the decoder dll)

Anyway, please let me know what parts of integration were not simple. I'll also make a guide in the future.

[nevcairiel]

I found another small annoyance. :)

Your decoder currently checks the dwProfile value in the media type for compatibility, however that value is not guaranteed to be present (or correct)
Its quite certainly possible that the source does not set or know the value, especially in the case of live streaming, when the media type usually doesn't contain extradata either. It also happened before that these values were wrong, which is why i changed to actually checking the bitstream (SPS for H264, and the sequence info for MPEG2).

I would be happy with a flag to disable your own checks, in case the DS decoder around it already does them, but if you want to re-work and improve your own checks, thats good too. :)
Personally, i would've designed your whole DLL indepedent of DirectShow specific things anyway, so no IMediaSample input and no DirectShow media types, but thats another thing. :)

PS:
While reading around in your code, i found this: (made me laugh a bit :))

// Discard audio NALUs
if (NALU_TYPE_AUD == naluType)
continue;


AUD is Access Unit Delimiter, not Audio. No reason to drop it. :D

[nevcairiel]

I also have a bug report:

Enabling multi-threading causes a freeze on MPEG-2 files when ReClock is used (possibly because of its own graph it builds), doesn't happen without ReClock or when multi-threading is off.
As a workaround, i disabled any HW decoding when i detect that ReClocks fake graph is building the graph, and this solves it for now.

I didn't test with ffdshows QS decoder, but i can try it later.

[egur]

I also have a bug report:

Enabling multi-threading causes a freeze on MPEG-2 files when ReClock is used (possibly because of its own graph it builds), doesn't happen without ReClock or when multi-threading is off.
As a workaround, i disabled any HW decoding when i detect that ReClocks fake graph is building the graph, and this solves it for now.

I didn't test with ffdshows QS decoder, but i can try it later.

I'll check it out. I didn't test with Reclock or got any feedback on freezes yet.
Any specific setting? Just MPEG2? All MPEG2 files?

BTW don't enable DVD decoding it's not functional.

Regarding checks, this must be done as a workaround for various issues I got in the past and may exist today. The decoder can expect the media samples to report something valid or close to it.
Reporting a supported profile when it's not, can lead to a severe decoder failure during init.
If the sequence headers come within the stream this will be OK. If miss report the format to the MSDK (e.g. profile/level/width/height) as long as it's still the same decoder, the HW decoder will fail gracefully and a operation will continue after a reset. This is transparent to you.
If the QS decoder refuses to play a clip, there's no need to force it. You can "fix" the media sample if you want, but this is probably a rare case.
I didn't get any reports on this issue yet.

Also parsing various headers will cause a lot of code bloat which I don't want ATM. I want to keep the code size to the minimum. No problems with ffdshow so far.
Supported formats might grow or shrink (not likely :) ) on different models so it's best that compatibility checks are black boxed.

[nevcairiel]

Regarding checks, this must be done as a workaround for various issues I got in the past and may exist today. The decoder can expect the media samples to report something valid or close to it.

I have sophisticated checks that don't rely on the source setting those values in the media type, instead they parse the extradata and get the real values - and if the extradata is not present, they read the actual frames until they find the info they need. I just want to be able to make use of those functions so i can offer a 100% working software fallback. It would be great to make use of these functions, because they work in many more cases where a pure checking of the media type fields fails.

Anyhow, i could probably produce an example pretty easily of a DVB application which does not set dwProfile (leaves it at 0).
Doesn't matter, i'll just fix up the media types, easy enough to do.

[egur]

I have sophisticated checks that don't rely on the source setting those values in the media type, instead they parse the extradata and get the real values - and if the extradata is not present, they read the actual frames until they find the info they need. I just want to be able to make use of those functions so i can offer a 100% working software fallback. It would be great to make use of these functions, because they work in many more cases where a pure checking of the media type fields fails.

Anyhow, i could probably produce an example pretty easily of a DVB application which does not set dwProfile (leaves it at 0).
Doesn't matter, i'll just fix up the media types, easy enough to do.

dwProfile ==0 in MPEG2 is 422 profile which isn't supported. Adding a kill switch for the init check is simple but I need to test this. Otherwise we'll go back and forth with crashes.
I can add a feature to create fake parameters if the info header is empty or invalid.
Can you supply me a clip (or flow) that demonstrates this behavior?
The Media SDK should be able to handle this situation.

Try sending a fake VIDEOINFOHEADER with fake width/height so it will pass inspection. The decoder should realloc resources and re-init the SDK when the actual stream arrives.

Update:
Using Reclock playback didn't start for several seconds on the first times I tested after installation. The debugger reported that my DLL wasn't loaded yet, LAV splitter wasn't loaded either.
A few more runs and it stopped freezing. This is very odd. I ran my entire MPEG2 collection and apart from a slower system initialization (because of reclock BTW) everything was fine.
I need to know your exact setup: player, 32/64 bit, splitter setting (I use the defaults in LAV), renderer.

[nevcairiel]

dwProfile ==0 in MPEG2 is 422 profile which isn't supported.
It could also just be a value which was never set because the demuxer doesn't extract that from MPEG-2. In my brief checks, it seems to be set at least for MPEG-TS demuxers, but who knows what in a MKV or so could happen. I still remember the bug reports, which is why i switched do bitstream analysis.


Try sending a fake VIDEOINFOHEADER with fake width/height so it will pass inspection.
I just modify the existing header and set a profile which is valid, seems to be fine. AVC1 needs its MPEG2VIDEOINFO, or stuff breaks, so i modify the dwProfile in it. Seems like the safest approach.

Anyhow, such a flag would be nice, just document it that it may cause breakage if used improperly.
Personally, i can go without it now, though.

I just fixed my last issues with VC-1 playback, and i'm about ready to post a test version.

[nevcairiel]

I found another issue.

http://files.1f0.de/samples/20100816_1715_-_TV3_(N)_-_According_to_Jim.ts

At around 0:27 its changing its aspect ratio from 16:9 to 4:3 (transition from the ads back to the show), however your decoder doesn't seem to notice the change, and keeps sending 16:9 in QsFrameData

[egur]

I found another issue.

http://files.1f0.de/samples/20100816_1715_-_TV3_(N)_-_According_to_Jim.ts

At around 0:27 its changing its aspect ratio from 16:9 to 4:3 (transition from the ads back to the show), however your decoder doesn't seem to notice the change, and keeps sending 16:9 in QsFrameData

I'll take a look.
BTW, VS2010 reports that when Reclock is used Haali media splitter is loaded before LAV splitter (along with a few other DLLs). But when DirectSound is used, it's not. Using ZoomPlayer 8.

update
Well the Media SDK doesn't report an aspect ratio change.
FFDShow with either limpeg2 or libavcodec do the same - no aspect ratio change. Tried with Haali splitter as well.
LAV video decoder + splitter (0.43) doesn't change AR as well (32 bit anyway).

[pirlouy]

Sorry if it has been asked.
Why QuickSync needs Intel GPU to be active ? From what I've read, I thought it was independant. Is there a possibility to use QuickSync to decode, and then send it to RAM for third party GPU for example ?
Is it an Intel limitation, or it's just something you don't have overlooked right now ?

[egur]

...
So here we go

Decoding Error = http://www.mediafire.com/?rld8gnlh52f03ud (not good) (Cyberlink DXVA = Fail, CoreAVC DXVA = OK, CoreAVC = OK, Arcsoft DXVA = OK, ffdshow-quicksync = Fail, Lav Video = OK, Mainconcept DXVA = Fail, Mainconcept = Fail, Microsoft DTV = Fail, DivX = Fail, Mirillis = Fail, Potplayer DXVA = OK)
Refresh Lock Problem = http://www.mediafire.com/?8u0sn24cfggx6dq (that is the strange behaving one, we might need jan here also involved as refreshing the experimental renderer also locks the what seems correct fps 29.97 seeking though seems to have the same effect i wonder if its related to the corrupt unsync issue)
Sync issue = http://ibc.cdngc.net/Avidan/dongle_3.ts (Sync can be forced by seeking)
...
So here is another sample of the unsync issue additionally = http://www.multiupload.com/QL5F0FRM7O (Sync can be forced by seeking)

The 1st shows corruption after 11 seconds. Strange that only if this clip is played from the start it shows corruption. If seeking anywhere between 0.5s and 11s will play the clip perfect. This will be hard to root cause.
The second clip played fine - the decoder reported 29.97 from the start (in debug builds I have trace prints) and this doesn't change. Tried with Haali as well. Tried 10 times to make it fail. Need more details to reproduce.
3rd clip issues are deterministic. Need to root cause. Play somewhat OK with libavcodec. Seems to be a broken stream.
4th clip - a lot of corruption at he start of the clip - probably what causing the sync issue. Maybe broken sequence header? Need to root cause.

[egur]

Sorry if it has been asked.
Why QuickSync needs Intel GPU to be active ? From what I've read, I thought it was independant. Is there a possibility to use QuickSync to decode, and then send it to RAM for third party GPU for example ?
Is it an Intel limitation, or it's just something you don't have overlooked right now ?

It's part of the Intel GPU (physically) and operated by the Intel GPU driver.
My decoder copies the frames back to system memory so you can use a renderer on another GPU. You'll need an H67/Z68 chipset for this to work. See this post on how to enable multi GPU setup: http://forum.doom9.org/showthread.php?p=1532786#post1532786

[hajj_3]

Egur, i don't suppose you know whether it is technically possible for sandy bridge's quicksync to hardware decode HEVC a.k.a h.265 when that is launched in 2013 or will the hardware on the gpu not be powerful enough to do it? It would be great if sandy/ivy bridge could hardware decode that with a software upgrade otherwise current pc's likely won't have the cpu power to decode it as it looks to be extremely cpu intensive.

[CruNcher]

@ Egur
i wont have the time to test both lav video and ffdshow-quicksync (i will though do certain cross compares on strange issues and cases) but primarily i will do all further tests with Lav Video i hope nev can help improve all the time stamping code in ffdshow-quicksync so that both will work perfectly in the end with Lav Splitter @ least for .ts now :)

if you cant reproduce it i guess we really need Jan here too i also get the same with Lav Video :) the actual decision when it recovers the lock seems non deterministic except when you seek :)

I'll make a Video of it (i hope i can capture it) :)

[nevcairiel]

update
Well the Media SDK doesn't report an aspect ratio change.
FFDShow with either limpeg2 or libavcodec do the same - no aspect ratio change. Tried with Haali splitter as well.
LAV video decoder + splitter (0.43) doesn't change AR as well (32 bit anyway).

Works for me in software decoding or CUVID decoding in LAV Video. The splitter plays no role here (or should not, its possible that Haali breaks it, because of its ugly stream AR overwriting)
Just confirmed that its indeed working just fine with LAV Splitter + LAV Video, both Software (avcodec) and CUVID. Seeking anywhere after the 0:27 mark switches AR instantly, seeking back to the start switches AR back. Playing the file from start to end switches at the proper time as well. (Make sure "Use Stream AR" option is on)

Also tested ffdshow (a rather old version i had around, r3967), and both avcodec and libmpeg2 switch the AR properly.

All tests in MPC-HC with vanilla EVR as well as EVR Custom.

[egur]

Works for me in software decoding or CUVID decoding in LAV Video. The splitter plays no role here (or should not, its possible that Haali breaks it, because of its ugly stream AR overwriting)
Just confirmed that its indeed working just fine with LAV Splitter + LAV Video, both Software (avcodec) and CUVID. Seeking anywhere after the 0:27 mark switches AR instantly, seeking back to the start switches AR back. Playing the file from start to end switches at the proper time as well. (Make sure "Use Stream AR" option is on)

Also tested ffdshow (a rather old version i had around, r3967), and both avcodec and libmpeg2 switch the AR properly.

All tests in MPC-HC with vanilla EVR as well as EVR Custom.

I tested with MPH-HC and saw what you described. ZoomPlayer have an issue with this clip as it doesn't change the renderer's AR.
I'll dig in deeper, but a quick fix is not probable.

[CruNcher]

I did some tests with this lock problem and tried this @ two refresh rates and indeed it locks faster @ 60 Hz then 75 Hz :P
@ 75 Hz it can be problematic as such that it takes longer or doesn't lock @ all not sure where this depends on Aero i guess, though im almost sure now this is more something on Jans Render side then a Splitter/Decoder issue :) Also the behavior on 60 hz Aero of both is pretty identical it deterministically never misses the lock and locks always after 20 second only the way to the lock differs a little

60 Hz (lock takes 20 seconds)

Fddshow Quicksync = http://www.multiupload.com/F3NDGFYDF7
Lav Video Quicksync = http://www.multiupload.com/NDDB6U5YU8

75 Hz (lock doesn't happen or takes very long, non deterministic, seeking forces it)

Fddshow Quicksync = http://www.multiupload.com/PMFRYQEWPI
Lav Video Quicksync = http://www.multiupload.com/VPG09HCV1H

PS: Btw trying to capture this with my GPU recording framework (Quicksync) failed same for the software based x264 counterpart this needs very low latency to be captured in Realtime Mirillis Low Latency I frame Codec was capable of achiving it without modifying the outcome result :)

[NikosD]

1) After the installation of latest driver Intel 15.22.52.2559 I found 3 MFT decoders by Intel at C:\Program Files\Common Files\Intel\Media SDK\s1\2.0\

The names are Intel Hardware H.264/MPEG-2/VC-1 Decoder MFT.

But during the enumeration of available codecs in DXVA Checker when I try to benchmark a video file, those decoders never show up.

Why?

Also in their properties they don't seem to have a DXVA option (enable/disable)



I don't know - I'm not part of the Media SDK dev team nor the graphics driver team. I'll forward your question.



4) Why Intel restricts such a POWERFUL DECODER like QS for 1920x1080 only?

I think that the driver's team should "open" the driver up to 4K x 2K that QS could handle with ease.

And of course your decoder and every other decoder using QS must be updated too, to include 4K x 2K.



See answer #1. My guess would be that it made the HW more expensive and not worth the cost. I'll forward the question.


Eric hi.

Any feedback from the Intel Media and drivers team for the above questions ?

Now that latest beta from PotPlayer v1.5.31323 supports DXVA H.264 4K x 2K resolutions with it's internal codec, it would be useful for us to check it out.

We only need Intel to update the drivers.

You could add those resolutions to your project too.

[Blight]

Thanks to an insight from nev, Zoom Player v8.1 final will support dynamic aspect ratio changes with EVR.
I just verified that it works against the test clip posted earlier with both LAV and Haali as the source filters :)

ETA to v8.1 release, ~4h

[CruNcher]

Eric hi.

Any feedback from the Intel Media and drivers team for the above questions ?

Now that latest beta from PotPlayer v1.5.31323 supports DXVA H.264 4K x 2K resolutions with it's internal codec, it would be useful for us to check it out.

We only need Intel to update the drivers.

You could add those resolutions to your project too.

4K works @ least non DXVA it seems

http://img266.imageshack.us/img266/720/ffdshowquicksync4k.png

Though im not sure if it might have fallen back to Intels Software Decoding Core or Libav ? (ill try to check)

[hajj_3]

wouldn't 4k be 2160p (3840x2160)?

4096 x 2304 seems an odd size?

[CruNcher]

3840x2160 that's QFHD (2160p)
4096 x 2304 is 4K @ 16:9 AR
Full 4K 4096 × 3112

http://www.youtube.com/view_play_list?p=5BF9E09ECEC8F88F

PS: I found out that Arcsofts Decoder on Intel is by default (when called from Directshow directly, not sure about TMT5) (@ least for VC-1) a "Copy Back Decoder" (and it has very poor performance the heavier the stream gets, comparable to what ffdshow-quicksync reached in the beginning without all the Copy improvements) :P

@Egur

So with this my testing @ least for playback stability of .ts (Lav Splitter) and with quicksync (ffdshow-quicksync,lav video quicksync) ended, i will finish the deinterlace test on lav video and then finally move on to .mp4/.mov/.mkv/.wmv/.mpg/.m2ts :D so only the 2 issues are left the Sync problems with those damaged streams that work fine @ Software Decoding (Libav) and this strange Decoding error and what i guess wont be fixed anymore on the Driver side the MC.ts VC-1 interlace issue :)
I hope especially someone is able to root cause the decoding error the Sync issue for damaged streams seems not so critical as it can be fixed manually by a short seek @ playback (though indeed i didn't tested if it becomes maybe unsync after some time again) and also not sure what happens @ Encoding i guess end result would be unsync though :)

Left Decoding stability issues ( Lav Splitter + FFdshow-quicksync/Lav Video Quicksync + Lav Audio Decoder):

Decoding Error = http://www.mediafire.com/?rld8gnlh52f03ud (not good) (Cyberlink DXVA = Fail, CoreAVC DXVA = OK, CoreAVC = OK, Arcsoft DXVA = OK, ffdshow-quicksync = Fail, Lav Video = OK, Lav Video Quicksync = Fail, Mainconcept DXVA = Fail, Mainconcept = Fail, Microsoft DTV = Fail, DivX = Fail, Mirillis = Fail, Potplayer DXVA = OK)
Sync issue = http://ibc.cdngc.net/Avidan/dongle_3.ts (Sync can be forced by seeking)

also Nev should look @ those last 2 issues from the Parser/Splitter part :)

[egur]

@NikosD
I had a crazy week and didn't get to do it.
Did you try posting on the driver or media sdk support forums?

I can't manage to download any of the 4k clips, can anyone help/share?

[CruNcher]

http://www.mediafire.com/?yn7pa6xe0cdp5cx

but they are rather easy to decode hence youtube and low bitrate harder are the QFHD samples with enormous bitrates 50 Mbps and up

[egur]

PS: I found out that Arcsofts Decoder on Intel is by default (when called from Directshow directly, not sure about TMT5) (@ least for VC-1) a "Copy Back Decoder" (and it has very poor performance the heavier the stream gets, comparable to what ffdshow-quicksync reached in the beginning without all the Copy improvements) :P

This is very odd. How do you they use DXVA?
BTW, with frame copying the resolution and frame rate is what makes the difference, not the bitrate.

So with this my testing @ least for playback stability of .ts (Lav Splitter) and with quicksync (ffdshow-quicksync,lav video quicksync) ended, i will finish the deinterlace test on lav video and then finally move on to .mp4/.mov/.mkv/.wmv/.mpg/.m2ts :D so only the 2 issues are left the Sync problems with those damaged streams that work fine @ Software Decoding (Libav) and this strange Decoding error and what i guess wont be fixed anymore on the Driver side the MC.ts VC-1 interlace issue :)
I hope especially someone is able to root cause the decoding error the Sync issue for damaged streams seems not so critical as it can be fixed manually by a short seek @ playback (though indeed i didn't tested if it becomes maybe unsync after some time again) and also not sure what happens @ Encoding i guess end result would be unsync though :)


Well, you know the last 1% is always the hardest...

On another matter, I'll release another update in a few days. There's a small bug related to multi threading. Afterwards, I want to really optimize the multithreaded path.
When this is done, it's time to put the video processing in.

[dukey]

Egur since you work for Intel. Can you get someone to fix the opengl drivers ? There's a list of serious problems with them .. In fact it's so bad it's enough to make developers want to abandon opengl.

eg
Intel -> http://i126.photobucket.com/albums/p95/dukeeeey/gfx%20stuff/image1.png
ATI/Nvidia -> http://i126.photobucket.com/albums/p95/dukeeeey/gfx%20stuff/Image2.png

[egur]

Egur since you work for Intel. Can you get someone to fix the opengl drivers ? There's a list of serious problems with them .. In fact it's so bad it's enough to make developers want to abandon opengl.

eg
Intel -> http://i126.photobucket.com/albums/p95/dukeeeey/gfx%20stuff/image1.png
ATI/Nvidia -> http://i126.photobucket.com/albums/p95/dukeeeey/gfx%20stuff/Image2.png

Sorry, please post in driver support forum.

[NikosD]

@NikosD
I had a crazy week and didn't get to do it.
Did you try posting on the driver or media sdk support forums?

I can't manage to download any of the 4k clips, can anyone help/share?

I didn't post there because we have Intel here :D

Here you are for the samples:

http://xhmikosr.1f0.de/index.php?folder=c2FtcGxlcy8yMTYwcA==

[CruNcher]

This is very odd. How do you they use DXVA?
BTW, with frame copying the resolution and frame rate is what makes the difference, not the bitrate.



Well, you know the last 1% is always the hardest...

On another matter, I'll release another update in a few days. There's a small bug related to multi threading. Afterwards, I want to really optimize the multithreaded path.
When this is done, it's time to put the video processing in.

Yep that could maybe explain why it crashes very strangely @ a 720p 50 fps clip Microsofts 2011 Build Keynote and inside TMT5 it gets totally unsync :P

with higher res 1080p it works outside but i get 15 fps for a 30 fps clip and im pretty sure those are no parser issues ;)

anyways here is a QFHD sample (Mainconcept) http://115.com/file/be83t4l4# it's heavier then the Life in the Garden 4K Bitrate wise

this really pressures Quicksync heavily and it gives it a run for its money also it seems Lav Video Quicksync Performed a tad better then ffdshow-quicksync but mostly performance is the same with audio brake ups and fps brakes, when changing to Software Decoding its flawless so im pretty sure Quicksync Decoded it (and IO was also no issue). Though i guess it doesn't even have todo with the Decoder but the Memory Copy i guess the Hardware would be capable of playing this flawless ?.
Trying some of the DXVA decoder on it

Nope DXVA fails as others already said or it falls back to Software Decoding

QFHD 50Mbps H 5.1

Lav Video

http://img810.imageshack.us/img810/176/lavvideo.png

Lav Video Quicksync

http://img42.imageshack.us/img42/1662/lavvideoquicksync.png

So for now with this performance i would make the suggestion to fallback to Software (Libav) for these complexities though with the 4K youtube it has less problems so it wont be enough to just decide this based on resolution i guess ;)

Lav Video Quicksync "Youtube 4K" H 5.1 Max 19.4 Mbps

http://img40.imageshack.us/img40/2609/lavvideoquicksync4k.png

So that runs rather ok but seeing those spikes i guess that's where the bitrate shoots higher and indeed the Quicksync Decoder gets problems to cope with that Bitrate Spikes + Resolution it seems. So if that starts here already it's no wonder it's dying with the QFHD sample though lets analyse the GPU MFX pressure (that's where it would be nice to have it directly in the OSD + Power consumption, craziest of course as another Realtime Graph :))

So there are 2 possibilities

Either the Decoder cant cope with the bitrate (most probably) or the +~6 fps are enough pressure on the copy side to cause the playback to endup like this (doubtful)

And so in the first case no DXVA would help here and Sandy Bridge would only be able to play very restricted 4K @ all (even youtube looks slightly to much for it ;) )

[egur]

anyways here is a QFHD sample (Mainconcept) http://115.com/file/be83t4l4# it's heavier then the Life in the Garden 4K Bitrate wise

Can you share on multiupload, download breaks all the time.

[fano]

Hy egur :D

I'm in a lot of trouble:
I've downloaded last ffdshow compiled by you: quicksync is present during installation, but not after installation (on the normal ffdshow Video Codecs page): Mediaportal plays the file but the ffdshow icon says it's using libvacopec (cpu usage is high!)... in ffdshow video I can't configure QuickSync anymore :mad:

It's a bug or my system it's not supported?

Strange as my hardware is AsRock Core 100 HT:
http://www.asrock.com/nettop/overview.asp?Model=Core%20100HT#Specifications

it shouldn't be supported?
If not why installer deludes me?
Official ffdshow have QuickSync selectable but in the they used libvacodec...

I've to install by hand (?) the famous QuickSync,dll? There's none in my system :p

:thanks: for your support!

[NikosD]

@Cruncher
@Egur

I can't think of a way to be possible for any DXVA decoder or DXVA through Intel Media decoder to play a video file of a resolution beyond 1920 x 1080 in DXVA mode, when DXVA Checker says that there are no device decoders capable of more than 1920 x 1080.

If Intel drivers don't install decoder devices capable of more than 1080, you will never manage to run DXVA beyond 1080, I think.

If you run DXVA Checker to check the decoder devices for Intel HD graphics, you will see what I'm talking about.

BTW did you check http://xhmikosr.1f0.de/index.php?folder=c2FtcGxlcy8yMTYwcA==

It has a lot of 4K samples and good download speed.

[egur]

Hy egur :D

I'm in a lot of trouble:
I've downloaded last ffdshow compiled by you: quicksync is present during installation, but not after installation (on the normal ffdshow Video Codecs page): Mediaportal plays the file but the ffdshow icon says it's using libvacopec (cpu usage is high!)... in ffdshow video I can't configure QuickSync anymore :mad:

It's a bug or my system it's not supported?

Strange as my hardware is AsRock Core 100 HT:
http://www.asrock.com/nettop/overview.asp?Model=Core%20100HT#Specifications

it shouldn't be supported?
If not why installer deludes me?
Official ffdshow have QuickSync selectable but in the they used libvacodec...

I've to install by hand (?) the famous QuickSync,dll? There's none in my system :p

:thanks: for your support!
I've just downloaded and installed the latest SVN build (4225) and it works fine. The DLL name is IntelQuickSyncDecoder.dll BTW.
It looks like your system is based on an older CPU (Nehalem or Westmere) - the 1st generation i3/i5/i7. Although these systems should work, they don't work as good as SandyBridge. Are you sure the Intel driver is enabled?

[CruNcher]

Can you share on multiupload, download breaks all the time.

Did you tried it from both server ?

@Cruncher
@Egur

I can't think of a way to be possible for any DXVA decoder or DXVA through Intel Media decoder to play a video file of a resolution beyond 1920 x 1080 in DXVA mode, when DXVA Checker says that there are no device decoders capable of more than 1920 x 1080.

If Intel drivers don't install decoder devices capable of more than 1080, you will never manage to run DXVA beyond 1080, I think.

If you run DXVA Checker to check the decoder devices for Intel HD graphics, you will see what I'm talking about.

BTW did you check http://xhmikosr.1f0.de/index.php?folder=c2FtcGxlcy8yMTYwcA==

It has a lot of 4K samples and good download speed.

The problem is it might not support even High Bitrate QFHD and DXVA cant change that it has nothing todo with it but the Decoder Asic

So it seems pretty useless to enable it when people would only get bad performance from it in the end customer support would be ringing all day and night for the ISVs as well, just for the same answer we never advertised with it it's not capable of it have a good day ;) .

It might be enough to higher the Frequency of the current Asic i guess in Ivy Bridge they will have done that (due to all the improvements a little more heat is no problem, they would cancel it out with the tri gates), The Quicksync encoder partly relies in performance on the GPU frequency (EU,Shader) but i doubt the Decoder shares the same though easy to test :)

[NikosD]

@Cruncher

Have you seen my thread with DXVA hardware comparisons ?

http://forum.doom9.org/showthread.php?t=163110

As you can see, QS Decoder is more than faster from VP5 which Nvidia says it's capable of 4K.
So if Nvidia says that VP5 is capable of 4K, then what Intel has to say about QS Decoder performance and 4K ?

Also the QS decoder has the same frequency as the GPU.

[CruNcher]

@Cruncher

Have you seen my thread with DXVA hardware comparisons ?

http://forum.doom9.org/showthread.php?t=163110

As you can see, QS Decoder is more than faster from VP5 which Nvidia says it's capable of 4K.
So if Nvidia says that VP5 is capable of 4K, then what Intel has to say about QS Decoder performance and 4K ?

Also the QS decoder has the same frequency as the GPU.

hmm yep that would be 2x more frequency than VP4 is by default running @ and could explain the performance + being ondie. Did someone ever benchmarked results GPU overclocked if the Asic and GPU are really bound with each others clocks you should see a improvement in Decoding performance, though due to my understanding they are separated from each other same as with Nvidias Asic most probably also AMDs.

Anyway you are right it's a little strange and i also would expect those QFHD Sample to play without issues though GPU seems overloaded i didn't look @ the stats yet but my mouse starts to lag and whole Aero latency explodes this is a clear indication of GPU @ its edge, though could also explain that GPU and Decoder are really dependent on each other and in the case of the Memory Copy they are so it's hard to say which of those 2 possibilities is the case here with QFHD playback. So you could say the Memory Copy is causing the stress and spikes seeing that the whole Aero Desktop is under pressure it very well could be the case and with DXVA it might run flawless.

What i could try is to unload the GPU Shaders from some load and see how that works out using MadVR @ lowest quality config or use overlay directly :)

Yep CPU gets @ the edge (fluctuates heavily) also when Rendering into Nul so most probably it is the the Memory Copy overload that is causing the problems, so with DXVA it should indeed play flawless :)

[nevcairiel]

Eric, i debugged the Aspect Ratio problem a bit, and i found why its not working.

Apparently, the structure you get back from GetVideoParams does not update - however the structure thats associated to the surface itself does contain the new data.

So, in CQuickSync::ProcessDecodedFrame, if you look at pSurface->Info, all the needed information is there, you just have to plug it into your output frame.

Hope you can address that soon'ish. :)

[egur]

Eric, i debugged the Aspect Ratio problem a bit, and i found why its not working.

Apparently, the structure you get back from GetVideoParams does not update - however the structure thats associated to the surface itself does contain the new data.

So, in CQuickSync::ProcessDecodedFrame, if you look at pSurface->Info, all the needed information is there, you just have to plug it into your output frame.

Hope you can address that soon'ish. :)

:thanks: for finding the workaround. I'll test it. I'm not sure this is the intended way of doing things, but as a temporary solution I'll implement the fix. I'm not very happy with how multithreading is done in my code and I already found a bug. I'll release a new version in a few days.

Update
I've committed the last fixes (rev16) including the AR fix - nev's workaround was working great 10x again.
Did very basic testing so I'm not releasing a build just yet. Only after the MT rework.

[NikosD]

My second visit to Core i5-2400 system and a more careful look to GPU frequency, Power consumption and performance.

During playback with PotPlayer DXVA and PotPlayer QS the GPU is always at default speed of 850MHz, the CPU at 1.6GHz and the total consumption of CPU package is ~12W - 15W and QS about 7 - 8 W.
To find QS power consumption, I substract from the whole package the IA cores and GT cores.

But for 60fps during playback with QuickSync only (not DXVA) the total consumption goes up to 25 - 28 W, because although GPU remains at default speed of 850 MHz, the CPU goes up to 3.2GHz (Turbo mode).
QS consumption still remain to 7-8 W.

During benchmarking I had a real surprise.

Most of the time during 60fps clips benchmarking with QS FFDshow the GPU remained at 850 MHz, it didn't go to 1100 MHz.

During pure DXVA benchmarking the GPU (QS) always goes to maximum speed of 1100 MHz, just as QS FFDshow goes up to 1100 MHz during benchmarking of non 60fps clips.

That explains the "poor" performance of QS FFDShow vs QS DXVA in 60fps clips. It never pushes QS to maximum speed.

The power consumption went very high up to 43W for the whole CPU package because CPU and GPU during benchmarking works at Turbo mode (3.2 GHz) and 1100 MHz.
QS FFDshow had 7-9 W more power consumption than QS DXVA.

One last thing...

During QS FFDShow VC-1 benchmarking, GPU (QS) was at default speed of 850 MHz, the QS utilization was ONLY 35% !! but it decoded 200 fps at the most difficult VC-1 clip I have found.

So if someone could use VC-1 decoder at 1100MHz and 97-98% utilization, he could easily exceed 700 fps!

[nevcairiel]

Update
I've committed the last fixes (rev16) including the AR fix - nev's workaround was working great 10x again.
Did very basic testing so I'm not releasing a build just yet. Only after the MT rework.

Tried it, and seems to be working great.
I disabled MT for the time being, and still going with r16. :)

[egur]

Tried it, and seems to be working great.
I disabled MT for the time being, and still going with r16. :)

Very well, maybe you can put a setup option to disable/enable MT for stress testing or benchmarks.

[nevcairiel]

I got reported a rather odd bug..

Sample: http://www.multiupload.com/96E38TN3HI

This file hangs the player after a few seconds when multi-threading is disabled. Funny enough, it works with multi-threading on, however not completely. If you seek alot, it can hang the player too.
The "special" thing about this file appears to be that it has 16 ref-frames, however i'm not sure thats the real cause for the problem.

I'll try to debug a bit as well, but if you get a chance to look at it, that would be great. :)

Edit:
First debug results:

It seems to hang in CQuickSync::ProcessDecodedFrame in the loop that waits for a free frame, but never gets one (the while (m_FreeFramesPool.Empty()) loop)
I increased the capacity in CQuickSync::InitDecoder from 4 to 20, and the hang seems to be gone in initial tests. I tried 8 before, and hang was still there, so i went overboard with 20 to be sure. :p

I'm not sure what that the fixed-size pool is good for anyway. If it cannot get one, just create a new one? Maybe i'm missing something. :) At least 4 seems to be not enough for some streams like that.

[nevcairiel]

Another problem/bug

When decoding Live TV with DVBViewer, it frequently happens that after a channel change you don't get an image for 20-30 seconds or so, then it suddenly starts working.

In the period when its not working, i'm spammed with these errors:

QSDcoder: Decode MFX_ERR_NOT_ENOUGH_BUFFER
QSDcoder: Error - ran out of work buffers!


Again, i'll try to look into it. :)

Edit:
I think i know why. Apparently you don't init the decoder until OnSeek is called, right? However, the Source filter in DVBViewer doesn't call NewSegment during the start of playback (and thus no OnSeek is triggered), it may take a while for this to happen (for some reason), and such, its not initialized in time.
I tried manually calling OnSeek during my own init, and then it works. I would suggest to check if you init'ed in ::Decode(), and if it didn't happen yet, perform these steps there? As i understand, the delay is only there to allow for setting the D3D device manager, so when you start decoding something, you should have that setup already.

[egur]

I got reported a rather odd bug..

Sample: http://www.multiupload.com/96E38TN3HI

This file hangs the player after a few seconds when multi-threading is disabled. Funny enough, it works with multi-threading on, however not completely. If you seek alot, it can hang the player too.
The "special" thing about this file appears to be that it has 16 ref-frames, however i'm not sure thats the real cause for the problem.

I'll try to debug a bit as well, but if you get a chance to look at it, that would be great. :)

Edit:
First debug results:

It seems to hang in CQuickSync::ProcessDecodedFrame in the loop that waits for a free frame, but never gets one (the while (m_FreeFramesPool.Empty()) loop)
I increased the capacity in CQuickSync::InitDecoder from 4 to 20, and the hang seems to be gone in initial tests. I tried 8 before, and hang was still there, so i went overboard with 20 to be sure. :p

I'm not sure what that the fixed-size pool is good for anyway. If it cannot get one, just create a new one? Maybe i'm missing something. :) At least 4 seems to be not enough for some streams like that.

This is a special clip - a specific call to Decode caused more than 4 frames to be outputted. I have overlooked this case.

the fix is add a call to DeliverSurface after ProcessDecodedFrame:
ProcessDecodedFrame(pSurface);
DeliverSurface(true);


The reason to use 4 is because using more wastes a lot of memory and doesn't gain any speed (using current implementation anyway). There's a race who works faster - the HW decoder or the frame copy. If the decoder is super fast (low bitrate) than an unlimited queue will eat up all the memory. If the decoder is very slow compared to the frame copy, a large queue will not help.
This will probably change a few times before I'm done with it.
Thanks for finding another bug.

[egur]

Another problem/bug

When decoding Live TV with DVBViewer, it frequently happens that after a channel change you don't get an image for 20-30 seconds or so, then it suddenly starts working.

In the period when its not working, i'm spammed with these errors:

QSDcoder: Decode MFX_ERR_NOT_ENOUGH_BUFFER
QSDcoder: Error - ran out of work buffers!


Again, i'll try to look into it. :)

Edit:
I think i know why. Apparently you don't init the decoder until OnSeek is called, right? However, the Source filter in DVBViewer doesn't call NewSegment during the start of playback (and thus no OnSeek is triggered), it may take a while for this to happen (for some reason), and such, its not initialized in time.
I tried manually calling OnSeek during my own init, and then it works. I would suggest to check if you init'ed in ::Decode(), and if it didn't happen yet, perform these steps there? As i understand, the delay is only there to allow for setting the D3D device manager, so when you start decoding something, you should have that setup already.

OK, i think I know the problem. I don't have a live TV capture setup and I'm not familiar with DVBViewer.

The decoder is initialized late to handle full screen exclusive mode where the decoder must have an external D3D device manager.
Long story short, because of DVD playback issues (DVD doesn't send NewSegment either) the Decode function looks for the internal variable m_bNeedToFlush. This variable is set to true on either NewSegment (OnSeek) or BeginFlush. It means that the decoder has received a flush (discard frames) event and the flushing have not completed. This is a must due to the asynchronous nature of the BeginFlush/EndFlush function calls (Nev, you know this but I'm trying to draw a complete picture).

Since DVBViewer doesn't send neither NewSegment nor BeginFlush, the Decoder Init function should set m_bNeedToFlush to true. In normal playback, OnSeek is called anyway so no performance is lost at all.
In InitDecoder:
MSDK_TRACE("QSDcoder: InitDecoder\n");
CQsAutoLock cObjectLock(&m_csLock);
m_bNeedToFlush = true;

[nevcairiel]

Since DVBViewer doesn't send neither NewSegment nor BeginFlush, the Decoder Init function should set m_bNeedToFlush to true. In normal playback, OnSeek is called anyway so no performance is lost at all.


It can also happen if a dynamic format change occurs.
Its possible for a DirectShow decoder to receive a new media type and perform a complete format change without any flush on the graph.

This change would also take care of that, good.

PS:
Are you commiting those changes, or do i have to ship a modified version to my testers? :D
Also, doesn't multi-threading also need a fix for the first issue? Well, i guess when you're reworking the whole MT anyway, you can handle it somehow. :)

[egur]

It can also happen if a dynamic format change occurs.
Its possible for a DirectShow decoder to receive a new media type and perform a complete format change without any flush on the graph.

This change would also take care of that, good.

PS:
Are you commiting those changes, or do i have to ship a modified version to my testers? :D
Also, doesn't multi-threading also need a fix for the first issue? Well, i guess when you're reworking the whole MT anyway, you can handle it somehow. :)
If it's the same kind of codec then there's no problem changing the media type during playback (should be). If a new codec is used then you must destroy the decoder and reinitialize - call Flush() before destruction.

I suggest for now to disable MT for testing.
I've made good progress on MT and probably release tomorrow.

[nevcairiel]

Sounds good.

With all the recent fixes, its working quite nicely now. :)

[El Topo]

Thanx for the work guys.

What Renderer should I use with QS Decoder? Normally I use EVR-Custom, but the performance seems to be significant lower than with vanilla EVR.

I have a SB Pentium G630T and a Celeron G530, if you want me to test specific things, let me know.

Nev, good work with the integration. Can't figure out any further problems with the fix1-version from yesterday.

[egur]

Thanx for the work guys.

What Renderer should I use with QS Decoder? Normally I use EVR-Custom, but the performance seems to be significant lower than with vanilla EVR.

I have a SB Pentium G630T and a Celeron G530, if you want me to test specific things, let me know.

Nev, good work with the integration. Can't figure out any further problems with the fix1-version from yesterday.

With SandyBridge, you best bets are either EVR (standard) or MadVR. EVR has better performance and more image processing algorithms. MadVR has several advanced features and is more configurable.

[El Topo]

Good to know... I always thought EVR Custom is more andvanced than EVR standard.

I use DVBViewer and XBMC most of the time, so no Madvr for me at the moment....

[nevcairiel]

Its more advanced, but it also needs more performance for those advanced features.

[fano]

I've just downloaded and installed the latest SVN build (4225) and it works fine. The DLL name is IntelQuickSyncDecoder.dll BTW.
It looks like your system is based on an older CPU (Nehalem or Westmere) - the 1st generation i3/i5/i7.

Thanks egur for your prompt response... for start now I've installed a official ffdshow: rev4192 for precision (I've formatted to restart clean!) so, I suppose it's normal there is no Quicksync dll (but in H264 decoder I've QuickSync selectable BUT not working as in you fork... this is a bug?) :p

So that's my CPUZ report m(it says it's ARRANDALE CPU!):
http://www.4shared.com/archive/EY6wLrGj/AsRcok_Core100.html

And GPUZ report:

http://gpuz.techpowerup.com/12/01/06/7fz.png


Although these systems should work, they don't work as good as SandyBridge. Are you sure the Intel driver is enabled?

Ahrrr sad news... it could not work? I hope you'd do work!

Yes I've installed GPU driver if it's that you're talking: in Intel GPU information I see it's version 6.14.10.5387...

I'd suppose it's the last...

There something other to install I've lost?
Thanks for all your help... it's appreciated :D

[nevcairiel]

Thats Windows XP, eh?
The Intel QuickSync tech only works on Vista or 7, no XP support.

[egur]

Good to know... I always thought EVR Custom is more andvanced than EVR standard.

I use DVBViewer and XBMC most of the time, so no Madvr for me at the moment....

EVR is special in the sense that it's output is different between Intel, Nvidia and AMD. Also different between GPU families and generations.
Many people think EVR uses simple bi-linear interpolation for scaling. For old cards, they are right. For the new cards that very wrong.
SandyBridge use a very advanced scaler. So it's best to test for yourself. The power/performance of the GPU is best utilized by the EVR. You should check the quality by applying a large scale factor to a clip (e.g. 4x) as well as very small scale factor (e.g. 1/4x).

[rica]

AFAIK, egur's utility wouldn't work on Arrandale/Clarkdale even it was Vista or Seven?

[egur]

Thats Windows XP, eh?
The Intel QuickSync tech only works on Vista or 7, no XP support.

Correct, XP not supported (need DXVA2 to work). Sorry.

[egur]

AFAK, egur's utility wouldn't work on Arrandale/Clarkdale even it was Vista or Seven?

Works on Penryn (or newer) with Intel GPU on Vista (or newer).
I only test Windows 7 (and newer) and SandyBridge (and newer).

[clsid]

I've installed a official ffdshow: rev4192That is an old version and does not yet include quicksync. Latest build available on SourceForge is 4225.

[rica]

Sorry egur, I've missed your latest update. :o

I will test it with my iGPU; i3 540+H55 on Seven 32.

[fano]

Correct, XP not supported (need DXVA2 to work). Sorry.

So I've lost... in the END :mad:
I NEVER install Vista or 7.. I hate them!

No chance to make it works in XP, too? Pretty please with chocolate on top :D

In the end Windows XP is the best Microsoft OS ever, right ;) ?

[nevcairiel]

No chance to make it works in XP, too? Pretty please with chocolate on top :D

No chance. Its impossible, the XP driver does not allow it.
The only chance would be if Intel starts supporting this in the XP driver, but the chance of that is slim to none.


In the end Windows XP is the best Microsoft OS ever, right ;) ?
It most certainly is not. :)

PS:
Eric, how is the progress on the next version coming? :)
I'm pondering releasing soon or waiting.

[egur]

Eric, how is the progress on the next version coming? :)
I'm pondering releasing soon or waiting.

Rev17 is out with all the fixes and the new MT code.

[Atak_Snajpera]

So I've lost... in the END :mad:
I NEVER install Vista or 7.. I hate them!

No chance to make it works in XP, too? Pretty please with chocolate on top :D

In the end Windows XP is the best Microsoft OS ever, right ;) ?
you are acting like child saying that you hate vista and 7. does your wonderful ancient xp have gpu accelerated interface, trim function for ssd, dx11 , self repairing capabilty, overall higher stabilty, evr ... and so on

[rica]

I will test it with my iGPU; i3 540+H55 on Seven 32.

Sorry but i can't find DXVA option on ffdshow?

ffdshow rev. 4225 + Intel HD Graphics: ver.8.15.10.2559 on Seven 32.
Ckarkdale i3 540+H55.

Thanks!

EDIT: OK, fixed, works like a charm. :thanks:

Chain: Lav Splitter > ffdshow video DXVA > EVR CP.

[egur]

Eric, how is the progress on the next version coming? :)
I'm pondering releasing soon or waiting.

Update: use rev18 - it has the correct version number. other than that rev17 is the same.

[egur]

Version 0.22 beta is out with the following changes:
* Much better multi-threading code (many fixes from v0.21).
* Fixed dynamic aspect ratio change during playback.
* FFDShow rev4227

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

[nevcairiel]

LAV Filters 0.44 now also "officially" features the 0.22 decoder.
Multi-threading is still off for the time being, until i can do proper testing.

[egur]

LAV Filters 0.44 now also "officially" features the 0.22 decoder.
Multi-threading is still off for the time being, until i can do proper testing.

That's great news :cool:

[rica]

LAV Filters 0.44 now also "officially" features the 0.22 decoder.
Multi-threading is still off for the time being, until i can do proper testing.

I gave it a go with Clarkdale. Even i can see "Intel Quicksync" option under "Hardware Acceleration", it says it is "not available".
And it is really "not available".

http://img843.imageshack.us/img843/7549/nev.th.png (http://imageshack.us/photo/my-images/843/nev.png/)

EDIT: I haven't tried with ffdshow yet, since sourceforge has collapsed for the time being.

EDIT: Here is the test file for you. (It is working with ffdshow 4225, btw.):

http://www.mediafire.com/?x2jk7irhns6506d


_ _ _ _

[DragonQ]

Yep, not working on Arrandale either (already said this in LAV thread :)).

[nevcairiel]

EDIT: Here is the test file for you. (It is working with ffdshow 4225, btw.):

http://www.mediafire.com/?x2jk7irhns6506d


_ _ _ _

Not sure what that file is meant to show..? Decodes just fine. :)

Anyhow, you're saying that QuickSync in ffdshow works on your Clarkdale, but with LAV it doesn't?
Did you check the CPU usage to confirm that its really using hardware decoding?

[rica]

Not sure what that file is meant to show..? Decodes just fine. :)

Anyhow, you're saying that QuickSync in ffdshow works on your Clarkdale, but with LAV it doesn't?
Did you check the CPU usage to confirm that its really using hardware decoding?

Sure I did. I will add the screen caps if you have enough time to wait.

EDIT: Here, they are:

http://img683.imageshack.us/img683/2816/004vb.th.png (http://imageshack.us/photo/my-images/683/004vb.png/)

http://img543.imageshack.us/img543/1026/005cq.th.png (http://imageshack.us/photo/my-images/543/005cq.png/)

_ _ _ _

[nevcairiel]

I can probably patch up a debug version that shows why QS fails, maybe it sheds some light on things.

Edit:
http://files.1f0.de/lavf/LAVVideo-0.44-debug.zip

Throw that on top of 0.44, and a log file should appear on your desktop. Maybe there is something interesting in there....
Paste the log on pastebin or something, don't want to wait for attachment approval. ;)

[nevcairiel]

EDIT: Here, they are:

http://img683.imageshack.us/img683/2816/004vb.th.png (http://imageshack.us/photo/my-images/683/004vb.png/)

http://img543.imageshack.us/img543/1026/005cq.th.png (http://imageshack.us/photo/my-images/543/005cq.png/)

Thats DXVA, not QuickSync
In any case, a log file would be useful.

[rica]

OK, tomorrow/or today.
Thanks!

[CruNcher]

EVR is special in the sense that it's output is different between Intel, Nvidia and AMD. Also different between GPU families and generations.
Many people think EVR uses simple bi-linear interpolation for scaling. For old cards, they are right. For the new cards that very wrong.
SandyBridge use a very advanced scaler. So it's best to test for yourself. The power/performance of the GPU is best utilized by the EVR. You should check the quality by applying a large scale factor to a clip (e.g. 4x) as well as very small scale factor (e.g. 1/4x).


The biggest issue is still subtitling though which @ least in MPC-HC is still dependent on EVR Custom.
So you allways have 1 issue either no Subtitling or all the Deinterlace Pain, there are only a few renderer that can do everything DXVA, + Deinterlacing + Subtitling all custom DirectX Renderer. MadVR could be another one once it supports DXVA + Custom Shader Code :). Though i wouldn't agree with this "The power/performance of the GPU is best utilized by the EVR." it can only be fully utilized by a Custom Renderer these days that utilizes the same backend as a Game Engine does ;)

[NikosD]

Version 0.22 beta is out with the following changes:
* Much better multi-threading code (many fixes from v0.21).
* Fixed dynamic aspect ratio change during playback.
* FFDShow rev4227


LAV Filters 0.44 now also "officially" features the 0.22 decoder.
Multi-threading is still off for the time being, until i can do proper testing.

I have done no tests with FFDShow 0.22 nor LAV Filters 0.44, but I think that by using Multi-Threaded code for the required work that has to be done by IA cores, may provide solution for eveything.

I mean that multi-threaded code should:

1) Increase the throughput required by 60fps clips

2) Feed better the QS decoding engine and

3) Push QS to maximum speed (frequency)

After all these, the decoding performance of 60fps clips should definitely increase.

About power consumption, the CPU frequency will go down from the Turbo Mode of single threaded code during playback of 60fps clips and probably power consumption will go down too.

During benchmarking or during playback of future difficult clips at 120fps the power consumption will increase again, I think.

Looking forward to test your next optimized multi-threaded versions in real tests.

[egur]

I have done no tests with FFDShow 0.22 nor LAV Filters 0.44, but I think that by using Multi-Threaded code for the required work that has to be done by IA cores, may provide solution for eveything.

I mean that multi-threaded code should:

1) Increase the throughput required by 60fps clips

2) Feed better the QS decoding engine and

3) Push QS to maximum speed (frequency)

After all these, the decoding performance of 60fps clips should definitely increase.

About power consumption, the CPU frequency will go down from the Turbo Mode of single threaded code during playback of 60fps clips and probably power consumption will go down too.

During benchmarking or during playback of future difficult clips at 120fps the power consumption will increase again, I think.

Looking forward to test your next optimized multi-threaded versions in real tests.

MT's purposes are the following:
1) Reduce decode thread latency - the decode thread will do just the HW decode and delivery of decoded images down the pipeline. A worker thread will do the rest - most time consuming tasks are frame copy and lockings the d3d9 surfaces. This allows more CPU work (video processing) to performed after decode.
2) Increase performance by adding parallelism - since the HW decode and the frame copying work in parallel, the HW decoder is better utilized allowing more FPS.

The MT work is not done. I believe I can achieve better performance than v0.22. v0.22 is much more stable than 0.21.

[CruNcher]

@ Eric
you allways post that sf.net url with a " @ the end ;)

BTW: Nev does the QFHD fallback to LAV (CPU) it's better though not doing that for ffdshow-quicksync also in terms of having a comparison point as Nev has no option in LAV Video to disable this restriction.

[NikosD]

MT's purposes are the following:
1) Reduce decode thread latency - the decode thread will do just the HW decode and delivery of decoded images down the pipeline. A worker thread will do the rest - most time consuming tasks are frame copy and lockings the d3d9 surfaces. This allows more CPU work (video processing) to performed after decode.
2) Increase performance by adding parallelism - since the HW decode and the frame copying work in parallel, the HW decoder is better utilized allowing more FPS.

The MT work is not done. I believe I can achieve better performance than v0.22. v0.22 is much more stable than 0.21.

So, the MT code involves IA cores, GPU cores, MFX engine or all of them ?
Could you give percentages for each component using MT code?

[egur]

So, the MT code involves IA cores, GPU cores, MFX engine or all of them ?
Could you give percentages for each component using MT code?

MT means running two or more threads on the IA cores. Running two or more code paths in parallel.

The QS decoder calls API functions of the Intel Media SDK to utilize the MFX engine. The Media SDK abstract the communication with HW much better than DXVA. The GPU cores (EUs) may be involved for some internal operations (don't know too much about this), but the bulk of the work is done by the MFX engine.
GPU parallelism as well as EU usage is abstracted by the MSDK and may change from generation to generation (or even driver versions).

[nevcairiel]

1) Increase the throughput required by 60fps clips


Even the most difficult clips you could find decode at 120fps, typical blu-rays decode at 300+ fps, i think 60fps clips are fine. :p
You over-estimate what multi-threading means, during normal playback there will be nearly zero difference, you only see it when benchmarking - so its really not all that great.

[CruNcher]

when you use quicksync decoding for encoding it can be :)

Eric do you know why the new driver has been removed http://webcache.googleusercontent.com/search?q=cache:FW2q-fo2vqYJ:downloadcenter.intel.com/Detail_Desc.aspx%3FDwnldID%3D20676

Had no issues with it

[NikosD]

@Egur

Thanks for the info.
The misunderstanding occurred by the following.
You used the term "HW decode thread" which usually means decoding not in CPU IA cores. CPU decoding usually referred as software decoding.
So by using the term "HW decode thread" you actually mean the work that has to be done in CPU to prepare the data for HW decoding in MFX engine.
No actual decoding happens in CPU.

@Nevcariel and Egur

I expect from MT code to drop the frequency of CPU during playback of 60fps clips from Turbo mode to much lower frequency, by spreading the load to more cores.

Have you seen by yourselves that even in normal playback mode of 60fps clips the CPU goes in Turbo Mode increasing Power consumption ?

Not in pure DXVA mode and not in other clips <60 fps.

Only with FFDShow QS decoder and only in 60fps and above.

[CruNcher]

NikosD don't you understand the Frame Copy GPU->CPU is pressuring the CPU ?

[NikosD]

NikosD don't you understand the Frame Copy GPU->CPU is pressuring the CPU ?

Read my previous post again please.

[CruNcher]

Over here its not always @ full frequency (on balanced power profile) it fluctuates as expected due to the frame copy though playback is fine with 4 girls and 5 birds also absolute smooth 2k the same 4k low bitrate also problems get heavy with high bitrate QFHD :) And yeah MT might be able to more evenly distribute the load so that frequency fluctuates less. Though also keep in mind that frequency isn't really costing that much power @ all voltage increase is the main factor here. You will not get DXVA consumption from ffdshow-quicksync it will always be lower with DXVA solely due to the frame copy.

[egur]

@Egur

Thanks for the info.
The misunderstanding occurred by the following.
You used the term "HW decode thread" which usually means decoding not in CPU IA cores. CPU decoding usually referred as software decoding.
So by using the term "HW decode thread" you actually mean the work that has to be done in CPU to prepare the data for HW decoding in MFX engine.
No actual decoding happens in CPU.

@Nevcariel and Egur

I expect from MT code to drop the frequency of CPU during playback of 60fps clips from Turbo mode to much lower frequency, by spreading the load to more cores.

Have you seen by yourselves that even in normal playback mode of 60fps clips the CPU goes in Turbo Mode increasing Power consumption ?

Not in pure DXVA mode and not in other clips <60 fps.

Only with FFDShow QS decoder and only in 60fps and above.

As CruNcher said, frame copy takes CPU cycles. That's a fact. in 1080p@60 there's a lot to copy, hence the higher CPU usage. Pure DXVA solution will always be faster (unless there's buggy or poorly implemented).

Regarding Turbo, in my tests Turbo wasn't active for the entire duration of playback. If there's a lot of compute/cpu work to be done, the most efficient way to it is in bursts and not by spreading the workload across time. Idle time after a burst allows power management to kick in. If you're worried about that the GPU will lose it's power budget to the CPU and thus work in a lower frequency, you may or may not be right. The algorithm for deciding this is not exposed to the public.
Anyway, this is only the start not the end of MT.

@CruNcher: 10x for correcting the typo in the web site link.

[NikosD]

@Egur

Is it possible for the Frame Copy process to be executed in parallel in more than one core? Or is it a strictly serial process ?

By using more cores for Frame Copy alone, could help us compare the behavior of the whole CPU package in different situations during playback, to what we have now with serial Frame Copy.

[egur]

@Egur

Is it possible for the Frame Copy process to be executed in parallel in more than one core? Or is it a strictly serial process ?

By using more cores for Frame Copy alone, could help us compare the behavior of the whole CPU package in different situations during playback, to what we have now with serial Frame Copy.

Excellent question!
In the Core2Dou days, I did a few benchmarks as I wrote an application that did a lot of memory copying.
My results were:
* Writing memcpy using SSE2 was 2x faster than the standard library version (vs2005).
* Using 2 threads gave almost 2x performance boost. Using more than 2 didn't change anything.

The benchmark were for large buffers (usually > 1M).
So my copy function was ~4x faster than the standard memcpy.

Today, using SSE2 copy doesn't change all that much, either vs2010 has a better memcpy or the CPU uArch implements the simpler memcpy better. Regarding threads, I need to test this.
I can assume that using 2 threads will help. This is next on my list. I'll make a programmable solution that allows scaling beyond 2 threads.
I'll post the results in this thread.

BTW, parallelizing memcpy is super trivial. Probably the easiest task to make parallel.

[NikosD]

Very good.

So you are into it.

You could also try Intel C++ Compiler, which whenever I used it - last time it was 11.1 version - I remember that it was a lot faster than MS VC++.

[egur]

Very good.

So you are into it.

You could also try Intel C++ Compiler, which whenever I used it - last time it was 11.1 version - I remember that it was a lot faster than MS VC++.

I support ICL12.1 builds.
Assembly code (copy function) is not subject to optimization by the compiler (as far as I know) and the rest of my code is very light so I doubt any compiler can do noticeably better.

[rica]

Thats DXVA, not QuickSync
In any case, a log file would be useful.

You're right; it was my mistake.

Today I tried again with LAV 0.44 and FFShow 4227.
Even I can see QuickSync as an option and select, neither LAV, nor FFShow can use it on my Clarkdale.

Here is the debug file:

LAVVideo.ax(tid f40) 28470 : CTransformInputPin::CTransformInputPin
LAVVideo.ax(tid f40) 28470 : CTransformOutputPin::CTransformOutputPin
LAVVideo.ax(tid f40) 28470 : SetMediaType -- in
LAVVideo.ax(tid f40) 28470 : ::CreateDecoder(): Creating new decoder...
LAVVideo.ax(tid f40) 28470 : -> Process is mpc-hc.exe, blacklist: 0
LAVVideo.ax(tid f40) 28470 : CDecQuickSync::Init(): Trying to open QuickSync decoder
LAVVideo.ax(tid f40) 28673 : -> Decoder reports abnormal status
LAVVideo.ax(tid f40) 28673 : -> Init Interfaces failed (hr: 0x80004005)
LAVVideo.ax(tid f40) 28673 : -> Hardware decoder failed to initialize, re-trying with software...
LAVVideo.ax(tid f40) 28673 : Shutting down ffmpeg...
LAVVideo.ax(tid f40) 28673 : Initializing ffmpeg for codec 28
LAVVideo.ax(tid f40) 28673 : -> Processing extradata of 51 bytes
LAVVideo.ax(tid f40) 28673 : -> File extension: .m2ts
LAVVideo.ax(tid f40) 28673 : ff_lockmgr: mutex: 042C7600, op: 1
LAVVideo.ax(tid f40) 28673 : ff_lockmgr: mutex: 042C7600, op: 2
LAVVideo.ax(tid f40) 28673 : -> ffmpeg codec opened successfully (ret: 0)
LAVVideo.ax(tid f40) 28673 : AVCodec init successfull. interlaced: 1
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 0
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 1
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 2
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 3
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 4
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 5
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 6
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 7
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 8
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 9
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 10
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 11
LAVVideo.ax(tid f40) 28673 : ::GetMediaType(): position: 12
LAVVideo.ax(tid f40) 29335 : Trying to connect Pins :
LAVVideo.ax(tid f40) 29335 : <XForm Out>
LAVVideo.ax(tid f40) 29335 : <EVR Input0>
LAVVideo.ax(tid f40) 29335 : ::GetMediaType(): position: 0
LAVVideo.ax(tid f40) 29335 : Trying media type:
LAVVideo.ax(tid f40) 29335 : major type: MEDIATYPE_Video
LAVVideo.ax(tid f40) 29335 : sub type : MEDIASUBTYPE_NV12
LAVVideo.ax(tid f40) 29336 : ::CheckTransform()
LAVVideo.ax(tid f40) 29336 : ::CheckTransform()
LAVVideo.ax(tid f40) 29336 : SetMediaType -- out
LAVVideo.ax(tid f40) 29338 : ::GetMediaType(): position: 0
LAVVideo.ax(tid f40) 29338 : ::GetMediaType(): position: 1
LAVVideo.ax(tid f40) 29338 : ::DecideBufferSize()
LAVVideo.ax(tid f40) 29338 : ::CheckTransform()
LAVVideo.ax(tid f40) 29344 : ::CheckTransform()
LAVVideo.ax(tid f40) 29344 : Connection succeeded
LAVVideo.ax(tid f40) 29374 : ff_lockmgr: mutex: 042C7600, op: 1
LAVVideo.ax(tid f40) 29374 : ff_lockmgr: mutex: 042C7600, op: 2
LAVVideo.ax(tid b88) 30502 : ::CheckTransform()
LAVVideo.ax(tid b88) 30508 : ::CheckTransform()
LAVVideo.ax(tid b88) 30508 : ::CheckTransform()
LAVVideo.ax(tid b88) 30552 : ::CheckTransform()
LAVVideo.ax(tid 144c) 30553 : ::NewSegment - 0 / 0
LAVVideo.ax(tid 918) 30568 : h264RandomAccess::parseForRecoveryPoint(): Found I frame
LAVVideo.ax(tid 918) 30568 : h264RandomAccess::parseForRecoveryPoint(): Found IDR slice
LAVVideo.ax(tid 918) 30685 : ::GetDeliveryBuffer(): Sample contains new media type from downstream filter..
LAVVideo.ax(tid 918) 30685 : -> Width changed from 1920 to 1920 (target: 1920)
LAVVideo.ax(tid 918) 30685 : ::CheckTransform()
LAVVideo.ax(tid 918) 30685 : SetMediaType -- out
LAVVideo.ax(tid 918) 64887 : EndOfStream, flushing decoder
LAVVideo.ax(tid 918) 65058 : EndOfStream finished, decoder flushed
LAVVideo.ax(tid b88) 69245 : ::BeginFlush
LAVVideo.ax(tid b88) 69250 : ::EndFlush
LAVVideo.ax(tid 144c) 69250 : ::NewSegment - 0 / 0
LAVVideo.ax(tid 918) 69255 : h264RandomAccess::parseForRecoveryPoint(): Found I frame
LAVVideo.ax(tid 918) 69255 : h264RandomAccess::parseForRecoveryPoint(): Found IDR slice
LAVVideo.ax(tid b88) 69351 : ::BeginFlush
LAVVideo.ax(tid b88) 69359 : ::EndFlush
LAVVideo.ax(tid f40) 75428 : ::BreakConnect
LAVVideo.ax(tid f40) 75428 : ff_lockmgr: mutex: 042C7600, op: 1
LAVVideo.ax(tid f40) 75428 : ff_lockmgr: mutex: 042C7600, op: 2
LAVVideo.ax(tid f40) 75428 : ::BreakConnect
LAVVideo.ax(tid f40) 75428 : Shutting down ffmpeg...
LAVVideo.ax(tid f40) 75428 : ff_lockmgr: mutex: 042C7600, op: 1
LAVVideo.ax(tid f40) 75438 : ff_lockmgr: mutex: 042C7600, op: 2
LAVVideo.ax(tid f40) 75438 : ff_lockmgr: mutex: 042C7600, op: 3
LAVVideo.ax(tid f40) 75438 : ff_lockmgr: mutex: 042C7648, op: 3
LAVVideo.ax(tid f40) 75438 : CTransformOutputPin::~CTransformOutputPin


H55+i3540 Clarkdale on Seven 32.

Thanks!

[nevcairiel]

That message means that the "getOK" function returns failure.
Maybe Eric can shed some light onto that, i sadly dont have any older hardware to test on.

[rica]

Thanks for checking out!

[DragonQ]

I also ran that debug version of LAV 0.44 on my i5-430M (Arrandale). Here's my log, looks exactly the same in the important bits:

LAVVideo.ax(tid 1da0) 2 : CTransformInputPin::CTransformInputPin
LAVVideo.ax(tid 1da0) 2 : CTransformOutputPin::CTransformOutputPin
LAVVideo.ax(tid 1da0) 2 : SetMediaType -- in
LAVVideo.ax(tid 1da0) 2 : ::CreateDecoder(): Creating new decoder...
LAVVideo.ax(tid 1da0) 2 : -> Process is mpc-hc.exe, blacklist: 0
LAVVideo.ax(tid 1da0) 2 : CDecQuickSync::Init(): Trying to open QuickSync decoder
LAVVideo.ax(tid 1da0) 61 : -> Decoder reports abnormal status
LAVVideo.ax(tid 1da0) 61 : -> Init Interfaces failed (hr: 0x80004005)
LAVVideo.ax(tid 1da0) 61 : -> Hardware decoder failed to initialize, re-trying with software...
LAVVideo.ax(tid 1da0) 62 : Shutting down ffmpeg...
LAVVideo.ax(tid 1da0) 62 : Initializing ffmpeg for codec 28
LAVVideo.ax(tid 1da0) 63 : -> Processing extradata of 163 bytes
LAVVideo.ax(tid 1da0) 63 : -> File extension: .mkv
LAVVideo.ax(tid 1da0) 63 : ff_lockmgr: mutex: 05A43518, op: 1
LAVVideo.ax(tid 1da0) 71 : ff_lockmgr: mutex: 05A43518, op: 2
LAVVideo.ax(tid 1da0) 71 : -> ffmpeg codec opened successfully (ret: 0)
LAVVideo.ax(tid 1da0) 71 : AVCodec init successfull. interlaced: 0
LAVVideo.ax(tid 1da0) 71 : ::GetMediaType(): position: 0
LAVVideo.ax(tid 1da0) 71 : ::GetMediaType(): position: 1
LAVVideo.ax(tid 1da0) 71 : ::GetMediaType(): position: 2
LAVVideo.ax(tid 1da0) 71 : ::GetMediaType(): position: 3
LAVVideo.ax(tid 1da0) 71 : ::GetMediaType(): position: 4
LAVVideo.ax(tid 1da0) 71 : ::GetMediaType(): position: 5
LAVVideo.ax(tid 1da0) 71 : ::GetMediaType(): position: 6
LAVVideo.ax(tid 1da0) 71 : ::GetMediaType(): position: 7
LAVVideo.ax(tid 1da0) 71 : ::GetMediaType(): position: 8
LAVVideo.ax(tid 1da0) 71 : ::GetMediaType(): position: 9
LAVVideo.ax(tid 1da0) 72 : ::GetMediaType(): position: 10
LAVVideo.ax(tid 1da0) 72 : ::GetMediaType(): position: 11
LAVVideo.ax(tid 1da0) 72 : ::GetMediaType(): position: 12
LAVVideo.ax(tid 1da0) 428 : Trying to connect Pins :
LAVVideo.ax(tid 1da0) 428 : <XForm Out>
LAVVideo.ax(tid 1da0) 428 : <EVR Input0>
LAVVideo.ax(tid 1da0) 428 : ::GetMediaType(): position: 0
LAVVideo.ax(tid 1da0) 428 : Trying media type:
LAVVideo.ax(tid 1da0) 429 : major type: MEDIATYPE_Video
LAVVideo.ax(tid 1da0) 429 : sub type : MEDIASUBTYPE_NV12
LAVVideo.ax(tid 1da0) 429 : ::CheckTransform()
LAVVideo.ax(tid 1da0) 429 : ::CheckTransform()
LAVVideo.ax(tid 1da0) 429 : SetMediaType -- out
LAVVideo.ax(tid 1da0) 430 : ::GetMediaType(): position: 0
LAVVideo.ax(tid 1da0) 430 : ::GetMediaType(): position: 1
LAVVideo.ax(tid 1da0) 430 : ::DecideBufferSize()
LAVVideo.ax(tid 1da0) 430 : ::CheckTransform()
LAVVideo.ax(tid 1da0) 438 : ::CheckTransform()
LAVVideo.ax(tid 1da0) 438 : Connection succeeded
LAVVideo.ax(tid c04) 1534 : ::CheckTransform()
LAVVideo.ax(tid c04) 1540 : ::CheckTransform()
LAVVideo.ax(tid c04) 1541 : ::CheckTransform()
LAVVideo.ax(tid c04) 1576 : ::CheckTransform()
LAVVideo.ax(tid 1d70) 1580 : ::NewSegment - 0 / 0
LAVVideo.ax(tid 81c) 1581 : h264RandomAccess::parseForRecoveryPoint(): Found IDR slice
LAVVideo.ax(tid 81c) 1613 : ::GetDeliveryBuffer(): Sample contains new media type from downstream filter..
LAVVideo.ax(tid 81c) 1613 : -> Width changed from 1920 to 1920 (target: 1920)
LAVVideo.ax(tid 81c) 1613 : ::CheckTransform()
LAVVideo.ax(tid 81c) 1613 : SetMediaType -- out
LAVVideo.ax(tid 1da0) 9578 : ::BeginFlush
LAVVideo.ax(tid 1da0) 9656 : ::EndFlush
LAVVideo.ax(tid 1da0) 9679 : ::BreakConnect
LAVVideo.ax(tid 1da0) 9679 : ::BreakConnect
LAVVideo.ax(tid 1da0) 9679 : Shutting down ffmpeg...
LAVVideo.ax(tid 1da0) 9679 : ff_lockmgr: mutex: 05A43518, op: 1
LAVVideo.ax(tid 1da0) 9691 : ff_lockmgr: mutex: 05A43518, op: 2
LAVVideo.ax(tid 1da0) 9691 : ff_lockmgr: mutex: 05A43518, op: 3
LAVVideo.ax(tid 1da0) 9691 : ff_lockmgr: mutex: 05A43560, op: 3
LAVVideo.ax(tid 1da0) 9691 : CTransformOutputPin::~CTransformOutputPin

[nevcairiel]

Eric,

seeking in this file (VC-1) causes the decoder to stop functioning, it just doesn't output any image anymore.

http://www.multiupload.com/2403BDXAFT

I didn't do any real checks yet, but it doesn't output any debug messages.

[Esperado]

In the first version i tried (With DvbViewer), mpeg2 was out of sync image before sound.
In the last two ones, H.264 freeze after half a second and crashes the program. Mpeg2 seems to work OK. But with fluctuations in the images rates.
(ffdshow 32bits in Seven 64)

[egur]

Eric,

seeking in this file (VC-1) causes the decoder to stop functioning, it just doesn't output any image anymore.

http://www.multiupload.com/2403BDXAFT

I didn't do any real checks yet, but it doesn't output any debug messages.

I'll check it out.

Update
I've root caused the problem. It will take me a few days to fix.
I've also implemented a MT frame copy but unfortunately the performance boost is next to zero.

[CruNcher]

@Eric
updated to the newest Arcsoft Beta and the Decoder seems now to use DXVA no issues anymore with Lav Splitter Intel and any .WMV Build Keynote doesn't crash anymore also the 15 fps clip plays @ 30 fps now as it should :)

2.28.474.133 <- Problems
2.28.480.134 <- Fixed upcoming TMT5.2

Also MC.ts works without issues DXVA accelerated with their decoder this is a little surprising seeing ffdshow-quicksync and lav Video quicksync fail @ decoding also the decoding error (H.264) stream works without that frame corruption.

http://img16.imageshack.us/img16/4839/arcsoftvc1dxva.png

No corruptions same for Cyberlinks Decoder


Lav Video refuses the connection for this file (hehe nev) ;)

ffdshow-quicksync

http://img834.imageshack.us/img834/3481/ffdshowquicksyncvc1tsde.png

So maybe this has actually something todo with the TS parsing as it seems the Quicksync Decoder (Hardware) is OK ;)

PS: Arcsofts DXVA also handles to much ref frames now like the CoreAVC DXVA implementation :)

[nevcairiel]

PS: Arcsofts DXVA also handles to much ref frames now like the CoreAVC DXVA implementation :)

There is no such thing as "too much" ref frames, 16 is the maximum, and the hardware can decode it just fine.

[egur]

@Eric

Also MC.ts works without issues DXVA accelerated with their decoder this is a little surprising seeing ffdshow-quicksync and lav Video quicksync fail @ decoding also the decoding error (H.264) stream works without that frame corruption.

I think both DXVA decoders are doing some kind of stream processing before sending the samples to the HW.

[CruNcher]

There is no such thing as "too much" ref frames, 16 is the maximum, and the hardware can decode it just fine.

Sorry out of Spec Ref frames @ DXVA playback this is under normal conditions resulting in decoding errors (blocking) though Mirillis , Arcsoft and CoreCodec found a way to avoid this in their implementations ;)

Also Eric testing WVC1 playback with Lav Video as well as ffdshow-quicksync showed lower overal utilization then with Arcsofts DXVA Decoder that really surprised first time i saw that even with the Memory Copy it's beating a DXVA Decoder and that with a pretty high difference also.

[egur]

...
Also Eric testing WVC1 playback with Lav Video as well as ffdshow-quicksync showed lower overal utilization then with Arcsofts DXVA Decoder that really surprised first time i saw that even with the Memory Copy it's beating a DXVA Decoder and that with a pretty high difference also.

This is odd, what are the numbers?

I also have a VC1 related question.
Does the VC1 spec allow sending the exact same image (e.g. same buffer) multiple times with different time stamps?

[CruNcher]

This is odd, what are the numbers?

I also have a VC1 related question.
Does the VC1 spec allow sending the exact same image (e.g. same buffer) multiple times with different time stamps?

The difference is 10% cpu utilization more for AP@L4 for Arcsofts DXVA Decoder i think i see also why it outputs by default in YUY2 instead of NV12

Arcsoft = Video: YUY2 1920x1080 50.00fps 14100kbps
Lav Video = Video: NV12 1920x1080 50.00fps

though changing Lav Video to YUY2 doesn't cause such a big difference @ all, strange strange
so in the end on MPC-HC Arcsofts DXVA renders with a utilization of 22% vs 12%

[nevcairiel]

This is odd, what are the numbers?

I also have a VC1 related question.
Does the VC1 spec allow sending the exact same image (e.g. same buffer) multiple times with different time stamps?

Yes,vc1 has a feature called skipped p frames, which means its supposed to output the previous p frame again. I can imagine that's whats happening here.

[egur]

Yes,vc1 has a feature called skipped p frames, which means its supposed to output the previous p frame again. I can imagine that's whats happening here.

Good to know. I need to handle this situation.
This is not relevant to LAV since you implicitly disable my internal queuing (by disabling the time stamp correction).
After I'll fix this I'll release another ffdshow build.

@CruNcher
10x for the info. I thought you meant it was faster than DXVA QuickSync (e.g. MS DTV-DVD decoder).
My decoder is usually much faster than Nvidia or AMD in all supported codecs.
The main goal of the QS decoder is power saving + low cpu utilization while retaining a simple (relatively) and open SW architecture.

[betaking]

Good to know. I need to handle this situation.
This is not relevant to LAV since you implicitly disable my internal queuing (by disabling the time stamp correction).
After I'll fix this I'll release another ffdshow build.

@CruNcher
10x for the info. I thought you meant it was faster than DXVA QuickSync (e.g. MS DTV-DVD decoder).
My decoder is usually much faster than Nvidia or AMD in all supported codecs.
The main goal of the QS decoder is power saving + low cpu utilization while retaining a simple (relatively) and open SW architecture.

compile standalone IntelQuickSyncDecoder.dll failed
正在运行 C/C++ 代码分析...
1>QuickSyncUtils.cpp(179): error C2220: 警告被视为错误 - 没有生成“object”文件
1>c:\qsdecoder\intelquicksyncdecoder\quicksyncutils.cpp(176): warning C6312: Possible infinite loop: use of the constant EXCEPTION_CONTINUE_EXECUTION in the exception-filter expression of a try-except. Execution restarts in the protected block
1>c:\qsdecoder\intelquicksyncdecoder\quicksyncutils.cpp(177): warning C6322: Empty _except block
正在生成代码...
1>已完成生成项目“C:\qsdecoder\IntelQuickSyncDecoder\IntelQuickSyncDecoder.vcxproj”(build 个目标)的操作 - 失败。
but compile with last ffdshow no problem!

[egur]

Static analysis failure fixed at rev21.

[betaking]

Static analysis failure fixed at rev21.

thank you for quick fix!

[NikosD]

@Egur

Have you seen this ? (http://software.intel.com/en-us/articles/copying-accelerated-video-decode-frame-buffers/)
A little old, though.

[nevcairiel]

@Egur

Have you seen this ? (http://software.intel.com/en-us/articles/copying-accelerated-video-decode-frame-buffers/)
A little old, though.

He already uses that instruction.

[egur]

@Egur

Have you seen this ? (http://software.intel.com/en-us/articles/copying-accelerated-video-decode-frame-buffers/)
A little old, though.

It may show some improvement (using a 4K cache), I'll test it. This is similar to what VLC does.
This article refers to Penryn - the first Intel cpu with the movntdqa instruction (SSE4.1). My version has an optimization that doesn't appear in the article so maybe an even faster version is possible.
What was optimal for Penryn might not be optimal for SandyBridge and vice versa.

[NikosD]

Eric,

Intel released a new version of Media SDK 2012 (http://software.intel.com/en-us/articles/vcsource-tools-media-sdk/)

Do we have to wait for new Intel drivers to integrate it, or is it possible to use it with current drivers ?
Can we install it over the current Media SDK installed by latest Intel's driver ?

Does it have any speed or other improvement regarding your QS decoder ?

I think I read that it has better handling of CPU <-> GPU memory communication.

I don't know if you have tested it already with your QS decoder.

UPDATE: Is there an easy way - without registration - to download Intel Media Checker ?

[nevcairiel]

Thats just the final version of the 3.0 SDK, which was in beta for like a year or so. I don't expect many SDK related changes.

[CharlieCL]

It may show some improvement (using a 4K cache), ...

It may be faster by using AVX instructions which are 256 bits.

[nevcairiel]

It may be faster by using AVX instructions which are 256 bits.

Its a common misconception that a new instruction set will magically make everything better.

Each SIMD instruction set has a very specific set of functions for very specific tasks, its not a generic set of instructions like x86 itself is.
AVX deals mostly with floating point operations, which are useless in this case. AVX2, which will come with the Haswell micro-architecture, will expand this to Integer/Memory operations, and might then potentially be useful.

[egur]

The new Intel Media SDK 2012, which exposes a new API (v1.3 instead of 1.1) will come in to play when a future driver will be released.
Current driver (v2559) supports API version 1.1.
From the technical side of things, linking with the new MSDK will change nothing. The HW implementation DLL is shipped with the driver. The library that QS decoder links to is a dispatch library. It just selects which implementation to use (HW - graphics driver DLL or SW a DLL that comes with the MSDK).
If linking with the SW implementation, you can use the new features. This is important for developers to get a head start on development before production drivers and new HW (e.g. IvyBridge) arrive.
I'll update the MSDK headers and lib with the new MSDK in SVN but again, it changes nothing until for the time being.

Performance update
I tried using the implementation from the old Intel article.
I used 2 clips both 1080p, one was relatively low bitrate (mp4 file I downloaded from the net) and the other high bitrate (Sumsong underwater clip ~40mbps).
In the Sumsong clip nothing changed, the HW decoder was slower than the frame copying.
The low bitrate clip ran at ~700 fps using the article's method and ~770 fps using the existing method.
Nehalem/Westmere and Sandybridge are very different when it comes to memory operations (SandyBridge is much better of course :) ).

I'll forward this topic to architecture as well as the author of this article. Maybe there's a 3rd way to do things.

BTW, AVX will not help in this case. We can try AVX2 (not sure it's relevant either) when it's available to the public.

[NikosD]

Thanks for the detailed infor about Media SDK.

In my opinion your QS decoder has only one obvious "weak" point.

Handling of 60fps and more clips, no matter the bitrate, if it's high or low.

So I think you could try the old implementation or any other future implementation mainly in those > 30 fps clips, like 50fps or 60fps.
There are plenty of such files in the link I gave you before here (http://xhmikosr.1f0.de/index.php?folder=c2FtcGxlcy8yMTYwcA==) and with versions at 1080p compatible with QS.

Is it possible to upload Intel Media Checker (http://software.intel.com/partner/app/software-assessment?locale=en-US&cid=ISPP:106BL103ENG1721&utm_campaign=sat-awareness&utm_content=flash-video&utm_source=flash&utm_medium=flash-video) somewhere easy to download ?

Thanks!

[!llus!on]

Is it possible to upload Intel Media Checker (http://software.intel.com/partner/app/software-assessment?locale=en-US&cid=ISPP:106BL103ENG1721&utm_campaign=sat-awareness&utm_content=flash-video&utm_source=flash&utm_medium=flash-video) somewhere easy to download ?

Thanks!

Here you go: Intel Media Checker v2.0 Multiupload (http://www.multiupload.com/ZQH1W3YGDF)

[egur]

Thanks for the detailed infor about Media SDK.

In my opinion your QS decoder has only one obvious "weak" point.

Handling of 60fps and more clips, no matter the bitrate, if it's high or low.

So I think you could try the old implementation or any other future implementation mainly in those > 30 fps clips, like 50fps or 60fps.
There are plenty of such files in the link I gave you before here (http://xhmikosr.1f0.de/index.php?folder=c2FtcGxlcy8yMTYwcA==) and with versions at 1080p compatible with QS.
...

I'll use a single copy function - whatever fastest.
One of the next steps is to output D3D9 surfaces (without any copying) and the renderer will be in charge of subtitles, etc. This flow is limited to a single GPU setup and I'm not sure how subtitles will be rendered.

I don't see a problem with 60fps. All HD clips play well above 60fps.
In low bitrates, using my i7-2600 and 1333MHz DDR3, I can pull ~800fps (NULL renderer). In very high bitrates, it drops to 100+ because the HW decoder is slowing the process. When >60fps movies (need matching screen & fast cable) will become more common, the HW should be fast enough.
Personally, I don't see the benefit of >60fps movies.

My fear is that there's some part in my code that limits performance by blocking the operation of the HW decoder. Maybe this type of flow would benefit from faster RAM, I'll buy 1833MHz RAM for my own HTPC.

[NikosD]

Here you go: Intel Media Checker v2.0 Multiupload (http://www.multiupload.com/ZQH1W3YGDF)

Thanks a lot!



I don't see a problem with 60fps. All HD clips play well above 60fps.


Yes they do. But they push CPU in Turbo mode even in normal playback.


Personally, I don't see the benefit of >60fps movies.


It's an open issue with a lot of different views.
60fps clips are by far smoother and "polished" than 30fps.

It's clear even by naked eye and amateurs. You don't have to be professional to see this.
I know the theory about the incapability of human eye to see more than 30fps.
For me the difference between 30fps and 60fps it's obvious, but I will not go on, on this subject.


My fear is that there's some part in my code that limits performance by blocking the operation of the HW decoder. Maybe this type of flow would benefit from faster RAM, I'll buy 1833MHz RAM for my own HTPC.

If you check Media Performance with the help of GPA, you will see that during playback & benchmarking, QS decoder is not utilizing MFX enfine as much as DXVA does.
So, there is definitely a bottleneck inside the code of something between your dll and HW.

Are you sure it's your code and not Intel Media SDK ?

[NikosD]

I hope Intel is going to fix this (http://semiaccurate.com/2012/01/09/intel-fakes-ivy-bridge-graphics-on-stage-at-ces/) before April.
Ivy means a lot to the whole CPU industry.

[egur]

It's an open issue with a lot of different views.
60fps clips are by far smoother and "polished" than 30fps.
>60 means greater than 60. I agree about 60fps being better than 30 fps.

If you check Media Performance with the help of GPA, you will see that during playback & benchmarking, QS decoder is not utilizing MFX enfine as much as DXVA does.
So, there is definitely a bottleneck inside the code of something between your dll and HW.

Are you sure it's your code and not Intel Media SDK ?

One explanation is that the renderer must do different work (copy the frame to the GPU in my case).
The other option is that the DXVA decoders run the HW decode on another thread. This is something on my TODO list. I wanted to thread the copy first and get that stable (I think now it's 100% stable) and hopefully optimized .
The decoder is still in beta so I'm not done yet :D

The MSDK may or may not block performance (probably it doesn't block performance). It's hard to tell and nothing to do about it...
One way to check is to check the utilization of the various MSDK sample decoders which are DXVA compliant (e.g. via the DXVA checker). If you time, you can try. Note that these decoders are sample code and don't have fancy features like real products (e.g. multi threading). So the results may not help much. If the samples have high MFX engine utilization, than my code is definitely to blame. The other case is less obvious since the samples don't have multi threading (for a good reason - complicate the samples too much).

[egur]

I hope Intel is going to fix this (http://semiaccurate.com/2012/01/09/intel-fakes-ivy-bridge-graphics-on-stage-at-ces/) before April.
Ivy means a lot to the whole CPU industry.

Just a demo of things to come, take this in the right proportions :)
I'm not worried about IvyBridge at all.

[NikosD]

After reading some more technical details about Sandy's GPU, I think that a good optimization for Frame Copy could be the use of LLC (Last Level Cache - L3) and ring interconnect to rapidly pass data from the GPU back to the CPU.

Almost any GPU data can be held in the LLC.

A flush command is needed to force data to be written back to the LLC prior to the CPU reading it.

The driver can also allocate a portion of the LLC as a non-coherent cache for display data and other uses.

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.

[CharlieCL]

Its a common misconception that a new instruction set will magically make everything better.

Each SIMD instruction set has a very specific set of functions for very specific tasks, its not a generic set of instructions like x86 itself is.
AVX deals mostly with floating point operations, which are useless in this case. AVX2, which will come with the Haswell micro-architecture, will expand this to Integer/Memory operations, and might then potentially be useful.

Sorry I suppose that AVX is a completed instruction set. But this is an Intel's mistake. An instruction set will be able to work for more than 10 years. So when they add one instruction they should think about 10 years' usage. Intel's SIMD instruction set is a failure. At first there was MMX, then SSE, SSE2, SSE3, SSE4, now AVX, future AVX2. This is similar to graphic cards from DX8, DX9, DX10, DX11. The GPU instruction set (shader model) was changed every year.

I hope that AVX will not repeat the mistake of SSE to generate AVX2, AVX3, AVX4 ... in the future. In this way there are few benefits for developers to use them.

[NikosD]

But they have to sell "new" processors/ graphics cards with "new" capabilities not found in previous generations.

[nevcairiel]

This is similar to graphic cards from DX8, DX9, DX10, DX11. The GPU instruction set (shader model) was changed every year.

Instruction sets are different, they very rarely replace each other, they add new instructions, you don't just use SSE4, you use SSE2+SSSE3+SSE4 in conjunction with each other.

The only cases of replacing was SSE2, which basically was MMX in 128-bit (instead of 64), and soon AVX2, which is SSE2 in 256-bit.

The comparison to GPUs is flawed in every way.
Also, what would you propose, just not invent new instruction sets? :p

If you ever had worked with them, you would know that they all do a very good job at doing *exactly* whats required for multimedia applications.

[NikosD]

You clearly misunderstood the meaning of his post.

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

As for GPUs they aren't directly comparable to CPUs but they also add things little by little just to have more selling points in their products.

[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 ;) ).

[RBG]

* HW Video processing: deinterlacing, film detection (3:2, 2:2 pulldowns, etc), noise reduction, sharpness, scaling, etc.

[nevcairiel]

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

Both NVIDIAs and AMDs hardware deinterlacing look much better then yadif on some content (especially sports)
Intels is a bit worse then NVIDIAs/AMDs, but a comparison to yadif is missing here.

[CruNcher]

Here are some Utilization results WVC1 1920x1080 50fps 14 Mbits (got VLD to work with Arcsofts/Cyberlinks Decoder and Potplayer for virtualy any WVC1 in .wmv though some files fail (black screen)) :)

Lav Video = 22%
Quicksync = 11%
IDCT = 8% (Potplayer)
VLD = 2% (Arcsoft/Cyberlink)

biggest boost is from software to Quicksync 50% and Quicksync to VLD

[NikosD]

Eric,

I have contacted PotPlayer's developer and he told me what Nevcariel has said too.
That VC-1 VLD HW acceleration is not standard DXVA, although VC1 IDCT is standard DXVA.
Moreover PotPlayer's developer told me that VC1 VLD is not open.

I found these statements odd, if they are true of course.

Both MPEG-2 and H.264 are far more common codecs than VC-1 and Intel support them by implementing standard DXVA VLD mode for both.

Why do you have this "special treatment" for VC-1 ?
Non standard DXVA and not open.

Is it something to do with Microsoft / ISV's ?

How is it possible for an independent developer like PotPlayer or Nevcariel to implement DXVA VC1 VLD?

One last question:
You have mentioned and I have tested that FFDshow QS decoder doesn't provide WMV3 accleration, which essentially is VC-1 Simple and VC-1 Main profiles.
It seems that only VC-1 Advanced profile is HW accelerated.

Is that a HW limitation or a software limitation ? (Intel MSDK or driver).

[goldie]

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.

Deinterlacing & film detection. :thanks:

[betaking]

to egur does Intel SandyBridge hardware accelerated support MPEG-4 ASP?

[egur]

OK then. everyone wants deinterlacing + film detection. I'll start with that. Scaling and other post processing features will follow.
I won't implement a custom DI myself, I'll use the one supplied by the driver. Personally I've tested it to be better than Nvidia/AMD but your mileage may vary.

@CruNcher
The scaling algorithm in SandyBridge is superior to both Nvidia and AMD in both upscaling and downscaling. Since I invented the algorithm for the video scaler, I have deep knowledge on the matter. Like many other parts of the video engine, it's implemented as ASIC and has very high performance.

@NikosD
I have relatively little knowledge on DXVA and what the driver support or not. Frankly I don't want to deep dive on the matter, I'd rather have a tooth pulled out :(
That's why I use the Media SDK, it simplifies (significantly) HW video decode/process and also adds encode as a bonus.
This means that dealing with DXVA is handled by the Media SDK developers and not me :)
Some features may be possible when using native DXVA that don't exist in the MSDK, but I can live with that.
Anyway, complaints about the driver (or feature requests) should be posted in the driver forum (http://communities.intel.com/community/tech/graphics).

@Betaking
The MSDK doesn't support MPEG4-ASP as far as I know. I don't know about driver support. Does DXVA support this format (any GPU)?

[nevcairiel]

Does DXVA support this format (any GPU)?

Yes, its supported on both NVIDIA and AMD (at least on recent GPUs, its one of the more recent additions).
Intel does not expose support for such a mode in DXVA, so i guess its not supported by the hardware. To be honest, its not really required anyway, MPEG4-ASP SD can be decoded by CPUs that are 10 years old, and HD material is somewhat rare (and even then its still very simply to decode).

The old LAV CUVID supported MPEG4-ASP, and LAV Video 0.45 will regain that ability. I may also add it to the DXVA2 decoder for AMD/ATI, if i ever feel really bored (its not implemented in ffmpeg yet, so more work then just flipping a switch)

@VC-1:
Its possible to intercept the calls from the MSDK into DXVA and check what its doing different (i used that alot the last few days to figure out VC-1 interlaced DXVA2 with other DXVA2 decoders), but since we have the MSDK - why bother? :d

[NikosD]

@NikosD
I have relatively little knowledge on DXVA and what the driver support or not. Frankly I don't want to deep dive on the matter, I'd rather have a tooth pulled out :(
That's why I use the Media SDK, it simplifies (significantly) HW video decode/process and also adds encode as a bonus.
This means that dealing with DXVA is handled by the Media SDK developers and not me :)
Some features may be possible when using native DXVA that don't exist in the MSDK, but I can live with that.


Thanks for the reply.

So, when you propose to "Output native DXVA surfaces" doesn't involve you in DXVA itself ?
You could output native DXVA surfaces through MSDK ?

I thought the proposal "Output native DXVA surfaces" was actually a proposal for building a direct DXVA decoder.

[RBG]

egur
Hello Eric.

Can you explain a little bit more about scaling and what do you mean by that. AFAIK video scaling(chroma, luma upscaling, downscaling) is something that is usually done on render level, and you are developing a decoder. Also how good is intel scaling compared to madVR?



The old LAV CUVID supported MPEG4-ASP, and LAV Video 0.45 will regain that ability

Great news, I don't have to use old CUVID any more. :)

[NikosD]

The old LAV CUVID supported MPEG4-ASP, and LAV Video 0.45 will regain that ability. I may also add it to the DXVA2 decoder for AMD/ATI, if i ever feel really bored (its not implemented in ffmpeg yet, so more work then just flipping a switch)


Good to know.
For Nvidia HW why isn't it possible to accelerate MPEG4-ASP in DXVA ? (Direct or Frame copy)
Why do you have to use LAV CUVID ?


@VC-1:
Its possible to intercept the calls from the MSDK into DXVA and check what its doing different (i used that alot the last few days to figure out VC-1 interlaced DXVA2 with other DXVA2 decoders), but since we have the MSDK - why bother? :d

Direct is always faster and more efficient in terms of power consumption, a requirement for laptops mainly.
Especially Intel's MSDK implementation with 60fps VC-1 clips, there is the same problem of Turbo CPU frequency as with H.264 60fps files, even in normal playback mode.

[betaking]

OK then. everyone wants deinterlacing + film detection. I'll start with that. Scaling and other post processing features will follow.
I won't implement a custom DI myself, I'll use the one supplied by the driver. Personally I've tested it to be better than Nvidia/AMD but your mileage may vary.
@Betaking
The MSDK doesn't support MPEG4-ASP as far as I know. I don't know about driver support. Does DXVA support this format (any GPU)?

Thanks for the reply.;)

[nevcairiel]

For Nvidia HW why isn't it possible to accelerate MPEG4-ASP in DXVA ? (Direct or Frame copy)
Why do you have to use LAV CUVID ?

Who says you have to?
DXVA is also possible.

[NikosD]

Nobody has done it, yet.
Including you.

[nevcairiel]

And i already said why i didn't do it yet, because ffmpeg doesn't support MPEG4 DXVA2 yet, and implementing that is quite a bit of work for very little benefit. It is however planned for some time in the future.

Also, my DXVA2 decoder is only a few days old, i rather focused on issues like VC-1 interlaced DXVA, which required you to use a commercial DXVA decoder up to now. :d

[NikosD]

So, PotPlayer's (which is based on FFMpeg) UVD3 support of MPEG4-ASP VLD is just a work of their own ?

Or FFMpeg implemented MPEG4 ASP only for ATI's HW ?

BTW, DivX codec itself has DXVA MPEG4 ASP support only for UVD3.

Update:
PotPlayer is free and can accelerate DXVA VC-1 Interlaced at least one year before!

[betaking]

So, PotPlayer's (which is based on FFMpeg) UVD3 is just a work of their own ?

Or FFMpeg implemented MPEG4 ASP only for ATI's HW ?

BTW, DivX codec itself has DXVA MPEG4 ASP support only for UVD3.

I not have UVD3 to test it !but arcsoft video codec support DXVA MPEG4 ASP only for UVD3 too!

[nevcairiel]

So, PotPlayer's (which is based on FFMpeg) UVD3 support of MPEG4-ASP VLD is just a work of their own ?

Or FFMpeg implemented MPEG4 ASP only for ATI's HW ?

Its not implemented at all, if they added it, its their own - and they "forgot" to contribute it back to ffmpeg, like the license mandates.


PotPlayer is free and can accelerate DXVA VC-1 Interlaced at least one year before!

A decoder limited to one player is not useful to many people.

Its just one example why their attitude is not really productive. They take open source code, then add their own features, and claim to have more features then everyone else.
If you base your work on open source, its mandatory to also contribute any changes back to the project, or at least make the changes available for the public. Its not only a "nice thing to do", but its also required by copyright law!

[NikosD]

So, they look like the "bad" guys of Open Source community.
They take things from others, but they give nothing back.

I don't know if that's true - I have heard it from others too - but I know that they sure have the most complete Video Player out there especially regarding DXVA video codecs support for all HW (ATI, Nvidia, Intel)

I consider PotPlayer and LAV filters among the best "new" free software for multimedia (MPC-HC, FFMpeg are the "grandfathers")

[egur]

Thanks for the reply.

So, when you propose to "Output native DXVA surfaces" doesn't involve you in DXVA itself ?
You could output native DXVA surfaces through MSDK ?
...

The MSDK outputs Direct3D9 surfaces (which I allocate BTW). These type of resource is used by DXVA for video frames. MSDK, according to its documentation is an abstraction layer on top of DXVA2. BTW, the overhead of the MSDK is extremely low. I add an overhead in my decoder (frame copying) so I can impersonate a SW decoder with the added benefits.

egur
Hello Eric.

Can you explain a little bit more about scaling and what do you mean by that. AFAIK video scaling(chroma, luma upscaling, downscaling) is something that is usually done on render level, and you are developing a decoder. Also how good is intel scaling compared to madVR?

Scaling
Assumption: an image is a discrete representation of the continuous world. this means that pixels (samples) are integrals of an area in the real world. This is similar to audio samples that represent an integral over time.

Scaling AKA resampling can be described as converting the discrete samples to a continuous signal and getting the value (actually integrating) the signal in new positions. If you create more sample points from the continuous signal, you up-scale the image (more pixels) if you sample less points, you're performing down-scaling.

Signal processing theory describes the process (some signal processing knowledge required :) :
* Create a continuous signal from the discrete samples. This done by adding zeros between the samples. The continuous signal is all zeroes with spikes where the samples where.
* Low-pass the signal (weaken or eliminate high frequency)
* Sample the values of the low-passed signal at new positions.

Actual resampling implementations (nearest neighbor, bi-linear, bi-cubic, Lanczos) do just that. Instead of integrating a signal which most of it is zero, you can simply sample the low-pass function and multiple the sampled values with the original pixels.

When down-scaling, the low-pass function must be designed so it will remove high frequencies that do exist in the output image. Every discrete signal has a Nyquist frequency which half it's size (one for horizontal and one for vertical).

From signal processing point of view, the perfect low-pass filter is a Sync (sin(x)/x). A Sync will clip all high frequencies and retain the amplitude (strength) of the low frequencies.

For performance reasons the number of samples used to derive a new pixel value is limited. This is called the sampling window width.
For down-scaling this is perfect (if all the pixels in the input image are used to create each and every output pixel).

For up-scaling things are not so easy. Using a Sync or a modified trimmed version of it (Lanczos) will result in ripples near edges. This is unpleasing to the eye (false edges and mosquito noise).

A variety of sampling functions exist, they are always compromise on performance, sharpness and artifacts.
* Lanczos is the sharpest. Exhibits strong edge artifacts. The more taps used (sampling window size) the output will be sharper with more artifacts
* Bi-cubic - less artifacts, less sharp.
* Bi-leaner - not sharp, geometric artifacts.
* nearest neighbor - sharp, heavy geometric artifacts

There are some sampling algorithms that work a little differently. They can guess the value of missing samples by some kind of heuristics or statistics (e.g. NEDI algorithm). They are computationally very heavy and the results are not worth the effort.

SandyBridge's adavnced video scaler has a different approach. A context adaptive scaler.
It will use a Lanczos4 scaler (8 taps) in order to create very sharp images. In order to avoid (most) of the artifacts, it will perform an analysis of the area and blend between the sharp scaler and a smooth scaler depending if the analysis thought the target pixel is prone to artifacts.

Context adaptive scaling is not a new idea but this implementation's quality and performance are probably one the best.
Some companies perform context adaptive scaling using a different paradigm - use a soft scaler like bi-cubic and perform post processing sharpness filter on edges that were very strong in the source image.

BTW, these tricks are used only for upscaling. For downscaling , the optimal filter is Lanczos for a given sampling window size.

Regarding luma and chroma scaling. Luma is he grey levels of the image (called Y) and chroma is the color information (called UV or CbCr). In the YUV color space, which most of the videos are encoded with, the UV color components are usually at a lower resolution and thus not fully aligned with the luma (Y) component. A scaler algorithm must make sure that chroma scaling produces a pleasing result. Most of the time, chroma values are resampled using a softer scaler (bi-cubic variant).

MadVR currently implements a wise variety of scaling algorithms, all of them are known textbook algorithms and allows selecting different algorithms for Y and UV scaling so the user can get the results he/she likes best.
Since theirs usually a trade-of between sharpness and various artifacts some users will sacrifice one for the other.

[NikosD]

The MSDK outputs Direct3D9 surfaces (which I allocate BTW). These type of resource is used by DXVA for video frames. MSDK, according to its documentation is an abstraction layer on top of DXVA2. BTW, the overhead of the MSDK is extremely low. I add an overhead in my decoder (frame copying) so I can impersonate a SW decoder with the added benefits.


It's clear now.

But then , I think is extremely easy to implement a "direct" DXVA decoder through MSDK, just by sending directly the decoded frame to EVR renderer.

So, I think the "direct" - through MSDK - DXVA decoder can be implemented earlier and easier than video scaling procedures. :D

[CruNcher]

OK then. everyone wants deinterlacing + film detection. I'll start with that. Scaling and other post processing features will follow.
I won't implement a custom DI myself, I'll use the one supplied by the driver. Personally I've tested it to be better than Nvidia/AMD but your mileage may vary.

@CruNcher
The scaling algorithm in SandyBridge is superior to both Nvidia and AMD in both upscaling and downscaling. Since I invented the algorithm for the video scaler, I have deep knowledge on the matter. Like many other parts of the video engine, it's implemented as ASIC and has very high performance.

@NikosD
I have relatively little knowledge on DXVA and what the driver support or not. Frankly I don't want to deep dive on the matter, I'd rather have a tooth pulled out :(
That's why I use the Media SDK, it simplifies (significantly) HW video decode/process and also adds encode as a bonus.
This means that dealing with DXVA is handled by the Media SDK developers and not me :)
Some features may be possible when using native DXVA that don't exist in the MSDK, but I can live with that.
Anyway, complaints about the driver (or feature requests) should be posted in the driver forum (http://communities.intel.com/community/tech/graphics).

@Betaking
The MSDK doesn't support MPEG4-ASP as far as I know. I don't know about driver support. Does DXVA support this format (any GPU)?

I fully believe you that :) though that wasn't the question on the scaling it was more how does it compare to NEEDI3 ;)

There are some sampling algorithms that work a little differently. They can guess the value of missing samples by some kind of heuristics or statistics (e.g. NEDI algorithm). They are computationally very heavy and the results are not worth the effort.

Yes extremely slow and that's the question how does yours compare Performance/Quality in Hardware implemented even Adaptive :)

SandyBridge's adavnced video scaler has a different approach. A context adaptive scaler.
It will use a Lanczos4 scaler (8 taps) in order to create very sharp images. In order to avoid (most) of the artifacts, it will perform an analysis of the area and blend between the sharp scaler and a smooth scaler depending if the analysis thought the target pixel is prone to artifacts.

It sounds good on paper (did you ever released one ?), and surely Intel wouldn't have bought it if it wouldn't have looked valuable for them ;)

[nevcairiel]

But then , I think is extremely easy to implement a "direct" DXVA decoder through MSDK, just by sending directly the decoded frame to EVR renderer

Its not that easy, there are a number of annoying factors to deal with. Personally, i think the copy-back solution is easier, which is why i started with it. :D

[RBG]

egur

Thanks for your reply, I appreciate it a lot.:) I want to clear something up, will SB scaling work on hybrid systems and what are the conditions of it? For example, there is no real display connected to my Intel HD graphics, I made a fake one, like you suggested here (http://forum.doom9.org/showpost.php?p=1532786&postcount=186).

[CruNcher]

@Eric
as this is one of your professions i would like to advice you that we also have Robidoux on Doom9 Madshi, Tritical and other who research in that field over @ the Avisynth area ;) (i know you are fully on with the decoder but maybe as soon as you get to the scaling implementation you could say hello ;) )

http://forum.doom9.org/showthread.php?t=160038
http://forum.doom9.org/showthread.php?t=145358
http://forum.doom9.org/showthread.php?t=160610
http://forum.doom9.org/showthread.php?t=154143


Context adaptive scaling is not a new idea but this implementation's quality and performance are probably one the best.
Some companies perform context adaptive scaling using a different paradigm - use a soft scaler like bi-cubic and perform post processing sharpness filter on edges that were very strong in the source image.

This is also what i currently prefer Realtime and use in my avisynth framework via the GPU shader though not with bi-cubic :)
Would really tove to see your implementations result, especialy speed beeing native asic and not Shader though copy back will hit that again :)
But yeah i voted for Deinterlacing + Ivtc and those are more important for now :D

[STaRGaZeR]

Good post right there egur ;)

[egur]

@CruNcher
SandyBridge's Advanced Video Scaler (AVS) is a programmable fixed function sclaler (ASIC) utilized when either using the EVR or by renderers from Cyberlink and Arcsoft and maybe other companies.
I've confirmed that the Media SDK uses the AVS for scaling. Older GPUs had simpler scalers.

I didn't release a paper/patent since the actual implementation is trade secret (the analysis part). But again, context adaptive scaling (or context adaptive algorithms in general) is not new.

The performance of the AVS will vary on GPU clock speed, but it can do several 1080p60 streams simultaneously.

The best way to test upscaling is by scaling DVD resolution to 1080p (720p-->1080p is a small scale factor). Downscaling can be checked by shrinking the player/render and playing test patterns - look for aliasing.

@RBG
EVR will use the video processing features (DI, scaling ,etc) available on the GPU connected to the screen showing the video. So with hybrid setups, you get what AMD/Nvidia gives you.

[RBG]

@RBG
EVR will use the video processing features (DI, scaling ,etc) available on the GPU connected to the screen showing the video. So with hybrid setups, you get what AMD/Nvidia gives you.

Ah... That's sad.:(

Now I don't understand what did you mean by writing:

What should be the next big feature?
* HW Video processing: deinterlacing, film detection (3:2, 2:2 pulldowns, etc), noise reduction, sharpness, scaling, etc.

Internal hw deinterlacing, edge-enhancement, all that works in LAV video(CUVID), and when I saw "scaling" in your list, I thought you are going to implement it somehow in the decoder itself, that is why I asked you about it.

[egur]

Ah... That's sad.:(

Now I don't understand what did you mean by writing:

What should be the next big feature?
* HW Video processing: deinterlacing, film detection (3:2, 2:2 pulldowns, etc), noise reduction, sharpness, scaling, etc.

Internal hw deinterlacing, edge-enhancement, all that works in LAV video(CUVID), and when I saw "scaling" in your list, I thought you are going to implement it somehow in the decoder itself, that is why I asked you about it.

I do plan to implement it internally and it will work on Intel HW regardless of the renderer. That's the beauty of the QS decoder's design, it cares very little about the renderer.
The decoder is (traditionally) not responsible for scaling, the renderer is. But I can expose the feature anyway, like ffdshow does (scale to a fixed resolution).

[RBG]

I do plan to implement it internally and it will work on Intel HW regardless of the renderer. That's the beauty of the QS decoder's design, it cares very little about the renderer.
The decoder is (traditionally) not responsible for scaling, the renderer is. But I can expose the feature anyway, like ffdshow does (scale to a fixed resolution).

Yes, scaling is done by render, I know that, but IMO it brings some inconveniences, especially on hybrid systems. That means if I want to get high quality picture, I should either stick with MadVR which is obviously not very stable, either use SB hw scaler, which is limited to vanilla EVR and physical display connection needed here. And in this situation internal hq hw scaling can be a real option. It will be totally awesome if you implement this feature someday. Also I wonder if it is possible to make internal hw scaling work dynamically, like it works on EVR, scale to the actual window size?

[nevcairiel]

Also I wonder if it is possible to make internal hw scaling work dynamically, like it works on EVR, scale to the actual window size?

I would doubt that this is feasible.

[egur]

...
Also I wonder if it is possible to make internal hw scaling work dynamically, like it works on EVR, scale to the actual window size?
The thing is that the decoder receives events/callbacks only for decoding frames.
When the player is paused and the window is resized, only the renderer will receive a notification that the size has changed. Changing resolutions within the decoder implies a (implicit) notification from the decoder to the renderer. Frequent notifications might cause the renderer to misbehave.
So technically it's not possible to do dynamic resolution change within the decoder.
If there was an open source renderer project than it would be possible.

For your kind of setup, if you choose not to use MadVR, you should check if you can use Lucid Virtu (Google it). It will copy the frames from EVR to the actual display with relatively small overhead.

[RBG]

The thing is that the decoder receives events/callbacks only for decoding frames.
When the player is paused and the window is resized, only the renderer will receive a notification that the size has changed. Changing resolutions within the decoder implies a (implicit) notification from the decoder to the renderer. Frequent notifications might cause the renderer to misbehave.
So technically it's not possible to do dynamic resolution change within the decoder.
If there was an open source renderer project than it would be possible.

Thanks for the clarification. Well, fixed resolution resize should be fine too.;)


For your kind of setup, if you choose not to use MadVR, you should check if you can use Lucid Virtu (Google it). It will copy the frames from EVR to the actual display with relatively small overhead.

Lucid Virtu runs on my motherboard only in trial mode, already tried it, and vanilla EVR itself is no good due to poor subtitle support and lack of custom shaders.

[NikosD]

Eric,

Your professional knowledge of scalers and Video Processing in general, could be an initial boost for Intel to move forward next generation Video Processing capabilities supported by DXVA-HD.

There is no driver available by any company supporting DXVA-HD, which BTW has nothing to do with decoding.
It's pure Video Processing enhanced compared to DXVA-VP.

Here they are some key points from Microsoft:

Improvements over DXVA-VP

DXVA-HD expands the set of features provided by DXVA-VP. Enhancements include:

•RGB and YUV mixing. Any stream can be either RGB or YUV. There is no longer a distinction between the primary stream and the substreams.
•Deinterlacing of multiple streams. Any stream can be either progressive or interlaced. Moreover, the cadence and frame rate can can vary from one input stream to the next.
•RGB background colors. Previously, only YUV background colors were supported.
•Luma keying. When luma keying is enabled, luma values that fall within a designated range become transparent.
•Dynamic switching between deinterlace modes.

DXVA-HD also defines some advanced features that drivers can support. However, applications should not assume that all drivers will support these features. The advanced features include:

•Inverse telecine (for example, 60i to 24p).
•Frame-rate conversion (for example, 24p to 120p).
•Alpha-fill modes.
•Noise reduction and edge enhancement filtering.
•Anamorphic non-linear scaling.
•Extended YCbCr (xvYCC).

[nevcairiel]

There is no driver available by any company supporting DXVA-HD,

Thats not true, NVIDIA supports DXVA-HD.
Intel does too, but Intels support is rather limited (and slow!)

AMD does not offer it at all.

I evaluated it a while ago to use it for deinterlacing, but because only NVIDIA really offered a working solution, i discarded the code again.

Obviously even NVIDIA doesn't offer every single mode, especially the IVTC support is very limited through DXVA-HD.

[egur]

Eric,

Your professional knowledge of scalers and Video Processing in general, could be an initial boost for Intel to move forward next generation Video Processing capabilities supported by DXVA-HD.

I'm in a different position, other people are responsible for video processing capabilities.
There's active R&D going on in video processing at Intel. Processors/GPUs after SandyBridge will have improved algorithms. It's an evolutionary process.
BTW, most of the features you specified exist in SandyBridge as far as I know.
I think an open source renderer would be a good place to advance the video processing field. LAV Renderer perhaps? :D

[nevcairiel]

LAV Renderer perhaps? :D

No thanks, i'm happy with madVR.

[patul]

I think an open source renderer would be a good place to advance the video processing field. LAV Renderer perhaps? :D

<OT>
That would be nice, might be reinventing the wheel as madVR (even though it's closed source) is doing a great job. I asked for full blown LAV Player (MF-based) few weeks ago, and nevcairiel said that I will have to lock him up in a room with computer for a year or two :D

</OT>

[egur]

No thanks, i'm happy with madVR.
I was kidding. You already do so much.

[RBG]

I was kidding. You already do so much.

Maybe you're were kidding, but you're all the way right here, indeed a new open source render concept is needed. MadVr is good, but it is not near as stable as EVR, and it's closed source project.

[CruNcher]

Eric,Jan,Madshi and Nev together that would be crazy (in the good sense) EriJaMaNev Player or why not finally do the "Doom9 Player" ;)

[Blight]

I wonder if dynamic scaling can be done in the decoder if the player used a function to inform the decoder of the resolution change.

[egur]

I wonder if dynamic scaling can be done in the decoder if the player used a function to inform the decoder of the resolution change.

Due to queuing on both decoder and renderer this will not be smooth...

[CharlieCL]

Is it possible to wrap encoder into ffdshow? So we can record a video from frame buffer. This may remove a big disadvantage of PC that can not record video from HDMI because of HDCP.

[CharlieCL]

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.

Eric,

Could you please select H.26, VC1, MPEG2 codecs to Intel QuickSync as default codecs in your ffdshow distribution? In Windows 7 I have to run another program to disable Windows codec even if the QuickSync was selected. This is not convenient. Since your distribution is especially for SB/IB the default values are better to this optimization.

[Blight]

Many users will accept jerky scaling while resizing a window if the end result is a better image quality once the window finishes resizing.

Due to queuing on both decoder and renderer this will not be smooth...

I vote deinterlacing in the poll, added as a new option in ffdshow's deinterlace setting and accessible through ffdshow's API.
Right now Zoom Player is setting ffdshow to 'yadif' if a user turns on deinterlacing, but it would be trivial to make SB deinterlacing an option if the API supported it.

[CruNcher]

Many users will accept jerky scaling while resizing a window if the end result is a better image quality once the window finishes resizing.



I vote deinterlacing in the poll, added as a new option in ffdshow's deinterlace setting and accessible through ffdshow's API.
Right now Zoom Player is setting ffdshow to 'yadif' if a user turns on deinterlacing, but it would be trivial to make SB deinterlacing an option if the API supported it.

Depends i guess how heavy the latency would be for regular window,full window, full screen switching see for example Jans Experimental Renderer latency its just acceptable if it would take longer it would feel odd it's already a completely different feeling compared to trunk with that 7ms latency.

PS: Though i agree having Lanczos4 Upscaling Quality In Realtime is something not so shaby and equal quality for both down/up due to the blending :)

[RBG]

Eric,

Could you please select H.26, VC1, MPEG2 codecs to Intel QuickSync as default codecs in your ffdshow distribution? In Windows 7 I have to run another program to disable Windows codec even if the QuickSync was selected. This is not convenient. Since your distribution is especially for SB/IB the default values are better to this optimization.

Another program? You mean you changed decoder merit?

Libavcodec can be switched to quicksync without any third-party software just in ffdshow configuration screen in a few clicks, from my point of view this problem is not even worth mentioning.

Many users will accept jerky scaling while resizing a window if the end result is a better image quality once the window finishes resizing.


As a user I will absolutely accept not smooth scaling if finally it will end in decent picture quality.:D I think most of the people use only about two resolutions, which are scaled by render, when they open movie in the window as a preview, and of course when they extend it to full screen. So indeed smooth resolution change is not that much needed.

egur
I got a question, what is the best way to deliver the internally scaled image to render(EVR), I mean what processing queue and output color space should ffdshow use not to ruin the hw re-sampled video?

[egur]

Eric,

Could you please select H.26, VC1, MPEG2 codecs to Intel QuickSync as default codecs in your ffdshow distribution? In Windows 7 I have to run another program to disable Windows codec even if the QuickSync was selected. This is not convenient. Since your distribution is especially for SB/IB the default values are better to this optimization.

Ever since my decoder was integrated into ffdshow's official builds (a few months back), I've set the default codecs to their original values (mostly libavcodec). If you install ffdshow on top of an existing version, you're settings are not touched. So you need to configure ffdshow only once and updates will not touch this.
Disabling windows codecs has nothing to do with ffdshow or my decoder. I don't know what problems you have and why you need to disable them again and again. This doesn't occur on my PC and I didn't receive complaints from other users.

@Blight
First version will have DI on by default for interlaced streams and ffdshow will not be aware that the stream is interlaced as it will receive progressive frames.
As for configuration of the video processing, I'll add a new TAB in ffdshow's window for this purpose or expose an interface from ffdshow or both. Please define what is needed from such interface, no hurry it will be a few weeks before VP will work.

@RBG
I agree with RBG that full screen scaling makes more sense and windowed mode can use the renderer's scaler, this will simplify things a lot.

For best performance use only NV12, it's the one and only supported format in HW (ATM). All other formats cause conversions to occur.

@CruNcher
Waht do you mean by "and equal quality for both down/up due to the blending". What blending?

BTW, I'll be on vacation for a week starting tomorrow so I'll might not be able to answer in the following week (till Jan 28th).

[CruNcher]

adaptively changing kernels for downscaling/upscaling :)
do you have any numbers of the raw speed of the Asic just for jaw dropping effect ;)

[CharlieCL]

Ever since my decoder was integrated into ffdshow's official builds (a few months back), I've set the default codecs to their original values (mostly libavcodec). If you install ffdshow on top of an existing version, you're settings are not touched. So you need to configure ffdshow only once and updates will not touch this.
Disabling windows codecs has nothing to do with ffdshow or my decoder. I don't know what problems you have and why you need to disable them again and again. This doesn't occur on my PC and I didn't receive complaints from other users.


Since there are many ffdshow distributions I do not know which one is official :-( I have tried one and found that there is a doubt trojan horse before.

BTW Are your setup program in open source?

There is a program called Win7DSFilterTweaker which allows you to configure your preferred DirectShow filters in Windows 7. FFDshow does not change the priority of filter in Windows 7. Actually I am testing QuickSync in Windows 8 Preview. In the case of automatic match filters just added codec will not be selected in ffdshow.

[egur]

adaptively changing kernels for downscaling/upscaling :)
do you have any numbers of the raw speed of the Asic just for jaw dropping effect ;)

Changing state for upscaling/downscaling is the responsibility of the driver (works per direction BTW).
I don't know the exact performance numbers and they probably vary depending on GPU clock speed and memory subsystem utilization, but it should support multiple 1080p@60 streams so no problem here. This is for the entire video processing pipeline.

[egur]

Since there are many ffdshow distributions I do not know which one is official :-( I have tried one and found that there is a doubt trojan horse before.

BTW Are your setup program in open source?

There is a program called Win7DSFilterTweaker which allows you to configure your preferred DirectShow filters in Windows 7. FFDshow does not change the priority of filter in Windows 7. Actually I am testing QuickSync in Windows 8 Preview. In the case of automatic match filters just added codec will not be selected in ffdshow.

I don't have setup at all. FFDshow (http://ffdshow-tryout.sourceforge.net/) has one and so does LAV filters (http://forum.doom9.org/showthread.php?t=156191). Downloads from these sites are safe, they are the official sites.

My decoder is just a DLL, not a DirectShow filter so it's not a standalone product.

I don't have any experience with win8 ATM so I can't comment on the matter. I personally used the Win7DSFilterTweaker tool so I can't use ffdshow (or LAV decoder) under Windows Media Center. I didn't see a problem when upgrading either LAV or ffdshow versions. Maybe win8 is somehow different. Anyway within ffdshow or LAV, my decoder will not affect the way it connects to the renderer or how it's enumerated by DirectShow. Maybe I'm missing something, anyway else had issues?

[RBG]

egur

I usually use YV12 as avisynth input doesn't accept NV12, but it doesn't matter, when I mentioned SB hw scaling in my previous post, I was thinking about how it will work in future. So lets imagine, that you have already implemented SB hw scaling inside ffdshow decoder, can you clear some things up for me.:) Ordinary video is 4:2:0 Y'CbCr, it has full luma resolution and a half of chroma resolution, for you to be able to watch video on computer display, render upscales or downscales chroma and luma to match monitor resolution and converts it to RGB. From how I understand the SB hw scaler technology, it resamples standard 4:2:0 to match display resolution in both chroma and luma, and that means that output will be full 4:4:4. Ffdshow in this case needs to know when internal scaling is turned on, and automatically output AYUV(or RGB) not to ruin picture quality archived by SB scaler. Correct me please, if I am wrong?

BTW Have a good vacation.:)

[tremens]

starting with version 0.21.0.0, the option for use of this decoder on my atom n280/945gm eeepc is disabled. i realize its unstable and this is probably why its disabled, but its the fastest h264 decoder for this lowly netbook and its use is worth the occasional crash for me. anyway to override?

[nevcairiel]

For some reason the later versions don't function on non-SandyBridge hardware anymore, there currently is no way to override it.
I hope egur can look into it at some point again, to allow usage on older hardware, even if its less efficient.

[namaiki]

That's pretty weird. I thought that the 945gm doesn't have H.264 hardware video decoding but starting with the Intel 4 series chipset which is about 2 generations later.

[nevcairiel]

Its not 100% clear from documentation, there is contradicting documentation out there.
Easiest way to check is just to use DXVA Checker.

Without doubt, the first chip to support everything properly is the X4500HD in the G45 chipset, any previous chips may offer some support, but nothing i would rely on.
The argument still stands however, Erics decoder doesn't work on a X4500HD or Intel HD Graphics with ClearVideo HD - only on QuickSync enabled CPUs.

I hope this can be fixed, somehow.

[tremens]

the 945gm does not support any real hardware h264 decoding, nevertheless, this decoder plays 720p files on this netbook that everything else stutters. libav, coreavc, divx...

[namaiki]

Just curious, but could you please post a screenshot of the 'Info' tab in 'ffdshow video decoder' when you are playing back a video in the last version which seems to work with the Quicksync decoder?

[tremens]

yes, it appears you're right. now as far as i can tell, i'm using libav no matter which is selected. so perhaps it was just placebo combined with updating ffdshow for the first time in a while? but i could of sworn i saw a clear indicator i was using it and i was definitely seeing occasional kernel panics that i had not normally experienced. ill keep trying older revisions but as of now i can't reproduce any of it...

[Blight]

egur:
I would prefer that deinterlacing be handled within the ffdshow framework.
If ffdshow's 'deinterlace' option is enabled, your code should check if ffdshow is set to the QuickSync deinterlace mode and if it is, it should deinterlace, otherwise, you should leave the frame as-is and even let ffdshow use a different deinterlacer.

With regards to image scaling. I have no problem if it only switched the QS scaler on fullscreen.

[CruNcher]

egur:
I would prefer that deinterlacing be handled within the ffdshow framework.
If ffdshow's 'deinterlace' option is enabled, your code should check if ffdshow is set to the QuickSync deinterlace mode and if it is, it should deinterlace, otherwise, you should leave the frame as-is and even let ffdshow use a different deinterlacer.

With regards to image scaling. I have no problem if it only switched the QS scaler on fullscreen.

yep it definitely should be chose able between Render Deinterlacing,ffdshow implementations, and direct Quicksync copy back Deinterlacing
chosing between Render Deinterlacing and Software works fine allready Quicksync Deinterlacing just has to be nicely put as adddition into this by directly including it to the Software Deinterlacing list but mark it as Intel GT1/GT2/GT3/GT4 Hardware Deinterlacing ?
Most devs of ffdshow wouldn't accept it otherwise anyways im pretty sure (because consistency is a major goal between different devices and Windows OS) :) Also this makes it needed i guess that all these IMSDK features are only enabled on Vista/7 and doesn't appear on pre NT 6 (so their needs to be a @ least a OS detection for these Quicksync features maybe even allowing to select them but resulting in a message box that NTs bellow 6 (Vista/7/8) aren't supported). A good thing would be also to use the IMSDK decoder(pp) given frame informations and send them back to the ffdshow OSD as well :)

http://img4.imageshack.us/img4/9942/ffdshowquicksyncdeinter.png

Just a good note VLCs Quicksync playback became more stable their on a good way (just some artifacts now but not the whole green screen problems anymore on most bitstreams) :) (lots of motion artifacts now but @ least you can identify stuff, wrong frame decoding orders,blocks in between ;) ) Cool thing it also works on the OpenGL Renderer (glwin32) :)

[pulbitz]

QuickSync decoder can't decode this file.
http://www.mediafire.com/?awac8rbwi3e55wn

[CruNcher]

wow that mkv lets my explorer crash (parser or decoder) ;) whatever tries to render the thumbnail crashes it :P other mkvs work fine rendering the thumb

pulbitz use lav splitter and there should be no problems with this mux or try to remux it (mkvmerge,haali) if you want 100% interoperability :)

[pulbitz]

You are right.
But I tested original file. (1.28GB avi file)

magnet:?xt=urn:btih:d1d9e7f7fc8145594d7ad7d06f3013ee10adec04

ms avi splitter + ms dtv-dvd decoder OK.
ms avi splitter + ffdshow libavcodec OK.
ms avi splitter + ffdshow quicksync fails.
mpc avi source + ms dtv-dvd decoder OK.
mpc avi source + ffdshow libavcodec OK.
mpc avi source + ffdshow quicksync fails.

[CruNcher]

hmm i guess with lav splitter as avi source it works ? did you also tried with lav video (quicksync)
H.264 inside .avi is also not really recommended if you don't know what you do encoding parameter wise :)

[pulbitz]

lav splitter + lav quicksync is OK.

In Korea, many video files are being released in H.264 .avi. Why? I don't know. :(

[CruNcher]

My first yadiff vs Intel (deinterlacing 25i->50p) result (upscaling intel SD->HD) (including intel sharpening)

Source = http://www.mediafire.com/?mbuq1zevy5lv59u

lav video intel + intel scale = http://www.mediafire.com/?0kwgpv0xxexwya3
lav video yadiff + intel scale = http://www.mediafire.com/?03v2adyrp3uplt9
lav video intel + intel scale/sharp = http://www.mediafire.com/?v16x8em9ye7e28u
lav video yadiff + intel scale/sharp = http://www.mediafire.com/?pd1i5s19e945756
lav video yadiff + billinear + chroma + sharpencomplex2 = http://www.mediafire.com/?rvewg1sd0d58j55
lav video yadiff + madvr + ffdshow unsharp = http://www.mediafire.com/?f0pcapl3251wmj8

Intel Deinterlacing/Scale:

http://img84.imageshack.us/img84/2817/inteldeinterlacing.th.png (http://img84.imageshack.us/img84/2817/inteldeinterlacing.png)

Yadiff Deinterlacing Intel Scale:

http://img215.imageshack.us/img215/66/yadiffdeinterlacing.th.png (http://img215.imageshack.us/img215/66/yadiffdeinterlacing.png)

Yadiff Deinterlacing + Intel Scale/Sharp (Automatic) 4% CPU/16% GPU

http://img267.imageshack.us/img267/8233/yadiffintelsharpautomat.th.png (http://img267.imageshack.us/img267/8233/yadiffintelsharpautomat.png)

Intel Deinterlacing Intel Scale/Sharp Automatic 1.50% CPU /16% GPU

http://img268.imageshack.us/img268/4481/intelintelscalesharp.th.png (http://img268.imageshack.us/img268/4481/intelintelscalesharp.png)


Yadiff Deinterlacing + Billinear (7% GPU) + Chroma (13% GPU) + Sharpen Complex 2 (19% GPU) (No Intel Upscaling,Sharpening, heavy shader load) 4% CPU/58% GPU Billinear CPU = 4%/51% GPU EVR Custom load = 18%

http://img16.imageshack.us/img16/7449/yadiffbillinearchromash.th.png (http://img16.imageshack.us/img16/7449/yadiffbillinearchromash.png)

Yadiff Deinterlacing + Madvr (Billinear) + ffdshow Unsharp 8% CPU/22% GPU

http://img337.imageshack.us/img337/4069/yadiffmadvrbillinearuns.th.png (http://img337.imageshack.us/img337/4069/yadiffmadvrbillinearuns.png)

There is a slight position difference between EVR (intel scaling) and MPC-HCs EVR Custom and MadVRs Billinear Shader scaling

[egur]

yes, it appears you're right. now as far as i can tell, i'm using libav no matter which is selected. so perhaps it was just placebo combined with updating ffdshow for the first time in a while? but i could of sworn i saw a clear indicator i was using it and i was definitely seeing occasional kernel panics that i had not normally experienced. ill keep trying older revisions but as of now i can't reproduce any of it...

Just to clear, Atoms are not supported by the Media SDK. Updating ffdshow (and other components) from time to time is highly recommended.

[egur]

QuickSync decoder can't decode this file.
http://www.mediafire.com/?awac8rbwi3e55wn
I'll check it out.

yep it definitely should be chose able between Render Deinterlacing,ffdshow implementations, and direct Quicksync copy back Deinterlacing
...


I'm not sure what the logic should be in ffdshow's deinterlacing tab. Adding the Intel HW deinterlacer (iGPU only) without the QS decoder is complex. What happens then if the QS decoder isn't used because of unsupported surfaces (e.g. 4:2:2 or >8bit) or unsupported codecs?

An option is to add a new field in the deinterlacing tab called Auto. I can check if it's checked and use it. Another option is to add a check box with "Use HW deinterlacing when possible".

I'm open for ideas. I'll also need to ask for approval on the ffdshow dev thread so I'll cause as little trouble as possible :)

[CruNcher]

Adding the Intel HW deinterlacer (iGPU only) without the QS decoder is complex.
I thought that's what you wanted todo so that it is independent of the decoder used :)

Also i might have an answer for some people for that Quicksync fails Haalis splitter seems to fail in certain situations with it and falls back to libavcodec actually it seems to always fail and im pretty sure because it uses the CCV1 fourcc and ffdshow quicksync doesn't recognizes this as AVC1

A note that the new Haali defaults to passing any H.264 video to the play with the FourCC CCV1 so that CoreAVC can be used in WMP and WMC. This can be disabled in Haali's options if it causes problems.

Output->Use custom Mediatype for H.264 (NO)

see https://forum.doom9.org/showpost.php?p=1554770&postcount=8655

[egur]

I thought that's what you wanted todo so that it is independent of the decoder used :)

Also i might have an answer for some people for that Quicksync fails Haalis splitter seems to fail in certain situations with it and falls back to libavcodec actually it seems to always fail and im pretty sure because it uses the CCV1 fourcc and ffdshow quicksync doesn't recognizes this as AVC1



Output->Use custom Mediatype for H.264 (NO)

see https://forum.doom9.org/showpost.php?p=1554770&postcount=8655

Fixed the CCV1 issue, will release in a few days.
I'm also tweaking the frame copy function some more. Managed to get another 1% speedup so far with reordering of the load/store operators.

Regarding the post processing. If I create a separate component it would mean that the source will be copied to the GPU and the double frame rate output will be copied back, causing - probably needing surface conversions on both sides. This is very heavy lifting. My first try will be to always enable the DI when needed and see how this works. At a later stage I'll add post processing without decode. Since video post processing is a part of the MSDK I didn't use before, I'd like to do things in small steps.

[nevcairiel]

Regarding performance -

There also seems to be a performance regression from 0.22 to now with the multi-threaded copying.
If i enable multi-threading, and multi-threaded copying, but not multi-threaded decoding, its significantly slower then 0.22 was on the same settings.

Only if i enable multithreaded decoding as well (default settings), it'll be close to 0.22 performance.
Since 0.22 didn't even have multithreaded decoding, shouldn't the performance remain the same?

Is that something you can explain by some changes?
Was truly odd behaviour.

I can try provide some solid test cases, if you need them.
Its only really obvious if multi-threaded decoding is disabled, though, so a default setup of ffdshow doesn't really expose the problem.

[egur]

QuickSync decoder can't decode this file.
http://www.mediafire.com/?awac8rbwi3e55wn

Fixed. An initialization bug on my part. Actually, I didn't check height/width being mod16.

[egur]

Regarding performance -

There also seems to be a performance regression from 0.22 to now with the multi-threaded copying.
If i enable multi-threading, and multi-threaded copying, but not multi-threaded decoding, its significantly slower then 0.22 was on the same settings.

Only if i enable multithreaded decoding as well (default settings), it'll be close to 0.22 performance.
Since 0.22 didn't even have multithreaded decoding, shouldn't the performance remain the same?

Is that something you can explain by some changes?
Was truly odd behaviour.

I can try provide some solid test cases, if you need them.
Its only really obvious if multi-threaded decoding is disabled, though, so a default setup of ffdshow doesn't really expose the problem.

How much was lost? Did you close all other applications before testing (e.g. browsers cause undeterministic and noticeable degradation)?
If you a have specific clip that shows a performance gap, please share.

[rsd78]

Hi Eric,

I did some very informal testing of your great decoder on a couple of my HTPCs (running i3 2100T). For some reason (I tried a few different h.264 MKVs) on all my machines it would do a very odd stutter effect, like it was repeating skipping back or forward a few frames. I was using Shark's tools, but I tried by enabling Quicksync via Ffdshow directly as well (but made sure to turn off the ffdshow version) via Lav decoder. I know I tried it with Haali splitter, and I think Gabest. I can't recall if I tried it with Lav splitter, but unfortunately for me I won't use Lav Splitter because it's not compatible with the Media Control plugin which I need. I don't know if this helps you very much, but maybe I missed something obvious.

Thanks

[vivan]

rsd78,
what's your intel HD Driver version? If .2559 - try downgrading to .2509...

[CoolerKing]

Hi Eric,

I did some very informal testing of your great decoder on a couple of my HTPCs (running i3 2100T). For some reason (I tried a few different h.264 MKVs) on all my machines it would do a very odd stutter effect, like it was repeating skipping back or forward a few frames. I was using Shark's tools, but I tried by enabling Quicksync via Ffdshow directly as well (but made sure to turn off the ffdshow version) via Lav decoder. I know I tried it with Haali splitter, and I think Gabest. I can't recall if I tried it with Lav splitter, but unfortunately for me I won't use Lav Splitter because it's not compatible with the Media Control plugin which I need. I don't know if this helps you very much, but maybe I missed something obvious.

Thanks

Hello,

I think I'm having the same problem with my i5-2500K ever since I first tried.. When I play h264 .mkv files with quick sync enabled, the video is constantly jumping frames back and forward fast, and also shows corruption occasionally. It happens both with LAV and recent FFDShow versions (tried early FFDShow builds before and they would only give me the corruption issues that some other people reported, but not the skipping frames back and forward IIRC).

Intel(R) HD Graphics 3000

Driver Version: 8.15.10.2559
Operating System: Windows 7 Service Pack 1(6.1.7601)
Default Language: Dutch (Netherlands)
DirectX* Version: 10.1
Physical Memory: 7912 MB
Minimum Graphics Memory: 256 MB
Maximum Graphics Memory: 1760 MB
Graphics Memory in Use: 140 MB
Processor: Intel64 Family 6 Model 42 Stepping 7
Processor Speed: 3292 MHz
Vendor ID: 8086
Device ID: 0112
Device Revision: 09

* Processor Graphics Information *

Processor Graphics in Use: Intel(R) HD Graphics 3000
Video BIOS: 2104.0
Current Graphics Mode: 1920 by 1200

edit: I tried rolling back the driver to .2509 and the issue persists. Hope someone can post a solution to this problem.

Here's a example picture showing the corruption: http://i.imgur.com/2Sbic.png

Also, when I close MPC-HC after playing, the process keeps running (could be related to the problem)

Let me know if I can test anything or supply additional logs.

[TPoise]

Just wondering, any reason why you aren't doing the x64 builds anymore?

I still really appreciate highly what you're doing here. This simple plug-in has changed my computing habits for the better. For those that travel a lot know what I mean. My battery thanks you.

[nevcairiel]

If you a have specific clip that shows a performance gap, please share.

http://xhmikosr.1f0.de/samples/2160p/ParkJoy/ParkJoy_1080p50.x264.CRF23.mkv

Default settings, i get around 292 fps with the current version
When i disable MT Decode and MT Processing, i get ~255 fps.

With 0.22, and the same settings, its also 292 fps (but of course, MT Decode and MT Processing didn't exist yet).

It seems that somehow the settings of MT Decode and MT Processing are linked with MT Frame Copy, or there really is a performance regression.

[Omel]

Hello,

I think I'm having the same problem with my i5-2500K ever since I first tried.. When I play h264 .mkv files with quick sync enabled, the video is constantly jumping frames back and forward fast, and also shows corruption occasionally. It happens both with LAV and recent FFDShow versions (tried early FFDShow builds before and they would only give me the corruption issues that some other people reported, but not the skipping frames back and forward IIRC).

Intel(R) HD Graphics 3000

Driver Version: 8.15.10.2559
Operating System: Windows 7 Service Pack 1(6.1.7601)
Default Language: Dutch (Netherlands)
DirectX* Version: 10.1
Physical Memory: 7912 MB
Minimum Graphics Memory: 256 MB
Maximum Graphics Memory: 1760 MB
Graphics Memory in Use: 140 MB
Processor: Intel64 Family 6 Model 42 Stepping 7
Processor Speed: 3292 MHz
Vendor ID: 8086
Device ID: 0112
Device Revision: 09

* Processor Graphics Information *

Processor Graphics in Use: Intel(R) HD Graphics 3000
Video BIOS: 2104.0
Current Graphics Mode: 1920 by 1200

edit: I tried rolling back the driver to .2509 and the issue persists. Hope someone can post a solution to this problem.

Here's a example picture showing the corruption: http://i.imgur.com/2Sbic.png

Also, when I close MPC-HC after playing, the process keeps running (could be related to the problem)

Let me know if I can test anything or supply additional logs.

Hi
I'm a novice in this. but i had the same issue but this was when using cyberlink pdvd11 codec and when i switch over and used LAV video the issue disappear

I dont know if this will help you in any way

Regards

Omel

[egur]

Hello,

I think I'm having the same problem with my i5-2500K ever since I first tried.. When I play h264 .mkv files with quick sync enabled, the video is constantly jumping frames back and forward fast, and also shows corruption occasionally. It happens both with LAV and recent FFDShow versions (tried early FFDShow builds before and they would only give me the corruption issues that some other people reported, but not the skipping frames back and forward IIRC).
...

Also, when I close MPC-HC after playing, the process keeps running (could be related to the problem)

Let me know if I can test anything or supply additional logs.

Jumping back and forth was happening on my personal machine when Lucid Virtu was installed. Only affected 64 bit version. I don't know if they fixed the problem or not because I stopped using it. I also couldn't find a way to report this bug directly to Lucid.

Frame corruption that occurs frequently (many clips) is a weird driver install issue. This was reported by several users in the past and all of them reinstalled the driver to overcome this. Some installed an older one and then the latest version. I personally didn't see this effect or know what's the root cause.

Just wondering, any reason why you aren't doing the x64 builds anymore?
...
I always build 64 and 32 bit.
For your convenience here's a link to the file folder on my homepage http://sourceforge.net/projects/qsdecoder/files/ffdshow_builds/
BTW, you can get newer builds from ffdshow's official download area: http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/

FYI, the large green link on the QS decoder homepage is generated by SourceForge, underneath it, you have a link to browse all file.

[CoolerKing]

Hi
I'm a novice in this. but i had the same issue but this was when using cyberlink pdvd11 codec and when i switch over and used LAV video the issue disappear

I dont know if this will help you in any way

Regards

Omel

Thx for the suggestion, but as I already mentioned, LAV and FFDShow both give the same problem (I just tested LAV 0.45 again).. guess they are using the same QuickSync decoder.

Jumping back and forth was happening on my personal machine when Lucid Virtu was installed. Only affected 64 bit version. I don't know if they fixed the problem or not because I stopped using it. I also couldn't find a way to report this bug directly to Lucid.

Frame corruption that occurs frequently (many clips) is a weird driver install issue. This was reported by several users in the past and all of them reinstalled the driver to overcome this. Some installed an older one and then the latest version. I personally didn't see this effect or know what's the root cause.

I've never heard of Lucid Virtu.. how can I check if it's installed, and how can I remove it?

Thanks

[CruNcher]

these are more likely parser decoder interoperability issues (with that specific stream) then driver problems
, its still problematic to mix up different dshow frameworks because they react most of the times totaly different to issues and combined then you get strange results ;)
see my recent .ts satellite bad stream exploration i tested different combinations on 1 specific test case and get very different results ;) https://forum.doom9.org/showpost.php?p=1554770&postcount=8655
Though in the quicksync case its always the same issue with any combination and that's unsync for this case.
Also MPC-HC and Lav Splitters parser are almost twins (except the bug count which is higher for MPC-HC)

[nevcairiel]

these are more likely parser decoder interoperability issues then driver problems

no, its a driver problem (or a problem with Lucid Virtu, take your pick)

[CruNcher]

then i would say lucid virtu as egur said as i yet have to see that issue myself with 2559 on GT1 but im not yet @ .mkv ;)

[egur]

http://xhmikosr.1f0.de/samples/2160p/ParkJoy/ParkJoy_1080p50.x264.CRF23.mkv

Default settings, i get around 292 fps with the current version
When i disable MT Decode and MT Processing, i get ~255 fps.

With 0.22, and the same settings, its also 292 fps (but of course, MT Decode and MT Processing didn't exist yet).

It seems that somehow the settings of MT Decode and MT Processing are linked with MT Frame Copy, or there really is a performance regression.

I'll take a look.

Update
I installed my own build that used v0.22 (32 bit - ffdshow_rev4227_20120107_egur.exe).
Setup:
Window 7 64 bit. Latest drivers.
Screen connected to Radeon HD 6950.
GraphStudioNext 32 bit. NULL renderer. 5 runs. All are release (non debug) builds.

0.22 - avg 260. max 273.
0.24 (r30) no MT decode - avg 270, max 282
0.24 (r30) all MT tricks enabled (default) - avg 273, max 288.

BTW, when Chrome is open, the numbers go down to avg-260.
I'll try a few more clips and report again.

[CoolerKing]

Well, I've tried both .2509 and .2559.. I never heard of Lucid Virtu before, so unless it's bundled with other software, I don't think I have it. Really hoping to fix this issue, so I'd be happy to provide any logs or try anything necessary (except maybe a full OS reinstall ;)) to fix this issue.

@CruNcher, so you have a file that I could test? couldn't find one linked in your post

[rsd78]

I can add all the 3 of my machines that showed this issue are 32 bit Win 7. So I'm guessing perhaps a driver issue. I'll have to check what version I'm using but its probably 6-9 months old at least.

[CruNcher]

Well, I've tried both .2509 and .2559.. I never heard of Lucid Virtu before, so unless it's bundled with other software, I don't think I have it. Really hoping to fix this issue, so I'd be happy to provide any logs or try anything necessary (except maybe a full OS reinstall ;)) to fix this issue.

@CruNcher, so you have a file that I could test? couldn't find one linked in your post

Cooler King that's a different issue in your case try a complete lav video chain (lav splitter->lav audio->lav video (quicksync)->EVR) does the problem persist ?
If it does please post a sample :)

[nevcairiel]

Cooler King that's a different issue in your case try a complete lav video chain (lav splitter->lav audio->lav video (quicksync)->EVR) does the problem persist ?
If it does please post a sample :)

Its a driver problem, accept it already. :p
No sample or change in filters is going to help

Quite alot people described the exact same problem in the LAV thread, and in all cases installing a different driver helped.

[CruNcher]

ok ok if its a specific problem of how quicksync handles that bitstream and you sure of it, could be that i didn't reached such a problematic bitstream yet, though currently im testing also more your DXVA copy back then quicksync direct ;)

Its a driver problem, accept it already. :p
No sample or change in filters is going to help

Quite alot people described the exact same problem in the LAV thread, and in all cases installing a different driver helped.

Yes but what if they also had Lucid Virtu in use @ the same time ;)
i mean i surely should have hit that issues in ffdshow quicksync when testing it (or the time testing lav video quicksync) but i never experienced a wrong frame order issue like described here.

Also this lucid issue might explain why Intel reverted the 2559 driver and pushed back to the 2509 as lucid is a not so uncommon usage case on SB (MBM sponsored) ;)
Though for their own Mainboards also with Lucid support they still push 2559 very weird this driver policy ;)

Though wondering where Synergy got stuck @ btw (guess we will see it with Kepler arriving as a feature MBM sponsored thing again) ;)

[egur]

Well, I've tried both .2509 and .2559.. I never heard of Lucid Virtu before, so unless it's bundled with other software, I don't think I have it. Really hoping to fix this issue, so I'd be happy to provide any logs or try anything necessary (except maybe a full OS reinstall ;)) to fix this issue.

@CruNcher, so you have a file that I could test? couldn't find one linked in your post

It's usually bundled with the OEM (or MB manufacturer) SW pack. Look in the "Programs and features" section.

[CoolerKing]

It's usually bundled with the OEM (or MB manufacturer) SW pack. Look in the "Programs and features" section.

Nope, I've looked everywhere, and also searched the registry, but it's not installed.. Could some BIOS setting be causing it?

Also, which driver should I install if .2559 isn't good? (both the .2559 and .2509 drivers that I was using were the ones supplied by windows update.. not sure if that matters)


Cooler King that's a different issue in your case try a complete lav video chain (lav splitter->lav audio->lav video (quicksync)->EVR) does the problem persist ?
If it does please post a sample :)

I've tried your 720p.mpg sample with only LAV as filters, but it's still skipping back and forth.. so whatever the problem is, I think it's purely QuickSync related (maybe some BIOS setting or problem with 2509/2559 WHQL driver).

[CruNcher]

that sample causes the DXVA2 copy back to fail i would be carefull with it ;)

[egur]

Nope, I've looked everywhere, and also searched the registry, but it's not installed.. Could some BIOS setting be causing it?

Also, which driver should I install if .2559 isn't good? (both the .2559 and .2509 drivers that I was using were the ones supplied by windows update.. not sure if that matters)
...

Don't ever install drivers from Windows update (for any HW!).
Download the drivers from Intel and install them. I had no issues with either 2509 or 2559. They behave exactly the the same regarding video playback.

[amtm]

Don't ever install drivers from Windows update (for any HW!).
Download the drivers from Intel and install them. I had no issues with either 2509 or 2559. They behave exactly the the same regarding video playback.

That's silly. Intel, and many other manufacturers, push their drivers out through Windows Update. If downloading the WHQL drivers from Windows Update is a bad idea, you need to tell Intel to fix it because that means they've done something stupid.

[CoolerKing]

Don't ever install drivers from Windows update (for any HW!).
Download the drivers from Intel and install them. I had no issues with either 2509 or 2559. They behave exactly the the same regarding video playback.

So if the drivers (they should be identical whether obtained from windows update or the intel website), windows version (rsd78 is running 32bit and me 64bit) or lucid virtu (not installed) all aren't causing the problem, what could be? rsd78 said he's having the problem on 3 of his machines? So I'm quite surprised that only a few people mentioned having the back/forward skipping issue.

[NikosD]

I have no problems at all with latest drivers from Intel, but they were installed on a clean system, first and only drivers.

It's clear to me that Intel's drivers lack the maturity of ATI/ Nvidia drivers and may have problems after updating/ uninstalling previous versions.

Maybe you could try to use a driver uninstaller, for a full uninstallation.

Just for a last try, use PotPlayer with internal DXVA codecs or Quicksync decoder from the same program.
It may play OK.

[hajj_3]

those of you that have been doing benchmarks with quicksync and seeing how well it plays compares to cyberlink's decoders you might want to try powerdvd 12 which came out today and see if that has improved things in comparison to quicksync's decoder.

[CruNcher]

PowerDVD makes rarely use of Copy back (when using some of the PP it does) it mostly utilize DXVA natively

[CoolerKing]

Just for a last try, use PotPlayer with internal DXVA codecs or Quicksync decoder from the same program.
It may play OK.

DXVA Decoder (VLD - Slice Long) plays fine, but how do I know if it's using QuickSync? because I can't seem to select it anywhere.. It's only showing VLD (bitstream decoder) under H264 in the built-in video decoder settings..

I've also tried LAV with PotPlayer and it gives the same stuttering when QuickSync is selected.

[egur]

So if the drivers (they should be identical whether obtained from windows update or the intel website), windows version (rsd78 is running 32bit and me 64bit) or lucid virtu (not installed) all aren't causing the problem, what could be? rsd78 said he's having the problem on 3 of his machines? So I'm quite surprised that only a few people mentioned having the back/forward skipping issue.

Unfortunately, they are not always identical. I don't know what drivers are shipped in Windows update for Intel's graphics drivers but I had multiple bad experiences with other HW. One time I even had to revert to a backup of my OS before the install because the network driver crippled Windows and stopped working at 1Gb completely.
Download the latest driver from http://downloadcenter.intel.com/ (graphics->processor graphics)

[NikosD]

DXVA Decoder (VLD - Slice Long) plays fine, but how do I know if it's using QuickSync? because I can't seem to select it anywhere.. It's only showing VLD (bitstream decoder) under H264 in the built-in video decoder settings..

I've also tried LAV with PotPlayer and it gives the same stuttering when QuickSync is selected.

When you select QuickSync inside PotPlayer or LAV Video, you actually use Egur's work intergrated in those filters.
It's not direct DXVA solution, it uses Intel's Media SDK.

PotPlayer can use both QuickSync and DXVA directly, when you select internal decoders FFmpeg and nothing more.

Best solutions often are the simplest solutions.

[CoolerKing]

I've just installed the latest driver from Intel website and reinstalled ffdshow, and it's showing Decoder: Intel QuickSync in ffdshow properties, and no longer stuttering :) so I hope it's working now.. maybe MS drivers are indeed bad, or what I did different now as well is that I checked the DXVA video decoder box when installing FFDShow (dunno if that makes any difference).

Anyway, thx for all the help

ps. How much cpu usage is normal? Because me and a buddy are both getting 35-40% cpu usage with ffdshow (both 2500K), which seems quite high compared to other decoders

edit: Also tried LAV now with quicksync (it's working) and only about 5% cpu usage there... think I'll use PotPlayer w/spline resize + LAV QuickSync from now on

[amtm]

Unfortunately, they are not always identical. I don't know what drivers are shipped in Windows update for Intel's graphics drivers but I had multiple bad experiences with other HW. One time I even had to revert to a backup of my OS before the install because the network driver crippled Windows and stopped working at 1Gb completely.
Download the latest driver from http://downloadcenter.intel.com/ (graphics->processor graphics)

Windows Update only pushes out the WHQL drivers given to them by the manufacturer. It's not as if Windows Update is pushing a generic driver, they are pushing out the Intel branded WHQL driver. If Windows Update is pushing out a different driver than what is hosted on Intel's site, Intel is screwing something up and you need to tell them to stop doing so. Besides how can they be different if they have the same date and version info?

[amtm]

maybe MS drivers are indeed bad

They aren't. I have the same chipset as you in one of my computers and the driver from Windows Update is identical to the one from Intel's site and they perform identically. There was something else causing your issue.

[vivan]

2559 was pushed via Windows Update, but then it was removed. And now "latest" is previous - 2509 driver.
So problem is just in a buggy 2559 driver that people got through Windows Update, but it's not MS fault.

[NikosD]

Eric,

do you know if QuickSync ASIC exists inside HD P3000 graphics card and if there is any difference with HD 2000/3000 (regarding QuickSync only - not GPU in general) ?

[amtm]

2559 was pushed via Windows Update, but then it was removed. And now "latest" is previous - 2509 driver.
So problem is just in a buggy 2559 driver that people got through Windows Update, but it's not MS fault.

Exactly. Unless it's a generic driver, Windows Update is just pushing out the WHQL driver given to them by the manufacturer. If Intel's driver through Windows Update is broken or different, Intel screwed up not Microsoft.

[egur]

Eric,

do you know if QuickSync ASIC exists inside HD P3000 graphics card and if there is any difference with HD 2000/3000 (regarding QuickSync only - not GPU in general) ?

You mean the single socket server chip Xeon E3-12x5? Didn't try it. I have little access to the server platforms. Should be OK.

[NikosD]

Yes exactly.
Intel claims "up to 4x better performance than Intel HD Graphics 3000” but i am more interested in QuickSync performance of that card, meaning if there is a new version of QS already - before IvyBridge.

[CruNcher]

Exactly. Unless it's a generic driver, Windows Update is just pushing out the WHQL driver given to them by the manufacturer. If Intel's driver through Windows Update is broken or different, Intel screwed up not Microsoft.

Yes though it seems for some Intel systems 2559 works excellent for Video the case on my system (I5-2400 GT1 HD2000) and i didn't experience a wrong frame order playback yet. So it seems system dependent also (on which level dunno) maybe 32bit 64 bit difference or maybe MSDK replaced the buggy driver mfx library, lets wait and see what the next intel drivers changelog says (though if it only states a lucid virtu issue it's still mysterious) ;)

i think i found a issue with your scaler Egur, though hardly mathematically seen it isn't if someone creates a wrong size stream 400x265 and the decoder isn't padding it, such things happen ;)

lav video = http://img821.imageshack.us/img821/5746/greenlinescalinglavvide.png
ffdshow = http://img62.imageshack.us/img62/3374/ffdshowscalingok.png

interesting though how the lines are shifted especially the bottom line looks unusual compared to for example Jans Lanczos4 Shader which errors with only a greater thicker green line on the top :)

Jans Lanczos4 Shader error (EVR Custom)

http://img140.imageshack.us/img140/2241/evrcustomjanlanczos4sha.png

Egur Intel Scaler error (EVR)

http://img718.imageshack.us/img718/9799/evregurintelscaler.png

though its definitely also visible that yours sharper :)

Again this shiffting though it looks correct as more data of the frame is actually visible Have to compare how Madvr stands against it) :D

Egur = http://img830.imageshack.us/img830/9624/egurintelscaler.png
Jan Lanczos4 = http://img545.imageshack.us/img545/6514/janslanczos4shader.png
Bicubic 1.0 = http://img192.imageshack.us/img192/3310/janbicubic10.png

Also it seems Jans Lanczos 4 is faulty or do i imagine just more sharpness in the Bicubic one ?

[!llus!on]

Hi to all,
can I ask about support for the new H264 profile Hi10P.
Is there any chance to offload at least the main h264 arithmetic from the CPU, because the new profile has 20-40% better compression and better video quality (10bit profile with ~30% better compression :) )

Here are some samples for testing:
http://www.nyaa.eu/?page=search&term=Hi10P&sort=2
http://coalgirls.wakku.to/?p=4465
picture samples:
http://blisswater.info/comparison/elephantsdream/

And some info about the new Hi10P (http://habrahabr.ru/blogs/mass_media/129099/)

[CruNcher]

@!llus!on
depending on how flexible that whole programmable part is it might be possible but no one knows that except intel, and their is a slim chance they will use this capability to integrate 10 bit support currently because they see no demand for it yet i would also like to see H.264 High Predictive 4:4:4 supported but that will also stay a Dream ;)
Though you would see chances for 10 bit if suddenly all Broadcasters would startup and implement it or 3D is outburned and their needs to be something new sold 10 bit would come close after 3D as you would need so much new Hardware it would be pretty good. Though don't expect it so soon there still needs to be a lot sold and some Anime Fans (0.00000000001 market) wont change that over night ;)

[nevcairiel]

I don't think the hardware is capable of 10-bit decoding, so the chance is basically zero. :p
Thats the draw-back of fixed function hardware, its designed for one task, and one task alone. But that task, it does at supreme speed.

[CruNcher]

Btw in case of SB if i get it right and Intels Scaler currently works only on EVR and not with EVR custom and subtitles only on EVR custom (DXVA) that would create a pretty bad situation as it seems not really efficient for SB user to use the current custom shaders and not be able to save that GPU load (which can be some amount of Shader Load depending on the Resize Shader) by letting Intels Hardware Scaler do the work and so also keep the better quality ;)

Though how the heck does Microsoft it in their Media Center then having closed captions for Broadcasts displayed, EVR (using the Hardware scaler) + DXVA (native) ?

I guess there must be a way to disable Custom Shader resizing on EVR Custom and let the Hardware scaler do its job instead while still maintaining DXVA, Subtitle and after Resizing PP Shader capabilities.
So i wonder if it would be possible to realize a "User Hardware Resizer instead of Shader" in MPC-HC EVR-Custom option, because im sure initially the idear was to replace the bad Hardware scaling (Billinear with Bicubic using Shader) though i guess slowly Hardware Resizer get on another Level and so this old believes are pretty outdated @ least for SB and Ivy Bridge user they will be forced to use something lower quality with less efficiency. :)

[nevcairiel]

I guess there must be a way to disable Custom Shader resizing on EVR Custom and let the Hardware scaler do its job instead while still maintaining DXVA, Subtitle and after Resizing PP Shader capabilities.

Just configure it to "Bilinear" in the MPC-HC Output screen, and not one of the PS2.0 options, that should ask the GPU to do the scaling.

[CruNcher]

Just configure it to "Bilinear" in the MPC-HC Output screen, and not one of the PS2.0 options, that should ask the GPU to do the scaling.

Would be nice if it would be that easy but nope doesn't work

see the result http://img171.imageshack.us/img171/4559/evrcustomcpu.png <- billinear

[egur]

Yes though it seems for some Intel systems 2559 works excellent for Video the case on my system (I5-2400 GT1 HD2000) and i didn't experience a wrong frame order playback yet. So it seems system dependent also (on which level dunno) maybe 32bit 64 bit difference or maybe MSDK replaced the buggy driver mfx library, lets wait and see what the next intel drivers changelog says (though if it only states a lucid virtu issue it's still mysterious) ;)

i think i found a issue with your scaler Egur, though hardly mathematically seen it isn't if someone creates a wrong size stream 400x265 and the decoder isn't padding it, such things happen ;)

lav video = http://img821.imageshack.us/img821/5746/greenlinescalinglavvide.png
ffdshow = http://img62.imageshack.us/img62/3374/ffdshowscalingok.png

interesting though how the lines are shifted especially the bottom line looks unusual compared to for example Jans Lanczos4 Shader which errors with only a greater thicker green line on the top :)

Jans Lanczos4 Shader error (EVR Custom)

http://img140.imageshack.us/img140/2241/evrcustomjanlanczos4sha.png

Egur Intel Scaler error (EVR)

http://img718.imageshack.us/img718/9799/evregurintelscaler.png

though its definitely also visible that yours sharper :)

Again this shiffting though it looks correct as more data of the frame is actually visible Have to compare how Madvr stands against it) :D

Egur = http://img830.imageshack.us/img830/9624/egurintelscaler.png
Jan Lanczos4 = http://img545.imageshack.us/img545/6514/janslanczos4shader.png
Bicubic 1.0 = http://img192.imageshack.us/img192/3310/janbicubic10.png

Also it seems Jans Lanczos 4 is faulty or do i imagine just more sharpness in the Bicubic one ?

Is the grey line at the bottom part of the video or a scaling artifact? It doesn't appear in all your samples that used EVR.

There's definitely a shift between the Intel scaler and the rest.
I've noticed this in a simulation I ran as well (I have the scaler implementation in SW). Try scaling a pattern image where the columns are white-black-white-black... (1 pixel wide).
Scaling such an image by 2x should:
* Show a nice sine pattern - looks identical across the screen.
* Even columns (0, 2, 4, ...) should have identical values to the source image.

[egur]

Hi to all,
can I ask about support for the new H264 profile Hi10P.
Is there any chance to offload at least the main h264 arithmetic from the CPU, because the new profile has 20-40% better compression and better video quality (10bit profile with ~30% better compression :) )

Here are some samples for testing:
http://www.nyaa.eu/?page=search&term=Hi10P&sort=2
http://coalgirls.wakku.to/?p=4465
picture samples:
http://blisswater.info/comparison/elephantsdream/

And some info about the new Hi10P (http://habrahabr.ru/blogs/mass_media/129099/)

Well, 10bit is not supported. I'm not familiar with the internals of the decoder so I don't know if partial acceleration is possible. 10bit has system wide implications (lots of SW changes) so it's probably not a small feature. The return on such a feature is small as 10bit is very rare. This might change of course when 10/12bit becomes more mainstream.

[egur]

Btw in case of SB if i get it right and Intels Scaler currently works only on EVR and not with EVR custom and subtitles only on EVR custom (DXVA) that would create a pretty bad situation as it seems not really efficient for SB user to use the current custom shaders and not be able to save that GPU load (which can be some amount of Shader Load depending on the Resize Shader) by letting Intels Hardware Scaler do the work and so also keep the better quality ;)

Though how the heck does Microsoft it in their Media Center then having closed captions for Broadcasts displayed, EVR (using the Hardware scaler) + DXVA (native) ?
...

I think subtitles are rendered into an image before EVR. EVR receives 2 raw video streams - video and subs and it blends them together to form the result image. That's the MS way of rendering subs. I don't know if the subs are scaled before or after it's blended with the video stream.

[JanWillem32]

Hello again! CruNcher pointed me here, and maybe I can be of use.
-The resizers in EVR CP are purely derived from either the bilinear texture sampler stage or the internal pixel shaders in the renderer (shared with VMR-9 r., Quicktime DX9 h., and RealMedia DX9 h.). In either way, only the shadercore is used for resizing. I can derive specific resizers from external DLL files, such as EVR.dll, but it will have to wait until the main renderer no longer requires the four external mixers and their handlers to manage the video input pin and other connections. Both the DirectX 9 and DirectX 11 renderers are ready, except for a custom mixer, so that's one of the main issues I have at the moment.
-When rendering in DirectX 9, all pixels are offset .5 pixel from their vertex position: http://msdn.microsoft.com/en-us/library/windows/desktop/bb219690%28v=vs.85%29.aspx .
(Note that there are much more efficient forms of vertex lists than the one stated in the summary. As long as it's clear that the X and Y vertex positions need to be offset by 0.5 pixel to the top left to align the top left pixel on [0, 0], it's fine. I can show a sample with more efficient vertex handling on request.)
-The base VMR-9 and EVR renderers allow up to 16 (as I remember) substreams to overlay the main video. For example, in MPC-HC, the OSD renderer sends a A8R8G8B8 texture. As long as the characteristics of the overlay texture are sent, the renderers will render it. It requires a palette index for 256-color P8 textures, or a YUV matrix identification for Y'CbCr textures for example. Resolution isn't a problem, all these textures are scaled independently before blending.

[CruNcher]

@Egur
thx for the explanation i guess that's also what most try currently to achieve os of MS
and yeah that 1 line most probably is a scaling artifact combined with the decoder

also something else another Dev integrated Intel GFX support :) http://www.youtube.com/watch?v=mhsNXaCHRd8

@JanWillem32

I see so the 5 pixels offset is a render issue of EVR-Custom and MadVR currently, good news on the replacement of that Render part i guessed it wouldn't be so easy :(
Did you also looked @ the Lanczos4 result it doesn't seem to reflect a 4 tap Lanczos ?

i pushed MadVR and Haali now against the Intel Scaler on this case (no deinterlacing progressive higher SIF lower SD , high quantization (Sorenson Spark) to HD :)

http://img854.imageshack.us/img854/9254/madvrbillinear.png <- Billinear
http://img31.imageshack.us/img31/3447/madvrbicubic75.png <- Bicubic 0.75
http://img846.imageshack.us/img846/5562/madvrlanczos4.png <- Lanczos 4 taps
http://img833.imageshack.us/img833/2834/madvrlanczos4linear.png <- Lanczos 4 taps (Linear)
http://img713.imageshack.us/img713/2964/madvrsoftcubic.png <- Softcubic 50% softness
http://img840.imageshack.us/img840/8785/madvrspline4.png <- Spline 4 taps
http://img718.imageshack.us/img718/6958/haali75.png <- Haali -0.75 (seems also to adjust a little different though you can compensate it with its settings if needed)

http://img830.imageshack.us/img830/9624/egurintelscaler.png <- Intel Hardware Scaler (definetly the sharpest of all)
http://img545.imageshack.us/img545/6514/janslanczos4shader.png <- Jan Lanczos 4 tap
http://img192.imageshack.us/img192/3310/janbicubic10.png <- Jan??? Bicubic 1.00

PS: Though the PC/TV Scale issue makes the results not really 100% comparable (though im sure compensating that wouldn't change much of the percepted sharpness difference) and in the End Intels Scaler is pretty good (Egurs) and can easily compete with MadVRs custom shaders (and keeps the correct position on EVR, doesn't kill visible data) :)

The Hardware Deinterlacer though shows weaknesses (left combing) compared to Yadiff, and that already in the first test

http://img839.imageshack.us/img839/771/intelscreenresult.png <- Intel
http://img16.imageshack.us/img16/9953/yadiffscreenresult.png <- Yadiff

Though to be also fair this is in a extreme High Motion Scene that's so fast over no Human would realize it in that spot anyways so for Realtime Playback its ok see the encodes, though a lot of frame by frame comparer would hate it however (no im not one of those crazy guys if my goal is Realtime Playback , i don't watch stuff in slowmo or frame by frame usually, and even my perception of things is good it's not that good) ;)

[JanWillem32]

Actually, the pictures comparing the renderers show what I expect them to look like. As far as I know, MadVR uses A16B16G16R16F textures, and you couldn't get EVR CP to work with anything but 8-bit textures. In terms of banding and handling contrast/color balance, it's quite visible.
The Haali renderer is well known to have the .5 pixel offset problem, EVR CP and MadVR properly compensate for it. This is also visible in the pictures. An overscan test of a single pixel border with large magnification factors can point out the problem more clearly. Some tests can be found here: http://www.w6rz.net/ .
As far as I know, the original bicubic shader set for VMR-9 (renderless) (or its predecessor, I'm not sure) was written by Haali. I only modified the resizer pixel shader set to allow more variants and load easier.

[CruNcher]

So you would also agree that Intels Scaler does upscaling in this case more efficient keeping more visible data alive ?

[egur]

@CruNcher one small correction. Lanczos4 is 8 tap. "4" is half the sampling window.

In the DI test there's a problem with the motion detection on Intel side (fingers) but the yadif mispredict the necklace. So the necklace is reconstructed better on the Intel DI. I don't see detail loss in the Intel DI. Looking at the right side of the girls shirt you can see better details in the Intel scaler.
BTW, I don't know your exact setup, but you should turn off any other enhancement (denoise, sharpen, etc.) so we can have apples to apples comparison.

[CruNcher]

its all of :)
yes you right the reconstruction looks more appropriate on the intel side if you see that its a plain surface when the lights hit it

[egur]

Version 0.25 beta is out with the following changes:
* Fixed handling of CCV1 streams (Haali splitter custom fourCC).
* Support for H264 AVI files.
* Optimized memory copy further. Removed ASM code. Code now uses intrinsic for both 32 and 64 bit as intrinsic code reached 32 bit efficiency.
* Code cosmetics.
* FFDShow rev4295

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

[ramicio]

Is this supposed to work with EVR CP or not? I can get it to work with everything else, but when I use EVR CP I just get black. Are there any specific settings I need to change to make it work with EVR CP?

[egur]

Is this supposed to work with EVR CP or not? I can get it to work with everything else, but when I use EVR CP I just get black. Are there any specific settings I need to change to make it work with EVR CP?

It works for me. Make sure NV12 output is enabled for best performence.

[DragonQ]

Version 0.25 beta is out with the following changes:
* Fixed handling of CCV1 streams (Haali splitter custom fourCC).
* Support for H264 AVI files.
* Optimized memory copy further. Removed ASM code. Code now uses intrinsic for both 32 and 64 bit as intrinsic code reached 32 bit efficiency.
* Code cosmetics.
* FFDShow rev4295

Download from SourceForge home page (http://sourceforge.net/projects/qsdecoder/)
Do you know when support for pre-Sandy Bridge Intel IGPs is going to be fixed?

[ramicio]

Everything defaults to NV12 color space. That was one of the first things I tried, switching between various output color spaces.

[nevcairiel]

Do you know when support for pre-Sandy Bridge Intel IGPs is going to be fixed?

I have been wondering about this.
Even when no compatible hardware is available, shouldn't it be capable of software emulation?
It looks like the getOK method your interface provides returns failure.

I wish i had such hardware around so i could test it.

[egur]

I have been wondering about this.
Even when no compatible hardware is available, shouldn't it be capable of software emulation?
It looks like the getOK method your interface provides returns failure.

I wish i had such hardware around so i could test it.

There's something wrong with the installer QS check added by clsid (tested ffdshow r4291). It fails on my 9400T (Penryn with gm45 chipset). The installer checks for a processor revision of 42 (from SysInfo). This might also fail on IvyBridge.
I'll inform clsid about the problem.

SW emulation is working if the Media SDK 2012 is installed (free). I just verified this.
BTW, The DLL shipped with the driver is doesn't contain all the code for SW emulation.
If you have a multi-GPU setup and want to test the SW fallback, connect the display to the dGPU and make sure the desktop is NOT extended to an iGPU socket. This will force the Media SDK to failback to SW emulation.

[nevcairiel]

I'm not using any installer checks, but just creating the decoder instance seems to fail on non-SNB CPUs. All i'm doing is calling your functions to check if its working, and get getOK function indicates failure. But, if i remember correctly, it used to work, so something must've changed.

[egur]

I'm not using any installer checks, but just creating the decoder instance seems to fail on non-SNB CPUs. All i'm doing is calling your functions to check if its working, and get getOK function indicates failure. But, if i remember correctly, it used to work, so something must've changed.

Ok, I see the failure, I'll report back when I've solved it.

Update:
I couldn't get the HW acceleration to work on my Penryn system. The Media SDK fails to initialize. Even updated the driver and nothing. I'm almost 100% sure it worked before.
At clsid's request I'll add a check function. It will return general support for HW acceleration and SW emulation.

Update2:
Done at r32

[CruNcher]

Ok here is another Deinterlace test thx to Didée for providing the test sequence :)

Intel = http://www.mediafire.com/?hibu8gbdluh81pn
Yadif = http://www.mediafire.com/?0180493ch5cc4ln

Really great result for Intel on this one, which imho weights also more then the motion failure it showed before as this is definitely a very perceptible case :)

[JanWillem32]

Egur, if I may ask a few questions...
Can I please see your performance data on the copy function and the time required for the surface lock operation to complete in the command before the copy? I'd like to know more about the characteristics of CPU<->GPU memory copy functions, such as GetRenderTargetData, D3DXLoadSurfaceFromSurface and locking types, such as yours.
In the body of the copy function, streaming load operations are used, but no streaming store operations. Why is that? In general, all texture data chunks are too large for the CPU cache to hold and only slow down writing the data with non-steaming store operations.
In my earlier tests for inline copy functions, I could not find any benefit from stacking multiple load operations before a store operation. I see that you've implemented 8-register and 16-register store loops. Could you show the performance differences with other copy loops you tried?
(my previous "copytest": http://www.mediafire.com/?ud2dpkfum6zgchx , 134 KB - x86, x64 and source code On request, I can show more functions in implementations like this.)
About the alignment test, does this function ever copy a texture from a point other than the first pixel? All DirectX surfaces and other types of buffers I've ever encountered were at least 16-byte aligned (some items are even 64-kilobyte aligned by default) at the base.
Lastly, as I see you're using _mm_sfence(), you might find __faststorefence() interesting: http://msdn.microsoft.com/en-us/library/t710k390.aspx .

[egur]

Egur, if I may ask a few questions...
Can I please see your performance data on the copy function and the time required for the surface lock operation to complete in the command before the copy? I'd like to know more about the characteristics of CPU<->GPU memory copy functions, such as GetRenderTargetData, D3DXLoadSurfaceFromSurface and locking types, such as yours.
In the body of the copy function, streaming load operations are used, but no streaming store operations. Why is that? In general, all texture data chunks are too large for the CPU cache to hold and only slow down writing the data with non-steaming store operations.
In my earlier tests for inline copy functions, I could not find any benefit from stacking multiple load operations before a store operation. I see that you've implemented 8-register and 16-register store loops. Could you show the performance differences with other copy loops you tried?
(my previous "copytest": http://www.mediafire.com/?ud2dpkfum6zgchx , 134 KB - x86, x64 and source code On request, I can show more functions in implementations like this.)
About the alignment test, does this function ever copy a texture from a point other than the first pixel? All DirectX surfaces and other types of buffers I've ever encountered were at least 16-byte aligned (some items are even 64-kilobyte aligned by default) at the base.
Lastly, as I see you're using _mm_sfence(), you might find __faststorefence() interesting: http://msdn.microsoft.com/en-us/library/t710k390.aspx .

Well, I did quite a few testing after consulting with both architecture and driver performance experts.
My function may not be the fastest for all platforms (and GPUs) - I didn't test other CPUs. The driver isn't doing anything better, I've used all the tricks they do.
GetRenderTargetData didn't work for me. don't know why.
I used D3D9 API for getting the address - pretty standard:

D3DLOCKED_RECT locked;
hr = pSurface->LockRect(&locked, NULL, D3DLOCK_READONLY | D3DLOCK_NOSYSLOCK);

I tried various other locking options. They either didn't work or had the same speed. Locking can be time consuming, that's why my code uses multithreading - decode in one thread (a worker thread) and copy in another. The DS decode thread is used mostly for synchronization.

The driver always returned a 64B (cache line) aligned address BTW. I did alignment and reminder checks for completeness.

_mm_sfence() is called only once so it's performance is meaningless. shaving less than a micro second won't change anything.

I always copy all the pixels in the surface. For most video sizes, it's 1:1. I did a few benchmarks and found out that it's not worth writing a separate function to copy lines or part of lines.
I just crop lines not needed in the output. That's why I copy Y and UV separately.

Here's a summary of the speedup tricks:
* Copy using 8 or 16 xmm registers using the method I used (via local variables). 16 registers give a very small performance boost. If you use _mm_stream_load_si128 to copy from source to target, MSVC will only use 2 xmm registers causing performance degradation.
* Source and target addresses page offsets (12lsb) must be different. CPU performs check that they don't overlap. Check is fastest with a 2K page offset. Allocate an extra 4K for the target buffer. I allocate the target buffer so I have control over this.
* Copy using 2 threads - each thread copies half. More than 2 threads didn't improve - only degraded performance. It's also a good idea to use 2 threads for system to system copy.
* Load before store - made a difference (1%). Forces MSVC to use more xmm registers.

You can look at my thread pool code. If you can improve it, let me know.

I don't have MB/s numbers as I did system tests using GraphStudioNext (high priority process). I used a 1080p clip with relatively low bitrate ~1.5mbps. In the benchmark ffdshow is copying the frame again to the renderer. ffdshow's copy method is not MT (yet).
For the clip I use, I get an average of ~835fps for 5000 frames for both 32 and 64 bit. This is far below the memory controllers speed, but again ffdshow is working, the GPU is decoding, etc. I didn't set up a pure copy benchmark environment before I fear that it might not reflect on real world performance.
BTW, I have relatively cheap memory DDR3@1333MHz.

[egur]

Driver v2622 is out on Intel's download page (http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Graphics&ProductLine=Processor+graphics&ProductProduct=2nd+Generation+Intel%C2%AE+Core%E2%84%A2+Processors+with+Intel%C2%AE+HD+Graphics+3000%2f2000&ProdId=3319&LineId=3310&FamilyId=39).

[STaRGaZeR]

Driver v2622 is out on Intel's download page (http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Graphics&ProductLine=Processor+graphics&ProductProduct=2nd+Generation+Intel%C2%AE+Core%E2%84%A2+Processors+with+Intel%C2%AE+HD+Graphics+3000%2f2000&ProdId=3319&LineId=3310&FamilyId=39).

Any noticeable improvements?

[CruNcher]

http://downloadmirror.intel.com/20843/eng/ReleaseNotes_GFX_64.htm

officially not a lot Quicksync stability improvements those are i think

[egur]

Any noticeable improvements?

WMV9 HW support. Works fast but has occasional corruption in several of my test clips. Weirdly slow seeks (maybe I can fix this).

@CruNcher
A driver after that (not public yet) fixes the notorious mc.ts clip. BTW this clip with Haali give me a bad frame rate. Haali is sending time stamps consistent with 40fps :rolleyes:

I didn't notice quality improvements in other clips.
I didn't benchmark anything yet.

[RBG]

WMV9 HW support.

Only WMV9 advanced profile.:(

[STaRGaZeR]

WMV9 HW support. Works fast but has occasional corruption in several of my test clips. Weirdly slow seeks (maybe I can fix this).

Argh, it also seems that some VC1 corruption is still there.

[nevcairiel]

Argh, it also seems that some VC1 corruption is still there.

As long as there is no new corruption.... :)
Eric said they are working on some WMV9/VC1 things, so i'm hopeful! ;)

[NikosD]

The most useful and right thing to do for Intel - regarding VC-1 - is to open it to all, by making a ModeVC1_VLD mode accessible to everyone and not only to Cyberlink and Arcsoft, in order to use other Video Player developers HW acceleration for VC-1 without using quicksync.dll and Intel's MSDK.

No offence for Eric and his great effort to build something useful, like QuickSync decoder (and to fix some things internally regarding Video support of Intel, as I understand)

[Xaurus]

hi egur,

I want to thank you for your excellent work. As I understand it you are probably able to answer this question:

Slightly off-topic, but does anyone know if it is possible to run the Intel 2000 IGP at the same time as a Nvidia 450 GTS?
I mean, connect the display to the 450 and just take the audio from the Intel 2000 IGP.

I've searched everywhere but I can't really find an answer.

[Blight]

btw, a bit old, but the reason why downloading drivers from windows update is a bad idea for display drivers is that often, these drivers are just bare-bones. Enough to get the OS working in the right resolution, but doesn't include every module the driver downloaded from the company's site might have.

In the WinXP days, I downloaded an nvidia driver that lacked Direct3D support from windows update, so I stopped trying and now go directly to the source.

[ramicio]

Yeah, I don't know why people rely on Windows Update like it's some holy grail. For motherboards and video cards, I usually download drivers right from the chip manufacturer, instead of the hardware-slapper-together.

[nevcairiel]

In the WinXP days, I downloaded an nvidia driver that lacked Direct3D support from windows update, so I stopped trying and now go directly to the source.

To be fair, Windows Update in Win7 is significantly different (and much better) then what WinXP had.

Nevertheless, getting the real driver from the official source is always better. I usually ignore this rule for stuff like network drivers or printer drivers, though =p

[HeadlessCow]

btw, a bit old, but the reason why downloading drivers from windows update is a bad idea for display drivers is that often, these drivers are just bare-bones. Enough to get the OS working in the right resolution, but doesn't include every module the driver downloaded from the company's site might have.


Nevertheless, getting the real driver from the official source is always better. I usually ignore this rule for stuff like network drivers or printer drivers, though =p

For video drivers this might be bad, but for printer drivers, the barebones version is so, very much better :) And hundreds of megabytes smaller!

[JanWillem32]

Thank you for your quick response, egur.Well, I did quite a few testing after consulting with both architecture and driver performance experts.
My function may not be the fastest for all platforms (and GPUs) - I didn't test other CPUs. The driver isn't doing anything better, I've used all the tricks they do.
GetRenderTargetData didn't work for me. don't know why.It's not well documented, but I believe the restrictions are pretty much the same as StretchRect: http://msdn.microsoft.com/en-us/library/windows/desktop/bb174471%28v=vs.85%29.aspx .
Locking a surface that isn't in the asynchronous command cue for renderer device tasks isn't very expensive indeed. The performance cost for allocating a lockable render target is probably low as well. (Standard render targets and render target surface levels of a texture are not lockable by default.)I used D3D9 API for getting the address - pretty standard:

D3DLOCKED_RECT locked;
hr = pSurface->LockRect(&locked, NULL, D3DLOCK_READONLY | D3DLOCK_NOSYSLOCK);

I tried various other locking options. They either didn't work or had the same speed. Locking can be time consuming, that's why my code uses multithreading - decode in one thread (a worker thread) and copy in another. The DS decode thread is used mostly for synchronization.There are no magic methods to get locking cheaper. Locking an offscreen plain surface might aquire a lock a bit faster, but that's mostly because it can't be re-used in a rendering chain. The D3DLOCK_NOSYSLOCK flag is unused since Windows 2000: http://msdn.microsoft.com/en-us/library/windows/desktop/ee416788%28v=vs.85%29.aspx . Windows 95 and 98 had 16-bit system parts that were problematic with locking.The driver always returned a 64B (cache line) aligned address BTW. I did alignment and reminder checks for completeness.Shouldn't that code go into a DEBUG_ONLY sequence or something similar then?_mm_sfence() is called only once so it's performance is meaningless. shaving less than a micro second won't change anything.

I always copy all the pixels in the surface. For most video sizes, it's 1:1. I did a few benchmarks and found out that it's not worth writing a separate function to copy lines or part of lines.
I just crop lines not needed in the output. That's why I copy Y and UV separately.Are you sure it's separated Y and UV? In an NV12 texture, the Y plane takes 2/3 and the UV plane takes 1/3 of the total memory. Isn't it more efficient to distribute the load so that each thread takes 50%?Here's a summary of the speedup tricks:
* Copy using 8 or 16 xmm registers using the method I used (via local variables). 16 registers give a very small performance boost.I've taken a look at the assembly MSVC generates, and found out that the assembly generates fine for 1- to 16-register loops. The only thing I did see, is that a loop of 5 registers or more takes more than 64 bytes of instruction code, and isn't aligned on a 64 byte boundary for that reason. (The loop for 4 registers takes 56 bytes and is cache line aligned.) In my tests, the loop of one load and one store is the most stable in its speed across a few tests. Larger loops are rarely faster, but sometimes are a lot slower. It could be that there's a generation gap in between the processors in my PCs and Sandy Bridge, though.If you use _mm_stream_load_si128 to copy from source to target, MSVC will only use 2 xmm registers causing performance degradation.I didn't exactly mean _mm_stream_load_si128 (movntdqa reg mem), but using _mm_stream_si128 (movntdq mem reg) instead of _mm_store_si128 (movdqa mem reg). In my tests (256 MB memory copy), the version with non-temporal stores is 53% faster.* Source and target addresses page offsets (12lsb) must be different. CPU performs check that they don't overlap. Check is fastest with a 2K page offset. Allocate an extra 4K for the target buffer. I allocate the target buffer so I have control over this.
* Copy using 2 threads - each thread copies half. More than 2 threads didn't improve - only degraded performance. It's also a good idea to use 2 threads for system to system copy.
* Load before store - made a difference (1%). Forces MSVC to use more xmm registers.

You can look at my thread pool code. If you can improve it, let me know.Thank you for the information, I'll try some more optimizations and let you know if I find something interesting.I don't have MB/s numbers as I did system tests using GraphStudioNext (high priority process). I used a 1080p clip with relatively low bitrate ~1.5mbps. In the benchmark ffdshow is copying the frame again to the renderer. ffdshow's copy method is not MT (yet).
For the clip I use, I get an average of ~835fps for 5000 frames for both 32 and 64 bit. This is far below the memory controllers speed, but again ffdshow is working, the GPU is decoding, etc. I didn't set up a pure copy benchmark environment before I fear that it might not reflect on real world performance.
BTW, I have relatively cheap memory DDR3@1333MHz.I generally just insert _ReadWriteBarrier(), _mm_mfence(), and such to order data in a certain section, and then use QueryPerformanceCounter() at the beginning and end to profile that section. I do avoid unnecessary calls to QueryPerformanceCounter() in release builds that are not used for profiling, as the kernel round-trip it uses is slow.

[nevcairiel]

In my tests, the loop of one load and one store is the most stable in its speed across a few tests. Larger loops are rarely faster, but sometimes are a lot slower.

When using streaming loads (movntdqa), you need to process a multiple of 4 loads at a time to fully exhaust the 64B streaming cache line(s). If you start mixing it with writes, it'll degrade performance.
Note that movntdqa reverts to normal movdqa behaviour when you run it on "normal" memory (anything thats not USWC), so benchmarking it on a normal memory buffer is pointless and needs to be done on a GPU -> System copy.

I agree that Eric should look into using _mm_stream_si128, it might offer a speed enhancement still.

[STaRGaZeR]

As long as there is no new corruption.... :)
Eric said they are working on some WMV9/VC1 things, so i'm hopeful! ;)

When talking about drivers, I guess you could say that... :D

[nevcairiel]

When talking about drivers, I guess you could say that... :D

He also said a yet unreleased driver fixes "MC.ts", which is a VC-1 stream that caused errors before, so, yay? :)

[egur]

...
The D3DLOCK_NOSYSLOCK flag is unused since Windows 2000

It was hard to benchmark the locks and I'm not an expert in D3D as you :)
Thanks, I'll remove the D3DLOCK_NOSYSLOCK flag.

Shouldn't that code go into a DEBUG_ONLY sequence or something similar then?
No, better safe than sorry, it doesn't affect performance. People might copy-paste this function to somewhere else...

Are you sure it's separated Y and UV? In an NV12 texture, the Y plane takes 2/3 and the UV plane takes 1/3 of the total memory. Isn't it more efficient to distribute the load so that each thread takes 50%?
Y is copied using 2 threads (50-50) and then UV is copied in 2 threads (50-50).
My (pseudo) code looks like:

mt_gpu_memcpy(outFrame.y, inFrame.y, height * pitch);
mt_gpu_memcpy(outFrame.uv, inFrame.uv, pitch * height / 2);



I've taken a look at the assembly MSVC generates, and found out that the assembly generates fine for 1- to 16-register loops. The only thing I did see, is that a loop of 5 registers or more takes more than 64 bytes of instruction code, and isn't aligned on a 64 byte boundary for that reason. (The loop for 4 registers takes 56 bytes and is cache line aligned.) In my tests, the loop of one load and one store is the most stable in its speed across a few tests. Larger loops are rarely faster, but sometimes are a lot slower. It could be that there's a generation gap in between the processors in my PCs and Sandy Bridge, though.I didn't exactly mean _mm_stream_load_si128 (movntdqa reg mem), but using _mm_stream_si128 (movntdq mem reg) instead of _mm_store_si128 (movdqa mem reg). In my tests (256 MB memory copy), the version with non-temporal stores is 53% faster.Thank you for the information, I'll try some more optimizations and let you know if I find something interesting.

What I meant is using only _mm_stream_load_si128:

dest[i] = _mm_stream_load_si128(src + i + j); // copy line 8 times, replace j with 0, 1, 2, ...

The above code would only use two xmm registers inder MSVC. ICL 12 will use them all.
I didn't try using _mm_stream_si128. I'll check it out and report my findings.


I generally just insert _ReadWriteBarrier(), _mm_mfence(), and such to order data in a certain section, and then use QueryPerformanceCounter() at the beginning and end to profile that section. I do avoid unnecessary calls to QueryPerformanceCounter() in release builds that are not used for profiling, as the kernel round-trip it uses is slow.
That's all good and well, but I'm interested in system performance, so I look at fps in GraphStudioNext boosted to highest priority.
Synthetic benchmarks sometimes stray from the real world.

Update
Benchmarked the gpu_memcpy function using _mm_stream_si128 instead of _mm_store_si128. It was slower:
_mm_store_si128 (current code): avg 866fps
_mm_stream_si128 (new): avg 803

BTW, the 2622 driver is faster than the 2559 driver. The latter produced only 835fps.

Update2
I've managed to further optimize the copy function. fps is now 910 (was 866). The optimization was found by mistake and I don't know why it works faster. But it does. I'll build tomorrow for all to test. Checked in SVN at r34.

[STaRGaZeR]

He also said a yet unreleased driver fixes "MC.ts", which is a VC-1 stream that caused errors before, so, yay? :)

May I have that sample?

[nevcairiel]

May I have that sample?

http://www.mediafire.com/download.php?1uc5b42u55ue280
Field Interlaced VC-1 (one of the worse parts of the VC-1 spec)

[DragonQ]

When is interlaced VC-1 actually used? The only time I've ever seen VC-1 used at all is on BDs and most of those are 23.976p.

[nevcairiel]

Blu-rays use interlaced VC-1, mostly for documentaries or concerts.

[STaRGaZeR]

http://www.mediafire.com/download.php?1uc5b42u55ue280
Field Interlaced VC-1 (one of the worse parts of the VC-1 spec)

Thanks, the guy who made that sample sure knows how to motivate the driver team :D

[Thunderbolt8]

http://www.mediafire.com/download.php?1uc5b42u55ue280
Field Interlaced VC-1 (one of the worse parts of the VC-1 spec)that file runs fine and smooth for me with LAV video (albeit just barely as present queue indicates), but not with the MS Videdecoder DMO.

[CruNcher]

Thanks, the guy who made that sample sure knows how to motivate the driver team :D

It took Nvidia 1 Driver release to fix it just as a side note, seems it will be 2 for Intel ;)

[egur]

It took Nvidia 1 Driver release to fix it just as a side note, seems it will be 2 for Intel ;)

Reading Nev's thread on LAV filters, show that Nvidia latest drivers are quite broken with respect to video and I had issues getting my AMD 6950 to play vc1. At least with the Intel driver the improvements are slow but monotone.

[nevcairiel]

I should test if Intels drivers still BSODs when i install my system in UEFI mode...
Nothing is ever perfect. :p

[NikosD]

All interlaced content (MPEG-2, H.264, VC-1) plays like progressive on ATi's HD 5000 series hardware/drivers using PotPlayer for the last many months (and HW accelerated of course)

What's so special about MC.ts anyway ?
Many extras in Blu-ray discs are encoded that way.
Like 300 for example.

[CruNcher]

Reading Nev's thread on LAV filters, show that Nvidia latest drivers are quite broken with respect to video and I had issues getting my AMD 6950 to play vc1. At least with the Intel driver the improvements are slow but monotone.

Im already fascinated by the Quality, btw does in the CE4150 series (Sodaville) anything of these implementations being used as well or is it completely different ? :)
It seems at least the Decoder Core is not from Intel but 3rd party licensed IP from PowerVR since the Atom http://www.youtube.com/watch?v=LzEgd1rF6Ps
so i really wonder if the next CE will use the new Intel Decoder and implementations around it (Scaler,Deinterlacer) as well :) ?

[egur]

Im already fascinated by the Quality, btw does in the CE4150 series (Sodaville) anything of these implementations being used as well or is it completely different ? :)
It seems at least the Decoder Core is not from Intel but 3rd party licensed IP from PowerVR since the Atom http://www.youtube.com/watch?v=LzEgd1rF6Ps
so i really wonder if the next CE will use the new Intel Decoder and implementations around it (Scaler,Deinterlacer) as well :) ?

the Atom family have a different GPU altogether (I think PowerVR) and a completely different and simpler core. Atoms are not scaled down versions of SandyBridge. It's probably impossible or at least not practical to have the same architecture and process span 1-150 Watts.

[CruNcher]

But a lot of improvements that where made on Atom (Power Consumption) have been ported to SB (SB in idle behaves according to Intels tools like a Atom @ full utilization, coincidence maybe ;)) :) so i guessed it would also work the other way ;) seeing tri gates coming which surely also the new CE generation is gonna share upon :)
Also the Scaler and Deinterlacer are fixed function as you said and the Decoder IP too the question is just how does CE4100s Scaler,Deinterlacer compare to the current fixed function SB and coming Ivy Bridge implementations, and are we seeing here a move away from PowerVR IP over the long run and unifying the CE Series with Intels IP, also seeing that you now have your own Video Codec research back again which becomes really interesting since the Indeo IP was sold ;)

[egur]

But a lot of improvements that where made on Atom (Power Consumption) have been ported to SB :)
I don't think this is accurate at all :)

[egur]

Version 0.26 beta is out with the following changes:
* Added option to disable SW decoding when HW can’t decode. Default is not to decode in SW.
* Even faster memory copy function
* FFDShow rev4313

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

[egur]

I ran a quick benchmark on my new HTPC:
i7-2600K, 3.8GHz, DDR3 6-8-6@1600. Windows 7 64 bit. 32 bit playback using LAV splitter and my latest build (0.26). GraphStudioNext.
Low bitrate H264 test clip.
Tried 2 memory speeds:
* BIOS default: 1333 - 905fps (about the same as my dev PC)
* XMP profile: 1600 6-8-6 timing - 1030fps.

So for the performance lovers, you can scale performance with memory speed by buying a slightly more expensive memory.

Changing the GPU clock (1350->1500) didn't change anything in this test. It might, on high bitrate clips. I'll ran a few more clips and test.

[nevcairiel]

Someone over at AVS Forum already established that higher memory frequency has quite a significant impact on performance on the IGP when using madVR, for example.
I guess its a two fold process, faster download of the frames, and also faster upload. Additionally, the memory is also used as GPU memory, so any processing will also be faster.

Considering IVB will bump up the default to 1600, i'll probably aim for 1833 or even 2133.

[egur]

Someone over at AVS Forum already established that higher memory frequency has quite a significant impact on performance on the IGP when using madVR, for example.
I guess its a two fold process, faster download of the frames, and also faster upload. Additionally, the memory is also used as GPU memory, so any processing will also be faster.

Considering IVB will bump up the default to 1600, i'll probably aim for 1833 or even 2133.

It's one of the only reason to buy fast memory - better iGPU utilization. In non-GPU benchmarks fast memory has very little impact, usually no impact.

Even today you can buy very fast memory but it will cost you a significant premium over the basic RAM.
SandyBridge's memory controller can handle 2133 of course - otherwise no one would buy this RAM.
The board manufacturer has to design a board that can handle these high speeds robustly. This comes at a price of course.
Benchmarks aside, is fast memory a must for building an HTPC?
If you use RAM that operates on standard voltage and delivers better bandwidth, than the CPU will spend less time in elevated power states and save power. E.g. it will have more time to doze off and save power.
The sweet spot these days is 1600, because its price premium is small and it works 20% faster.
Future memory technologies (DDR3L, LP-DDR3, DDR4, ...) will use less power (less voltage) and provide same or better bandwidth helping to make the HTPCs smaller and quieter and probably cheaper too.

[ajp_anton]

I just bought some cheap "ValueRAM" at 1333MHz, overclocked it to 1600 and undervolted to 1.27V =).

[egur]

I just bought some cheap "ValueRAM" at 1333MHz, overclocked it to 1600 and undervolted to 1.27V =).

It works stable at 1.27V? Impressive.
Maybe this tweaking can be done automatically by the BIOS and save power...

[DragonQ]

Which kinda makes you wonder...is it worth spending more money on faster RAM just to utilise the IGP when you could get cheaper RAM and a stand-alone GPU (in a desktop anyway)?

[nevcairiel]

I would rather buy both, but i would also never try to save on a PC on the wrong ends. :p

[CruNcher]

i would rather use ARM or Atom (though not the consumer Atom stuff industry or CE ;) ) for a HTPC or Sandy or Ivy Bridge Mobile versions :)

[ajp_anton]

It works stable at 1.27V? Impressive.
Maybe this tweaking can be done automatically by the BIOS and save power...I was as surprised as you. Actually, it was stable at 1.23V for half a year, but then I got a random BSOD. Don't know what caused it, but the RAM felt most likely so I upped it to 1.27V.
So now its voltage is the same as my CPU =).

[RBG]

I just bought some cheap "ValueRAM" at 1333MHz, overclocked it to 1600 and undervolted to 1.27V =).

And what's the point in lowering ram voltage? That will only reduce your stability with no actual benefits....

[ryrynz]

It reduces heat, power consumption and improves product longevity. It's not THAT important unless you just love to tweak.

[ajp_anton]

It's not THAT important unless you just love to tweak.Haha, it's mostly this =). Two 4GB DIMMs probably won't use much power compared to the overclocked 2600k in the system.
But I was just making the point that noone should be running slow memory. 1600MHz doesn't seem to be a problem for even the cheapest RAM out there.

[RBG]

It reduces heat, power consumption and improves product longevity. It's not THAT important unless you just love to tweak.

To tell you the truth it is TOTALLY not important unless you're running a hpc with terrabytes of ram. ;) On an ordinary computer from undervoltaging your ram you'll benefit up to 1 watt during idle and up to 3 watt at peak, compared to the overall system power consumption this value looks not worthy of note. Heat output is not a problem too. And I don't think that you'll get significant longevity increase by lowering ram voltage, but you'll get stability problems for sure. From my experience I even doubt that ajp_anton's system is really stable if only there wasn't used some kind of LoVo DDR3.:rolleyes:

[ryrynz]

They're pretty insignificant for sure but you did ask the question :) it's mostly OCD regarding getting the most out of your components.

Regarding stability if it's stable for his needs, it's stable. Some go the whole nine yards to test rock solid stability and some don't, let's avoid turning this into an overclocking thread hmm? ;)
Watch this space for more QuickSync magic!

[RBG]

They're pretty insignificant for sure but you did ask the question :)

It was a rhetorical question. :p

Regarding stability if it's stable for his needs, it's stable.


Tertium non datur. You either have stable ram or you have not.;)

[ajp_anton]

Everything is unstable. The question is what the "half time"-equivalent of your system is. Out-of-the-box it's probably in the order of millions of years, so it's practically stable.
Having it running 24/7 for 6 months before a BSOD, with lots of video compression and Avisynth scripts filling 90% of my RAM, it's stable enough for me. After this I upped the voltage just a bit, so now it should be even more stable, *if* the BSOD was even caused by the RAM and not the OC'd CPU. Either way I don't care. I couldn't live with a computer I didn't tweak to death.

---

Random question that may or may not be off-topic: =)
Can for example x264 create lossless streams that are compatible with QS? Like, skipping the non-compatible but efficient lossless algorithms, and instead just through enough bitrate at it to make it lossless?
Would be useful for intermediate files between heavy Avisynth scripts if they were really fast to decode in hardware.

[nevcairiel]

No matter how much bitrate you throw at it, it'll never be truely "lossless", however you can probably make it "visually lossless" to some degree.

[egur]

...
Random question that may or may not be off-topic: =)
Can for example x264 create lossless streams that are compatible with QS? Like, skipping the non-compatible but efficient lossless algorithms, and instead just through enough bitrate at it to make it lossless?
Would be useful for intermediate files between heavy Avisynth scripts if they were really fast to decode in hardware.

My guess is that if you make the intermediate clip all I-frames with super high bitrate (50+ mbps) it will be fast and with excellent quality.

[RBG]

Everything is unstable. The question is what the "half time"-equivalent of your system is. Out-of-the-box it's probably in the order of millions of years, so it's practically stable.


You are moving the topic to philosophical matter, and I think that is wrong. Mostly all hardware parts in you PC are covered by manufacturer's warranty and that means that during that period of time your hardware unit will work properly and will be stable, of course as long as you follow manufacturer's service instructions, otherwise it will be replaced or you''ll receive a money refund. So there is no third option here, either it is stable or it is not.


Either way I don't care. I couldn't live with a computer I didn't tweak to death.

Well it is your choice, though I strongly recommend you to do proper ram testing, pure read/write series of test patterns and the same under full psu load.

[CruNcher]

@ Egur

Intels PP doesn't seem to work with Adobes Flash Player (Custom Direct3D Renderer) ?

AMD has i think a special option for it in their Controll Panel

http://oi40.tinypic.com/aavgg4.jpg

[egur]

@CruNcher,
Didn't check it, but it should be enabled via Adobe (in my opinion) and not forced by the driver.

[DragonQ]

Eww @ all that post-processing. That's what makes many modern TVs look so bad.

[CruNcher]

Ehh depends on the TV some use very good research up to the point of Super Resolution in Hardware ;)
though it's not easy to find out what for a technology (algorithm) works in the background and most marketing is like crazy encryption ;)
Samsung for example likes to work together with MSU(Yuvsoft) http://compression.ru/video/resampling/index_en.html on their TV PP research though it's not easy to find out in which actual product these things are being used in the end ;)

PS:
Can't wait to see MSUs GPU Encoder compare will be interesting to see if Intel can keep on with the good result of SB with Ivy (better performance is clear, but will it be still @ the top of Quality ;) ) and if Nvidia improved their Encoder and what AMD now reaches with the Motion Estimation improvements for the Encoding part :)

[egur]

Eww @ all that post-processing. That's what makes many modern TVs look so bad.

Mine looks great and much better then my previous (6 years old) that was one of the best at the time. You need to tune it and definitely not max out the enhancements. For PC display, you should turn practically all enhancements off.

[CruNcher]

@Egur
What is the difference between ILK = ??? and SNB = SandyBridge ? binaries like libmfxhw[bit]-i1/s1.dll ?

[egur]

@Egur
What is the difference between ILK = ??? and SNB = SandyBridge ? binaries like libmfxhw[bit]-i1/s1.dll ?

ILK is IronLake - the code name for Westmere's chipset (or integrated north bridge, don't remember),
The difference between the various Media SDK DLLs is the API they support. The newer the API, more features are supported.
I use MSDK API 1.1 which correlates to SNB. I don't have a Westmere (32nm i3/5/7 Core Processor) so I'm not sure what API it supports - probably API 1.0.
IvyBridge's driver has a similar DLL (libmfxhw32-i2.dll). It supports API version 1.3 (same as the latest MSDK 2012 version). The latter DLL does not work with SNB.

[ajp_anton]

Westmere was weird. At least on desktop, don't know about mobile. i5 existed only as overpriced dual-cores with no real advantage over i3, and i7 only existed as the hex-core on LGA1366 (no iGPU).

[CruNcher]

@ Egur

https://forum.doom9.org/showpost.php?p=1557962&postcount=9048

is this correct FFdshow Quicksync and Lav Video Quicksync both doesn't reach yet Intels own Reference implementation Efficiency ?
which according to these benchmarks is ~2 higher then Mainconcepts Decoder Core running on the CPU alone and lowering the CPU utilization @ the same time by over 50% or does the Intel Decoder switch between DXVA and Quicksync depending where it renders to (that would be actually very smart) ?

ILK is IronLake - the code name for Westmere's chipset (or integrated north bridge, don't remember),
The difference between the various Media SDK DLLs is the API they support. The newer the API, more features are supported.
I use MSDK API 1.1 which correlates to SNB. I don't have a Westmere (32nm i3/5/7 Core Processor) so I'm not sure what API it supports - probably API 1.0.
IvyBridge's driver has a similar DLL (libmfxhw32-i2.dll). It supports API version 1.3 (same as the latest MSDK 2012 version). The latter DLL does not work with SNB.

This opens another question general improvements done in newer APIs (non really hardware dependent, bugfixes, quality improvements,performance improvements) will be backported between the Driver or stay new API exclusive so you not going the same way as Nvidia i guess with their UDA ?
As you say Ivy Bridge will have it's own Driver Mfx components not backward compatible with SNB ?

[egur]

@ Egur

https://forum.doom9.org/showpost.php?p=1557962&postcount=9048

is this correct FFdshow Quicksync and Lav Video Quicksync both doesn't reach yet Intels own Reference implementation Efficiency ?

I use similar code as the the Media SDK sample. The performance differences are that the sample will work in pure DXVA and my code (within ffdshow or LAV) will cause the frames to copied at least twice: GPU->CPU, CPU->Renderer's sample. In high bitrates I can achieve similar performance.

v0.27 performance will be much better on high bitrate clips BTW. It seems I can't optimize for both low and high bitrates and the latter are more important.
Who cares if a clip plays at 1000fps or 1100 fps when a high bitrate clip can play at 270fps instead of 160 (real numbers BTW)?

This opens another question general improvements done in newer APIs (non really hardware dependent, bugfixes, quality improvements,performance improvements) will be backported between the Driver or stay new API exclusive so you not going the same way as Nvidia i guess with their UDA ?
As you say Ivy Bridge will have it's own Driver Mfx components not backward compatible with SNB ?
The same DLL is able to support several API levels. e.g. SandyBridge's HW DLL can support MSDK API 1.1 and 1.0.
An API is basically a collection of functions, types and constants. An API may change during alpha/beta stage but doesn't after it's released.
The actual implementation of an API can change over and over as long as the documented functionality of the API stays the same.

IvyBridge driver (API 1.3) should run all code built with API 1.1 and 1.0. If it doesn't, then it's a bug.
Actual usage is quite simple. During initialization, my decoder asks the MSDK for a minimum API level. The MSDK searches for the HW DLL and returns success if the API is the same or higher than what I requested.
When I'll add features specific to IvyBridge (or future products), these features will be enabled/disabled at runtime depending on the API level.

[CruNcher]

@Egur

the Mpeg-2 result differences (Performance) i (hopefully) carefully benched seem pretty huge

Lav Video Quicksync:

http://img221.imageshack.us/img221/1778/lavvideoquicksync1.png

FFdshow Quicksync:

http://img513.imageshack.us/img513/2123/ffdshowquicksync1.png

Lav Video DXVA2

http://img826.imageshack.us/img826/6760/lavvideodxva2.png

Intel SDK Decoder Quicksync ? (pretty impressive)

http://img836.imageshack.us/img836/8784/intelmpeg2.png

Mainconcept CPU (Slices)

http://img198.imageshack.us/img198/7311/mainconceptmpeg2.png

Mainconcept CPU (Frames)

http://img819.imageshack.us/img819/7028/mainconceptmpeg2smpfram.png

[egur]

@Egur

the Mpeg-2 result differences i (hopefully) carefully benched seem pretty huge
...

You should wait with the compares until I release v0.27. I already reported a performance issue which I've already fixed. Just a few days... :)

[CruNcher]

You should wait with the compares until I release v0.27. I already reported a performance issue which I've already fixed. Just a few days... :)

Ok the ffdshow,lav video quicksync/dxva2 Kernel Peaking though looks strange compared to the Reference Decoder :)

[egur]

Version 0.27 beta is out with the following changes:
* Optimized code path to high performance on high bitrate clips.
* FFDShow rev4322

Downloads
* For the latest cutting edge FFDShow builds download my builds Intel QuickSync Decoder SourceForge home page (http://sourceforge.net/projects/qsdecoder/)
* FFDShow-tryout site (http://ffdshow-tryout.sourceforge.net/download.php)
* LAV Splitter builds (http://forum.doom9.org/showthread.php?t=156191)

[CruNcher]

@ Egur

this doesn't look good it looks even more bad then before now :(

now:

http://img7.imageshack.us/img7/8203/ffdshowquicksync027kern.png

before:

http://img513.imageshack.us/img513/2123/ffdshowquicksync1.png

intel reference:

http://img836.imageshack.us/img836/8784/intelmpeg2.png

[egur]

Do you mean the low CPU utilization, right?

Strange, doesn't reproduce on my machine on other clips. Also tried a high bitrate m2ts file. Splitter is LAV 0.46 in my case.
A CPU usage of 13% (e.g. 1 core at 100%) is a little low. Should be 23-30% on an 8 thread machine.

Can you share the clip?
Do you have similar issues with other clips?

[CruNcher]

Do you mean the low CPU utilization, right?

Strange, doesn't reproduce on my machine on other clips. Also tried a high bitrate m2ts file. Splitter is LAV 0.46 in my case.
A CPU usage of 13% (e.g. 1 core at 100%) is a little low. Should be 23-30% on an 8 thread machine.

Can you share the clip?
Do you have similar issues with other clips?

I mean the overall Performance of the Reference Quicksync Decoder cant be compared with ffdshow-quicksync @ least for Mpeg-2 in General it already fall into my eye when comparing vs DXVA and power consumption now i looked deeper and saw this Kernel Explosion of ffdshow-quicksync and Generally in Performance that's not a good Sign.

According to the data both use Quicksync i could have understood the difference with Interlaced due to the ffdshow overhead maybe (but even then this is pretty heavy, it remembers me of some heavy firefox problems with kernel Explosions) but this is progressive :(

I didn't looked deeper yet in the H.264 performance differences and overhead

http://img684.imageshack.us/img684/9558/performanceefficiencyin.png

[nevcairiel]

You cannot compare the reference decoder to Erics QuickSync, because the reference does not copy the data back from the GPU.
Also, MPEG-2 isn't a good format to benchmark, its decoding is too simple. Use H.264.

The memory copy from the GPU to the CPU is simply a kernel operation.

I do however agree that Eric seems to be "over optimizing" the thing. Find a state that works well and stop touching it, its fast enough. :P
I haven't tested 0.27 yet, so i cannot comment how well it works.

[CruNcher]

ah so it's Quicksync without copy back but not DXVA that explains a lot

http://img828.imageshack.us/img828/5999/intelmediacheckerquicks.png

i just used it to manipulate the surface on the EVr renderer in realtime with ffdshow as NV12 input and it works without any copy back fully accelerated

though for what specific reason we do use copy back again for Playback wasn't it initially subtitles or overlays in General this seems pretty outdated doesn't it (since Nt 6) ?

And i really wonder who uses Lav Video or ffdshow-quicksync for encoding ?

[egur]

Nev is right.
I'd like to further explain.
My decoder copies the frame from the GPU. ffdshow copies the frame again to the buffer supplied by the renderer.
This is because ffdshow performs various video processing algorithms on the first copy and converts it to the colorspace/format of the renderer on the second copy.
LAV decoder might do something similar.

The MSDK filter is very basic, it doesn't perform any video processing or format conversions so it's operation is much simpler. It's a simple example on how to use the MSDK within a DirectShow environment. Making it complex would render it less effective for developers...
Since it's a DirectShow filter, it can negotiate with the renderer so it will allocate the frame buffers instead of the renderer. For DXVA this is a must. I don't remember if it's done when it's not connected to a non-DXVA renderer.

The various MSDK decoder filters should have similar performance to a pure DXVA decoders.

In my opinion, working in a restrictive SW architecture like DXVA cripples and significantly complicates everything. This is one of the main reasons I started this project - abstract the HW and simplify things so everyone can use the HW acceleration. This comes at a small performance price as you've noticed. You can't have the cake and eat it ;)

[nevcairiel]

though for what specific reason we do use copy back again for Playback wasn't it initially subtitles or overlays in General this seems pretty outdated doesn't it (since Nt 6) ?

Why would i want to limit myself with silly DXVA restrictions when current QuickSync decoder still does 300+ fps in copy back mode?

After all, the important part is playback (at least for me), and if i can benchmark it at 300 fps, doing 24 fps in playback (or even 60 fps) is done at nearly no load at all.

[CruNcher]

Yes sure but even if you compare it to Lav Video DXVA2 Copy Back there are pretty big differences

and you doesn't push the kernel or cpu too that extreme and still reach better FPS and this is automatically also visible in load and Power Consumption comparing both side by side also if taken Lav Video Quicksync it looks the same.

Lav Video DXVA2 Copy Back

http://img826.imageshack.us/img826/6760/lavvideodxva2.png

FFdshow Quicksync Copy Back

http://img513.imageshack.us/img513/2123/ffdshowquicksync1.png

Lav Video Quicksync Copy Back

http://img221.imageshack.us/img221/1778/lavvideoquicksync1.png

and the only real DXVA problem are Reference Frames and if people dont accept the rule H.264 Profile setting i dunno to blame Microsoft for it i never experienced a problem with it in the wild except when Anime guys Encode stuff ;)

[egur]

Setup:
* GraphStudioNext, 10 passes, NULL renderer.
* 10 clips from http://forum.doom9.org/showthread.php?t=163110
* FFDShow rev4322 (QS 0.27) 32 bit.
* Windows 7 Ultimate 64 bit, Aero on.
* Intel driver: v2622.
* Lucid Virtu: not installed.
* CPU: i7-2600 (3.4GHz), power management on. HD 2000 (GT1) iGPU.
* DDR3 @1333MHz (nothing fancy)
* Score are lowest/avg/highest frame rates for the entire clip.
* Note - the min score is due to graph contruction time which affects short clip benchmarks. The most interesting results are the highest FPS as the median score is very close to them.
1.Twinpeaks1080p30fpsRef2-27Mbps.mov
279/323/340

2.Samsung.Demo.Oceanic.Life-1080p30fpsRef16-40Mbps.mkv
268/273/278

3.Basketball-1088p60fpsRef8-10Mbps.mkv
349/361/368

4.Girls.YoonYoon-1080p60fpsRef5-21Mbps.mkv
338/343/348

5.Birds_1080p60fpsReF2-30Mbps.mp4
316/324/332

6.Cat-1080p60fpsRef4-25Mbps.m2ts
324/323/332

7.Vortexx_1088p24fpsRef3-109Mpbs.mp4
114/129/131

8.Birds_1080p24fpsRef4-112Mbps.mkv
122/134/137

9.Ducks.Take.Off.1080p30fpsRef5-108Mbps.mkv
138/148/154

10.Crowd.Run.1080p25Ref4-116Mbps.mkv
109/121/125

[egur]

Yes sure but even if you compare it to Lav Video DXVA2 Copy Back there are pretty big differences

and you doesn't push the kernel or cpu too that extreme and still reach better FPS and this is automatically also visible in load and Power Consumption comparing both side by side also if taken Lav Video Quicksync it looks the same.

...
and the only real DXVA problem are Reference Frames and if people dont accept the rule H.264 Profile setting i dunno to blame Microsoft for it i never experienced a problem with it in the wild except when Anime guys Encode stuff ;)
With DXVA copy back you only do 1 copy not 2.

If both I and Nev change our code (not trivial on both sides and will dirty both our SW designs) we can cut down the extra copy or even work in pure DXVA (no copy). I think it's NOT worth the effort. If someone wants the pure DXVA route there are several alternatives.
Since memory bandwidth and HW decode performance is guaranteed to increase, the current solution is scalable to very high bit rate/ frame rate video.

[NikosD]

Setup:
* GraphStudioNext, 10 passes, NULL renderer.
* 10 clips from http://forum.doom9.org/showthread.php?t=163110
* FFDShow rev4322 (QS 0.27) 32 bit.
* Windows 7 Ultimate 64 bit, Aero on.
* Intel driver: v2622.
...
...
...
...

1.Twinpeaks1080p30fpsRef2-27Mbps.mov
279/323/340

2.Samsung.Demo.Oceanic.Life-1080p30fpsRef16-40Mbps.mkv
268/273/278

...
...
...

10.Crowd.Run.1080p25Ref4-116Mbps.mkv
109/121/125

Huge performance difference from my results, back then (http://forum.doom9.org/showthread.php?t=163110)

The benchmark tool is different and the QS HW works in different frequencies for Core i5-2400 vs Core i7-2600, but the advantage is more than clear.

Well done!

I do hope to see current generation QS HW (SandyBridge), to become capable in HW acceleration of 4K files, with the help of new drivers.

It's a pity to waste so fast and efficient resources to just 1080p.

I don't believe this is going to happen before IvyBridge.

But I do hope that such a large company as Intel, will not afraid of loosing sales of new products (Ivy) by upgrading the old ones (Sandy).

I believe the Intel's drivers team will give us an Easter egg when 4K capable Ivy's drivers will be released, supporting SNB as well for that feature.

:thanks: in advance

[CruNcher]

Did you looked into the new DXVA Checker
there are now 2 VLD ClearVideo Device entries for VC1 ?

ModeVC1_VLD_2_ClearVideo: DXVA2, 720x480 / 1280x720 / 1920x1080
ModeVC1_VLD_ClearVideo: DXVA2, 720x480 / 1280x720 / 1920x1080

also you can create your own Device with resolution now (not sure if you can workaround driver limitations that way but im currently trying if it has any effect) ;)

http://img208.imageshack.us/img208/922/devicecreationfailed.png

[egur]

Huge performance difference from my results, back then (http://forum.doom9.org/showthread.php?t=163110)

The benchmark tool is different and the QS HW works in different frequencies for Core i5-2400 vs Core i7-2600, but the advantage is more than clear.

Well done!

10x

...
But I do hope that such a large company as Intel, will not afraid of loosing sales of new products (Ivy) by upgrading the old ones (Sandy).
In my opinion, if people buy Sandybridge now and not wait for IvyBridge, Intel will probably make more money in the long run as that SandyBridge will become outdated faster than IvyBridge and that user will buy the next PC sooner.

[CruNcher]

@ Egur
hmm i just realized ffdshow-pp doesn't work with the Quicksync Decoder ?

it works with the Intel Reference Decoder + ffdshow (though their seems to be a bug somewhere pading line)

http://img46.imageshack.us/img46/9536/pprealtimesppintelrefer.png

[clsid]

PP only works for certain formats. It is simply skipped for H.264.

[CruNcher]

thats Mpeg-2, with Quicksync as Decoder i dont get SPP to work to pressure 1/4 of the consumption of cores completely :)
activating ffdshow-warpsharp also crashes though also on the surface with another decoder awarpsharp works
High Quality aWarpsharp crashes with Quicksync as Decoder works with another

[nevcairiel]

I did my own peformance series, and i'm kind of pleased that my results are higher then Erics. :D

* GraphStudioNext, 5 passes, NULL renderer, first result not used.
* 10 clips from http://forum.doom9.org/showthread.php?t=163110
* Windows 7 Professional 64 bit, Aero on.
* Intel driver: v2622, no Lucid Virtu
* CPU: i7-2600k (3.4GHz), power management on. HD 3000 (GT2) iGPU.
* DDR3 @1600Mhz
* All Scores are averages

https://docs.google.com/spreadsheet/ccc?key=0Ajo8vvjNtaZ5dC1abjBSeVlmcnZXSjYwampfamk3ZWc

Note that at these speeds any little activity on the PC can alter the scores, so difference of 1-2 FPS are negligible.
I'm happy to report that the speed has increased basically across the board with QS 0.27 (and the changes i did for yet unreleased LAV 0.47)

I'm still a bit confused by that Samsung clip, why does it behave to special.

[CruNcher]

People shouldn't concentrate on x264 bitstreams alone if im not wrong all of those 10 clips are x264 bitstreams ;)

@Nev
could you please post those results outside of Google Docs ;)

[nevcairiel]

People shouldn't concentrate on x264 bitstreams alone if im not wrong all of those 10 clips are x264 bitstreams ;)
H264 is the most complicated format of the three to decode, everything else is irrelevant and will most likely just run faster.
Its also the most popular format.

Also, no-one really came up with a good set of test samples for VC-1. :p


@Nev
could you please post those results outside of Google Docs ;)
Nope. :)

[wanezhiling]

A new driver 8.15.10.2626 (http://www.necacom.net/index.php?option=com_content&view=article&id=5931:intel-hd-graphics-i357-gen23-drivers-version-815102626&catid=56:intel&Itemid=82)

IVB seems to be supported.:p
http://i.imgur.com/cVxmd.png

[CruNcher]

ui a leak with a official release date in the readme ? :) ?

[wanezhiling]

:pI think so.

Good night for me.

[CruNcher]

could be no bootkit virus indeed ;)
http://server.zdnet.com.cn/server/2012/0214/2078751.shtml

http://www.station-drivers.com/page/intel%20graphics.htm ( i don't trust this other site ;))

[egur]

A new driver 8.15.10.2626 (http://www.necacom.net/index.php?option=com_content&view=article&id=5931:intel-hd-graphics-i357-gen23-drivers-version-815102626&catid=56:intel&Itemid=82)

IVB seems to be supported.:p
http://i.imgur.com/cVxmd.png

It's probably a leaked IVB driver. Will work on SNB. I personally tested with 2639 which is a little newer (also IVB driver).
Strange enough, the 2622 driver (SNB) which was available on Intel's website is not available anymore. Newest one is 2509. The 2559 driver which was available till recently is also gone.

[nevcairiel]

It's probably a leaked IVB driver. Will work on SNB. I personally tested with 2639 which is a little newer (also IVB driver).
Strange enough, the 2622 driver (SNB) which was available on Intel's website is not available anymore. Newest one is 2509. The 2559 driver which was available till recently is also gone.

The 2559 is still available when you look at one of their 6 series desktop boards.

Their driver policy is weird..

[CruNcher]

Yeah intels Driver releasing is weird again drivers gone that where official the 2nd time now, though that with the boards could be understandable in tested drivers for their specific bios (optimized the best way possible) :P

[egur]

The 2559 is still available when you look at one of their 6 series desktop boards.

Their driver policy is weird..

I looked at the main download center and couldn't find it.
The 2622 driver (and others) can be found here (http://drivers.softpedia.com/progDownload/Intel-HD-Graphics-Display-Driver-152254642622-for-Vista64-Windows-7-x64-Download-149821.html)
I downloaded it and it was identical to my copy.

[CruNcher]

i mean even if intel forgot some restriction or did put some in the newer driver concerning their PVP or a bug it would be pretty dumb to believe after a official driver release the driver is out of history (and do like it never existed) ;)
Such silent delete operations only make some people more suspicious whats going on Nvidia @ least learned to explain why they remove drivers (if the reasons are the truth or not isn't really important, just tell them something and don't just remove and forget official released driver) ;)

PS: I did several load tests now and i have to say Microsofts Mpeg-2 Decoder rocks in latency it seems heavily optimized for threaded frameworks :) intels reference decoder latency under pressure looks odd against it, though pretty much no other ISV can cope with it is so damn stable (despite the missing 4:2:2 support, and not so great benchmark results). Pressuring the cores and getting such low latency without any heavy render brake ups is just amazing http://img59.imageshack.us/img59/3185/microsoftmpeg2latency.png http://www.mediafire.com/?gbk85ypx7alv2bu (yup you don't imagine it it's still sync, and yep there are different low latency timers running simultaneously, not forgetting the capture task) though no Haiku http://vimeo.com/33197748 here ;)

@Egur

Only Intels Reference Decoder shows this issue with ffdshow (green line right into the content)

http://img46.imageshack.us/img46/9536/pprealtimesppintelrefer.png

Only Possible with Microsofts Decoder (Playback Performance) :(

http://www.mediafire.com/?nm948sww3lyhwt7

ahh no wait that is a surprise MPC-HCs Internal Mpeg-2 Decoder is also capable of those low latencies and performs even better with this presure and core distribution is also more sane :)

http://www.mediafire.com/?ipik22iyiumpyg5 (perfect)

[RBG]

CruNcher

I am just curious, why are you paying so much attention to mpeg-2, isn't it an outdated format?

[roytam1]

CruNcher

I am just curious, why are you paying so much attention to mpeg-2, isn't it an outdated format?

Don't you know MPEG-2 is used in digital video broadcasting standard?

[ryrynz]

A new driver 8.15.10.2626 (http://www.necacom.net/index.php?option=com_content&view=article&id=5931:intel-hd-graphics-i357-gen23-drivers-version-815102626&catid=56:intel&Itemid=82)
[/url]

Didn't work for me, my system does not meet the minimum requirements for whatever reason, also won't update manually, oh well.

[egur]

With the exception of testing purposes, I advise against installing unreleased drivers. Do this at your own risk.
They are aimed at ISVs and OEMs.

[CruNcher]

@Egur

It looks like Intels Mpeg-2 Reference Decoder is shifting chroma when connected to ffdshow-quicksync ?

[egur]

@Egur

It looks like Intels Mpeg-2 Reference Decoder is shifting chroma when connected to ffdshow-quicksync ?

Do you mean that ffdshow is shifting chroma? Then open a sighting in the ffdshow thread. If not, then I don't understand.

[CruNcher]

yes no it only happens with intels decoder though so far only for this stream, also this SPP restriction for Quicksync decoding is really odd :D

[egur]

yes no it only happens with intels decoder though so far only for this stream, also this SPP restriction for Quicksync decoding is really odd :D

Although my code started from the reference decoder, I used it for reference, I had to change things and add features to make it work like it works today.

Regarding ffdshow's lack of support for various video processing, it might be what clsid pointed out, that some algorithms do not support NV12 which is the native output of the QS decoder (or any other HW decoder for the matter).
I'll need to take a deeper look.

[RBG]

Don't you know MPEG-2 is used in digital video broadcasting standard?

H.264 is also used in DVB... It's not like I don't know the standards or asking a general question, it is just to sate my curiosity, since I myself see no reason in benchmarking MPEG-2, but that's just me, I wanted to know another point of view.;)

[TPoise]

As a mobile specific user, the lowest CPU usage (which should correspond to the lowest wattage/battery usage) is MOST important for me, as long as the decoder can do 1x realtime with no dropped frames. So if I had to decide between an LAV decoder that could do 13x at 50% cpu or a QuickSync-based decoder that could only do 12x at 13% CPU, then the choice is pretty clear for me.

So, why should the performance really matter when you're several magnitudes higher than realtime, other than just for optimization's sake? Transcoding? I haven't seen any transcoder out in the wild that uses QS for decoding.

[nevcairiel]

LAV has a QuickSync based decoder. :p
Optimizing the speed of course has advantages, if you can increase the top speed, you reduce resource usage on real-time speed, its just that simple.

Realtime playback of typical Blu-ray material is at around 2-3% CPU for me, and that includes audio decoding as well as all other components in playback. :) (that is with LAVs QuickSync, i bet ffdshow is the same)

[CruNcher]

As a mobile specific user, the lowest CPU usage (which should correspond to the lowest wattage/battery usage) is MOST important for me, as long as the decoder can do 1x realtime with no dropped frames. So if I had to decide between an LAV decoder that could do 13x at 50% cpu or a QuickSync-based decoder that could only do 12x at 13% CPU, then the choice is pretty clear for me.

So, why should the performance really matter when you're several magnitudes higher than realtime, other than just for optimization's sake? Transcoding? I haven't seen any transcoder out in the wild that uses QS for decoding.


Hehe the Chinese affiliate Devs aren't as fast as they where with Nvidia (Wondershare, Xilsoft and Co, there are far to many to list them all here and most are doughters of the big ones anyways and mostly all have ffmpeg violation in common) ;) for now you only have the top ISV products (Elemental,Cyberlink,Arcsoft,Corel,MainConcept SDK) :D or (semi)* top ISVs that support it (BIT,Movavi,Mirillis,CoreAVC) i guess new stuff like freemakes (Ellora Assets) DXVA copy back decoding will be pretty much the same way defunct as Nevs copy back decoder with Intel currently ;)
Hmm though i didn't tried the crash bitstream yet on freemake though i guess it will do like the others and crash and most H.264 bitstreams i guess will also most probably show heavy decoding issues ;)

*PS: Some of the semi top ISVs are in some places better then the TOP ISVs imho, though BIT is controversial as of its ffmpeg issue same as Movavi (i forgot their company name strange russian one) ;)

http://www.intel.com/content/www/us/en/architecture-and-technology/quick-sync-video/quick-sync-video-general.html

Also a lot of other software recently got Intel HD Graphic updates it looks pretty good for Intel support wise, something that AMD also could have had so easily but no they sleeped it out and now running with fusion after it :)

[hoborg]

Hi.
Can somebody share latest "IntelQuickSyncDecoder.dll"?
Or is there a simple way how i can extract it by myself from FFDshow.exe installer?

BTW, it is possible to share IntelQuickSyncDecoder.dll between LAV video decoder and FFDshow? Both decoders are using exactly the same name for this dll.

[egur]

Hi.
Can somebody share latest "IntelQuickSyncDecoder.dll"?
Or is there a simple way how i can extract it by myself from FFDshow.exe installer?

BTW, it is possible to share IntelQuickSyncDecoder.dll between LAV video decoder and FFDshow? Both decoders are using exactly the same name for this dll.

They usually have the same dll (right click on the DLL for version number). Sometimes LAV or ffdshow use a newer version until the other picks up. Currently both use 0.27.
You said it didn't install because your iGPU is disabled? So why do you need it? You can always run the installer again when do enable the iGPU. It won't change your settings.

[amtm]

CruNcher

I am just curious, why are you paying so much attention to mpeg-2, isn't it an outdated format?

Because it's still used widely in TV broadcasting and for DVDs (you know those optical discs that still outsell Blu-Ray by quite a large margin)?

H.264 is also used in DVB... It's not like I don't know the standards or asking a general question, it is just to sate my curiosity, since I myself see no reason in benchmarking MPEG-2, but that's just me, I wanted to know another point of view.;)

You ask why people want to benchmark a format that is still widely used for video? Because they have lots of videos in that format possibly?

[STaRGaZeR]

After all, the important part is playback (at least for me), and if i can benchmark it at 300 fps, doing 24 fps in playback (or even 60 fps) is done at nearly no load at all.

Maximum speed is important for seeking too. Seeking with ATI's DXVA can be a pain (max. is only ~2x playback speed), while it's fast as hell with QS or software.

[CruNcher]

@ Egur
That MFX driver thing is definitely not UDA style like im used to hehe
so you have different directories and the same size .dll that get installed but based on Hardware Detection in the installer :D so the driver will get pretty big over the time with always cloning the same components for different hardware revisions with haswell their will be 3 by then, though ILK is not in that driver release anymore

That leaked Driver also seems to have OpenCL 1.1 support :)

Though what is strange is that they're actually 2 different libmfxhw revisions for both platforms i wonder how the installer makes the decission which to copy in the common files folder for general application use and why 2 revisions i guess 1 of those 2 fixes the VC-1 interlaced decoding issue ;)

Current libmfxhw 18 Oct 2011

2.11.10.18
2.0.556.36397


New Driver libmfxhw 1 16 Dez 2011

3.11.12.16
3.0.253.38506

New Driver libmfxhw 2 19 Jan 2012

3.12.1.19
3.0.255.38772

both seem api version 1.03
the old one api version 1.01

[RBG]

Because it's still used widely in TV broadcasting and for DVDs (you know those optical discs that still outsell Blu-Ray by quite a large margin)?

So what? How do you think what percentage of people are using their PC for DVD playback? Compared to all that huge amount of sold DVD's they are absolute minority. And the idea of watching DTV on a computer sounds just ridiculous to me. :p


You ask why people want to benchmark a format that is still widely used for video?

Well, on PC it is not that widely used nowadays compared to h.264 or vc-1, moreover MPEG-2 itself is not a power hungry format, even an entry-level SB cpu can handle it easily without any kind of hardware accelerated decoding.

[CruNcher]

I got it (pretty windows standard actually) ;)
seems Asus as Vendor was not in the list i added my Subsys Hardware ID and the installer accepts it ;)

Jep seems to be a OEM ISV Driver

SLAOEMISV1/RBK/01-21-00 <- Software License Agreement OEM ISV

Voila installed ;)

http://img851.imageshack.us/img851/1314/leakdriverinstall.png

New Driver libmfxhw 2 19 Jan 2012

3.12.1.19
3.0.255.38772

was chosen by the installer


New Optimal 3D mode

http://img11.imageshack.us/img11/7656/optimal3dmode.png

could be something like Catalyst AI or some Optimization for Specific Engines (Games,Applications)

Design Order of the PP functions changed a bit

http://img195.imageshack.us/img195/363/designorder.png

2622 WPI :

http://img580.imageshack.us/img580/4057/2622.png

2626 WPI :

http://img836.imageshack.us/img836/8617/2626.png

GPU-Z still a no go

http://img27.imageshack.us/img27/1636/gpuzcapsviewer.png


Fixed as expected:

http://www.mediafire.com/?0ljab8afkp1jm47

[Mixer73]

So what? How do you think what percentage of people are using their PC for DVD playback? Compared to all that huge amount of sold DVD's they are absolute minority. And the idea of watching DTV on a computer sounds just ridiculous to me. :p

Maybe I'm wierd but I watch MPEG2 on my computer every day. We still have MPEG2 DVB-T broadcast and I have dual head so I can watch TV on one screen and do other stuff on the other inbetween watching. More comfortable than using a laptop on the couch.

Well, on PC it is not that widely used nowadays compared to h.264 or vc-1, moreover MPEG-2 itself is not a power hungry format, even an entry-level SB cpu can handle it easily without any kind of hardware accelerated decoding.

See above. However I get Nev's comment that MPEG2's simplicity makes it not the best tool for comparitive performance benchmarking. However its still a very important and oft-used format.

[NikosD]

@ Egur

That leaked Driver also seems to have OpenCL 1.1 support :)





GPU-Z still a no go

http://img27.imageshack.us/img27/1636/gpuzcapsviewer.png



I have told you before, but you didn't get it.

There is no such thing as HW OpenCL support for SandyBridge GPU.

It's only software support (CPU).

Did you actually test HW OpenCL support with the new driver ?

[ramicio]

I had to turn off "full floating point processing" in the renderer settings, and it works now.

[CruNcher]

I have told you before, but you didn't get it.

There is no such thing as HW OpenCL support for SandyBridge GPU.

It's only software support (CPU).

Did you actually test HW OpenCL support with the new driver ?

I said its OpenCL nothing more :) though it's anyway surprising don't you think that they provide the OpenCL support for the CPU with the GFX driver ;)

[NikosD]

OpenCL support was there from the beginning.

What is the change with the new driver ?

OpenCL usually is paired with GPU because it's a lot faster than CPU (for the specific tasks)

And because Ivy will support HW OpenCL 1.1, they probably put it in GPU drivers from the beginning.

As a matter of fact, where else could they put it ?

GPU is inside CPU.

CPU and GPU drivers, go together.

[CruNcher]

Going way to oftop

https://forum.doom9.org/showthread.php?p=1559021

[RBG]

We still have MPEG2 DVB-T broadcast and I have dual head so I can watch TV on one screen and do other stuff on the other inbetween watching.

I've got a hardware decoder for that stuff, and it is way better than a PC in terms of power consumption and reliability.;)


See above. However I get Nev's comment that MPEG2's simplicity makes it not the best tool for comparitive performance benchmarking. However its still a very important and oft-used format..

As for me, there should be more VC-1 testing, as it really requires hw acceleration more than other formats, mostly because it lacks decent software decoders.

[NikosD]

"According to Digitimes, a weak global economy has caused a build-up of Sandy Bridge inventory both at Intel and OEMs.

If Intel went ahead and mass released Ivy Bridge in April, these Sandy Bridge parts would have to be thrown away or sold at much lower prices.

Now the plan is to release some Ivy Bridge chips in April, but postpone mass shipments (presumably of consumer-oriented parts) until after June.

System builders should still be able to get their hands on some mid- and high-end Ivy Bridge chips in April."

[nevcairiel]

All that means is that the low to mid-end dual core chips will be delayed. I can still get me a quadcore to build my high-end HTPC. :D

[CruNcher]

Nah i wouldn't buy Ivy Bridge i'll wait for Haswell the amazement will be much heavier by then, even if its a big change having the first Tri Gate Processor but i want the even more advanced one not the first one :D ;)

Though since the first days i was always jumping forth and back from AMD/INTEL (with a short stay with Cyrix) and i guess not much will change and currently im in the INTEL stage again, though i want to see how Fusion Develops too and so i guess it could happen that the Next Bulldozer Generation is in between the Haswell shift ;)

[STaRGaZeR]

Eric, take a look at this post (http://forum.doom9.org/showpost.php?p=1559102&postcount=9154). Forcing nOutputQueueLength in the QS config to 8 seems to fix it, but maybe there's more to it, related to your recent changes.

EDIT: after some time there is stutter here and there even with 8, just like with 16 but sporadic.

[nevcairiel]

Hey Eric,

it seems like the QS decoder isn't particularly happy with H264 in Annex B format (MEDIASUBTYPE_H264). I've been trying to improve rtp/rtsp streaming, and i figured with such a volatile stream it might be beneficial to let the splitter keep it in its original form (which is H264 AnnexB), however when i feed that to your QS decoder through LAV Video, i get nothing (only black screen, it doesn't seem to output any decoded frame)
Any ideas? I can try to upload a test build that does this so you can try to reproduce.

[egur]

Eric, take a look at this post (http://forum.doom9.org/showpost.php?p=1559102&postcount=9154). Forcing nOutputQueueLength in the QS config to 8 seems to fix it, but maybe there's more to it, related to your recent changes.

EDIT: after some time there is stutter here and there even with 8, just like with 16 but sporadic.
I can't test live TV, but Nev's point on the high delay during playback affecting live TV makes sense. Long queues provide good performance and good frame rate calculations. The latter isn't important for LAV as he disables the feature.
In order to reduce latency in live playback, the queues need to be much shorter. Since my decoder doesn't know the context, maybe the fix should be in the DirectShow decoder filter (LAV, ffdshow).
@Nev, any suggestions?

Hey Eric,

it seems like the QS decoder isn't particularly happy with H264 in Annex B format (MEDIASUBTYPE_H264). I've been trying to improve rtp/rtsp streaming, and i figured with such a volatile stream it might be beneficial to let the splitter keep it in its original form (which is H264 AnnexB), however when i feed that to your QS decoder through LAV Video, i get nothing (only black screen, it doesn't seem to output any decoded frame)
Any ideas? I can try to upload a test build that does this so you can try to reproduce.
I have a single clip with this subtype (MEDIASUBTYPE_H264) so my testing so fat was limited (works fine BTW).
The HW decoder only accepts this sort of stream. For AVC1 I have to convert it to such a stream.
I can try to reproduce, sure. Please supply a problematic clip. I don't think I need a your build unless you change the stream somehow.
Also, does it work with another splitter (Haali)?

[nevcairiel]

The HW decoder only accepts this sort of stream. For AVC1 I have to convert it to such a stream.
I can try to reproduce, sure. Please supply a problematic clip. I don't think I need a your build unless you change the stream somehow.
Also, does it work with another splitter (Haali)?

Its a streaming source, i cannot make it into a clip (and Haali doesnt support streaming protocols)

[nevcairiel]

I can't test live TV, but Nev's point on the high delay during playback affecting live TV makes sense. Long queues provide good performance and good frame rate calculations. The latter isn't important for LAV as he disables the feature.
In order to reduce latency in live playback, the queues need to be much shorter. Since my decoder doesn't know the context, maybe the fix should be in the DirectShow decoder filter (LAV, ffdshow).
@Nev, any suggestions?

Well how do your queues work? Does it not output anything until they are full?
Is it maybe possible to decrease the delay without cutting into the performance so drastically? (Using queues at 0 is quite the performance impact right now)

Specifying a context would require somehow listing all sorts of TV applications, which would be an impossible task.

[egur]

Without being able to debug, I can't root cause the decode problem (H264 fourcc). If there's a streaming setup I can run using a web source and not a live TV source then please specify the full setup and I'll debug it.

Regarding queue length and performance, I'm not sure why lengthening the queues remove such a big bottleneck. It took me a couple of hours tweaking with v0.22 which had less features than 0.26 (0.22 didn't have async decode or mt copy). The only way I managed to keep 0.22's performance high is to always use queues, even if they are not needed in a functional way (no need to calc time stamps). Applying that to 0.26 with some other fine tuning created v0.27.
I'll try to further root cause the bottleneck and hopefully use shorter queues.

If all else fails, we can go the GPU driver way - use profiles (e.g. cheat :) ). High queues for benchmarks and low/zero queues for the rest.

[nevcairiel]

I don't really care for benchmark values, but higher speed also helps with transcoding tasks or simply with seeking. Granted, when seeking there is probably no big difference between 200 or 300 fps, as long as its quite a bit faster then realtime speed.

[egur]

I don't really care for benchmark values, but higher speed also helps with transcoding tasks or simply with seeking. Granted, when seeking there is probably no big difference between 200 or 300 fps, as long as its quite a bit faster then realtime speed.

Seeking speed is determined by how fast current decode is aborted and how how the first frame from the new segment is outputted. I can somewhat improve on the former (abort stage) and the latter should improve if not using queues (do less work before outputting a frame).
So if you don't care about benchmarks, just kill the queues via config or set them to a length of 1.
It might be possible for you to expose an interface to the player and have him set an option for live/offline playback. Maybe the various player writers can comment on this.

[nevcairiel]

Seeking speed is determined by how fast current decode is aborted and how how the first frame from the new segment is outputted.

How fast the first frame is outputted depends on decoding speed. Seeking usually does not end up on a keyframe exactly, which means you need to start decoding at the previous key-frame, and there can be quite alot of frames in between now and the last key frame. The faster you decode those "pre-roll" frames, the faster the seeking is done. That means that decoding speed is directly proportional to seeking speed.

@STaRGaZeR:
Can you test if buffers set to 0 runs flawless for you?
Maybe i can add a "low latency" checkbox that would trigger this (and possibly also activate it by default). Should probably benchmark the difference to decide if i turn it on by default.


Edit:
I finished benchmarking in "low latency" mode with Queue = 0
https://docs.google.com/spreadsheet/ccc?key=0Ajo8vvjNtaZ5dC1abjBSeVlmcnZXSjYwampfamk3ZWc

The results are odd. On some clips, i see increased speeds, other clips remain the same - only that weird Samsung clip is significantly slower (apparently it has 16 ref-frames)
Maybe that decision should be based on the number of refframes a clip has? :d

[egur]

How fast the first frame is outputted depends on decoding speed. Seeking usually does not end up on a keyframe exactly, which means you need to start decoding at the previous key-frame, and there can be quite alot of frames in between now and the last key frame. The faster you decode those "pre-roll" frames, the faster the seeking is done. That means that decoding speed is directly proportional to seeking speed.

@STaRGaZeR:
Can you test if buffers set to 0 runs flawless for you?
Maybe i can add a "low latency" checkbox that would trigger this (and possibly also activate it by default). Should probably benchmark the difference to decide if i turn it on by default.

Edit:
I finished benchmarking in "low latency" mode with Queue = 0
https://docs.google.com/spreadsheet/ccc?key=0Ajo8vvjNtaZ5dC1abjBSeVlmcnZXSjYwampfamk3ZWc

The results are odd. On some clips, i see increased speeds, other clips remain the same - only that weird Samsung clip is significantly slower (apparently it has 16 ref-frames)
Maybe that decision should be based on the number of refframes a clip has? :d

I'm using the Samsung clip for testing. When queue len is 0, it runs at single threaded speeds (aside from MT copying). Meaning some of the MT code is being serialized somehow. I'm working on it. My next release will also include some tweaks to abort decode faster. I'll report again when I have something useful.

Edit:
The decode speed shown in benchmarks show average decode speed across the entire length. When queue length is zero. The QS decoder will output the first frames ASAP. Otherwise it will queue 16 decoded frames and then start to output them. If the HW decoder has to work hard (very high bitrate), the seek time should be lower as it will not have to decode 15 extra frames.

For ffdshow, I must keep queues at least 8 long for proper time stamp correction...

[nevcairiel]

In the meantime, i build a check based on ref frames. MPEG2 and VC1 are limited to two ref frames, so they always get 0, and for H264 i parse the value from the SPS if its available and set the value accordingly.

[pururin]

Greetings Eric. I've got a Sandybridge since early 2011 (using microsoft decoder before and you don't know how much I'm happy when your decoder were born!)

There's a thing I'd like to ask.
In this sample: http://www.wupload.com/file/2651705652

around 0.46-0.47 sec when color goes black there are artifacts on the lower half of the screen.
This happens only when HW acceleration is active whether on any decoder I've used. When inactive the color is pure black as it should've been.
:thanks:

[NikosD]

Eric,

I'm not finished updating my page with benchmark results.
I just did the tests for my system (signature).

What is the best way to update an existing Intel driver ?

Override the old driver with the new one ?

Uninstall manually from Control Panel (or other program) the old driver and then install the new one ?

Automatically install from the on-line tool of Intel's site the new driver ?

I want to benchmark the Intel system with the new driver but I don't want to mess things up because the Intel system is not mine and with present driver v2559, it works very well.

[egur]

Eric,

...
What is the best way to update an existing Intel driver ?

Download the Intel driver from Intel's download center.
Here're links to v2622: 32 bit (http://api.viglink.com/api/click?format=go&key=fad87231d097b7ba2504b595a06d6249&loc=http%3A%2F%2Fwww.avsforum.com%2Favs-vb%2Fshowthread.php%3Ft%3D1303066%26page%3D70&v=1&libid=1329813926490&out=http%3A%2F%2Fdownloadcenter.intel.com%2FDetail_Desc.aspx%3Fagr%3DY%26ProdId%3D3231%26DwnldID%3D20840%26ProductFamily%3DGraphics%26ProductLine%3DDesktop%2Bgraphics%2Bcontrollers%26ProductProduct%3DIntel%25c2%25ae%2BHD%2BGraphics%26lang%3Deng&ref=http%3A%2F%2Fwww.avsforum.com%2Favs-vb%2Fshowthread.php%3Ft%3D1303066&title=Official%20Sandy%20Bridge%20%2F%20LGA1155%20for%20HTPCs%20Thread%20-%20Page%2070%20-%20AVS%20Forum&txt=32-bit&jsonp=vglnk_jsonp_13298141264473) 64 bit (http://api.viglink.com/api/click?format=go&key=fad87231d097b7ba2504b595a06d6249&loc=http%3A%2F%2Fwww.avsforum.com%2Favs-vb%2Fshowthread.php%3Ft%3D1303066%26page%3D70&v=1&libid=1329813926490&out=http%3A%2F%2Fdownloadcenter.intel.com%2FDetail_Desc.aspx%3Fagr%3DY%26ProdId%3D3231%26DwnldID%3D20842%26ProductFamily%3DGraphics%26ProductLine%3DDesktop%2Bgraphics%2Bcontrollers%26ProductProduct%3DIntel%25c2%25ae%2BHD%2BGraphics%26lang%3Deng&ref=http%3A%2F%2Fwww.avsforum.com%2Favs-vb%2Fshowthread.php%3Ft%3D1303066&title=Official%20Sandy%20Bridge%20%2F%20LGA1155%20for%20HTPCs%20Thread%20-%20Page%2070%20-%20AVS%20Forum&txt=64-bit&jsonp=vglnk_jsonp_13298141819224)

No need to uninstall. Just install, reboot, run benchmarks, reinstall old driver and tell installer to overwrite the new driver with the old.
I jumped back and forth with driver versions a few times without problems.

[egur]

Greetings Eric. I've got a Sandybridge since early 2011 (using microsoft decoder before and you don't know how much I'm happy when your decoder were born!)

There's a thing I'd like to ask.
In this sample: http://www.wupload.com/file/2651705652

around 0.46-0.47 sec when color goes black there are artifacts on the lower half of the screen.
This happens only when HW acceleration is active whether on any decoder I've used. When inactive the color is pure black as it should've been.
:thanks:

I'll take a look. Unfortunately decode errors occur from time to time. Hopefully a future driver will fix them. BTW, what splitter was used?

[pururin]

I tried with both haali and Lav splitter. Just now I happened to think up so I tested with other HW mode in Lav
and find that dxva2 got quite the same too, so I wonder if the problem is at lower level or maybe something about the clip it self?
(in software decoding mode all is fine though)

[CruNcher]

yep like the mysterious decodingerror.ts which btw wasn't fixed with the Driver update

[egur]

yep like the mysterious decodingerror.ts which btw wasn't fixed with the Driver update

Hi Cruncher, can you repost the url for the clip

[NikosD]

Eric,

I have finally completed my survey of HW and SW decoders at my thread for Intel and ATI HW.

The results are odd.

For clips 1 to 6 the new QS decoder 0.28, although is heavily optimized and multi-threaded, is A LOT SLOWER than QS 0.20 (more than 20%) for the FFDShow implementation.
LAV QS is faster, but not fast.

The same goes for VC-1 clip, too.

On the other hand FFDshow is very fast, even faster than native DXVA on clips 7 to 10.

Take a look here:
http://forum.doom9.org/showthread.php?t=163110

[egur]

Eric,

I have finally completed my survey of HW and SW decoders at my thread for Intel and ATI HW.

The results are odd.

For clips 1 to 6 the new QS decoder 0.28, although is heavily optimized and multi-threaded, is A LOT SLOWER than QS 0.20 (more than 20%) for the FFDShow implementation.
LAV QS is faster, but not fast.

The same goes for VC-1 clip, too.

On the other hand FFDshow is very fast, even faster than native DXVA on clips 7 to 10.

Take a look here:
http://forum.doom9.org/showthread.php?t=163110

Very odd indeed.
I don't use DXVAChecker for testing, only GraphStudioNext. Nev's benchmarks (https://docs.google.com/spreadsheet/ccc?key=0Ajo8vvjNtaZ5dC1abjBSeVlmcnZXSjYwampfamk3ZWc#gid=0) which are very similar to what I see at home has significantly better results.
I'll try running it today with DXVA checker.

Can other users run at least one of the benchmark's clips and report what they got?
Maybe the code is not optimal for the i3 processor (Nev and I have i7).

Also please change "QS LAV" to LAV, it's confusing.

Correction:
You used an i5 system, which should provide similar performance to my i7.

[CruNcher]

@ egur
you already have that stream anyway http://www.mediafire.com/?rld8gnlh52f03ud if you seek no problems if you let it play 1 frame will be corrupted on Quicksync nothing changed

[NikosD]

Also please change "QS LAV" to LAV, it's confusing.



QS-LAV-QS means QS HW video processor-LAV video decoder-QuickSync (QS) mode

[egur]

@NikosD
I ran a few tests at home and reproduced your results.
I don't know why the slowness in this scenario occurs or why ffdshow is a little faster.
What troubles me is that it doesn't work with at least one of the clips in LAV (basketball clip). In my PC it didn't crash, it was in some kind of infinite loop (taking a lot of CPU).
I ran DXVAChecker under a debugger and paused it during the freeze. LAV filter wasn't even loaded so the problem is somewhere within DXVAChecker.

It seems the copy back method used slows things down for the first 6 clips. For the remaining 4 clips, the decoder is slower than copying so there's no impact - they occur in parallel.
EVR also copies the image, so that's another overhead on top of the benchmarks in GraphStudioNext.

BTW, I removed the copy function call from my code and it didn't change the results that much (less than 3%) so something is definitely wrong here.

It seems that when EVR is present, the system is very sensitive to how many D3D9 surfaces I use within decoder. Less surface gives a performance boost.

[nevcairiel]

The first step should be to figure out which parts actually require more time when running with EVR. Somehow it seems odd that the decoder itself just runs that much slower just because EVR is loaded. Otherwise the same problem would occur if you just open a EVR while doing a GraphStudio benchmark, wouldn't it?
I can even watch a movie in one window (with EVR) and benchmark in another window, without any performance loss.

The odd thing is, DXVAChecker even runs slower when its EVR is running on my NVIDIA with QuickSync decoding on the IGP. This doesn't make sense.
I have some ideas that might explain this, but i need to investigate a bit when i'm back home before i can comment on those.

[ryrynz]

Nev, does it set to defaults? or perhaps keep previous settings? You could try removing the dGPU and try changing the setting then reinstalling it, I have a feeling it's probably setting defaults however.

[NikosD]

I've finished my benchmark survey.

All platforms included (ATI, Nvidia, Intel) and the main decoders:

Microsoft DirectShow,
Microsoft MediaFoundation,
LAV Video all modes (NVCUVID, QuickSync decoder, DXVA2 Copy-back, DXVA2 Native),
CoreAVC (NVCUVID, DXVA2),
FFDShow QuickSync decoder.

Results here:
http://forum.doom9.org/showthread.php?t=163110

[NikosD]

The first step should be to figure out which parts actually require more time when running with EVR. Somehow it seems odd that the decoder itself just runs that much slower just because EVR is loaded. Otherwise the same problem would occur if you just open a EVR while doing a GraphStudio benchmark, wouldn't it?
I can even watch a movie in one window (with EVR) and benchmark in another window, without any performance loss.

The odd thing is, DXVAChecker even runs slower when its EVR is running on my NVIDIA with QuickSync decoding on the IGP. This doesn't make sense.
I'm inclined to call tool failure. :p

Too bad GraphStudio can't benchmark with EVR, it has VSYNC enabled and tops out at 60fps :(

I have some more ideas that might explain this, but i need to investigate a bit when i'm back home before i can comment on those.

GraphStudioNext is missing a lot of benchmark informations.

It doesn't have GPU load, CPU load and most importart it doesn't have min and max values for FPS counting.

It displays only Avg values for FPS.

The benchmark mode of DXVA native, using EVR, is completely wrong.

It pushes CPU load to max 100%, which is wrong operation.
CPU has nothing to do with DXVA native.

You can benchmark DXVA native with DXVA Checker only, which has all of the above information, too.

With that tool - DXVA Checker - you can benchmark everything (CPU, DXVA (all modes), NVCUVID, QuickSync decoder)

Even for LAV copy-back modes I would definitely trust more DXVA Checker tool, than GraphStudioNext.

The latter is useful only for pure CPU mode.

[nevcairiel]

And DXVAChecker cannot benchmark pure decoding performance without the overhead a renderer adds, quite a serious flaw if you want to benchmark anything that is not native DXVA.
No tool is ever perfect. :p

[egur]

@Nev,
Please check the following with DXVa checker:
* Does LAV decoder connect to EVR using NV12?
* Basketball clip - does it refuse to connect to EVR? Is LAV decoder even instantiated?
* What splitter is used for the Basketball clip?

You can't benchmark EVR in GraphStudio - it maxes out at 60 fps (any clip). GraphStudio probably doesn't configure EVR for full speed.

When the renderer is on a dGPU, I see a performance boost but it's still very far from GraphStudio with NULL-renderer results.

[nevcairiel]

I had some time to think about this, and to analyze some processing flows, and i have an idea that makes somewhat sense.

With all the multi-threading, the decoder usually works like this:

- Input Buffer
- Input Buffer
- Input Buffer
- Input Buffer
- Output Frame
- Output Frame
- Output Frame
- Output Frame
- Input Buffer
- Input Buffer
- Input Buffer
- Input Buffer
- ... and output again, and repeat

For three input buffers, no frame is output, but for the last one, it outputs 4 frames at once.
Now what i think the problem is that in the time it takes to actually render those 4 frames, the DirectShow filter cannot supply new data, so the QS decoder basically runs dry.
This is not a problem with the NULL renderer, because the rendering operation is instant (a no-op)

Eric, would it maybe be possible to spread out the output of those frames, so it would basically go like this:

- Input Buffer
- Input Buffer
- Input Buffer
- Input Buffer
- Output Frame
- Input Buffer
- Output Frame
- Input Buffer
- Output Frame
- Input Buffer
- Output Frame
- ... etc

Of course the initial delay will remain, but after that, try to interleave input and output events so that the decoder gets new data sooner? Of course there should be a threshold in case there are too many queued frames that it sometimes pushes out more then one, but 4-5 seemed to be a pattern i observed.
Am i making sense here? :)

PS:
Output Queue Length does not influence the behavior, but turning off MT causes it to be 90% properly interleaved.

[egur]

The MT is different than what you described.
Ti represent thread i.

* T1 (Receive thread): Every compressed sample is sent to the decoder if it's idle asynchronously - MSDK returns a wait handle . If copied samples are ready they are sent to the owning DS filter (e.g. LAV).
* T2 (async decode thread) waits for a thread message. A message will include D3D surface and a wait handle from T1. T2 will wait on the handle (frame decode complete) and add the ready D3D surface to a queue. T2 will enter the message loop.
* T3 (post process/frame copy thread) wait on its message loop. A message contains a D3D surface from T2. It will push the D3D surface to an output queue. If the output queue is long enough, it will process the frame (mostly copy to system buffer). The result buffer is taken from a fixed size free frame queue. It will wait until a frame is available. After copying the result is saved into a processed frame queue, ready to be sent to the DS filter. Frame copying is done in MT using threads T4 and T5. T3 waits until they are done. The free frames and processed frames queues are short (size 2) in order to keep the L3 cache hot. This is not a bottleneck.

During the run of T1, it will query the processed frames queue several times and see if a frame is ready to be sent. So a frame is sent out very quickly.
If for some reason the DS decoder (LAV) doesn't get Receive calls no frames will be outputted. Maybe there's a way to increase EVR's frames queue to overcome the problem.

Update:
Disabling MT improves performance by more than 60%! --> Update False results. Running tests too late at night :(
Nev, even if your theory is correct, I don't see how to force it. Allow only 1 output frame per Decode call? I need to think about it.

[nevcairiel]

Nev, even if your theory is correct, I don't see how to force it. Allow only 1 output frame per Decode call? I need to think about it.

I didn't even do any assumptions of how the MT works internally, i just added some logging on every call to Decode and every call of my Frame Callback. Thats what i saw, usually 4-5 Decode calls, and then it outputs 4-5 frames in one go.
Empirical evidence ftw. :)

I think my theory makes sense, and i think it shouldn't be too hard to test.
Anyway, yeah, output one frame per decode call, unless the output queue gets too long, then either output all the ones that are "too much" for the queue, or just output two for a while until its balanced out again.
This will ensure the decoder is always fed with new data to decode, and generally operates smoother and not in such bursts.

The fact that turning off MT actually improves performance supports my theory, because in single-threaded mode the calls to Decode and of the Frame Callback are usually pretty balanced.
I tried checking your code, but you have like 5 places where surfaces are delivered and only a queue of 2 frames, so this whole design would need to be adjusted a bit to allow for smarter handling of the frame output.

I would probably go with a queue size of maybe 6. If you're in the middle of the decoding process and you need more space, deliver just enough to make room, and then deliver one at the end of the decode process.
I don't feel confident enough with your whole MT trickery to try to adjust it myself, though, as i dont understand the reasons for all the scattered DeliverSurface calls and don't want to cause a deadlock.

I can probably even do that myself by queueing up frames internally (copy onto a media sample, but don't deliver yet). I would try that tomorrow or over the weekend, unless you try inside the Intel decoder first.

[nevcairiel]

Also, now that i think about it again, i wonder if its really worth spending much time on. Even in the DXVAChecker benchmark, i get nearly 300 fps (granted, rendering on my NVIDIA GPU and with faster RAM).

If its easy enough for you to test, i wouldn't mind seeing results, but if its not, i don't care all that much.

If you have some other plausible ideas, i'm all ears.

[egur]

Using a dGPU really improved results.
Disabling MT hurt results. The results from last night were completely wrong, I had a build w/o actual copying.
I've managed to tweak the code a little but no big improvement when EVR is on the iGPU. I'll do more tests after the weekend.

[CruNcher]

So this Performance issue is only a problem if you use quicksync with rendering out on the iGPU @ the same time ?
Though it makes sense as the MFX uses the EUs and if the EUs are pressured their should be a performance impact and using EVR presures the EUs same as Aero (dwm) does @ the same time with Deinterlacing i guess the pressure should be even higher (you can actually measure the overhead its small though but it's their).
Im pretty sure with Encoding (H.264, here it's even official that the MFX uses the EUs for Motion Estimation) and Rendering directly out (EVR) you gonna see the same effect (most probably any PP in the Intel Control Panel might even stress more).

[nevcairiel]

I tested software mode in DXVAChecker and GraphStudio to get a baseline comparison, and i can basically see the same results.

Twin Peaks sample
Software: ~550 in GraphStudio, ~330 in DXVAChecker (EVR on both Intel and NVIDIA, didn't seem to make a difference).
QuickSync: ~400 in GraphStudio, ~280 on NVIDIA, ~190 on Intel in DXVAChecker.

I'm inclined to say that EVR is just the limiting factor and uploading the frames in the renderer just takes that much more time.
Maybe it can still be optimized, but i'm really wondering if its worth any effort. It wouldn't help CPU usage during playback, the only thing it would change is the benchmarking numbers.
It does show that not copying the frame back and forth is of course far more efficient, but in the end, during normal playback, the difference is still minimal.

The only time you really need everything the decoder can give you is either during benchmarking, or maybe for transcoding. The decoder is basically only limited by the consumer in this case, be it a renderer or a encoder.

In my opinion, just leave the speed be, and start thinking about deinterlacing. :)

[CruNcher]

was Aero off (especially the glass shader) ?

[NikosD]

Eric, Nevcairiel, Cruncher

In my opinion there is no such thing as NULL Renderer.
In real life scenarios - during playback - you will always use a renderer.

If you have such a performance loss, just by using a renderer (EVR), the first thing you should do is to improve the performance of QuickSync decoder.

If you think it's not worth it or you can't improve it due to software or hardware limitations, then make a native DXVA decoder using Intel' MSDK for H.264, MPEG-2 and VC-1.

The performance of QuickSync decoder, as it is right now, should not make you happy with a hardware like QuickSync.

The performance of LAV DXVA copy-back is embarassing for QS HW.

[nevcairiel]

In real life scenarios - during playback - you will always use a renderer.


In real life scenarios - during playback - you'll watch content at a maximum of 60 fps.
Why would anyone care if it outputs 250 or 350 fps in benchmarks?

The decoder is not slow (in fact, its very fast), whats making it slow is the renderer. Sure, it probably is possible to make the benchmark go faster, but... why? All it changes is the benchmark, playback will be 100% exactly the same.

If you think you need 400 fps with EVR to watch a movie, then make a native DXVA decoder using Intel' MSDK for H.264, MPEG-2 and VC-1. :)

[NikosD]

Because:

A) There is always the possibility of a new Intel driver for SNB, allowing 4K decoding of H.264 - where you would need every fps possible.

B) There is always the pressure "from inside" the perfectionist developer - like Eric - to optimize as much as he can.

[egur]

Because:

A) There is always the possibility of a new Intel driver for SNB, allowing 4K decoding of H.264 - where you would need every fps possible.

B) There is always the pressure "from inside" the perfectionist developer - like Eric - to optimize as much as he can.

I don't believe SNB will ever support 4K because of HW limitations. Lucky for most users is that 4K is a very small niche ATM with low bitrates that ffmpeg can handle without problems (on SNB).

I plan to investigate the EVR performance a little more but not much more. I seem to hit a wall here. Like Nev said, performance is already very good.

I personally don't like the DXVA route as it cripples the SW architecture severely.

Regarding performance. If you look at CPU utilization and power usage during playback, the state is very good. MT doesn't help that one bit. It only reduces latency and time spent in the decoding thread. This allows faster seeks which is a good feature.
But benchmarks results may be (are) tainted with locks and waits associated with MT. This means that the CPU can wait for queues to fill or operations to finish. These are meaningless with respect to playback efficiency. It only affects "full speed" playback.

Nev is working on a DXVA decoder which should have same performance as other pure DXVA solutions. I want to concentrate on HW video processing in the near future.

[nevcairiel]

Nev is working on a DXVA decoder which should have same performance as other pure DXVA solutions. I want to concentrate on HW video processing in the near future.

That would be much more fun if Intel would adhere to DXVA "standards", or at least disclose the differences in their implementation. :p

Apparently, only the MSDK really knows how its supposed to work with Intel (which is why it would also be nice to get support for older GPUs back somehow)

[egur]

So this Performance issue is only a problem if you use quicksync with rendering out on the iGPU @ the same time ?
Though it makes sense as the MFX uses the EUs and if the EUs are pressured their should be a performance impact and using EVR presures the EUs same as Aero (dwm) does @ the same time with Deinterlacing i guess the pressure should be even higher (you can actually measure the overhead its small though but it's their).
Im pretty sure with Encoding (H.264, here it's even official that the MFX uses the EUs for Motion Estimation) and Rendering directly out (EVR) you gonna see the same effect (most probably any PP in the Intel Control Panel might even stress more).

Aero was off for the tests.
I didn't test with deinterlacing active so that's another issue.
The EUs don't do much for both decode, video processing and encode. The bulk of the work is done via ASIC (fixed function HW). That's why its so fast. That's also why it's hard or impossible to add features (codecs, profiles, etc).
You can't have a cake and eat it ;)

When EVR uses the same HW, it burdens the memory systems. Since I don't know the internals of EVR, it would be hard to find the optimal method using it with respect to performance.

[NikosD]

I don't believe SNB will ever support 4K because of HW limitations. Lucky for most users is that 4K is a very small niche ATM with low bitrates that ffmpeg can handle without problems (on SNB).


HW limitations ? That's a new one.

I remember a previous post from you, explaining that in theory QS ASIC is capable of processing 4K resolutions (both pixels and decoding bandwidth)


Regarding performance. If you look at CPU utilization and power usage during playback, the state is very good. MT doesn't help that one bit. It only reduces latency and time spent in the decoding thread. This allows faster seeks which is a good feature.


Last time I checked out playback, it was still draining a lot of power using QuickSync decoder, compared to native DXVA implementations, especially for 60fps clips (even for low bitrate clips)

I wouldn't recommend QuickSync decoder - as it is right now - to laptop users, especially when there are so fast and efficient native DXVA implementations like PotPlayer internal codecs and MS DS/MFT, CoreAVC etc.

And bugless too (as bugless as they can be with Intel hardware/drivers)

If Intel doesn't want to make a 4K driver for SNB, at least it should open VC-1 VLD to all and provide the appropriate documentation for native DXVA implementation for all formats (H.264, MPEG-2, VC-1)

Grow up Intel :sly:

[andyvt]

I wouldn't recommend QuickSync decoder - as it is right now - to laptop users, especially when there are so fast and efficient native DXVA implementations like PotPlayer internal codecs and MS DS/MFT, CoreAVC etc.

On most laptops the screen is so poor that there's no benefit to messing with any of this stuff.

[egur]

@NikosD,
You can recommend or not recommend what ever you want.

QS decoder was meant for those who find Microsoft's decoder insufficient and/or want the SW-like look and feel so they can keep using their video setup without dramatic changes.
There's no competition between my decoder and CoreAVC or any other proprietary codec. In fact I've made my source code BSD license so they can use it as a whole as reference code so we could all enjoy high quality video using the HW resources.

The MS decoder is free and yet there's room for CoreAVC, ffdshow, LAV, CyberLink, Arcsoft, etc. Why? because MS decoder isn't working very well and can't be used on a daily basis (for many people).

Since my resources are very limited, I have to channel my efforts to what people want most.

If you don't appreciate what I do than there are other threads in doom9 for you to post in. Let's keep the discussions civilized.

[NikosD]

The MS DS decoder sure has some problems.

That's why I put the asterisk (*) whenever I find out decoding bugs (Artifacts) during playback or benchmarking.

I think the asterisk is obvious at my benchmarks post.

Also MS MFT is one of the fastest decoders with no decoding errors - as far as I can say - but it's limited to WMP12 and any other Media Foundation Player.

About other decoders i can say the competition is good as long as it produces better products.

I like your effort from the beginning, that's why I have contributed a lot - I think - to improve it - not from the developer's view (I'm not a developer), but from a user's view with some knowledge and skills to test and push some things forward.

I take every opportunity I can get, to be "uncivilized" not to you personally, but to every tactic I see from big Companies like Intel, AMD, Nvidia that is against the majority of us - users.

And because I respect you personally, I will stop "attacking" Intel, because you work for them.

But you have to understand, even if you aren't responsible, that you "represent" Intel here in a way.

[wanezhiling]

@NikosD
I think PotPlayer's internal DXVA decoder is good enough to Intel except that ModeVC1_VLD isn't accessible.

[NikosD]

The new DXVA checker v2.8.0 (it's in beta) has fixed the problem with LAV Video and Basketball clip and it will support renderless VMR and EVR benchmark modes.

[egur]

The new DXVA checker v2.8.0 (it's in beta) has fixed the problem with LAV Video and Basketball clip and it will support renderless VMR and EVR benchmark modes.

Made some nice progress optimizing the flow for EVR workloads. I'll release a new version in a few days.

BTW, where can I download DXVA checker v2.8.0 beta?

[CruNcher]

I wonder if it clears out the brake up issues when decoding + pp (ffdshow) under heavy cpu core load http://forum.doom9.org/showpost.php?p=1558451&postcount=785 :) That Microsoft and MPC-HC have less/no issues with

[wanezhiling]

15.26.3.64.2639 is out, only for IVY.

http://i.imgur.com/8isVE.png

[nevcairiel]

15.26.3.64.2639 is out, only for IVY.

http://i.imgur.com/8isVE.png

A driver is "out" when its available on Intels site, and not on some chinese website. :p
Still more then a month until Ivy release

[egur]

15.26.3.64.2639 is out, only for IVY.

http://i.imgur.com/8isVE.png

IvyBridge driver (15.26 family) but also installs on SandyBridge.
You can get it from Intel's download center here (http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=20910&keyword=2639&DownloadType=Drivers&lang=eng). IvyBridge Drivers are available by selecting "Desktop boards" from the download center, then select one of the IvyBridge boards (e.g. 77 series). Don't download drivers from unofficial sites.

Adds initial WMV9 HW support. Not perfect. Otherwise nothing major with respect to video as far as I've seen. Doesn't fix any issues I know about.

With the exception of developers or very bored people, users should stick with the current SNB drivers (2509, 2559, 2622).

[wanezhiling]

IvyBridge driver (15.26 family) but also installs on SandyBridge.
You can get it from Intel's download center here (http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=20910&keyword=2639&DownloadType=Drivers&lang=eng). IvyBridge Drivers are available by selecting "Desktop boards" from the download center, then select one of the IvyBridge boards (e.g. 77 series). Don't download drivers from unofficial sites.
Thanks Eric. I DID DOWNLOAD it from Intel official site.:)


Adds initial WMV9 HW support.
PotPlayer' QuickSync decoder could support WMV9 since they integrated your DLL in PotPlayer 1.5.30927(19.12.2011), how did they do that?
http://i.imgur.com/tmVc2.jpg

[nevcairiel]

PotPlayer' QuickSync decoder could support WMV9 since they integrated your DLL in PotPlayer 1.5.30927(19.12.2011), how did they do that?
http://i.imgur.com/tmVc2.jpg

The QuickSync decoder always supported WMV9, but check your CPU usage, until now it did it in software.

[egur]

...
PotPlayer' QuickSync decoder could support WMV9 since they integrated your DLL in PotPlayer 1.5.30927(19.12.2011), how did they do that?
http://i.imgur.com/tmVc2.jpg

I added support for WMV9 months ago. The SandyBridge drivers only offered support for SW decoding but as soon as HW acceleration was available I tested it and it worked.
BTW, the 2622 driver doesn't have HW acceleration for WMV9 but 2639 does. Actually all 15.26 drivers have WMV9 support. BTW, 2622 belongs to the 15.22 family.

[CruNcher]

i already saw this support creeping out in this preview Sandy Bridge Driver 2626 with Quicksync hope 2639 is more stable ;)
though i guess moding this driver will be a little harder this time as it's most probably missing all the main Hardware IDs for Sandybridge not only the specific Subsystem ones

[wanezhiling]

I added support for WMV9 months ago. The SandyBridge drivers only offered support for SW decoding but as soon as HW acceleration was available I tested it and it worked.
BTW, the 2622 driver doesn't have HW acceleration for WMV9 but 2639 does. Actually all 15.26 drivers have WMV9 support.

Er..I'm confused, QS is a HW decoder,so you mean in fact this (http://i.imgur.com/tmVc2.jpg) is in software mode not QS mode?

[CruNcher]

Er..I'm confused, QS is a HW decoder,so you mean in fact this (http://i.imgur.com/tmVc2.jpg) is in software mode not QS mode?

Jep Intel can dynamically dispatch based on the bitstream between their HW decoder.dll and Software decoder.dll clever thing, so in theory they could also support 4:2:2 or 10 bit fallback for example though their Software Decoder doesn't support neither as well ;)
If you install 2626 this fallback is disabled and it tries to decode the bitstream on the Hardware which looked odd (like you would try to play DRM encrypted WMV, lot of strange colored blocks)
Though i didn't looked much into it

[egur]

Er..I'm confused, QS is a HW decoder,so you mean in fact this (http://i.imgur.com/tmVc2.jpg) is in software mode not QS mode?

Yes, SW mode.

Media SDK HW DLL (libmfxhwXX.dll) will work in SW mode (e.g. SW fallback) if it doesn't support a profile in some cases.
Some examples:
* Video is wider or taller than 1080p.
* WMV9 (VC1 simple and main profiles)

Some features may exist (currently) only in the SW version of the MSDK dll (libmfxswXX.dll), available as part of the Media SDK 2012 install:
* H264-3D: stereo or MVC profiles
* MJPG
The above are meant for developers to test their code before HW support is available.

[nevcairiel]

Er..I'm confused, QS is a HW decoder,so you mean in fact this (http://i.imgur.com/tmVc2.jpg) is in software mode not QS mode?

Technically, the name "QuickSync" decoder isn't accurate, it really should've been called "Intel Media SDK" decoder.
They offer both software and hardware decoders for the 3 formats, and the software decoder also supported WMV3, but the hardware version didn't until now.

Their software decoders are generally slower then for example the ffmpeg versions, so they don't find much use.

[wanezhiling]

egur,nevcairiel,CruNcher, thanks a lot!
Very useful information for me.:thanks::thanks:

[egur]

QuickSync is the Intel brand name for HW accelerated video decode/process/encode starting with SandyBridge. The brand name strongly implies fast transcoding (which it does but I don't support).
The Media SDK is the method I used to get the job done.

Intel QuickSync Decoder sounds better than Media SDK Decoder. Like "LAV filters" sound better than "FFMPEG filters" as FFMPEG is also a means to an end and might be replaced if a better alternative arises (not very likely :) ).

[wanezhiling]

@egur
When I use your ffdshow QS to play a WMV3 file, does this (http://i.imgur.com/Am0cd.png) mean I'm in QS(SW) mode?
If playing a normal H.264/MPEG2/VC1 file like this (http://i.imgur.com/eL4L5.jpg), then means I'm in QS(HW) mode?

PS: Driver is still 2622.


@nev
As above, LAV QS says available not active when playing a WMV3 file, does this mean I'm in QS(SW) mode as well?

:thanks:

[egur]

@egur
When I use your ffdshow QS to play a WMV3 file, does this (http://i.imgur.com/Am0cd.png) mean I'm in QS(SW) mode?
If playing a normal H.264/MPEG2/VC1 file like this (http://i.imgur.com/eL4L5.jpg), then means I'm in QS(HW) mode?

PS: Driver is still 2622.


@nev
As above, LAV QS says available not active when playing a WMV3 file, does this mean I'm in QS(SW) mode as well?

:thanks:

Latest official builds of either ffdshow or LAV removed support for SW playback through the QS decoder. You should see 1-2% CPU utilization when HW is used. if you see >10% than it's probably SW.

If you'll build a debug version of my DLL, it will color the top left corner in blue for HW and red for SW.

[wanezhiling]

Latest official builds of either ffdshow or LAV removed support for SW playback through the QS decoder. You should see 1-2% CPU utilization when HW is used. if you see >10% than it's probably SW.
Thanks, update to rev4336
http://i.imgur.com/48GaY.jpg :)

[egur]

Thanks, update to rev4336
http://i.imgur.com/48GaY.jpg :)

If you'll build a debug version of my DLL, it will color the top left corner in blue for HW and red for SW.

[NikosD]

BTW, where can I download DXVA checker v2.8.0 beta?

Unfortunately beta versions of DXVA Checker are not publicy available.

BTW, I changed one clip at my benchmark collection.

I removed Birds-60fps and I added Avatar-60fps due to higher bitrate.

[ryrynz]

Be a nice guy and link a build for him anyway :p

[egur]

Version 0.29 beta is out with the following changes:
* Support for VFW (under FFDShow-VFW).
* Optimized code path for playback under real world conditions (at the expense of GraphStudio).
* Bug fixes.
* FFDShow rev4364

Downloads
* For the latest cutting edge FFDShow builds download my builds Intel QuickSync Decoder SourceForge home page (http://sourceforge.net/projects/qsdecoder/)
* FFDShow-tryout site (http://ffdshow-tryout.sourceforge.net/download.php)
* LAV Splitter builds (http://forum.doom9.org/showthread.php?t=156191)

[nevcairiel]

So, i benchmarked the new version, and the only clip that changed was the samsung ref16 clip, all others remained the same. I think we're really just at the limit of EVRs capability to accept frames in system memory there.

Here are the benchmarks:
https://docs.google.com/spreadsheet/ccc?key=0Ajo8vvjNtaZ5dC1abjBSeVlmcnZXSjYwampfamk3ZWc

The good thing is, GraphStudio didn't really slow down either.
Good job, i guess!

How about that deinterlacing now? :)

[egur]

So, i benchmarked the new version, and the only clip that changed was the samsung ref16 clip, all others remained the same. I think we're really just at the limit of EVRs capability to accept frames in system memory there.

Here are the benchmarks:
https://docs.google.com/spreadsheet/ccc?key=0Ajo8vvjNtaZ5dC1abjBSeVlmcnZXSjYwampfamk3ZWc

The good thing is, GraphStudio didn't really slow down either.
Good job, i guess!

How about that deinterlacing now? :)

Part of the slowdown was related to noticed before in ffdshow was related to ffdshow - fixed that.

Yes, EVR is very limited when working in system memory, even if the GPU copy back function would be zero time, it would still output less than 230fps in the Samsung clip...

Up next is deinterlacing. Will be active if and only if decoder is active (at first anyway).

Nev, maybe you should separate your benchmarks results for DXVA checker and GraphStudio so they'll be clearer.

[CharlieCL]

If you'll build a debug version of my DLL, it will color the top left corner in blue for HW and red for SW.

Where is the Debug version?

I had difficult to know if Quick Sync was enabled or not.
From CPU usage I guess QS codec was not used.

I have a testing PC with Core i5 2405S DH61AG MB 4GB DDR3
Windows 7 64-bit. But when I tried to install Intel's Win7Vista_152254 Graphic driver, it said my system was not satisfied the mini requirements. This is weird.

What is the mini requirements to use QS hardware codec?

I am not sure the architecture of Sandy Bridge. The video acceleration hardware seems to connect CPU directly. This is unlike GPU card which the video acceleration hardware is connected through PCIe. Everything looks right for Sandy Bridge. However in my testing, Sandy Bridge looked slow in data rate between CPU and GPU.

[egur]

Where is the Debug version?

I had difficult to know if Quick Sync was enabled or not.
From CPU usage I guess QS codec was not used.

I have a testing PC with Core i5 2405S DH61AG MB 4GB DDR3
Windows 7 64-bit. But when I tried to install Intel's Win7Vista_152254 Graphic driver, it said my system was not satisfied the mini requirements. This is weird.

What is the mini requirements to use QS hardware codec?

I am not sure the architecture of Sandy Bridge. The video acceleration hardware seems to connect CPU directly. This is unlike GPU card which the video acceleration hardware is connected through PCIe. Everything looks right for Sandy Bridge. However in my testing, Sandy Bridge looked slow in data rate between CPU and GPU.

A debug version is not supplied. one has to download the sources from sourceforge and compile them.

The driver you're trying to install is the same one I use. Very strange. Try the latest driver from the board manufacturer. Do you see the driver in the Device Manager under Display adapters?
BTW, if by a long shot you have an engineering sample of SandyBridge, the production (standard) drivers will not install.

FFDShow reports it's using QS in it's tray icon. Also in the config dialog when a clip is running. LAV video decoder reports "Available" when QS is enabled and "Active" when it's actually used.

Although CPU and GPU share the same RAM and even share L3 cache. The GPU uses memory in a special way (called USWC) which makes it optimized for burst reads/writes (GPU like it) but take longer for the CPU to process.

For low bitrate clips, CPU will be faster.

[Esperado]

FFDShow reports it's using QS in it's tray icon. It says libavcodec on my config, while QuickSync was chosen in FFDShow for H264 and MPEG2. Why ?
My two screens are plugged in the Intel connectors, my CPU is Sandy bridge I5-2500k, graphic card is: Sandy Bridge-DT GT2 (Integrated 8086 / 0112, Rev 09), drivers are "Intel(R) HD Graphics Family" 8.15.10.2509.
What am-I doing wrong ?

[edit] Tried with driver 8.15.10.2622 (10/01/2012): same issue.

[CharlieCL]

A debug version is not supplied. one has to download the sources from sourceforge and compile them.

The driver you're trying to install is the same one I use. Very strange. Try the latest driver from the board manufacturer. Do you see the driver in the Device Manager under Display adapters?
BTW, if by a long shot you have an engineering sample of SandyBridge, the production (standard) drivers will not install.

FFDShow reports it's using QS in it's tray icon. Also in the config dialog when a clip is running. LAV video decoder reports "Available" when QS is enabled and "Active" when it's actually used.

Although CPU and GPU share the same RAM and even share L3 cache. The GPU uses memory in a special way (called USWC) which makes it optimized for burst reads/writes (GPU like it) but take longer for the CPU to process.

For low bitrate clips, CPU will be faster.

My driver is 8.15.10.2372 date 4/15/2011 this is on the Intel's CD. Now I upgrade to 8.15.10.2509 from online date 8/31/2011. The latest drevier is 15.22.54.2622 date 01/12/2012.

My Sandy Bridge is in a retail box so I guess it is not a engineering sample.

Tested the LAV decoder. There was an item of Quick Sync and it was set to available. But no "active" display in the property list.

What I want is to display that the QS hardware accelerator is used while a video was playing. Could you distribute a non-debug version that can display if QS is using?

So far I am disappointed on the performance of Sandy Bridge. I run my program on Pentium dual core 2.9GHz DDR2 800Mhz with Nvidia Quadra fX 3500 card, the FPS is 54. But on
my new SB quad core 2.5GHz DDR3 1333, the FPS is only 31.
In both PCs only ffdshow software codec was used.

[CruNcher]

@ Egur
im currently testing 2639 (libmfxhw32-s1 3.0.357.38898) but the decodinerror.ts is still not fixed (lav video quicksync, ffdshow quicksync) :( ?

No Problems with CoreAVC DXVA and other implementation Nevs DXVA is absolutely broken here

No difference to MC.ts that is still fixed no regression visible :)

Still Nevs DXVA crashes with the 720p.mpg (x264 mpeg-2 benchmark sequence)

Though both of the Nev issues aren't driver related but implementation issues.

[egur]

@ Egur
im currently testing 2639 but the decodinerror.ts is still not fixed (lav video quicksync, ffdshow quicksync) :( ?

I know, it's a different issue than the mc.ts clip. I have sent this clip and others for the driver and MSDK teams to analyze. It seems (to me) that these corruptions happen on scene changes. So maybe there's a way to fix them by manipulating the stream headers somehow...
Now that I use QS to play all my movies and TV shows on my i7-2600k HTPC, I get this sort of corruption from time to time (about once per 3-4 clips) - always very short and always on scene changes. I mostly watch 720p h264 mkv files. VC1 decode errors were reported here as well (or maybe in the AVS forum thread), this issue is also handled.

The good thing is that these issues are addressed and not ignored. A solution isn't always is quick or simple but the general direction is definitely positive.

The 2639 driver (which is not a final IVB driver or even the latest) gave me a few problems so I uninstalled it. I suggest you do the same...

Anyway, keep the issues coming, it will help drivers/MSDK mature faster.

Edit
If CoreAVC DXVA is working well then my hunch on stream pre processing looks even more viable.

[CruNcher]

Yup definitely great support in fixing problems :)

The only issue i have is when doing realtime surrface manipulation with @ the same time video output (low latency) testing that with ffdshows and SPP processing (which is very heavy on the CPU) with Quicksync i dont get it stable its stucking very often and sync is lost, reported that some pages back :(

Though something like this not always works nicely it seems heavily dependent on the Decoder best results so far i got with MPC-HCs and Microsofts own Mpeg-2 Decoder those seem really stable in such a time critical workflow.

[egur]

Yup definitely great support in fixing problems :)

The only issue i have is when doing realtime surrface manipulation with @ the same time video output testing that with ffdshows and SPP processing (which is very heavy on the CPU) with Quicksync i dont get it stable its stucking very often, reported that some pages back :(

I'll look into that today.

[Esperado]

It says libavcodec on my config, while QuickSync was chosen in FFDShow for H264 and MPEG2. Why ?
My two screens are plugged in the Intel connectors, my CPU is Sandy bridge I5-2500k, graphic card is: Sandy Bridge-DT GT2 (Integrated 8086 / 0112, Rev 09), drivers are "Intel(R) HD Graphics Family" 8.15.10.2509.
What am-I doing wrong ?

[edit] Tried with driver 8.15.10.2622 (10/01/2012): same issue.Any help ?

[CruNcher]

@Egur

Im not sure but it seems the normal decoding overhead (copy back) is too high for it to get stable fps though i wonder why Intels Decoder also has problems, with it's so small overhead (despite the green line problem, it also stucks from time to time like with quicksync decoding but not as heavy most probably less overhead related see bellow) and many Software Decoder as well.
Though it seems improving Performance to much isn't very good for latency and decreases performance in such specific realtime workflows (especially when mixing multi threaded with single threaded parts) might be also why MPC-HCs libmpeg2 performs so well its Performance isn't really that good (better than Mainconcept Singlethreaded) but therfore it keeps very stable in that case :)


Though first of i really have to find out when and if the Reference Decoder is using Quicksync Hardware and when it doesn't

i also wonder if this improves just by switching to Windows 8 ;)


So with EVR output it uses the Hardware:

http://img62.imageshack.us/img62/5487/realtimemanipulationtes.png

Also with Null it uses the Hardware (so those amazing improvements are indeed hardware (ASIC) related compared to the software decoders and not software, Performance wise in direct comparison with the best decoders i would say you get almost multithreaded performance of 4 cores (90%) @ single threaded cpu utilization levels (25%) very impressive so the ASIC saves like 65% depending on the Software Decoders Multi threading efficiency.

http://img256.imageshack.us/img256/3753/inteldecoderanalyzenull.png

So i guess those stucking in the realtime test and sync issues will be the same for everything hardware decoded and the copy back overhead on the cpu (double the utilization thrown around the cores by lav video quicksync, ffdshows quicksync) just amplifies the problem more :( ?

[egur]

Any help ?
Do you mean that in the codecs tab you selected the QS decoder and in the info tab you saw libavcodec? What player/splitter do you use? Does it happen with LAV video decoder?

@CruNcher
I fixed ffdshow to use PP on all QS codecs (VC1, mpeg2, H264).
I analyzed SPP with a profiler on an SD clip (720x480), MPEG2. Results are that SPP is taking practically all the CPU cycles.
It's also single threaded so it doesn't scale well with modern CPU architectures.
My decoder only outputs NV12 so it might add some overhead to SPP.

To make matters worse, ffdshow uses inline functions to mask out intrinsic function calls. this works nice in optimized builds but it's dead slow in debug builds (1/2 fps!) making the debug process very hard.

I'll contact clsid for a solutions to these problems. MT can be done with OpenMP and using the intrinsic functions 'as is' without wrappers would be very fast in debug builds.
OpenMP requires a few simple but significant changes in ffdshow - link with dynamic version of the CRT. This can complicate ffdshow distribution.
OpernMP has a bug that it crashes on exit when being used with a static version of the CRT (libc).

[nevcairiel]

OpernMP has a bug that it crashes on exit when being used with a static version of the CRT (libc).

An alternative would be using Microsofts Parallel Patterns Library (PPL), i use it in LAV Video and it seems to work just fine.
Super easy to create a parallel for loop with it.

PS:
Intrinsics in debug builds will always be much slower then release builds, because the debug intrinsics always have an extra step to move register content back to system memory so the debugger can easily look into it.

[egur]

An alternative would be using Microsofts Parallel Patterns Library (PPL), i use it in LAV Video and it seems to work just fine.
Super easy to create a parallel for loop with it.
Didn't work with it before, what are the dependencies?
OpenMP is super easy too and it ships with the compiler.

Intrinsics in debug builds will always be much slower then release builds, because the debug intrinsics always have an extra step to move register content back to system memory so the debugger can easily look into it.
My copy function is written using intrinsics and it works very fast in debug builds.

[nevcairiel]

Didn't work with it before, what are the dependencies?
OpenMP is super easy too and it ships with the compiler.

No dependencies, include ppl.h and get cracking. Its included in VS2010 (not earlier versions)
http://msdn.microsoft.com/en-us/library/dd492418.aspx


My copy function is written using intrinsics and it works very fast in debug builds.
The copy instructions are not affected because they copy memory anyway (so the debugger knows whats going in the register) but all processing instructions are.
My code to convert YUV -> RGB is incredibly slow in debug builds <.<

[egur]

No dependencies, include ppl.h and get cracking. Its included in VS2010 (not earlier versions)
http://msdn.microsoft.com/en-us/library/dd492418.aspx


Works nice for my copy function - ~same performance as my threadpool with 1/100 of the code :)
Checked with Dependency Walker - no new dlls are linked. QS decoder dll is twice as big though.

[nevcairiel]

Works nice for my copy function - ~same performance as my threadpool with 1/100 of the code :)
Checked with Dependency Walker - no new dlls are linked. QS decoder dll is twice as big though.

All the code required is dynamically pulled in through templates and whatnot, so yeah it ends up in your file.

[Esperado]

Do you mean that in the codecs tab you selected the QS decoder and in the info tab you saw libavcodec? What player/splitter do you use? Does it happen with LAV video decoder?
Yes for your first question.
for the second, I'm using BVBViewer (a very good TNT program). You can chose all the elements you want to use in the directX configuration page.
If i chose an other decoder (CoreAVC, cyberlink, or ATI), it works as expected.
If i chose FFDSHow (your version), it is ffdshow, and everything seems to wok. The only problem is, in ffdshow, i had configured Quick Sync for the codec, and (thanks to the direct show intelligent connect, of ffdshow ?) right clicking on the icon or opening Info & cpu tab shows Libavcodec as used instead.

It says " input FOURCC:H264, Decoder: Libavcodec h264, Output color space: YV12 "
I had tried both with EVR or VMR9 rendrers, same issue.

According to one of your messages, i had configured the graphic card in BIOS to reserve 500 Mo of ram, and i can indeed see 3553 for the available physical memory (instead of 4GO) in the SEVEN task manager, and 543 Mo as reserved for material.

[CharlieCL]

Yes for your first question.

If i chose FFDSHow (your version), it is ffdshow, and everything seems to wok. The only problem is, in ffdshow, i had configured Quick Sync for the codec, and (thanks to the direct show intelligent connect, of ffdshow ?) right clicking on the icon or opening Info & cpu tab shows Libavcodec as used instead.

It says " input FOURCC:H264, Decoder: Libavcodec h264, Output color space: YV12 "
I had tried both with EVR or VMR9 rendrers, same issue.

According to one of your messages, i had configured the graphic card in BIOS to reserve 500 Mo of ram, and i can indeed see 3553 for the physical memory (instead of 4GO) in the SEVEN task manager.

This may be the reason that I can not use QS Codec. I also applied DirectShow Intelligent Connect. I set a testing code that when input format is YV12 the video display as gray. So the wmv video was displayed as gray but h.264 and MP4 video was still displayed in color. I am sure the HW acceleration has been applied in some players but not sure QS was used.

[CruNcher]

@ Egur
Still a lot Decoding issues with WMV3/9 MP though i guess you and the MSDK guys know that http://img859.imageshack.us/img859/9984/intelwmv3decodeissues.png ;)

[egur]

Esperado,
Can you try LAV video decoder instead of ffdshow - it will show you if QS is enabled on your system.

I don't have live TV streams to check and very little test material for fourcc::H264 (most h264 content is AVC1). Make sure you are using the ffdshow latest version, fourcc::H264 wasn't supported a few versions ago.

The problem could also be in the stream - if it's an h264 10bit or 4:2:2 profile than HW acceleration doesn't support it (neither on Nvidia/AMD).

[egur]

@ Egur
Still a lot Decoding issues with WMV3/9 MP though i guess you and the MSDK guys know that http://img859.imageshack.us/img859/9984/intelwmv3decodeissues.png ;)

Yes, known issue. Thanks.

BTW, SPP deblocking or probably any other deblocking algorithm within ffdshow relies on having the quantization parameter for each macro block.
I can't supply those parameters, so the deblocking algorithms will smooth the image a lot and effectively become useless.

[Esperado]

I don't have live TV streams to check and very little test material for fourcc::H264 (most h264 content is AVC1). Make sure you are using the ffdshow latest version, fourcc::H264 wasn't supported a few versions ago.Thanks a lot for your care, Egur.
Can it helps-you if i provide in line for you some .ts files recorded from TNT HD ? If yes, just tell-me how long you want-them.

Yes, Intel Quick Sync seem activated, as it works now with ffdshow on non HD programs (since i had reserved memory for the graphic card ?).
But it is not fluid (disappointing). Still does not woks with H264.
Under libavcodec it is 1ms instable, under Quick sync it is 27-32ms, varying continuously.
FFDshow Version is tryouts rev4322 feb 13 20 12 21:44:36 (MSCV 2010) and says H264 is implemented.

If you need some extra info, feel free to ask me (with the way to get-it).

[Esperado]

Installed LAV video decoder. It says "Intel Quick Sync active". And wow !
Works out of the box. Even with H264 HD channnels. The best de-interlacing of all my (numerous) testings.
Added ffdshow raw video filter for a little Xsharpen, and gosh ! The best image of all. Soft and hardware.
I have too an ATI Radeon R6850.
50 I/s absolutely constant in EVR renderer, <1ms of instability.
And 0ms of instability with VMR9 (witch i prefer the texture).

Only a little disappointed by cpu usage: it eats as much cpu than ffdshow libavcodec.
Still here, Egur, if you need some files, and thanks so much for your help and fantastic work, together with Nevcairiel !

[egur]

Installed LAV video decoder. It says "Intel Quick Sync active". And wow !
Works out of the box. Even with H264 HD channnels. The best de-interlacing of all my (numerous) testings.
Added ffdshow raw video filter for a little Xsharpen, and gosh ! The best image of all. Soft and hardware.
I have too an ATI Radeon R6850.
50 I/s absolutely constant in EVR renderer, <1ms of instability.
And 0ms of instability with VMR9 (witch i prefer the texture).

Only a little disappointed by cpu usage: it eats as much cpu than ffdshow libavcodec.
Still here, Egur, if you need some files, and thanks so much for your help and fantastic work, together with Nevcairiel !

Good that it works. Your system is QS enabled but have some other issues I can't identify.
Both ffdshow and QS use the same QS dll but LAV sets the timestamps better. The latter is affected by the splitter in many cases and LAV does a better job than what I can do within my code (my code is not aware of the DirectShow environment as it's not a DS filter). LAV also has a very nice SW fallback mechanism in case a specific profile isn't supported in HW.
CPU utilization levels are affected by bitrate - high bitrate will make QS shine, lower bitrates will make libavcodec shine.

In live TV playback, LAV is superior to ffdshow with respect to QS usage as it works in lower latency. This has to do with timestamps generation as stated above.

Update
The latest (http://sourceforge.net/projects/qsdecoder/files/ffdshow_builds/) ffdshow I've built fixes most of the live TV issues. you should try it too.

[CruNcher]

Thus i say having a non copy back version like in the Reference Decoder would rock with less overhead lower latency :)

[egur]

Thus i say having a non copy back version like in the Reference Decoder would rock with less overhead lower latency :)

No image processing, no subtitles, must use EVR/VMR and the gain is mostly visible in benchmarks not in real playback of contemporary streams (e.g. most of stuff we watch today). One can use the MS decoder or a bunch of other DXVA decoders for that.

[nevcairiel]

To be fair, subtitles do work in many players, just not with ffdshows subtitle renderer or DirectVobSub.

[CruNcher]

if everyone looks @ what dukey did and builds up on it subtitles would be no problem :)
and image processing the most important stuff can still be done over the shaders though i dunno what for the quality of intels EVR chain is excellent :)

[nevcairiel]

if everyone looks @ what dukey did and builds up on it subtitles would be no problem :)

His subtitle renderer only supports IA44 colors, which is a 4-bit paletted format. For many subtitles, that is by far not enough.
In theory it should work with AYUV, but many GPUs don't support that.

[easyfab]

new driver for Intel HD Graphics : 15.26.3
Is there something new for Quicksync ?

[egur]

new driver for Intel HD Graphics : 15.26.3
Is there something new for Quicksync ?

Yes, HW WMV9 playback and probably MVC (not supported in my code) as well but this driver isn't ready for the public yet so I recommend not using it. I recommend sticking with the official SandyBridge drivers for now (15.22 family).

[hajj_3]

When will intel be announcing whether or not x264 encoding support will be added to ivy bridge or as a software update to sandy/ivy bridge? Hoping they will add support.

[andyvt]

When will intel be announcing whether or not x264 encoding support will be added to ivy bridge or as a software update to sandy/ivy bridge? Hoping they will add support.

QS offers h.264 support already on SNB.

[Esperado]

LAV also has a very nice SW fallback mechanism in case a specific profile isn't supported in HW.
CPU utilization levels are affected by bitrate - high bitrate will make QS shine, lower bitrates will make libavcodec shine.
How can i be sure QS is using Intel * hardware* in LAV ?
Well, about CPU usage, to give-you an idea (I5-2500k overclocked at around 4.5Ghz) i use ~50% CPU looking at 4 HD streams in the same time around 7/11 Mbits each in four different windows. Fluently.

Last question: Are we obliged to reserve memory in Bios for Intel graphics ? And, if yes what would be the good size, with 4Gb of ram to reserve less as possible ?

[DragonQ]

If you're running MPC-HC, go to View -> Filters -> LAV Video and you should see that it says "Active" next to the QuickSync decoder. If it doesn't, then it's fallen back to software mode.

[hajj_3]

QS offers h.264 support already on SNB.

I'm on about x264 specifically.

[andyvt]

I'm on about x264 specifically.

You mean the FOSS SW h.264 encoder?

[hajj_3]

i realise x264 is a h.264 encoder but i'm pretty sure there is no way to hardware encode x264 with intel chips only intel's own h.264 codec.

[andyvt]

i realise x264 is a h.264 encoder but i'm pretty sure there is no way to hardware encode x264 with intel chips only intel's own h.264 codec.

x264 is a component that encodes h.264. There should be little practical difference b/w its output and the output of Intel's QS h.264 HW encoder. The thing you're asking for already exists.

[egur]

QS offers h.264 support already on SNB.

I think he meant patching the x264 encoder with QS HW acceleration.
I don't know if such a project is in the works.

[egur]

How can i be sure QS is using Intel * hardware* in LAV ?
Well, about CPU usage, to give-you an idea (I5-2500k overclocked at around 4.5Ghz) i use ~50% CPU looking at 4 HD streams in the same time around 7/11 Mbits each in four different windows. Fluently.

Last question: Are we obliged to reserve memory in Bios for Intel graphics ? And, if yes what would be the good size, with 4Gb of ram to reserve less as possible ?

I didn't change the defaults (I think it was 400MB). More RAM for the GPU means more streams can be played simultaneously. You'll get better performance if you OC the RAM. CPU overclocking and GPU overclocking made little change in my (very limited) performance tests compared to RAM OC.

[andyvt]

I think he meant patching the x264 encoder with QS HW acceleration.
I don't know if such a project is in the works.

That would be a bizarre project :)

[Esperado]

I didn't change the defaults (I think it was 400MB). More RAM for the GPU means more streams can be played simultaneously. You'll get better performance if you OC the RAM. CPU overclocking and GPU overclocking made little change in my (very limited) performance tests compared to RAM OC.Overclock is for other softwares, like CAO or photo ones. And it speed the general behavior of Seven, including the boot time.
Well, i do not understand this memory stuff. i reduced to 150MB et don't see any difference. It looks like the memory is dynamically called by my TNT card software.

[edit] I discovered that the memory info for graphic card is available in the Intel graphic configuration panel (CTRL + Alt +F12). "Option and help -> information center".
By default, my Bios reserves only 64MB for the graphic card. The Bios setting modify only the minimum graphic memory value and it seems that the GPU is able to dynamically assign as much it needs. I can read, playing 3 TV windows, that the Graphics use only around 130MB. It do not seem change with the numbers of opened TV windows.

So i had set only 160MB for the graphics. The result shows: "Minimum graphic memory: 160Mo, maximum graphics memory: 1760Mo, Grahics memory in use: 127MB." Everything seems OK and i do not lose precious Ram that way.

[Esperado]

I had, with some Mpeg2 channels in VMR9 a strange behavior. Image perspective is not linear, and the left and right sides are like zoomed.
No problem with H264.
So, i'm back with EVR :-(
nb: this problem never occurred with sw decoders.
I prefer VRM9 because it gives more details in images (specially on skin's visages)

[NikosD]

Ivy Bridge QuickSync performance (Intel HD 4000) about 40% faster in transcoding than Sandy Bridge QS (Intel HD 3000).

The article says its advantage comes from decoder's performance (and drivers).

http://www.anandtech.com/show/5626/ivy-bridge-preview-core-i7-3770k/17

[egur]

I had, with some Mpeg2 channels in VMR9 a strange behavior. Image perspective is not linear, and the left and right sides are like zoomed.
No problem with H264.
So, i'm back with EVR :-(
nb: this problem never occurred with sw decoders.
I prefer VRM9 because it gives more details in images (specially on skin's visages)

Non linear scaling is an option you can turn on/off from the graphics control panel. The player might enable this feature overriding the driver defaults.

[egur]

Intel's Graphics Performance Analyzers 2012 R1 (http://software.intel.com/en-us/articles/vcsource-tools-intel-gpa/) has been released.

[Esperado]

Non linear scaling is an option you can turn on/off from the graphics control panel.Oh, thanks, Egur. It was activated by default in the graphic panel, but at 0%. Works perfect now.
BTW: I wrote a false info (the graphics panel do not update fast enough). On my system, it appears that the used memory is around 110MB, plus around 200MB for each full frame tv instance.

AS the graphic card can use the needed RAM dynamically, what is the interest to reserve more than the minimum for it in Bios ?

My god, all those direct show things are so confused and complicated....

[egur]

Oh, thanks, Egur. It was activated by default in the graphic panel, but at 0%. Works perfect now.
BTW: I wrote a false info (the graphics panel do not update fast enough). On my system, it appears that the used memory is around 110MB, plus around 200MB for each full frame tv instance.

AS the graphic card can use the needed RAM dynamically, what is the interest to reserve more than the minimum for it in Bios ?

My god, all those direct show things are so confused and complicated....
I don't why you changed the BIOS defaults, you should leave them as is. You should not lower the minimum values. Actual values are dynamic which is usually the best option.

[Atak_Snajpera]

does intel decoder support avc high 10bit profile?

[egur]

does intel decoder support avc high 10bit profile?

Only 4:2:0 8 bit for all codecs.
BTW, are you aware of any GPU that supports 10bit and/or 4:2:2/4:4:4 profiles?

[Esperado]

I don't why you changed the BIOS defaults.I had read somewhere in this thread that, to can activate itself, QSync decoding need >128MB of reserved ram. That's why. But this is not true, indeed.
You should not lower the minimum values
Once again, by default, it was 64MB in Bios. And i'm now at 160MB.

[Atak_Snajpera]

BTW, are you aware of any GPU that supports 10bit and/or 4:2:2/4:4:4 profiles?
It's a shame that even modern GFX cards do not support AVC fully .

[Esperado]

As a photographer, i'm very involved in images quality. Using Qsync in LAV video filter, WMR9 renderer, sharpen in Intel graphics and a little Xsharpen added in post processing with FFDshow raw filter, i get a fantastic result.

With good HD programs, images are so sharp, perspectives, reliefs and perception of the depth of field astonishing, without this "video game" non natural feeling i used to get with other decoders with enhanced sharpening.

De-interlacing is perfect and only limited by the latency of my screen. Stability problems forgotten.

Even in a non interesting program, it is a physical pleasure to look at the image's quality. Equal if not even better than my best digital post-processed photos.

Egur and nevcairiel, (and Intel) thank-you so much for your "state of the art" perfect work. I am very appreciative and grateful.

[egur]

Great!
You might consider switching to EVR for better quality.

[Esperado]

Great!
You might consider switching to EVR for better quality.I do not agree at all. For two reason (on my PC):
1- Frequency is perfectly stable with WMR9, (0ms instability). It is constantly variable around the 50hz point with EVR (49,98 to 50,02 Hz, 1ms instability).
2- EVR seem to smooth the colors, skins look like repaint with less details and i don't like it.
On a TV logo, as an example, there is a little color gradient on the background. I can see the mpg compression steps in VMR9 ( like in Gif images) while it is smoothed with EVR and seems monochromatic or monotone. Less sharp, too. Like too much noise reduction in photo post prod.
I had chosen WMR9 because images look better on my system with better details. Chosen with my eyes, with no doubt, while my original belief was that EVR was better.
The only side where i find EVR better is CPU usage.

Oh, i have a question. While my Ram is over-clocked at 828Mhz
7-8-7-20, and my CPU to 4550MHz, is any benefit to be expected overclocking Intel GPU from 850 to 1100MHz, just to watch live or recorded TNT programs (i don't play video games) ?

[CharlieCL]

Ivy Bridge QuickSync performance (Intel HD 4000) about 40% faster in transcoding than Sandy Bridge QS (Intel HD 3000).

The article says its advantage comes from decoder's performance (and drivers).

http://www.anandtech.com/show/5626/ivy-bridge-preview-core-i7-3770k/17

In my testing of the latest GPA, the architecture of Sandy Bridge may be the main problem of lower performance than Ivy Bridge. In my testing I found 50% GPU EU stalled. The wider ring bus of Ivy Bridge may make higher performance.

[egur]

I do not agree at all. For two reason (on my PC):
1- Frequency is perfectly stable with WMR9, (0ms instability). It is constantly variable around the 50hz point with EVR (49,98 to 50,02 Hz, 1ms instability).
2- EVR seem to smooth the colors, skins look like repaint with less details and i don't like it.
On a TV logo, as an example, there is a little color gradient on the background. I can see the mpg compression steps in VMR9 ( like in Gif images) while it is smoothed with EVR and seems monochromatic or monotone. Less sharp, too. Like too much noise reduction in photo post prod.
I had chosen WMR9 because images look better on my system with better details. Chosen with my eyes, with no doubt, while my original belief was that EVR was better.
The only side where i find EVR better is CPU usage.

Oh, i have a question. While my Ram is over-clocked at 828Mhz
7-8-7-20, and my CPU to 4550MHz, is any benefit to be expected overclocking Intel GPU from 850 to 1100MHz, just to watch live or recorded TNT programs (i don't play video games) ?

Skin tone correction can be turned off (or weakened) in the control panel. so does noise reduction, sharpening, auto contrast, etc.

Overclocking will not get you anything (anything good) if your use case is playback. it will help in transcoding and benchmarks. Your system is already very fast for playback.

[egur]

In my testing of the latest GPA, the architecture of Sandy Bridge may be the main problem of lower performance than Ivy Bridge. In my testing I found 50% GPU EU stalled. The wider ring bus of Ivy Bridge may make higher performance.

Wider ring bus? Where did you hear that?

[mbcd]

Hi Guys,

I could need some help getting it to run.

System: I7 2nd-Edition, Windows 7, Lucid Virtuo 1.2.105.17711, Intel HD 8.15.10.2622 Driver

I downloaded ffdshow from egur and installed it. But on Codec page I cant choose IntelQuickSync, only "libavcodec" or "disabled".

So it seems that something is going wrong.

My primary Videocard is an ATI, because my MB does not have an Graphic-Out-Port onboard.

Virtua says that it is running, so some idea where to fix ?

[CharlieCL]

Wider ring bus? Where did you hear that?

It was open published. here is the URL

http://www.anandtech.com/Gallery/Album/1375#6

The ring bus is 256-bits.

[nevcairiel]

The ring bus is 256-bits.

Sandy Bridge also has a 256-bit ring bus.

[egur]

Sandy Bridge also has a 256-bit ring bus.

Correct.
IvyBridge adds some micro architectural performance enhancements with respect to SSE/AVX. It should be worthwhile to write an AVX copy back function.

[CruNcher]

It's a shame that even modern GFX cards do not support AVC fully .

It's called Markets ;) 10 bit non consumer (still) consumers got wonderful useless 3D instead ;)

[dread]

Hi !

It looks like QuickSync Decoder isn't working on my setup.

My setup: Celeron G530, Asrock H61M U3S3, 4GB RAM 1333Mhz.
OS Windows 7 64bit.

I've installed LAV Filters, activated QuickSync on LAV Video Decoder (also tried ffdshow), and set output to EVR.
While watching 1080i/p on MPC-HC I'm getting very high cpu usage like it was not using hardware acceleration - avg ~60% both cpu and gpu on 1080p, and ~100% on 1080i with enabled yasif deinterlacing, and as you can imagine, it's jerky and unwatchable.

On TMT on the other hand, with enabled hardware acceleration I'm getting cpu usage of ~25% (gpu ~20%) while watching 1080p movie, and ~35% cpu (70% gpu) while watching 1080i deinterlaced material and it plays smooth.

I've tried Microsoft DTV-DVD Video Decoder on MPC-HC, and it has lowest cpu usage (15%), but there are ocassionally decoding artifacts appear, so it's not a solution for me.

I've also tried latest OEM Graphic Drivers (v8.15.10.2618) and these from downloadcenter.intel.com (v8.15.10.2622).

Below I've uploaded a few screenshots of used filters and display stats so maybe someone could find a clue why QuickSync is not working for me.

http://img59.imageshack.us/img59/5733/evrdu.th.jpg (http://img59.imageshack.us/img59/5733/evrdu.jpg) http://img841.imageshack.us/img841/4234/evr2.th.jpg (http://img841.imageshack.us/img841/4234/evr2.jpg) http://img442.imageshack.us/img442/9559/evr3.th.jpg (http://img442.imageshack.us/img442/9559/evr3.jpg)

[CruNcher]

It's working what you see as High CPU usage is mostly coming from the copy back the GPU usage from the EVR custom presenter (the osd and timers also create some overhead) and the Shader resizing + Deinterlacing though you have a SNB system you mostly do'nt need it use EVR basic and utilize Intels (Egurs) Hardware Resizer this will drop the usage of Aero(dwm) and the GPU a lot , CPU usage will also drop considerably if Egur implements the Native path without Copy back :)

Also if you need every last resource try Mirillis Splash Player they make very efficient use of every part in their Player (it's excellent work so far with Intel Quicksync support + additional fixes most other decoder don't have, for the formats it supports, partly they already beat CoreCodecs DXVA might be they use a custom quicksync non copy back implementation) custom renderer not sure though if they use Intels Hardware Scaling or something else but looking @ the resource usage suggest they utilize intels Native Scaling (Lanczos4) (didn't conducted quality tests yet to confirm this) :)

TMT and PowerDVD already use Intel Specific optimizations also + DXVA + some of their own fixes, MPC-HC (and most MPC code based Player) on the other side are still not 100% ready for it (though their DXVA status varies from broken to functional with quirks), especially the internal DXVA playback is broken heavily for Intel HD Graphics and MPC-HC ;)

[nevcairiel]

~100% on 1080i with enabled yasif deinterlacing, and as you can imagine, it's jerky and

Don't use YADIF deinterlacing, let EVR take care of that. Your CPU isn't fast enough for that.

[dread]

It's working what you see as High CPU usage is mostly coming from the copy back the GPU usage from the EVR custom presenter and the Shader resizing + Deinterlacing though you have a SNB system you mostly do'nt need it use EVR basic and utilize Intels (Egurs) Hardware Resizer this will drop the usage of Aero(dwm) and the GPU a lot , CPU usage will also drop considerably if Egur implements the Native path without Copy back :)

I've set output to EVR but I don't see any difference in cpu usage. It's still ~60% on 1080p material.
Also disabled yadif deinterlacing, now on 1080i material video is much smoother but still a lot of dropped frames and very high cpu (80-90%) and gpu usage (100%).

I don't really know what is Intels Hardware Resizer and how to enable it on MPC-HC.
Under the filters menu there is File Source (Async.) in work, is it ok ?

Also if you need every last resource try Mirillis Splash Player they make very efficient use of every part in their Player (it's excellent work so far with Intel support, for the formats it supports)

Thanks, I'll try it.

[wanezhiling]

YADIF deinterlacing will surely kill poor G530.

[egur]

For low end CPUs, you'll get the best quality and performance if you use EVR and EVR-CP. They behave completely different BTW.
You can tweak (or disable) sharpness, noise reduction, skin tones correction and more in the graphics control panel.

For SandyBridge, EVR has a better scaler and uses much less power.

Please report back your CPU utilization after using EVR.

Like Nev said, let EVR do the deinterlacing, also make sure NV12 is selected as an output for both LAV and ffdshow (saves format conversions as EVR likes NV12 and QS decoder outputs NV12).

[CruNcher]

I've set output to EVR but I don't see any difference in cpu usage. It's still ~60% on 1080p material.
Also disabled yadif deinterlacing, now on 1080i material video is much smoother but still a lot of dropped frames and very high cpu (80-90%) and gpu usage (100%).

I don't really know what is Intels Hardware Resizer and how to enable it on MPC-HC.
Under the filters menu there is File Source (Async.) in work, is it ok ?



Thanks, I'll try it.

is your system set to High Performance or Balanced Performance ? dropping frames (in non exclusive fullscreen, and windowed mode) can have a lot of reasons it can also be a background application interfering timer problems are most common in badly coded apps for example sensor software polling extremely or having bad coded kernel drivers can cause problems, some motherboard or GPU Manufacture 3rd party software is known for these problems though they slowly replace their stuff these days
Asus Probe 2 for example that came initially with their SNB Mainboards is heavily bad coded and causes DPC spikes @ every pooling interval in their Kernel Driver i made them aware of it it should be fixed by now hopefully.
If you see dropped frames @ playback first thing you should do is check the DPC status of the system either via the Performance Console and the DPC performance counter or much easier with http://www.thesycon.de/eng/latency_check.shtml its a essential tool for troubleshooting video playback as well as other system performance related problems under windows in both Hardware issues as well as Software :)

Generally to many counter and to high update intervals bellow 15 ms depending on the system can be still problematic HPT compensate somewhat but to many different running in the background or mixing will cause issues, and if dynamic frequency switching adds to it (like in the balanced profile) it becomes more problematic though it got much better these days thx to Intel and Microsoft ;)

Dread as i said you using a non native quicksync on your system you wont see a big improvement unless you use either a native version or DXVA :) try Nevs DXVA2 and see if it helps you though it's not stable yet for Intel it can work for 1 Video but fail for another the heaviest thing that could happen is a bsod in the Driver but that's very rare these days it most probably will just crash the player and trigger a WER report.

Try the following setting

in MPC-HC enable EVR instead of EVR Custom presenter
in Lav Video enable DXVA2 native instead of Intel quicksync, disable Yadif and untick RGB options

this should lower the pressure on both CPU as well as GPU

Though i guess once you tried Mirillis Splash you don't want to go back to MPC-HC anyways (@ least for most common formats) ;)

if playback is ok (no corruptions) and you see still frame drops then read above what i wrote and download dpclat.exe and check the stability @ playback and try High Performance in the Energy Settings instead of Balanced

it could be that instead of frame drops you now see frame corruptions if that is the case you have to use another DXVA decoder with Intel support a good and cheap one would be http://corecodec.com/products/coreavc ( a lot of testing gone into this also by me hunting a lot of bugs ;) )

[mbcd]

Does no one have an idea why I am not able to get Quicksync to work? -> http://forum.doom9.org/showpost.php?p=1563925&postcount=947

Everywhere I read that my P6Z68-DELUXE is capable of using it. I installed the latest 0.49 of lav, but there is still not success.

[egur]

Does no one have an idea why I am not able to get Quicksync to work? -> http://forum.doom9.org/showpost.php?p=1563925&postcount=947

Everywhere I read that my P6Z68-DELUXE is capable of using it. I installed the latest 0.49 of lav, but there is still not success.

Sorry, I missed your original post.
In order to use QS (any app that uses QS) you have one option with this board - Lucid Virtu.
Open the Virtu control panel and add your media player(s) to the list of applications that will work on the iGPU - the list is probably preoccupied with several transcoding apps.

After you do this, the apps in the iGPU white list will operate on the iGPU and the result video will be outputted to the dGPU screen. This add some overhead but not too bad.

BTW, install the latest Virtu version from their website (http://www.lucidlogix.com/driverdownloads-virtu.html). Old versions like you have had issues.
I personally stopped using it (because I don't need to) at version 106. Back then Virtu had issues with 64 bit playback - frames play out of order. 32 bit players worked great.

Let me know if this works for you.

[dread]

is your system set to High Performance or Balanced Performance ?

High Performance.

Try the following setting

in MPC-HC enable EVR instead of EVR Custom presenter
in Lav Video enable DXVA2 native instead of Intel quicksync, disable Yadif and untick RGB options

this should lower the pressure on both CPU as well as GPU

With dxva2 native enabled, instead of QuickSync, I'm getting pretty impressive cpu usage but there are decoding artifacts. I don't think it's working properly with Intel graphics, correct me if I'm wrong...

Though i guess once you tried Mirillis Splash you don't want to go back to MPC-HC anyways (@ least for most common formats) ;)

Tried splash pro and it's really great with Intel, but I would really like to see similar performance on MPC-HC which has some important for me features that Splash player and TMT don't have.

For SandyBridge, EVR has a better scaler and uses much less power.

Please report back your CPU utilization after using EVR.

1080p24 clip cpu usage on MPC-HC + EVR + LAV Filters + NV12:
http://img641.imageshack.us/img641/8917/1080pnative.png
red line - hardware decoder set to: none
blue line - QuickSync (avg gpu usage 52%)

1080p24 clip cpu usage compared to Splash Pro player:
http://img208.imageshack.us/img208/7259/1080pl.png
red line - QuickSync (avg gpu usage 52%)
blue line - Splash Pro (avg gpu usage 25%)

1080i60 clip cpu usage:
http://img339.imageshack.us/img339/7861/1080i.png
red line - QuickSync (avg gpu usage 94%)
blue line - Splash Pro (avg gpu usage 41%)

[mbcd]

In order to use QS (any app that uses QS) you have one option with this board - Lucid Virtu.
Open the Virtu control panel and add your media player(s) to the list of applications that will work on the iGPU - the list is probably preoccupied with several transcoding apps.

After you do this, the apps in the iGPU white list will operate on the iGPU and the result video will be outputted to the dGPU screen. This add some overhead but not too bad.

Thanks for that advice egur,

so I cant use it for transcoding. My goal was to use it for converting to x264, so only on transcoding. So I have no application that I could use in Lucid Virtu. It only accepts executables, and in my construction:

Graphfilter -> avissynth -> x264

I only have the x264.exe that is usable for Lucid, and that makes no sin, because x264 doesnt use Quicksync.

So I thought there is a way that there is direct access to iGPU.

Or is there another possible way to use it for transcoding?

My purpose was to use is for decoding, so I have more power for encoding, I dont need it for visible output on any screen.

As Info:
I can see the Intel-HD-Graphics, but I cant use it as extended screen, because there is no hardwareconnection:

http://s3.imgimg.de/thumbs/Monitorsce2bf565png.png (http://www.imgimg.de/bild_Monitorsce2bf565png.png.html)


BTW: I even thought testing it with an Player, but VLC (actual version) shows "licence required" when implemented in Lucid. Still MPC shows this message. Im not happy with this at all, Now I bought an expensive mainboard and cant use one of the feature that were top important ...

[egur]

Thanks for that advice egur,

so I cant use it for transcoding. My goal was to use it for converting to x264, so only on transcoding. So I have no application that I could use in Lucid Virtu. It only accepts executables, and in my construction:

Graphfilter -> avissynth -> x264

I only have the x264.exe that is usable for Lucid, and that makes no sin, because x264 doesnt use Quicksync.

So I thought there is a way that there is direct access to iGPU.

Or is there another possible way to use it for transcoding?

My purpose was to use is for decoding, so I have more power for encoding, I dont need it for visible output on any screen.

As Info:
I can see the Intel-HD-Graphics, but I cant use it as extended screen, because there is no hardwareconnection:

http://s3.imgimg.de/thumbs/Monitorsce2bf565png.png (http://www.imgimg.de/bild_Monitorsce2bf565png.png.html)


BTW: I even thought testing it with an Player, but VLC (actual version) shows "licence required" when implemented in Lucid. Still MPC shows this message. Im not happy with this at all, Now I bought an expensive mainboard and cant use one of the feature that were top important ...

You can add GraphEdit (or better yet GraphStudioNext) to Virtu's app list. You can always keep 2 GraphEdit executables - one under Virtu and one normal (just create a copy of the exe).

Virtu is licensed by a special BIOS key, updating your BIOS will set things right - I had the same problem. Your OEM probably signed with Lucid too late.

I'll contact the driver team and see if they have a more elegant solution to your problem. The problem is with Direct3D9, it will not enumerate a disconnected device but obviously Lucid found a way to overcome this limitation.

[CruNcher]

High Performance.



With dxva2 native enabled, instead of QuickSync, I'm getting pretty impressive cpu usage but there are decoding artifacts. I don't think it's working properly with Intel graphics, correct me if I'm wrong...



Tried splash pro and it's really great with Intel, but I would really like to see similar performance on MPC-HC which has some important for me features that Splash player and TMT don't have.



Yes they are a lot of decoding issues with Nevs DXVA2 native see my last bug hunt on it :( pretty severe problems the only thing that could help would be a native quicksync this could reach very low overhead with great compatibility as the copy back works with almost all of those streams without any issues (only 1 issue with the decodinerror.ts, but not as heavy as with dxva2 native) :) .
Does all of your tested streams result in problems with DXVA2 Native ? could you post a result of it's utilization on your system vs Mirillis :)

Here is a big list of bitstream issues http://forum.doom9.org/showpost.php?p=1564452&postcount=9794
though tested with unofficial 2639 drivers

also you could try either Cyberlinks or Arcsofts decoder they both are stable with quicksync and get as stable results as quicksync copy back but with the lower overhead.

PS: Dread also make sure you use Nev latest official build http://forum.doom9.org/showpost.php?p=1564287&postcount=9765

[egur]

@dread
Can you also report the CPU frequency when QS is working. You can use this free tool CoreTemp (http://www.alcpu.com/CoreTemp/)
BTW, what's the bitrate of the tested clip?

[mbcd]

You can add GraphEdit (or better yet GraphStudioNext) to Virtu's app list. You can always keep 2 GraphEdit executables - one under Virtu and one normal (just create a copy of the exe).

Thanks, I will try it, didnt thought it, because I load graph directly into avisynth and I dont see any thread in task-manager while converting.


Virtu is licensed by a special BIOS key, updating your BIOS will set things right - I had the same problem. Your OEM probably signed with Lucid too late.

Just did it, on first try I installed the latest BIOS from ASUS and lastest Virtu but didnt had success, then I downgraded Virtu because I thought there might be a licence problem, but still with the actual stuff even VLC tells me "licence needed".

Virtu correctly reports my Mainboard and its Manufactor. Even there is no hint that its running in "non-licence" ... this message only appears using VLC or MPC ... confusing !


I'll contact the driver team and see if they have a more elegant solution to your problem. The problem is with Direct3D9, it will not enumerate a disconnected device but obviously Lucid found a way to overcome this limitation.

Thanks for that, it would be fine to get a solution, I bought this board especially for use of encoding, so it would be very disapointing if Quicksync is now unusable for it.


If you need more Information let me know !

[egur]

...
Just did it, on first try I installed the latest BIOS from ASUS and lastest Virtu but didnt had success, then I downgraded Virtu because I thought there might be a licence problem, but still with the actual stuff even VLC tells me "licence needed".

Virtu correctly reports my Mainboard and its Manufactor. Even there is no hint that its running in "non-licence" ... this message only appears using VLC or MPC ... confusing !

I think you should contact ASUS's support for this issue.

[CruNcher]

Normaly Virtu supported boards are clearly marketed as such if their is no indication on the website that virtu is not supported it isn't the best chance you have even with the cheapest Intel board (if i had known that i wouldn't have bought ASUS) ;)
Though hopefully Nvidia Synergy if it reaches the light one day will be fully free for every board though as you can guess only for Nvidia owners, but it's not clear how it's gonna to be marketed either but im very sure Nvidia will give it out for free LucidLogix is in another position they cant do it Intel where the firsts to include the Bios Key for all their Boards even the cheapest H67 boards many other Manufactures only give it out with the Z boards as a exclusive thing i guess Asus belongs to them the same like MSI and others, but i didn't tried it yet (Though i don't have big hope my "relatively cheap" board is licensed even after the Chipset disaster ;)
Btw egur does your creating 2 Monitor surface trick for MediaSDK detection also work with utilizing the encoder or would it also need to be adapted to it like you did with the decoder in ffdshow ?

Btw that Intel where the first to give the key out for free for all their boards was a little surprising because the first who announced Virtu support where actually MSI ;) though i speculated that ASUS would also drive the same road and thus decided for a ASUS board which was faster available @ the first days (yeah i was a early adopter) ;)
But i totally missed Intel i thought it was a pretty generic "reference" board and such though in the end it even showed better energy consumption results (though Asus even have their own extra Chip for managing this, which of course also consumes energy itself) and later Intel presented Lucid Logix Virtu on their Stands @ presentations and then the Press release all their Bios would support it and i was feeling like "doh" ;)
And then the others started to market it with Z boards much later s a exclusive thing even after the chipset disaster when Intel announced the support for it on every of their Boards ;)
So i pretty doubt if i install Virtu i will be greeted with a happy smile on my Asus H board, but landing into evaluation mode, so my last hope is Nvidia :)

Btw technically seen of course this whole Bios Key stuff is a restriction (serial key on a very deep level in intels proprietary UEFI Bios structure) not a system requirement problem Virtu runs on every board it was even tested on my Board according to the PDF so i might be lucky and the key is in my bios without knowing it ;)

Im not 100% sure but i think Intel hadn't planed the support for every Board as well but after the Chipset Disaster they said a come one we give them something back licenses for every board (yes would be a nice task taking all boards back and giving user something extra, so to see as compensation for their problems) ;) but im not sure it might have been also the strategy of Lucid to be available on every Intel Board after the close corporation and show offs of it with Intel ;)

Though if i look back @ this i shouldn't have concentrated to much into the Board Manufactures knowing that they crave for every extra money the can make and Lucid needing to sell licenses so in the end what happened with Intel and Lucid was a pretty logic thing :( and i really thought about getting the Intel board even if it hadn't (solid capacitors,extra chips, more , bunch of useless bad coded tuning and sensor software) and such high class components but it was solidly done @ foxconn :(

http://www.asus.com/Motherboards/Intel_Socket_1155/P8H67M_PRO/ <- nothing about Virtu support so i guess i dont even need to try it ;)

http://ark.intel.com/products/50101/Intel-Desktop-Board-DH67CL <- this was my other candidate back then, in the end i decided for ASUS :)

http://www.lucidlogix.com/download/PR_Intel_310311.pdf <- when this was released i was like "doh" please let me calculated right

the next doh was then this right after it http://www.lucidlogix.com/download/PR_MB_LucidLogix_ASUS_050211_final.pdf and i new i could forget the H release from Asus for it :(

and this was the ultimate doh then http://downloadmirror.intel.com/20008/eng/BL_0110_ReleaseNotes.pdf jep intel did

[egur]

Normaly Virtu supported boards are clearly marketed as such if their is no indication on the website that virtu is not supported it isn't the best chance you have even with the cheapest Intel board (if i had known that i wouldn't have bought ASUS) ;)

Yes, but his board features Virtu according to ASUS's web page.

[CruNcher]

ah sorry P6Z68-DELUXE jup should be clearly have a license all Z boards per se from Asus have it, only the ultra expensive Maximus Line doesn't seem to be licensed very crazy.

I guess Intel are the only ones and a exception that granted a license to users for all boards from H to Z, which makes angry somewhat angry @ myself for not deciding for the Intel Board and angry @ ASUS for forgeting all the early adopters even after the chipset problems :(

[mbcd]

Ok guys, thanks a lot for your answers, I dont want to go too offtopic on this here. Maybee some good information for someone else in my position.

So I have two problems:

- Luzid Virtu is not licenced by ASUS (nice they even dont have a clear customer-support, I dont know where to contact them without needing serial of Mainboard, can`t get it right now)

- Luzid Virtu needs an executable which I cant offer in combination with lav, avisynth. I specialy need avisynth for filtering and I didnt found a way to get it implemented in Graphstudio. Even batching could be problematic with Graphstudio.


So it was a disaster with Intel:
- Problems with my H67 board and 3 destroyed Harddrives
- No sin in offering a P67-Deluxe-Board, because it cant switch between onbard and additional graphic-card, and even there are problems in cooperation with LUZID VIRTU. And at all: You can only use VIRTU if you have an executable ... which I dont have here for decoding ...

So a warning to all, dont buy this Board, its useless ... :mad::mad::mad:

[CruNcher]

Ok guys, thanks a lot for your answers, I dont want to go too offtopic on this here. Maybee some good information for someone else in my position.

So I have two problems:

- Luzid Virtu is not licenced by ASUS (nice they even dont have a clear customer-support, I dont know where to contact them without needing serial of Mainboard, can`t get it right now)

- Luzid Virtu needs an executable which I cant offer in combination with lav, avisynth. I specialy need avisynth for filtering and I didnt found a way to get it implemented in Graphstudio. Even batching could be problematic with Graphstudio.


So it was a disaster with Intel:
- Problems with my H67 board and 3 destroyed Harddrives
- No sin in offering a P67-Deluxe-Board, because it cant switch between onbard and additional graphic-card, and even there are problems in cooperation with LUZID VIRTU. And at all: You can only use VIRTU if you have an executable ... which I don't have here for decoding ...

So a warning to all, dont buy this Board, its useless ... :mad::mad::mad:

This is strange i mean shouldn't it work with the host process ? so the .dll that get called by the main executable should be included so if you include graphstudio.exe in the lucid manager it should hook and include any decoder/encoder called from within it first that would be graphstudio.exe->ffdshow.dll->quicksync.dll->libfxhw32.dll and send it's result to the framebuffer and d output ?

You only bought a Z board because of Virtu support ?

Wait didn't you said initially you got a Z board no P board ?

Or do you really want to say you switched from H to P to Z :D

[dread]

@dread
Can you also report the CPU frequency when QS is working. You can use this free tool CoreTemp

2,4Ghz.

BTW, what's the bitrate of the tested clip?

1080p was a first few minutes of Braveheart Blu-ray untouched (MPEG4 AVC) - I guess avg ~20-25Mbps, and peak @ ~40Mbps + DTS HD MA track.

1080i60 was a mkv 2min clip uploaded by AVS member (http://www.avsforum.com/avs-vb/showthread.php?p=21009914#post21009914), avg bitrate also around ~25Mbps + DTS HD MA track.

Disabled aero theme, and it did helped but just a little :)

Does all of your tested streams result in problems with DXVA2 Native ?

It's my new build, I didn't even had a chance to watch one movie from start to finish.
First few minutes of Braveheart Blu-ray was a pretty awful experience with dxva2 native (LAV 0.48), on the other hand there weren't any decoding issues with first few minutes of LOTR or 1080i60 clip I tested.

could you post a result of it's utilization on your system vs Mirillis :)

Sure, but you have to wait for a while :)

also you could try either Cyberlinks or Arcsofts decoder they both are stable with quicksync and get as stable results as quicksync copy back but with the lower overhead.

I don't see any Arcsoft filter available from the list in MPC-HC. I have TMT5 latest version installed.

[CruNcher]

https://forum.doom9.org/showthread.php?t=163845

[mbcd]

This is strange i mean shouldn't it work with the host process ? so the .dll that get called by the main executable should be included so if you include graphstudio.exe in the lucid manager it should hook and include any decoder/encoder called from within it first that would be graphstudio.exe->ffdshow.dll->quicksync.dll->libfxhw32.dll and send it's result to the framebuffer and d output ?

You only bought a Z board because of Virtu support ?

Wait didn't you said initially you got a Z board no P board ?

Or do you really want to say you switched from H to P to Z :D

Sorry, too much problems with Intel in a short time.

First I had an "P"-Board with this famous chipset-failure.
Got B3-Version and that killed 3 Harddrives, so another exchange. Exchanges took months, and now they lost package and I only got the naked mainboard back ... :mad:

Between these exchanges I bought a "Z"-Board, because I wanted more Power for Decoding/Encoding, and of course: I needed a Mainboard to be able to use my computer. And now this ...


Problem is that I only have an executable here at last position:

Avisynthscript (with integrated, direct call of ".GRF") -> x264.exe (Encoder)

So there is no Graphstudio or something else loaded. I only see the x264-executable in Taskmanager, and adding this to VIRTU doesnt show any advantage in speed, also I think there had to come the "licence required"-Message as with VLC or MPC too if it tries to get access to iGPU.

I thought that egurs solution directly get access to iGPU (because he comes directly from INTEL), but now its clear that it doesnt.
iGPU seems to be there in my system, but it still needs VIRTU in use without hardware-graphical-out.

Hard thing ... to come with ;)

[CruNcher]

ahhhh now i get your problem :)
i have a solution for it use x264.exe call the avisynth script and include the quicksync decoder as directshowsource call include x264 in lucids manager and load your avisynth script, nobody is happy with that Virtu stuff just for using the decoder/encoder especially with no real video output for the encoder that's for sure :)

i wonder why you load the encoder via the avisynth script ? and not the avisynth script via the encoder ;)

if you still need it that way you could also use virtualdub with its cmd encoding and x264.exe behind it and put virtualdub in the lucid list <- though pretty overhead and complex for normal encoding, this way you could combine avisynth, directshow + virtualdub ;)

[mbcd]

i wonder why you load the encoder via the avisynth script ? and not the avisynth script via the encoder ;)

No I do:

avisynthscript loads graph
x264 loads avisynthscript

Avisynthscript (with integrated, direct call of ".GRF") -> x264.exe (Encoder)

direct264 is pretty nice, but still I need avisynthfilter and an actual x264-version, so I think I have to play with virtualdub again :scared: Was happy to get that overload away such times ago and now it comes back :eek:
Of course I could integrate an script in ffdshow, but that complicates the process if you need different scripts in a batch ... you always had to reconfigureate ffdshow, not very comfortable.

A "simple/single" problem which get so complicated for getting a max of quality ...

[CruNcher]

No I do:

avisynthscript loads graph
x264 loads avisynthscript



direct264 is pretty nice, but still I need avisynthfilter and an actual x264-version, so I think I have to play with virtualdub again :scared: Was happy to get that overload away such times ago and now it comes back :eek:
Of course I could integrate an script in ffdshow, but that complicates the process if you need different scripts in a batch ... you always had to reconfigureate ffdshow, not very comfortable.

A "simple/single" problem which get so complicated for getting a max of quality ...

Hmm but then it should also work
if you add x264.exe to the lucid list then open a cmd line for example and do

x264 [avisynth script]

and inside the avisynth script you load the quicksync decoder via a directshowsource call i dunno why it shouldn't work

[mbcd]

Exactly, but it cant work, because I cant tell to use quicksync.

ATM I use LAV and DXVA2 (native) which works, as you can see on pics it is not posible to acrivate QS EVEN if x264 is running and VIRTU got it.

As I said, maybee a problem with those licence-failure, but then I wonder why there is no message in this case on picture 2.

http://s3.imgimg.de/thumbs/DXVA2nativeb86cd2eajpg.2.jpg (http://www.imgimg.de/bild_DXVA2nativeb86cd2eajpg.jpg.html)

http://s3.imgimg.de/thumbs/QSx264running06084a0djpg.2.jpg (http://www.imgimg.de/bild_QSx264running06084a0djpg.jpg.html)

If there is a try like with VLC or MPC to get QS to work within VIRTU, why there is no message about "licence-missing".

I think its more a problem with VIRTU, so offtopic.
Maybe egur finds a way to get access directly to QS, then virtu should be useless someday ...

[CruNcher]

Exactly, but it cant work, because I cant tell to use quicksync.

ATM I use LAV and DXVA2 (native) which works, as you can see on pics it is not posible to acrivate QS EVEN if x264 is running and VIRTU got it.

As I said, maybee a problem with those licence-failure, but then I wonder why there is no message in this case on picture 2.

http://s3.imgimg.de/thumbs/DXVA2nativeb86cd2eajpg.2.jpg (http://www.imgimg.de/bild_DXVA2nativeb86cd2eajpg.jpg.html)

http://s3.imgimg.de/thumbs/QSx264running06084a0djpg.2.jpg (http://www.imgimg.de/bild_QSx264running06084a0djpg.jpg.html)

If there is a try like with VLC or MPC to get QS to work within VIRTU, why there is no message about "licence-missing".

I think its more a problem with VIRTU, so offtopic.
Maybe egur finds a way to get access directly to QS, then virtu should be useless someday ...

He allready found one for the Decoder :) see in this thread some pages back how it works though my question is if it would work for the encoder the same way :) and yeah hopefully well see the Intel MSDK guys finding a solution but the problem is it would render @ least the old Virtu useless (Virtu currently transforms into a package of specific solutions, not really Intel dependent anymore) and Intel has a agreement with them it seems about this specific encoder usage thing ;)

Though it's a little surprising that DXVA2 Native accelerates it and that the result can be captured in your framework that's mainly what copy back would be for (quicksync and that seems not working very strange) though the whole framebuffer thing is really complex matter that Windows since NT 6 now allows specifically between different drivers such things where more or less only done in professional stuff before on unix based solutions preferably broadcast systems its a very exciting field and LucidLogix has some interesting stuff going on after moving from Hardware to Software manipulating all kinds of things their and improving even the driver render pipelines to be more efficient :)

Maybe this license failure is because LucidLogix want to avoid such frameworks as i spoken of to be realized on consumer systems though i can't say for sure :(


Though i wonder how this all works together in terms of 64 bit OS and 32 bit apps and such i mean you have a lot of components here the 32/64 bit version of ffdshow the driver being 32/64 bit and lucid virtu having 2 versions best of course would be 1 complete same from start to end trying to avoid mixups ah and dont forget the new security stuff introduced with vista which could also make problems here and their i guess.

I would have said now you could also try the other prefered way and connect the Igpu and use the 3D Engine stuff in the virtu list instead, but that's a no go in your case.

[egur]

Exactly, but it cant work, because I cant tell to use quicksync.

...

If there is a try like with VLC or MPC to get QS to work within VIRTU, why there is no message about "licence-missing".

I think its more a problem with VIRTU, so offtopic.
Maybe egur finds a way to get access directly to QS, then virtu should be useless someday ...

If you opened LAV's config dialog from the start menu it will not show you that QS is enabled because it doesn't find a display connected to the iGPU.
Here's how you can make sure it's working:
Rename IntelQuickSyncDecoder.dll (32 bit).

Load a special build from here (http://www.mediafire.com/?tckfh8z6rx280ak)
It's the same build as LAV 0.49 but it colors a blue rectangle on the top left corner. Copy it to LAV's x86 folder (where the old dll is).

Now try your setup.

Also to clarify things, if x264.exe loads the QS decoder under Virtu, Virtu will enable QS for x264 and all the dlls it loads.
The reason that Virtu works this way is because that's the only way to distinguish between apps.

[mbcd]

Thanks for your explanations egur.

Halfway good news:

Downloaded dll and replaced.
Added Graphstudio to VIRTU and build a graph.

Then the window "licence required" pops up lots of times, and LAV sais : Quicksync available".

But rendering on screen still not shows the blue rectangle, maybe because of those ""missing"" licence ...

Damn licencing, only problems for customers with this shit. Seems I have to contact ASUS for this problem ...

I will try to find another to test if VIRTU works with other applications that use it ... have to find a demo software.

[egur]

Thanks for your explanations egur.

Halfway good news:

Downloaded dll and replaced.
Added Graphstudio to VIRTU and build a graph.

Then the window "licence required" pops up lots of times, and LAV sais : Quicksync available".

But rendering on screen still not shows the blue rectangle, maybe because of those ""missing"" licence ...

Damn licencing, only problems for customers with this shit. Seems I have to contact ASUS for this problem ...

I will try to find another to test if VIRTU works with other applications that use it ... have to find a demo software.

Virtu acquires the license from the BIOS (probably from the ME - management engine). Did you disable any drivers or SW that came with your installation CD?

[CruNcher]

Virtu acquires the license from the BIOS (probably from the ME - management engine). Did you disable any drivers or SW that came with your installation CD?

Arghh i didn't thought about the Key being in the ME part like the PVP key then you really have to make sure the Intel ME service is also running (might be also why it's called Lucid Server in the Intel change log ?).
Though wouldn't that be insecure as the ME part can be easily exchanged between different bios and flashed separately ?

[egur]

Arghh i didn't thought about the Key being in the ME part like the PVP key then you really have to make sure the Intel ME service is also running (might be also why it's called Lucid Server in the Intel change log ?).
Though wouldn't that be insecure as the ME part can be easily exchanged between different bios and flashed separately ?

The ME ships from Intel as a binary - some parts of the BIOS SPI image are given to OEMs as binaries without source code and are used 'as is'.
When I got my H67 Intel board (a year ago), it had a BIOS dated from October 2010 and wasn't licensed with Virtu. After a BIOS update, Virtu was licensed.

[CruNcher]

the 110 BLH6710H.86A.0110.2011.0415.1506 ME Firmware: 7.1.11.1069 bios update ?

[egur]

the 110 BLH6710H.86A.0110.2011.0415.1506 ME Firmware: 7.1.11.1069 bios update ?

I don't know what was your question but I my BIOS version is 132. I think originally I updated to 119. It also improved the fan controls significantly as well as added fast boot which was missing in the original BIOS release. My board is DH67GD.

[CruNcher]

I don't know what was your question but I my BIOS version is 132. I think originally I updated to 119. It also improved the fan controls significantly as well as added fast boot which was missing in the original BIOS release. My board is DH67GD.

Its a generic Bios :) PRODUCTS: DH67BL, DH67CF, DH67CL, DH67GD, DH67VR (Standard
BIOS)

I already have experience with updating the ME part from another Manufactures Bios so i wonder if it could copy the license also, and i guess less problematic would be Intels Bios then especially as its a H67 License :)

Jup its the 110 bios :) and lucid server support :) http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=19993&ProdId=3334&lang=eng&OSVersion=Windows%207%2C%2064-bit*&DownloadType=Software%20Applications

[egur]

Its a generic Bios :) PRODUCTS: DH67BL, DH67CF, DH67CL, DH67GD, DH67VR (Standard
BIOS)

I allready have experience with updating the ME part from another Manufactures Bios so i wonder if it could copy the license also :)

There's no such thing as generic BIOS, these BIOSes are derivatives of the reference board BIOS.

[CruNcher]

I mean generic in the term that this 1 bios works for all of the above versions, only updating the ME part of my Bios with Intels shouldn't be problematic i guess it's worth a try or i wait till lucid sells licenses directly to end customers shouldn't take that long anymore http://eshop.lucidlogix.com/?q=catalog/1 ;)

http://www.lucidlogix.com/virtu-product-list.html <- intel is definitely the only H67 license currently

[aufkrawall]

This might have been asked a few times, but I really can't find it.
Can anybody give me the link to egur's guide how to set QS up by using a virtual second monitor?
I got it working but it's annoying that the mouse cursor can disappear into the virtual desktop.

:thanks:

[CruNcher]

http://forum.doom9.org/showpost.php?p=1532786&postcount=186

[aufkrawall]

Thanks, CruNcher. :)
I already found that solution by myself. Not ideal -> droppping it. :(

Edit: MPEG2 decoding is bugged too.

[egur]

Thanks, CruNcher. :)
I already found that solution by myself. Not ideal -> droppping it. :(
Why?

Edit: MPEG2 decoding is bugged too.
If there's an issue please report.

[aufkrawall]

Why?

I might be a bit oversensitive, but I still find it annoying when the cursor can get lost (happened a few times).
It'd be nice if there was a way to make the cursor completely locked to the real desktop.


If there's an issue please report.
Playback of the following MPEG2 interlaced file was jittering heavily:
http://www.mediafire.com/?4y1yngo6mnimo65

[mbcd]

So, a little report:

QS is running now, there are MUCH problems with QS, depending on LUZID and Motherboard-Vendors that are related to the BIOS-integreated licence LUZID needs.

My Board is runnning now, because there was an Bios-update again :D

Here my facts:
- LUZID does not prevent freeware from being used, VLC and other Programs can be used with it, so there is no lock out for freeware which would need a special licence from LUZID.

- My encoding-path dont use QS, I dont get it to run in that case. Fact is: QS is not activated if I add the x264.exe (encoder) to the list. I dont know why. In response to:
Also to clarify things, if x264.exe loads the QS decoder under Virtu, Virtu will enable QS for x264 and all the dlls it loads.
The reason that Virtu works this way is because that's the only way to distinguish between apps.
So it seems not to cunction that way.

- If I load the (unchanged) avisynth-script into Virtualdub I get QS to work. Really strange. Thats the part I dont understand. With x264.exe it itsnt loaded, but with Virtualdub it runs. The chain is theoreticly the same ... :confused:

- At first impression I couldnt get a difference in speed, seems that there is no major enhancement using DXVA2 (native) or Quicksync. But I didnt tested it correctly, but first impression was more negative.

[egur]

I might be a bit oversensitive, but I still find it annoying when the cursor can get lost (happened a few times).
It'd be nice if there was a way to make the cursor completely locked to the real desktop.
Unfortunately this is a DirectX limitation. Lucid have overcome this by creating what seems like a driver that intercepts DirectX calls.

Playback of the following MPEG2 interlaced file was jittering heavily:
http://www.mediafire.com/?4y1yngo6mnimo65

There was a problem with the HW device, a problem not seen before :(
I didn't notice any jitter, the clip just froze after 4-5 seconds.
I don't know your setup but you should not EVR-CP, only EVR, VMR9 or MadVR.
I've patched my code and hopefully this will solve the issue.
Here's a test dll (http://www.mediafire.com/?090beu9nr48cpqz), just replace the original.

I'm going on a business trip for a week, so if this patch works for you, I'll release a new build.

[CruNcher]

So, a little report:

QS is running now, there are MUCH problems with QS, depending on LUZID and Motherboard-Vendors that are related to the BIOS-integreated licence LUZID needs.

My Board is runnning now, because there was an Bios-update again :D

Here my facts:
- LUZID does not prevent freeware from being used, VLC and other Programs can be used with it, so there is no lock out for freeware which would need a special licence from LUZID.

- My encoding-path dont use QS, I dont get it to run in that case. Fact is: QS is not activated if I add the x264.exe (encoder) to the list. I dont know why. In response to:

So it seems not to cunction that way.

- If I load the (unchanged) avisynth-script into Virtualdub I get QS to work. Really strange. Thats the part I dont understand. With x264.exe it itsnt loaded, but with Virtualdub it runs. The chain is theoreticly the same ... :confused:

- At first impression I couldnt get a difference in speed, seems that there is no major enhancement using DXVA2 (native) or Quicksync. But I didnt tested it correctly, but first impression was more negative.

you mostly wouldn't see a speed difference as the bottlneck is more probably avisynth majorly singlethread processing though you should see lower CPU utilization wich can be used for the avisynth part if it allows it to (you need to optimize your script for multithreading and use avisynth MT and or multithreaded plugins), though im not sure how the Virtu overhead itself plays into this :)
That x264.exe doesn't work with Quicksync Decoding via Avisynth seems strange

[egur]

So, a little report:

QS is running now, there are MUCH problems with QS, depending on LUZID and Motherboard-Vendors that are related to the BIOS-integreated licence LUZID needs.

My Board is runnning now, because there was an Bios-update again :D

Here my facts:
- LUZID does not prevent freeware from being used, VLC and other Programs can be used with it, so there is no lock out for freeware which would need a special licence from LUZID.

- My encoding-path dont use QS, I dont get it to run in that case. Fact is: QS is not activated if I add the x264.exe (encoder) to the list. I dont know why. In response to:

So it seems not to cunction that way.

- If I load the (unchanged) avisynth-script into Virtualdub I get QS to work. Really strange. Thats the part I dont understand. With x264.exe it itsnt loaded, but with Virtualdub it runs. The chain is theoreticly the same ... :confused:

- At first impression I couldnt get a difference in speed, seems that there is no major enhancement using DXVA2 (native) or Quicksync. But I didnt tested it correctly, but first impression was more negative.

BTW it Lucid not Luzid.
It's hard to know why this odd behavior exists in your setup.
I'm going on a business trip tomorrow for a week and after that I'll look into avisynth+QS performance.
Since decoding is probably a small part of the transcoding process, it might not provide a significant boost. Theoretically it could hurt performance due to the copying.
Your flow can't work in pure DXVA mode as x264 needs frames in system memory. If by some means you hand it GPU memory buffers, the performance will be at least 10-20x slower.

[aufkrawall]

I'm going on a business trip for a week, so if this patch works for you, I'll release a new build.
The new dll doesn't fix the issue. :(
Movements are still jittering/stuttering.
Seems to happen only with MPEG2, VC-1 und H.264 are fine.
It occurs with every renderer.