[ACCELERANTS] Intel SandyBridge

[forart.it]

It would be great to have hardware accelerated decoding support for Intel SandyBridge GPUs.

Here's the FFDShow-related project: Intel SandyBridge hardware accelerated FFDShow decoder (H264/VC1/MPEG2).

Source code

I hope that the author (Eric Gur, Processor Client Application Engineer @ Intel Corp.) could be involved too.

[VLC_help]

Better thing is to integrate pure decoder stuff to libavcodec. DXVA support should work with SandyBridge GPUs.

[forart.it]

Eric is coming...

I'll join, VLC was on my radar.

[Jean-Baptiste Kempf]

Eric is coming...

I'll join, VLC was on my radar.

This is great news!

[egur]

Hi all, took some time to register as he forum rejects my home IP for some reason...
Anyway, there are a few differences between what I did for ffdshow and using DXVA natively.
1) Support for HW VC1 decode.
2) Images are copied back to system memory for normal SW processing.
3) Much more robust than Microsoft's DTV-DVD decoder and ffdshow DXVA. Plays many more clips, less artifacts.
4) Time stamp correction + automatic inverse telecine. Support variable frame rates.
5) Support multi GPU via simple one time setup. E.g. decoder will use Intel GPU (can be disconnected), renderer can use the GPU connected to the screen. No DXVA implementation enables this.

About integration:
1) Decoder code is DLL (open source - soon in SourceForge) with no dependency on ffdshow. Depends on standard Microsoft libraries (Windows SDK) and the Intel Media SDK. The latter will be bundled with the source code (very small footprint).
2) Still in alpha stage. Interfaces can change. Not feature complete.

Future plans:
1) Build proper SourceForge project for the decoder.
2) Merge with ffdshow's main source trunk.
3) Add HW video processing (deinterlacing, noise reduction, sharpness, color, scaling)

If anyone is interested, please visit my doom9 thread at:
http://forum.doom9.org/showthread.php?t=162442

Eric Gur, Processor Client Application Engineer
Intel Corp

[Jean-Baptiste Kempf]

Hello Eric,

Thanks for joining around here, and sorry for the difficulty for registration (but we've had major spam issues and we are very under-staffed).

Let me comment a bit on your post.

0) We don't use DxVA in VLC, but only DxVA2. I agree it is an horrible piece of crap as an API.
1) I think we are able to decode VC1 in DxVA2, but I don't know if this is for all hardware.
2) We copy back to system memory after the decoding stage, even with DxVA2, because this is a proper separation of stages in the pipeline.
3) VLC DxVA2 has still many artefacts, but some are our faults and got fixed in VLC 1.2. Some are still untested and unreproducable.
4) IVTC? nice! variable frame rates? very nice!
5) Are you sure? I thought I had the case with decoding on an nVidia GPU and display on an ATI one in VLC 1.1. I may be mistaken, of course.

0) open source, cool!
1) Is the Intel Media SDK GPL compatible?
2) expected. Not a problem for us.

One issue we have with Intel hardware, IIRC, were the non-standard GUID used for DxVA2.

Questions:
- encoding at some point? or just decoding?
- I guess you will add more filtering, do you intend to do deinterlacing and colorspace conversions too?

Thanks a lot.

[egur]

2) We copy back to system memory after the decoding stage, even with DxVA2, because this is a proper separation of stages in the pipeline.

I know, I saw your code. After consulting with CPU architecture, I modified the copy function I use to make it a little faster.

5) Are you sure? I thought I had the case with decoding on an nVidia GPU and display on an ATI one in VLC 1.1. I may be mistaken, of course.

I'm not aware of hybrid GPU playback before my project, but I could be mistaken. Anyway I enabled it in a DirectShow environment so most players can use it.

1) Is the Intel Media SDK GPL compatible?

No problem. It's made so everyone can use it. Closed or open source.

One issue we have with Intel hardware, IIRC, were the non-standard GUID used for DxVA2.

Not really my ballpark - I don't use DXVA directly. I use the Intel Media SDK.

Questions:
- encoding at some point? or just decoding?
- I guess you will add more filtering, do you intend to do deinterlacing and colorspace conversions too?

- Encoding seems impossible with my current resources. But who knows.
- Yes, deinterlacing is probably the most improtant. Color space conversion must be in the renderer - performance overhead would be huge, also scaling is better done in YCbCr.
I'll add the post processing features after I submit my code in SourceForge and modify the API for simple integration with other projects. API requirement are welcome.

BTW, I still can't login from home, I've sent a mail to report this. Until this is solved, my responses are limited to work hours.

[Jean-Baptiste Kempf]

2) We copy back to system memory after the decoding stage, even with DxVA2, because this is a proper separation of stages in the pipeline.

I know, I saw your code. After consulting with CPU architecture, I modified the copy function I use to make it a little faster.

Cool.

5) Are you sure? I thought I had the case with decoding on an nVidia GPU and display on an ATI one in VLC 1.1. I may be mistaken, of course.

I'm not aware of hybrid GPU playback before my project, but I could be mistaken. Anyway I enabled it in a DirectShow environment so most players can use it.

OK. VLC is not DShow, though...

1) Is the Intel Media SDK GPL compatible?

No problem. It's made so everyone can use it. Closed or open source.

That is cool. That isn't what other people from Intel told me.

One issue we have with Intel hardware, IIRC, were the non-standard GUID used for DxVA2.

Not really my ballpark - I don't use DXVA directly. I use the Intel Media SDK.

OK I had to try, though

Questions:
- encoding at some point? or just decoding?
- I guess you will add more filtering, do you intend to do deinterlacing and colorspace conversions too?

- Encoding seems impossible with my current resources. But who knows.
- Yes, deinterlacing is probably the most improtant. Color space conversion must be in the renderer - performance overhead would be huge, also scaling is better done in YCbCr.
I'll add the post processing features after I submit my code in SourceForge and modify the API for simple integration with other projects. API requirement are welcome.

Thanks for the answers...
From a VLC point of view, the easiest the API is, the best it is (ie, NOT like DxVA2). CrystalHD codec example is a good example; DxVA or VDA, that require libavcodec are not cool.

BTW, I still can't login from home, I've sent a mail to report this. Until this is solved, my responses are limited to work hours.

Please mail me your IP and time of connexion.

[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.)

[Jean-Baptiste Kempf]

Really cool.

[forart.it]

...any news ?

[egur]

...any news ?

Been very busy lately...
I have a working version that enables WMC full screen playback as well as a configuration method (enable/disable features). I need a few more days of testing and I'll post a new version.
DXVA surface output will have to wait for the next version.
Eric

[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