Intel QuickSync Decoder - HW accelerated FFDShow decoder with video processing [Archive] - Page 21

egur

17th March 2012, 23:48

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.

I can't reproduce the jitter, using EVR within ZoomPlayer or MPC-HC produce zero jitter (according to EVR anyway).
It might be an ffdshow issue, try installing the latest ffdshow build (I'm currently synced with ffdshow r4379) and overwrite the QS dll.
Turn off all processing within ffdshow and output only NV12 - and see if that helps (basically factory default).

Edit:
I could only play this file when LAV splitter was used. Haali and MPC splitters failed to connect.

nevcairiel

18th March 2012, 00:00

Pat357

18th March 2012, 00:12

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:

But your Z68 board is OK now ? :p

CruNcher

18th March 2012, 10:24

Unfortunately this is a DirectX limitation. Lucid have overcome this by creating what seems like a driver that intercepts DirectX calls.

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.

Fixes the Freeze and correctly changes the AR with ffdshow quicksync
Lav Video Quicksync still freezes @ the AR change

The MPEG-2 thing might be a driver problem, and maybe egur is still running some newer driver where this is fixed. An Intel engineer apparently working on the Linux VAAPI interface submitted a patch to ffmpeg just last week to fix decoding of such samples, if the Media SDK part needed the same fix it may not be in our "older" versions yet. 2622 clearly shows the problem though.

Here are some more streams that illustrate the issue:
http://samples.ffmpeg.org/MPEG-VOB/mpeg2dec-streams/hhi/hhi_burst_long/stream
http://samples.ffmpeg.org/MPEG-VOB/mpeg2dec-streams/sony/sony-ct1/stream

I believe its the same problem.

Both are decoding with a lot of image jitter, if you compare that with a software decoder, the software decoder is just much smoother.

I don't see any issues with 2639 (Win7/Vista 64) and the supplied libmfxhw32.dll at least on the Sony stream so it might work if you replace it for testing just in the lav video and ffdshow directories but be careful it could brake i know to less about the driver ;) with Nvidia it brakes most of the times when CUDA changes majorly :D
Dunno how it is with Intel i guess we gonna find that out now http://www.mediafire.com/?5hwcv2ztgpcck0h ;)

PS:
Actually their is a Problem very visible with Lav Video Quicksync especially on the Sony bitstream it seems to detect the interlacing wrong (you have to treat it as progressive to avoid intels Deinterlacer distort it) but ffdshow quicksync doesn't show any problems with that though it also shows the zoom jitter problems on the HHI bitstream like Lav Video Quicksync though it doesn't trigger deinterlacing flags for the Sony stream like Lav Video Quicksync does and so no real issues on that bitstream visible.

So the Sony Bitstream might never had a problem actually or was fixed though the HHI stream has a real issue that can't be fixed treating the stream as progressive and indeed causes jitter on the zoom @ the boats @ playback.

Though i could swear i remember this issue on the renderer it looks the same as @ the thread start the evil trees.ts problem that wasn't visible with Software Decoding (Lav Video on EVR) :) but failed with Quicksync the same strange FPS difference and caused microstuttering Quicksync plays the HHI stream @ 50 fps and Lav Video @ 48.xx

egur

18th March 2012, 11:45

The MPEG-2 thing might be a driver problem, and maybe egur is still running some newer driver where this is fixed. An Intel engineer apparently working on the Linux VAAPI interface submitted a patch to ffmpeg just last week to fix decoding of such samples, if the Media SDK part needed the same fix it may not be in our "older" versions yet. 2622 clearly shows the problem though.

Here are some more streams that illustrate the issue:
http://samples.ffmpeg.org/MPEG-VOB/mpeg2dec-streams/hhi/hhi_burst_long/stream
http://samples.ffmpeg.org/MPEG-VOB/mpeg2dec-streams/sony/sony-ct1/stream

I believe its the same problem.

Both are decoding with a lot of image jitter, if you compare that with a software decoder, the software decoder is just much smoother.
I reinstalled the driver to v2622 and it still plays fine (cut.mpg). With LAV video (0.49) the clip will not end well - would not stop or rewind after it reaches the end. I didn't see any jitter visually or via EVR's property page.
The clips you posted look fine too in ffdshow (renamed them to .ts).
LAV 0.49 shows jitter on the 2 clips but ffdshow doesn't. Must be a time stamp issue. Could also be wrong DI flags like Cruncher said.

nevcairiel

18th March 2012, 11:58

So the Sony Bitstream might never had a problem actually

That interlacing problem is the problem that it has. It is missing some fields, and because of that the deinterlacing screws up the video.
I had the same problem with DXVA2 in LAV, then i applied a fix, and everything is fine now.

PS:
I'm not talking about any "jitter" that EVR stats claim to have, thats a completely different concept. Look at the image, if its broken, you'll notice that its not smooth.

CruNcher

18th March 2012, 12:01

yep but that is no real deep problem the HHI stream looks more interesting (the boat zoom) :)

