Intel Engineer Ports QuickSync Video Decoding to FFDShow
by Anand Lal Shimpi on September 28, 2011 6:59 PM EST- Posted in
- CPUs
- Intel
- Sandy Bridge
- Quick Sync
An Intel engineer by the name of Eric Gur started an AVSForum thread indicating he had begun work on enabling Quick Sync support in FFDShow's video decoder. Quick Sync is typically known as Intel's hardware accelerated transcoding engine found in Sandy Bridge, however there are both encode and decode aspects to the engine. Gur's work focuses on the latter.
To access Intel's hardware video decode acceleration application developers typically turn to the DirectX Video Acceleration (DXVA) API. Sandy Bridge's hardware decode engine interfaces with DXVA and can return decoded frames not run on the x86 CPU cores. As we've lamented in the past, open source DXVA decoders haven't typically worked all that great for Sandy Bridge (or previous generation Intel GPUs, for that matter). FFDShow users have often avoided DXVA solutions as they can't be used with any custom post processing FFDShow filters.
Gur's Quick Sync filter for FFDShow gets around all of this. By accessing SNB's video decoder through Quick Sync, FFDShow gets full hardware acceleration by going through the Intel Media SDK and not through DXVA directly. It can also be used on non-Sandy Bridge systems, but, with higher CPU usage. The filter is obviously unsupported software but head on over to AVSForum if you're interested in checking it out. If you want more technical details check out the related thread on the Doom9 Forums.
Source: AVSForum
Facebook
Twitter
RSS
23 Comments
View All Comments
Spazweasel - Friday, September 30, 2011 - link
But we're entitled! To free stuff! And we get to crap on the people we take free stuff from (well, free for me anyway, it costs others but WHO CARES)! Because we're entitled! And don't want to do the work ourselves! Let someone else do it! And give it to us for free! Because we're ENTITLED!I think that pretty much sums it up.
Joe H - Thursday, September 29, 2011 - link
This is fantastic news. Now all we need is for an Intel engineer to allow X264 access to the QuickSync encoding engine low level API and we can get some real high quality hardware accelerated H264 encoding.mariush - Thursday, September 29, 2011 - link
That's not gonna happen. Intel is not willing to expose all the high level functions of Quicksync, they want people to use their sdk and all the other code they've written.Basically, what they're willing to offer is like a black box - send the picture to Quicksync and get the h264 encoded picture back - useless for the x264 developers.
brucek2 - Thursday, September 29, 2011 - link
Can you elaborate on why this is? Not doubting you -- since the lack of QuickSync in any widely used software is undeniable -- I just don't understand it.I would've thought Intel's #1 goal would be to sell more chips, which would be best served by making their unique capabilities exposed via real world applications.
Unfortunately it seems QuickSync is just something we read about on blogs like Anand's, but are never able to actually take advantage of. What a waste.
Penti - Thursday, September 29, 2011 - link
They have the Intel Media SDK for it and everybody uses it including this project and that should be fine. It's more then most have to help. x264 however is a software encoder and the whole project becomes essentially useless if they switch their software for a hardware implementation. Just switch out x264 for a different solution if you like hw accelerated encoder then.Joe H - Friday, September 30, 2011 - link
Dark Shikari, the lead developer of X264, has hinted that there are aspects of QuickSync that would greatly speed up the X264 rendering time if Intel gave them low level access to the API (not the high level SDK, which is useless for any software renderer). Basically there are certain operations that X264 could send to QuickSync instead of sending them to the CPU that QuickSync would handle much faster. However, Intel has made little to no indications they are open to opening QuickSync up. It is really too bad for Intel, they are simply losing out on an incredible opportunity to make their chips more attractive.Penti - Saturday, October 1, 2011 - link
Well I'm pretty sure there are no such low-level API's to be exposed without writing a framework for x264s homebrew codec. Which wouldn't be what they would ask for anyway. Not is it a DSP for that sort of thing either. It would have many limitations for a project like a software encoder that wants to control everything by their own means. I'm sure they could be helped by using quicksync to decode the incoming video frames though. It's usually used with a none accelerated ffmpeg frontend.No one has that kind of low-level access open to their video ASICs in their gpus anywhere so they are not really missing out on anything. They adding QuickSync-accelerated features to Intel IPP wouldn't mean x264 would use that any way. I don't see x264 project to be interested in more then CPU accelerated techniques any where in the foreseeable future.
fic2 - Thursday, September 29, 2011 - link
I don't think it is surprising that QuickSync isn't more supported since it seems they made the decision to only support is on certain chipsets and only on certain configurations of those chipsets. Then their new low end line has QS disabled - the G series.Alexvrb - Thursday, September 29, 2011 - link
No to mention that although it is extremely fast, the QUALITY of the Quicksync black box leaves much to be desired. Software-based x264 encodes are much slower, but they also look much better at the same settings. For something you're archiving, this is important. For something you're just quickly re-encoding to play back on your portable device, quicksync is fine.The quicksync decode side is fine, however. Then again, you can decode on just about anything these days, GPU accelerated.
mister_cow - Sunday, October 2, 2011 - link
Most initial reviews did show that QSync decode quality was much better than AMD or NVIDIA.Encode quality was not as good as a pure software solution, but likewise still better than solutions from the discrete GPU manufacturers.