It is only after so many years of trying that ATI has started supporting Linux in a decent manner wrt video decoding. Intel has just now started paying attention to us.. I think this is a great first step!
ffdshow works so well because of the direct-show framework. Microsoft actually has a cohesive API for video acceleration and codec management.
Linux on the other hand depends on different implementations depending on the video hardware in use. I think only Nvidia successfully has video acceleration working on linux, by basically porting their Windows implementation to Windows and skipping the linux stack entirely.
No he opted for Intel Media SDK which is only available on Windows and uses Microsofts tech. OS X and Linux got nothing like it from Intel. Obviously he is not doing hardware/driver engineering, it's an abstraction layer not low-level hw access. You can use VA API/libVA for it -- both decoding and encoding on Linux systems though. On OS X your pretty much screwed no matter what hardware you have (Intel, Nvidia, or AMD). Apple or their partners has no coherent API's for video stuff, they all do their own things internally and Quicktime uses that as it pleases, no public API's to speak of. Not even per vendor. Guess you have to write your custom stuff with OpenCL and Cuda (think LAV CUVID and custom OGL overlay if nVidia as they can will support the video features through the third party CUDA-driver and VDPAU through that) as well as your own CPU optimizations there, but the cpus should be plenty fast.
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!
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.
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.
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.
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.
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.
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.
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.
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.
Projects like this deserve recognition. Hats off to you, Mr. Gur; if you're ever in southwest Michigan, I'll buy you a good brew (or two) for your efforts.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
23 Comments
Back to Article
gvaley - Thursday, September 29, 2011 - link
Windows-only. Sigh.ganeshts - Thursday, September 29, 2011 - link
ffdshow = Windows only :)It is only after so many years of trying that ATI has started supporting Linux in a decent manner wrt video decoding. Intel has just now started paying attention to us.. I think this is a great first step!
gvaley - Thursday, September 29, 2011 - link
Considering that ffdshow is more or less a Windows port of FFmpeg, one would expect this to be backportable to any platform.Unfortunately, Eric Gur still opted for Intel's QuickSync SDK which is Windows-only.
hechacker1 - Thursday, September 29, 2011 - link
ffdshow works so well because of the direct-show framework. Microsoft actually has a cohesive API for video acceleration and codec management.Linux on the other hand depends on different implementations depending on the video hardware in use. I think only Nvidia successfully has video acceleration working on linux, by basically porting their Windows implementation to Windows and skipping the linux stack entirely.
Penti - Thursday, September 29, 2011 - link
No he opted for Intel Media SDK which is only available on Windows and uses Microsofts tech. OS X and Linux got nothing like it from Intel. Obviously he is not doing hardware/driver engineering, it's an abstraction layer not low-level hw access. You can use VA API/libVA for it -- both decoding and encoding on Linux systems though. On OS X your pretty much screwed no matter what hardware you have (Intel, Nvidia, or AMD). Apple or their partners has no coherent API's for video stuff, they all do their own things internally and Quicktime uses that as it pleases, no public API's to speak of. Not even per vendor. Guess you have to write your custom stuff with OpenCL and Cuda (think LAV CUVID and custom OGL overlay if nVidia as they can will support the video features through the third party CUDA-driver and VDPAU through that) as well as your own CPU optimizations there, but the cpus should be plenty fast.mister_cow - Sunday, October 2, 2011 - link
Whoa an Intel engineer opts to use an Intel SDK. How unusual!JKflipflop98 - Monday, October 3, 2011 - link
Well, they are the best.jalexoid - Thursday, September 29, 2011 - link
If Linux graphics stack wasn't such a CPU hog, then maybe...(and I'm talking as an Ubuntu user)
Malih - Thursday, September 29, 2011 - link
well, these days new PCs and Laptops come with Windows installed, so 'Windows-only' should not be a problem for most people.LoneWolf15 - Thursday, September 29, 2011 - link
A guy takes his own personal time to develop something useful.And then gets crapped on because it wasn't for Linux.
Hmm...
Hey, I've got an idea...why don't you apply for the information needed and then take the time to code something like this for Linux?
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.
azcoyote - Thursday, September 29, 2011 - link
Does this still require the special chipset or will my P series benefit?JarredWalton - Thursday, September 29, 2011 - link
To access Quick Sync, you need a chipset that supports the IGP, so only H6x and Z68 will work (and maybe some of the Q6x stuff).LoneWolf15 - Thursday, September 29, 2011 - link
Projects like this deserve recognition. Hats off to you, Mr. Gur; if you're ever in southwest Michigan, I'll buy you a good brew (or two) for your efforts.