nevcairiel

18th March 2012, 12:02

Its the same problem. Its missing some fields.

Like i said earlier, an Intel Engineer (Gwenole Beauchesne) actually submitted a fix for this exact issue to ffmpegs HW Accel component, and i can see the exact same problem when using QuickSync.
Just with this information alone, its safe to conclude that the MSDK still needs this fix, and probably will get it in an upcoming driver.

CruNcher

18th March 2012, 12:06

but treat as progressive doesn't help like it does with the Sony stream ?

and yes i know which jitter you mean i call it most of the times microstutter ;) and the Sony Dance scene when treat as progressive shows non though the HHI zoom does very obviously no matter if played with ffdshow quicksync or lav video quicksync (treat as progressive)

and the difference on the renderer EVR basic @ playback is clear 50.xx fps for Lav Video and for ffdshow quicksync (microstutter) and 48.92 fps for Lav Video avcodec (smooth zoom) (Aero V-sync refresh rate 75 Hz, MPC-HC tester 4151 Windowed/Fullscreen)

nevcairiel

18th March 2012, 12:17

The odd thing is, I have 2622 installed, and Windows Update is offering me a new driver now. But on the Intel website, i cannot even find 2622 anymore. I wonder if i should try installing it =p

Edit:
It was 2653, but didn't update the MSDK files. Maybe the Windows Update driver doesn't have them, and i couldn't find a stand-alone installer o.o
Really hate this part about the Intel drivers. Just put them all in a central place already.

CruNcher

18th March 2012, 12:29

Intel seems to like drivers vanish out of the user minds (believe us it never existed) though normally they have a nice history for drivers @ their download page but for the GFX driver it seems very different ;)

I keep a history of them so in case something stops working ;)

On the intel page moving over the Products->Desktop Boards->Intel® 6 Series Chipset Boards->Chose any = 8.15.10.2559

and when you move over to Products->Processor Graphics->2nd Generation Intel® Core™ Processors with Intel® HD Graphics 3000/2000 = 15.22.50.64.2509

and if you go to Products->Processors->Desktop->Chose your Ix then = 15.22.54.64.2622

This is so lovely ;)

PS: 8.15.10.2656 eg 15.26.5.64.2656 appeared "leaked" http://www.youtube.com/watch?v=yUoxQHqBnCI ;)

* February 22, 2012
*
*
* NOTE: This document refers to systems containing the
* following Intel chipsets/processors:
*
*
* 3rd generation Intel(R) Core(TM) processors (codename Ivy Bridge)
* 2nd generation Intel(R) Core(TM) i3 processor
* 2nd generation Intel(R) Core(TM) i5 processor
* 2nd generation Intel(R) Core(TM) i5 vPro(TM) processor
* 2nd generation Intel(R) Core(TM) i7 processor
* 2nd generation Intel(R) Core(TM) i7 vPro(TM) processor

