View Full Version : Intel QuickSync Decoder - HW accelerated FFDShow decoder with video processing
CruNcher
2nd April 2012, 17:23
Im using High Performance Profile not balanced for testing i like to see it the other way and keep the system from fluctuating to much when running measurements and use balanced when testing responsiveness (latency) (Frequency adaption impacts) ;)
Though SB and NT 6 are very efficient in those regards but i keep with this way of testing :)
The Frequency goes down look @ the Cyberlink DXVA and MSDK no copy back result and the difference from 5W to 8W = +3W and 1W to 4W = +3W why should they be meaningless ? :)
DXVA = +3W
MSDK = +4W + 1W
Avcodec = +6W
WMvideo Decoder = +6W + 1W
ffdshow-quicksync = +7W + 1W
Lav Video Quicksync +7W + 1W
what should be wrong here (also keep in mind this is complete overhead of the playback including Client,Splitter,Decoder(Video,Audio) and Renderer) ?
CruNcher
2nd April 2012, 18:26
VLC almost got it right (guess most of the VLC Linux guys hate DXVA by now ;))
http://forum.doom9.org/showpost.php?p=1568136&postcount=19182
Omel
2nd April 2012, 19:14
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).
Thanks Egur that was the information i was looking for.
that explain a lot for me
best regards
Omel
Omel
2nd April 2012, 19:23
@Egur
Hi
I am a little confused, under downloadcenter.intel.com I find one driver under Graphics/processor and another under my Mainboard DH67GD which one wil be the correct to use?
my processor is a I3 -2100T?
Best regards
Omel
egur
2nd April 2012, 22:37
@Egur
Hi
I am a little confused, under downloadcenter.intel.com I find one driver under Graphics/processor and another under my Mainboard DH67GD which one wil be the correct to use?
my processor is a I3 -2100T?
Best regards
Omel
For desktops use the newest you can find.
egur
3rd April 2012, 11:34
Im using High Performance Profile not balanced for testing i like to see it the other way and keep the system from fluctuating to much when running measurements and use balanced when testing responsiveness (latency) (Frequency adaption impacts) ;)
Though SB and NT 6 are very efficient in those regards but i keep with this way of testing :)
The Frequency goes down look @ the Cyberlink DXVA and MSDK no copy back result and the difference from 5W to 8W = +3W and 1W to 4W = +3W why should they be meaningless ? :)
DXVA = +3W
MSDK = +4W + 1W
Avcodec = +6W
WMvideo Decoder = +6W + 1W
ffdshow-quicksync = +7W + 1W
Lav Video Quicksync +7W + 1W
what should be wrong here (also keep in mind this is complete overhead of the playback including Client,Splitter,Decoder(Video,Audio) and Renderer) ?
I'm getting 3-5% CPU usage (i7-2600) for the player's executable (ZoomPlayer) when playing this clip using ffdshow+qs+EVR. The CPU frequency is 1600MHz (LFM).
Summary (wmv9, 60fps, 6mbps, progressive, NV12 output, no post procesing):
ffdshow+QS: 3-5% @1600MHz
ffdshow+wmv9: 6-7% @3600MHz
ffdshow+libavcodec: 4% @2000MHz - fluctuates a lot
Omel
3rd April 2012, 12:05
For desktops use the newest you can find.
I use it as a mediaplayer (mediaportal) with TV and Movies and use LAV filters the latest ?
Will the latest intel driver be the optimal driver ? or should I use the 2622 driver as you said previously ?
kind regards
Omel
egur
3rd April 2012, 12:07
I use it as a mediaplayer (mediaportal) with TV and Movies and use LAV filters the latest ?
Will the latest intel driver be the optimal driver ? or should I use the 2622 driver as you said previously ?
kind regards
Omel
Always use latest LAV and/or ffdshow.
With drivers, the performance differences are small and should not concern you. Just use the latest.
CruNcher
6th April 2012, 06:58
@Egur
http://forum.doom9.org/showpost.php?p=1568698&postcount=10281
Am i right and Microsofts DTV Decoder acts as a Quicksync API Wrapper ?
This would make major sense as you would have full control on a higher level off every Application output that makes use of it, i guess virtually all GPU Vendors will handle it this way and take control over it with their Native ways :)
egur
6th April 2012, 12:14
@Egur
http://forum.doom9.org/showpost.php?p=1568698&postcount=10281
Am i right and Microsofts DTV Decoder acts as a Quicksync API Wrapper ?
This would make major sense as you would have full control on a higher level off every Application output that makes use of it, i guess virtually all GPU Vendors will handle it this way and take control over it with their Native ways :)
Microsoft DTV Decoder most likely uses DXVA2.
It might use low level DDI calls but that would make very little sense.
The DTV decoder probably initializes the DXVA device differently somehow. It may also parse SPS/PPS headers for errors and try to recover them.
Part of the QuickSync feature set is exposed via the DXVA2 API (decode, vpp), the rest (encode) is done via DDI calls as DXVA2 doesn't support encode.
There's no official QuickSync API. The APIs used under Windows are Media SDK, DXVA2, DDI.
CruNcher
6th April 2012, 15:43
thx egur indeed i wonder if the DTV Decoder can be used as a supplier for encoding with quicksync fast as Lav Video DXVA Native can't and Copy back shows lower performance then intels own Decoder connected to it :) (faster encoding speed with it)
Though the DTV Decoder must as you said use a different initialization it handles bitstreams that even Cyberlink fails on partly even Arcsoft and i saw that yet only either that Quicksync (MSDK API) Decoder handling (ffdshow-quicksync, lav-quicksync) or Intels Native MSDK Decoder.
Though that Microsoft can't have thought into the future made me wonder what mode it calls that seems to give a perfect result on Intel Hardware or Intel takes over the calls it does (hooks somehow into it) and directs it to MSDK via the Driver that would make the most sense to me, and explain the same decoding issues.
I don't take this with the Recovery because you don't need recovery to handle MBAFF streams correctly and those fail neither the same as bitstreams with to much references (which seems to be a explicit MSDK fix) with the DTV Decoder nor any MSDK based one but practically currently with most other DXVA implementation @ Least Lav DXVA (Laurents DXVA2 implementation from VLC) shows problems MPC-HCs DXVA does it more correct (though it has disturbed frame issues @ seek currently for practically every bitstream) i guess a compare of how both handling it would shed some light whats going on :)
This also made me believe a good idea for Lav DXVA would be to skip Laurents DXVA2 for Intel and connect to the DTV Decoder like being done with the DMO Decoder for VC-1 and use AVcodec as the fallback for non DXVA, this should also fix the 720p.mpg crash without big effort :)
Every Decoding issue though most probably needs to be directly fixed by Intel then and seeing that their is no progress with decodinerror.ts and MSDK makes me wonder how problematic this issue must be also seeing Laurents DXVA2 in Lav DXVA falling apart on it completely but MPC-HC DXVA handling it without problems melts my brain ;).
nevcairiel
6th April 2012, 16:44
You cannot access Microsofts DXVA decoder directly.
The DMOs are directly designed to allow that, the DTV-DVD Decoder is not a DMO, its a pure DirectShow/MF Filter.
You can use the Microsoft DirectShow decoder directly though, no reason to wrap it into something else.
For Encoding its probably not helpful, because it only supports "native" DXVA and not a copy-back mode, as required for encoding.
Anyway, if you look hard enough you'll find a stream that fails with every decoder sooner or later.
I don't care for Intel support in my DXVA implementation. Intel does not support 100% vanilla DXVA, and they don't document their differences properly (or they don't make those documents publicly available). So, why bother? Can always use the MSDK based Decoder, it works better with every driver release.
As long as my DXVA works fine with AMD and NVIDIA, all is fine. And your broken streams are usually fine on those.
So, you can stop posting streams that are broken only on Intel DXVA2, i don't care anymore (actually, i never cared). Use MSDK.
At some point in time, i'm sure we can also produce a "native" mode decoder with MSDK, without copy-back i mean, but its really low priority.
CruNcher
6th April 2012, 16:57
The problem is the DTV Decoder has no fallback, it accepts everything so there is only the way over the splitter or the Host Application to handle this :(
wanezhiling
6th April 2012, 17:09
CruNcher, where can I find MSDK based Decoder? thx
nevcairiel
6th April 2012, 17:10
LAV and ffdshows QuickSync decoders are based on the MSDK.
There is also a demo decoder which comes with the MSDK itself.
CruNcher
6th April 2012, 17:10
As i said you can use the DTV Decoder results are practically the same or use Intels SDK Decoder in MSDK it is a Native (non copy back) Quicksync Decoder (it gives the best performance with the encoder though) but it has it's quirks too.
Mpeg-2 wise i find Lav DXVA2 native decoder gives the best performance though it produces this crash with 720p.mpg in ntdll which it shares with many other implementations.
wanezhiling
6th April 2012, 17:34
The Intels SDK decoder in MSDK is a mft decoder? How can i use it in mpc-hc or potplayer .etc
CruNcher
6th April 2012, 17:56
2 decoder samples are included 1 mft 1 dshow
wanezhiling
6th April 2012, 18:03
:)I see. thx
hajj_3
6th April 2012, 18:07
ivy bridge motherboards went on sale today, does that mean we will be getting new stable graphics drivers soon egur?
nevcairiel
6th April 2012, 18:09
The driver is really more for the CPU then the board, and that will be a few more weeks.
Anyway, boards have been available here throughout the past week, and i already have one sitting here.
On that note, the 2712 driver appeared on the Intel website (again passworded), but the driver on the CD that came with the board is only 2598.
hajj_3
6th April 2012, 18:23
if the driver is in a .zip file i can try and crack it with password cracking software.
CruNcher
6th April 2012, 18:43
Intel wont be so dumb and use anything under AES or a easy word, so unless you working @ the NSA good luck so better wait till it's released officially (or unofficially) saves you energy and doesn't pollutes our environment for nothing ;)
PS: Though who knows if it was prepared by the PR guys everything seems possible, but for that case you have company standards ;)
2696 leaked
Driver Revision: 15.26.8.64.2696
March 23, 2012
************************************************************
*
* NOTE: This document refers to systems containing the
* following Intel chipsets/processors:
*
*
* 3rd generation Intel(R) Core(TM) processors
* 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
The Denoiser PP can now be selected to be applied either on Luma only or on Luma + Chroma :)
no decoding changes
No immediate crash for Potplayers DXVA anymore :)
http://forum.doom9.org/showpost.php?p=1568833&postcount=2381
egur
7th April 2012, 15:58
ivy bridge motherboards went on sale today, does that mean we will be getting new stable graphics drivers soon egur?
Yes, driver 2656 (15.26) is now available from the download center (graphics->processor graphics). This version fixes some of the decode problems but if I remember correctly HW WMV3 is not perfect.
I can assume that the 15.26 driver family will stay with us for the next year.
2712 didn't make or break anything in my video test suite (decode) compared to 2669 or 2696.
The separation of luma/chroma noise reduction is new.
egur
7th April 2012, 16:04
thx egur indeed i wonder if the DTV Decoder can be used as a supplier for encoding with quicksync fast as Lav Video DXVA Native can't and Copy back shows lower performance then intels own Decoder connected to it :) (faster encoding speed with it)
.
Technically yes. You can write a DS filter that behave like EVR and accepts DXVA surfaces from the decoder. The encoder can copy-back the frames and send them to the encoder.
It sounds like a lot of work with very little in return.
Surfn
8th April 2012, 09:33
The driver is really more for the CPU then the board, and that will be a few more weeks.
Anyway, boards have been available here throughout the past week, and i already have one sitting here.
On that note, the 2712 driver appeared on the Intel website (again passworded), but the driver on the CD that came with the board is only 2598.
abit of topic but would it be ok to ask which z77 board you went for nev
nevcairiel
8th April 2012, 09:41
I got the P8Z77-M PRO from ASUS.
CruNcher
8th April 2012, 16:55
Hmm was it the same Again Asus and Intel boards first available, my main Bord decission for SB back then was initialy MSI but as said it was non available @ that early days ?
Welcome in the M PRO club i guess not much will have changed in that Board series and it will come with Protect 3 ? ;)
Though nobody really ever made a test to my known about Protect 3 and if it really does what it's advertised for ;) but if they make a special board of this series for enterprises with that same guarantee i guess it can't be that bad ;)
Though the first tests of their EPU Chip didn't looked that good back then and even Intel boards beat it in Power Consumption (Reference boards).
PS: 2696 are released now http://downloadmirror.intel.com/21159/eng/ReleaseNotes_GFX.htm
endiz
12th April 2012, 20:02
Hi Eric, is there any chance you will backport this for ffmpeg?
egur
12th April 2012, 20:53
Hi Eric, is there any chance you will backport this for ffmpeg?
No, I don't have the bandwidth for it.
Schrade
12th April 2012, 21:38
PS: 2696 are released now http://downloadmirror.intel.com/21159/eng/ReleaseNotes_GFX.htm
Proper links to download the drivers:
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21159&lang=eng (32-bit)
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21160&lang=eng (64-bit)
endiz
13th April 2012, 00:26
No, I don't have the bandwidth for it.
I understand. Thanks for the quick response!
CruNcher
13th April 2012, 11:37
2712 also leaked (was released through OEM) without IVB support http://www.station-drivers.com/forum/viewtopic.php?t=3741&p=13815
you need again to add the subsys id of your vendor to make it work, works fine so far no issues yet though also doesn't fix decodinerror.ts yet.
pulbitz
14th April 2012, 13:07
I've reproduced/confirmed the issue on another player. Still root causing it.
Bump.
Maybe You forget it?
P.S. LAV QuickSync, PotPlayer QuickSync is OK. Only ffdshow QuickSync has a trouble.
egur
15th April 2012, 07:47
Bump.
Maybe You forget it?
P.S. LAV QuickSync, PotPlayer QuickSync is OK. Only ffdshow QuickSync has a trouble.
I've patched my code a while back when the post was new. This clip is part of my test suite.
I'll check again with the latest ffdshow using LAV and Haali splitters and report back.
CruNcher
16th April 2012, 21:07
Hey i just read that
Khenglish confirms 295.xx beta desktop driver drives the internal LCD in additional to providing the x1 pci-e compression making it unnecessary to use the modded Verde driver below.
It seems Nvidia is preparing Synergy (Optimus for Desktops, Lucid Virtu counterpart) into the Main Driver Stack (Framebuffer exchange) , so it cant be much long anymore before time to market is coming (i wonder if currently anyone is testing it under NDA by now already) :)
Maybe they wait for Ivy Bridge Release ;) would make sense, though not nice to think about that SB users might not profit then again from it if it gets marketed Ivy Bridge exclusive hopefully not again MB exclusive though Nvidias plans where not todo that but still it needs a key in the Bios like Virtu (how i hate such things).
Many things Nvidia added now into the driver stack make it to some kind of enhanced Virtu like Lucidlogix is gonna market with the Universal and MVP series, so this will be really interesting how this here turns out it could also very well explain why Lucidlogix is preparing to sell their Virtu soon to anyone MB license independent ;)
Btw lucid released something new from their Labs of Framebuffer Manipulation ideas ;) http://eshop.lucidlogix.com/?q=dynamix1
these Israeli Researcher have implemented some similar thing to Intels Dynamic Resolution http://software.intel.com/en-us/articles/dynamic-resolution-rendering-article/ as a addon for Skyrim to show the Performance improvements that can gained from a Engine (Creation Engine,Modified Gamebryo Engine) not supporting it :D
The solution aims to enable a playable performance (fps) by dynamically transforming texture resolution mapped on objects in real time, considering object visibility and motion.
All informative elements , such as HUDs, texts, menus and maps remain unchanged and presented in full resolution.
The solution maintains the maximum possible visual experience while increasing game frame rate, bringing it to a playable performance level.
Though the License Process is awkward for something they call free they want you entire Data, and it's bound to a activation server as well geez :P
Though Game Developer have to implement it directly not some 3rd party via a addon interfering into the rendering, also the use for older Games and 3D Engines is near 0, guess this idea of them commercializing this will die fast, i guess next out of their Labs will be some 3D stuff ideas as addon from them stay tuned :P
egur
17th April 2012, 20:39
Bump.
Maybe You forget it?
P.S. LAV QuickSync, PotPlayer QuickSync is OK. Only ffdshow QuickSync has a trouble.
I don't see any issue using LAV splitter - 32 bit playback.
pulbitz
18th April 2012, 12:00
I don't see any issue using LAV splitter - 32 bit playback.
strange...
I test MPC-HC, KMPlayer and PotPlayer with LAV splitter 32bit.
Only ffdshow QuickSync like yadif output mode 25p/30p.
Other(LAV QuickSync, PotPlayer QuickSync, DXVA and libavcodec) like yadif output mode 50p/60p.
P.S. another sample file http://www.sendspace.com/file/whr0pa
egur
18th April 2012, 12:18
strange...
I test MPC-HC, KMPlayer and PotPlayer with LAV splitter 32bit.
Only ffdshow QuickSync like yadif output mode 25p/30p.
Other(LAV QuickSync, PotPlayer QuickSync, DXVA and libavcodec) like yadif output mode 50p/60p.
P.S. another sample file http://www.sendspace.com/file/whr0pa
Which renderer is used in MPC-HC?
Does it work with standard EVR?
FYI, EVR-CP is known to have issues which I can't solve.
Does anyone else have issues with this clip?
pulbitz
18th April 2012, 14:55
Which renderer is used in MPC-HC?
Does it work with standard EVR?
FYI, EVR-CP is known to have issues which I can't solve.
Does anyone else have issues with this clip?
I tested with standard EVR. (I don't use EVR-CP.)
CPU/GPU: i5-2500 with HD Graphics 2000
OS: Windows 7 Ultimate x64 SP1
Driver: 2696
egur
18th April 2012, 15:00
I tested with standard EVR. (I don't use EVR-CP.)
I'll test it with MPC-HC+EVR and report back.
Update
Works fine in the above configuration. Can't reproduce.
Second clip plays fine too.
tomos
18th April 2012, 22:06
hi,
just tried this today on my new laptop (win7x64 ult / 2670qm i7) in mpc and it worked like a charm. no probs at all on a few different samples.
thanks :)
pulbitz
19th April 2012, 15:02
I'll test it with MPC-HC+EVR and report back.
Update
Works fine in the above configuration. Can't reproduce.
Second clip plays fine too.
It is very wired.
Then problem cannot be resolved in the future. :scared:
I'll just have to wait.
JohnPeterson
20th April 2012, 11:46
What about QSV encoding through ff_vfw.dll?
The availability of an open QSV encoder would encourage QSV encoding implementation in popular encoding software such as VLC. It would make sense to have a #transcode{venc=qsv) option in VLC.
ajp_anton
22nd April 2012, 01:45
I get glitches when decoding this with QuickSync. Software decoding works fine.
http://www.multiupload.nl/9YC1XS9JNY
egur
22nd April 2012, 09:47
I get glitches when decoding this with QuickSync. Software decoding works fine.
http://www.multiupload.nl/9YC1XS9JNY
I'll check it out but please provide more details (player/renderer/splitter)
ajp_anton
22nd April 2012, 14:20
I use MPC-HC, LAV splitter and madVR/EVR, but it looks very much like a decoder-only problem.
pulbitz
22nd April 2012, 16:18
I get glitches when decoding this with QuickSync. Software decoding works fine.
http://www.multiupload.nl/9YC1XS9JNY
I test with 2696 driver.
libavcodec is OK.
H/W decoders get glitch.
(MS DTV-DVD DXVA, PotPlayer DXVA/QS, ffdshow QS)
CruNcher
22nd April 2012, 16:32
yup same here every DXVA implementation fails too, very strange artficating could be custom matrix caused
http://img9.imageshack.us/img9/2373/quicksynccmfail.png
vivan
22nd April 2012, 16:45
CUVID also has artefacts (http://3.firepic.org/3/images/2012-04/22/ks0g0rjgioqo.png) (much smaller, though)...
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.