On 1 April 2014 15:50, Michael Müller michael@fds-team.de wrote:
Which APIs did you consider for this? What were the various issues? What made you choose VAAPI in the end? Do you have tests for how the dxva / d3d9 interface is supposed to work?
I mostly considered VAAPI and VDPAU for this as they both offer support for multiple vendors.
VDPAU has native support for nvidia, amd (only open source driver) and S3 but not for intel. There is a OpenGL backend for VDPAU which can be used on Intel graphic cards but I expect the video decode engine of Intel to reach a better performance than an implementation which is completely based on OpenGL.
VAAPI has native support for intel, crystal HD decoder, S3 and can also use VDPAU and the amds proprietary XvBA interface. It simply supports everything VDPAU does plus Intel and the proprietary AMD driver. I think that a library which offers support for the most graphic cards is the best possible option for Wine as we do not want to implement these decoders multiple times.
I don't have a particularly strong preference for one or the other, provided it works with the free drivers, but I was hoping for more of an analysis of the actual APIs, and how well they fit with DXVA. That does require figuring out all the D3D / DXVA interactions first, of course. In terms of vendor support, if it comes down to it, I don't think fglrx support is a very convincing argument, and I'm sure Intel would happily accept patches for e.g. VDPAU support. Did you look into OpenMAX at all?
There are currently no tests so far. The reason for this is that mingw does not support the dxva header files and you can not use the hardware decoder in a VM. So I basically wrote some test code in MSVC and tested it on an old laptop which is running Windows 7 with a nvidia 9800 GTS.
VLC wrote some header files for mingw which they use to cross compile VLC, but it does not offer everything we need ( http://www.videolan.org/developers/vlc/modules/codec/avcodec/dxva2.c ). Maybe whe can use the wine header file or ship a more complete version to allow cross compiling.
I'm not sure how you're currently writing tests, but unless you have a good reason not to, you probably should be using "make crosstest".