Libmfxhw32-s1.dll (API 1.3)

2639 = 3.12.1.62/3.0.357.38898
2656 = 3.12.2.8/3.0.361.39233

Doesn't need to be modded installs directly :)

No decoding improvements on the last reports (decodinerror.ts,WMV3) though it's also only 1 week older then the last (the Decoder part)
and still 720p.mpg crashes with Lav Video DXVA2 Native ;)

Also all of these issues are still the case with Lav DXVA2 Native
https://forum.doom9.org/showpost.php?p=1564452&postcount=9794

CharlieCL

18th March 2012, 15:39

Quick Sync codec can not work in Exclusive Full Screen mode of DirectX in LAV. It was Freeze. In windows it worked fine.

egur

21st March 2012, 03:14

Quick Sync codec can not work in Exclusive Full Screen mode of DirectX in LAV. It was Freeze. In windows it worked fine.

This is something Nev should fix in his code:
Pass the ID3DDeviceanager obtained from EVR.
Call the check() and IQuickSyncDecoder::TestMediaType functions afterwards. These functions will fail otherwise as they try to create a DXVA device. A DXVA device can't be created on its own in full screen exclusive mode (DXVA limitation).
This is what was done in ffdshow although I'm not sure it still works. I'll check it when I return from my trip.

CruNcher

22nd March 2012, 07:12

The WMV3 Bug is in the Quicksync API DXVA VLD works no Decoding issues ;)

http://img513.imageshack.us/img513/2522/intelwmv3fulldxva.png

nevcairiel

22nd March 2012, 07:37

This is something Nev should fix in his code:

If it freezes, thats a bug in your code. :D
It should just fail.

egur

22nd March 2012, 18:35

If it freezes, thats a bug in your code. :D
It should just fail.

It does fail. It can't work in FSE without the receiving the d3d9 device manager. Maybe the return codes are not always checked.

clsid

22nd March 2012, 18:44

@eric
Haruhiko and I are planning to push a new release of ffdshow very soon. Do you have any plans for changes/fixes for which the release should be postponed?

egur

22nd March 2012, 22:07

@eric
Haruhiko and I are planning to push a new release of ffdshow very soon. Do you have any plans for changes/fixes for which the release should be postponed?

I would like to revisit the initialization (TestMediaType) that occurs during full screen exclusive mode (WMC).
My code needs to receive the d3d device manager from EVR prior to any media type checks. In ffdshow these events occur at different times and I need to think about how to solve this so it works OK with IvyBridge's enhanced capabilities.
So current code may not work well in FSE. It should fallback to SW (e.g. libavcodec) and never use HW in FSE.
I'm currently on a business trip and can't test anything. Soonest I can check is on Monday.

BTW, by "release" you mean a new beta or a major release?

CharlieCL

23rd March 2012, 01:18

It does fail. It can't work in FSE without the receiving the d3d9 device manager. Maybe the return codes are not always checked.

Tested the Quick Sync in FFDShow under Exclusive Fullscreen, it only displayed green screen in H.264, sometimes displayed mess pictures for other type of media file.

clsid

23rd March 2012, 18:36

It will be a new major release (v1.2.xxxx). We are no longer going to use the beta tag.

Please let me know when you have fixed the FSE issue and think QS is ready for the release.

egur

26th March 2012, 11:40

Tested the Quick Sync in FFDShow under Exclusive Fullscreen, it only displayed green screen in H.264, sometimes displayed mess pictures for other type of media file.
It very hard to debug FSE since I can only use debugger prints (I don't have 2 monitors) so please help.
Since there are several setups available, please tell me what's yours:
* Screen is connected to iGPU or dGPU?
* Single or multi screen desktop?
* If you select libavcodec for h264 in ffdshow, does it work?
* Do you know which splitter is used?

CharlieCL

26th March 2012, 13:56

It very hard to debug FSE since I can only use debugger prints (I don't have 2 monitors) so please help.
Since there are several setups available, please tell me what's yours:

* Screen is connected to iGPU or dGPU?

Screen is connected to HDMI port in Sandy Bridge i5 2405.
The GPU used is inside the i5.

* Single or multi screen desktop?

Only single screen.

* If you select libavcodec for h264 in ffdshow, does it work?

yes. it worked. In software codec there is no problem. When used FFDShow with Quick Sync in windows the time stamp may be not correct. The motion picture was displayed in pause.

* Do you know which splitter is used?

LAV Splitter.

egur

26th March 2012, 14:13

OK, I'll work on this today.

CruNcher

26th March 2012, 20:33

btw the new driver seems stable as it was before also the 3d performance is ok on the GT1 :) see http://blip.tv/file/get/Cr4bl3r-intelhdrecordingtestx264tuned349.mp4

egur

27th March 2012, 10:34

Version 0.30 beta is out with the following changes:
* Fixed playback under WMC full screen. Unfortunately plays in SW unsupported profiles (only under WMC).
* Fixed a rare freeze.
* FFDShow rev4407

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)

CharlieCL

27th March 2012, 22:12

0.30 version still not worked fine in true full screen. But FFDShow worked fine in windows mode now.

egur

28th March 2012, 08:33

0.30 version still not worked fine in true full screen. But FFDShow worked fine in windows mode now.

I have the exact same setup and it worked. I had issues with VC1 in ts files but they didn't work with libavcodec/wmv3 too. Received bad media sample from LAV splitter (only under WMC).
Note that I didn't test LAV decoder only ffdshow.
The sort of corruptions you report should come from a different decoder. I can't reproduce this. Even in the previous ffdshow builds, QS would fail very early and ffdshow would switch to libavcodec smoothly.

BTW, I use the 2622 driver but any >2509 should be OK. Which one do you use?

CruNcher

28th March 2012, 10:59

@ Egur
it seems either hard or impossible to use Quicksync for Recording the GPU data (3D Game Engine,Direct3D 9) efficiently without impacting the Framerate (of the GT1) more heavily then x264 does on the multiple CPU cores (even @ fast speed and low latency the impact seems higher, and to reach the same quality @ lower overhead seems impossible that way not to speak of better Performance, same situation for anything it seems that needs high EU resources "Video with lot of PP or heavy HTML5 accelerated via Direct2D")
I guess the fact that Motion Estimation is done on the EUs @ the same time (as the heavy (Direct3D 9, Direct2D) GPU utilization, lot of resources are free on the CPU side in most scenarios enough for CABAC even) and obviously x264s heavy optimization plays heavily into this (even with the Paths being shorter the overhead seems to kill its usability for it) :(

I wonder if Ivy Bridge still uses the EUs (Hybrid Design) for ME (i guess not much will have changed ?) and how Nvidia is handling it on their new ASIC Encoder ? :)

egur

28th March 2012, 12:35

QS uses lots of memory bandwidth, so does D3D, so encoding in HW (or SW) affects 3D performance as both CPU and GPU share the same memory controller(s).

I don't think the EUs perform ME. I think all the low level stuff is in ASIC.
I didn't get a chance to read a review on the new Nvidia encoder.
Since most platforms today are mobile, it makes sense to implement video acceleration in ASIC due to its high efficiency (battery life) compared to programmable solutions (CUDA/shaders/OpenCL/etc.)

CruNcher

28th March 2012, 13:56

That it uses the EUs for the ME part was stated in this Article i think it was under Motion Estimation track :) http://software.intel.com/en-us/articles/using-intel-graphics-performance-analyzer-gpa-to-analyze-intel-media-software-development-kit-enabled-applications/

Motion Estimation Track
The Motion Estimation Track is actually the kernel software which runs on the Execution Units (EUs) of the graphics unit. This kernel is executed while adaptively invoking the motion estimation acceleration hardware. The actual behavior depends on the TargetUsage set by the application. Here we can see 4 stages inside the Motion Estimation Track with MFX_TARGETUSAGE_BALANCED mode. The performance of this track depends on the usage parameter, but it is also affected by whether graphics Intel Turbo Boost Technology is on or off.

According to this it's "adaptively invoking the Hardware ME part" not sure what the criteria for this invoking are but execution seems to take place on the EUs never the less the same where the 3D Engine is putting almost full load on (same if you have Aero especially with Glas Shader on dwm puting load to them thus encoding gets slower).
But indeed i see the second GPU Node becoming active when recording which isn't the same node as the D3D rendering takes place on but the same Node where you would also see Decoding utilization so indeed could be ME going on on that Node and the bottleneck is the Bandwith but the Nodes aren't Physically separate units only the Node View (Process Explorer,Process Hacker, Vista,7) shows them as such ?.
I guess i will have to run some experiments also with overclocking the GFX part to see if i @ least reach the Performance of x264 with CABAC.
Trying MFX_TARGETUSAGE_FAST and low latency makes it somewhat less frame dropping on the Game part but also quality of Recording is heavily reduced compared with --subme 2 --dia and crf 23 of x264 Multithreaded on the 4 Cores, though this is still @ sane bitrates i guess the picture would change big time when bitrate and so CABAC utilization is getting higher :)

This is really crazy :) are these High Performance Timers ? http://software.intel.com/en-us/videos/channel/visual-computing/intel-gpa-2012-demo-at-gdc-2012/1532811356001

Im gonna analyze the situation more carefully especially with intels excellent tools and try to find optimization ways, egur do you know something comparable for Windows http://pcitop.berlios.de ? :)

PS: Some to look @ result of mixing things http://forum.doom9.org/showthread.php?t=164555 could even play in the Video Window, also note i didn't used the CQP mode yet which could come closer to CRF ;)

Sorry for the Oftop

CharlieCL

29th March 2012, 00:16

I have the exact same setup and it worked. I had issues with VC1 in ts files but they didn't work with libavcodec/wmv3 too. Received bad media sample from LAV splitter (only under WMC).
Note that I didn't test LAV decoder only ffdshow.
The sort of corruptions you report should come from a different decoder. I can't reproduce this. Even in the previous ffdshow builds, QS would fail very early and ffdshow would switch to libavcodec smoothly.

BTW, I use the 2622 driver but any >2509 should be OK. Which one do you use?

My old driver on Windows 7 64-bit is 2622. Now I installed Windows 8 Consumer Preview. The driver is MS preinstalled original Intel's driver. I heard that Intel's Media driver has not finished so it does not hardware acceleration. On Win8 the new version 0.30 still freeze in Exclusive Fullscreen under FFDShow. In Win8 a picture was displayed and then freeze.

egur

29th March 2012, 08:39

My old driver on Windows 7 64-bit is 2622. Now I installed Windows 8 Consumer Preview. The driver is MS preinstalled original Intel's driver. I heard that Intel's Media driver has not finished so it does not hardware acceleration. On Win8 the new version 0.30 still freeze in Exclusive Fullscreen under FFDShow. In Win8 a picture was displayed and then freeze.

If I understood you correctly, it worked on Win7 but doesn't work on Win8?

@CruNcher
I've asked around for a PCIe measurement tool, I'll get back to you.

CruNcher

29th March 2012, 10:02

@egur
thx :) this is also handy http://software.intel.com/en-us/articles/intel-performance-counter-monitor/ all the tools that are introduced actually from every part of the SB architecture are impressive :)
Just great egur i already analyzed some stuff the ability to see power output (in the analyzer HUD) and other counters in almost Realtime is just great and it's so damn responsive updating you don't even need to guess anymore which frame is causing the bottleneck you have immediate response i love it also the overhead seems really acceptable, and especially seeing it as a Graph + Numbers is much much better then most 3rd party tools do it with just numbers much better temporal tracking of whats going on this way, the same way as in MPC-HCs own Graph debuging it helps so often to find issues either in streams itself or the Player just the resolution needs to be high enough and background noise eliminated Intel GPA does that efficiently in the way Microsoft set it up back with Vista,7 and WPA and in 8 with WPA&WPR adding Intels tools for even more targeted analyzing is a great addition :)

CharlieCL

29th March 2012, 16:26

I removed Windows 7 and installed Windows 8 before 0.30 released. I only tested on Windows 8 now.

GZZ

30th March 2012, 20:46

Maybe a dumb question, I have installed the FFDshow package (0.30) and enabled Intel Quick Sync. So now if I encode a movie using x264 and let it use FFMS (no avisynth or anything, just loading the h264 mkv file). Will it then use intel quick sync to decode the h264 stream and if it does, how do I know if its using intel quick sync ? :)

nevcairiel

31st March 2012, 06:01

wanezhiling

31st March 2012, 07:24

nev did you test 2669?

nevcairiel

31st March 2012, 07:51

No.

I also found a 2696 driver on the Intel website, but the driver zip is password protected, apparently available only under NDA for testing on IVB.

egur

31st March 2012, 13:19

2656 fixes mc.ts clip. Some VC1 corruptions exist in other clips.
2669 fixes all the wmv3 corruptions in my (small) test suite. H264 occasional corruptions still exist. Not sure about VC1 corruptions. No quality regression.
2696 - No VC1 corruptions in my test suite. H264 corruptions (rare) still in place. No quality regression.

CruNcher

31st March 2012, 15:06

I don't think it was mentioned here before, but the 2656 driver is now officially available on the Intel website and does include a new Media SDK library. Quick Tests show that it fixes some VC-1i corruptions.
The same driver from Windows Update did NOT include the new Media SDK library.

32-bit: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3319&DwnldID=21030&ProductFamily=Graphics&ProductLine=Processor+graphics&ProductProduct=2nd+Generation+Intel%c2%ae+Core%e2%84%a2+Processors+with+Intel%c2%ae+HD+Graphics+3000%2f2000&DownloadType=Drivers&lang=eng
64-bit: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3319&DwnldID=21033&ProductFamily=Graphics&ProductLine=Processor+graphics&ProductProduct=2nd+Generation+Intel%c2%ae+Core%e2%84%a2+Processors+with+Intel%c2%ae+HD+Graphics+3000%2f2000&DownloadType=Drivers&lang=eng

WMV3 Hardware acceleration is also active with these drivers, however it does occasionally still show minor corruption.
Still, a step forward.

It only shows corruption in WMV3 for the Quicksync API though it works fine with some 3rd Party DXVA VLD implementations such as Cyberlinks, every bitstream i have tested that showed issues before works perfectly and cpu utilization is super low for anything now VC-1,WMV3,H.264 and MPEG-2 (prefering Nevs DXVA 2.0 implementation for playback of Mpeg-2, though it crashes on 1 bitstream H.264 has still to much stability issues especially no workaround yet for the to much reference frames problem like other implementations have those fixed, i would have a idea for a fix switching to Quicksync from the DXVA Decoder would be a relative simple workaround not sure if the 3rd parties might even do that ;) )

2669 seems to fix all the WMV3 issues for the Quicksync API then as well :)

NOTICE: This download requires a program password to unzip. Contact your Intel salesperson if you received a sample board that requires this driver.

2696 is indeed password protected lol

egur

31st March 2012, 20:18

The password thing is new. OEMs and ISVs usually download drivers and other SW/firmware from the SW support site.

CruNcher

1st April 2012, 11:47

Made a current compare with 2669 on the WMV3 state with the 50 fps Keynote Video, any yup it fixed all Quicksync API Decoding issues :)

Cyberlink DXVA = 1.30%
Media SDK = 2.50%
Lav Video Quicksync = 6.50%
Lav Video (avcodec) = 7.00%
ffdshow Quicksync = 7.50%
WMV Decoder = 7.50%

this includes all overheads (Lav Splitter(except for Media SDK doesn't support Lav Splitter using WMV ASF Reader here),Renderer(EVR basic),Audio(WMAudio),MPC-HC GUI Rendering + Copy Back for Lav Quicksync and ffdshow Quicksync)

This is only CPU utilization was not interested for this part in Memory and GPU ;)

egur

1st April 2012, 18:17

What's the average CPU frequency for these tests?

Omel

1st April 2012, 18:21

Hi t

new drivers as 2669 and 2696 where can i find them. I have tried at downloadcenter.intel.com but can't find them
??

regards

Omel

Superb

1st April 2012, 20:06

Hi t

new drivers as 2669 and 2696 where can i find them. I have tried at downloadcenter.intel.com but can't find them
??

regards

OmelGeez man... read the freakin' comments.

Omel

2nd April 2012, 10:00

Geez man... read the freakin' comments.

Whaoooo.. what a friendly answer thx man

egur

2nd April 2012, 10:18

Hi t

new drivers as 2669 and 2696 where can i find them. I have tried at downloadcenter.intel.com but can't find them
??

regards

Omel

They are not available to the general public yet.
IvyBridge will be out very soon and along with it the new generation of drivers will be publicly available.
Current driver generation (Win7): 15.22.xx.xx
Next driver generation (Win7): 15.26.xx.xx

2622 belongs to the 15.22 family.
2639, 2656, 2669, 2696, 27xx all belong to the 15.26 family.

Since drivers are shared between desktop and mobile systems, they need especially long validation and are not released to the public regularly.
The released/leaked 15.26 drivers were aimed at OEMs and ISVs for validation purposes. End users should that use these versions do this at their own risk.
My personal HTPC uses 2622. It's very stable and has very good performance. I use the newer drivers for testing my code and logging the driver progress (also report issues if I find any).

egur

2nd April 2012, 14:50

@CruNcher
Can you share (or reshare :) ) the clip you tested on (wmv3)?

CruNcher

2nd April 2012, 16:35

Here are pretty accurate measurements 1 minute sure here you can find it http://video.ch9.ms/build/2011/key01/BUILD2011KeynoteDay1_2MB_ch9.wmv :)

High performance Profile

Idle State:

http://img851.imageshack.us/img851/6505/pcidlehighperformance.png

Cyberlink VLD DXVA:

http://img851.imageshack.us/img851/7923/cyberlinkwmv3dxva.png

Intel MSDK:

http://img267.imageshack.us/img267/5195/msdkwmv3nocpb.png

ffdshow-quicksync:

http://img405.imageshack.us/img405/313/ffdshowquicksyncwmv3.png

Lav Video Quicksync:

http://img808.imageshack.us/img808/259/lavvideoquicksyncwmv3.png

Lav Video avcodec:

http://img842.imageshack.us/img842/8941/lavvideowmv3avcodec.png

WMVideo Decoder:

http://img822.imageshack.us/img822/743/microsoftwmvvideo.png

PS: Memory Utilization is not as accurate as everything else, it takes some time to get back to the old memory state so don't compare memory utilization here as i didn't had the time to wait every x minutes to compare exactly with the old state ;)
Also this is awkward it worked out well though it was meant for overclockers and it's not really good from a screen estate state also it's consuming some overhead itself and probably is responsible for a lot of the frequency changes in idle state and some peaks @ measuring as well :P but hey it has a graph yeah :D
Getting High resolution noiseless near realtime measuring results (not pre recorded) directly on the system is always a adventure :)
Perfmon maybe could have done the job as well but i would have had to import the performance counter first for the TDPs Graphic Frequency and then i wonder if Rivatuner wouldn't be actually more efficient as a host for them ;)