NVIDIA To Create Protocol For VDPAU

[gbeauche]

If that is what you care about I have to ask again why you settled for VA-API.

VDPAU did not exist at that time. I don't mind how many players are using this or that API, I care about existing capabilities and drivers for our solutions. Our solutions cover AMD, Intel, NVIDIA products and I wanted a single API. I picked what worked well first. And between VA API and XvBA, the choice was obvious (openess was one criterion, among others).

[Kano]

As it seems you are the one to blame for the libva, mplayer and gnash patches maybe you could tell me a few things:

a) Why did you --disable-i965-driver? I patched it back of course to try it. vainfo shows Mpeg2 support (using U 9.10 daily) but mplayer crashes using a Q45.

b) What's the logic of that -va vaapi option to mplayer? I understand that you use -vo vaapi[:gl][:reflect], but -va vaapi gives to me no new info, so what's the purpose? Also are there any other options, like deinterlacing or whatever which are not written somewhere?

c) I tested of course the mplayer rendering using the video vdpau wrapper, that worked fairly well. Will you add divx accelleration for dx 10.1 cards too?

d) Could you add a way to use internal ffmpeg for gnash and maybe the hwdecode-demos as I definitely do not intent to install patched ffmpeg libs globally?

e) Could you provide a working patch against latest vlc with internal ffmpeg?

[gbeauche]

Why did you --disable-i965-driver? I patched it back of course to try it. vainfo shows Mpeg2 support (using U 9.10 daily) but mplayer crashes using a Q45.

In the version I distribute? Building the G45 driver requires libdrm2.4, which I don't have on my dev systems.

In the upstream version? Actually, the i965/g45 driver should have had its own repository, and distributed packages. Unfortunately, fd.o admins work on a best effort basis and getting things setup is not a fast process. e.g. the list was created ~6 months after the request. So the driver was integrated in the main libVA tree. Packaging-wise, this driver should not be provided within libVA.

b) What's the logic of that -va vaapi option to mplayer? I understand that you use -vo vaapi[:gl][:reflect], but -va vaapi gives to me no new info, so what's the purpose?

It's used to select the Video Accelerator. I had versions with -va vdpau for example. Unfortunately, making the Video Accelerator choice based on the Video Output (-vo) didn't seem a good idea, I was told IIRC. Anyway, I am working on an alternative that will make VA API enabling much easier, so the conventional vo_vaapi could be dropped since it duplicates code from the vo_x11 code for example (the same applies to vdpau). In the end, the plan is to only keep -va vaapi.

Also are there any other options, like deinterlacing or whatever which are not written somewhere?

There are no other options yet. I have not implemented OSD yet because I initially did not know how to use it, neither with what kind of files I should use actually.

c) I tested of course the mplayer rendering using the video vdpau wrapper, that worked fairly well. Will you add divx accelleration for dx 10.1 cards too?

If I get one. I thought my GTX 280M module should be suitable (G92 core?), I have not checked for sure. I have not received the new NVIDIA shipment yet either.

d) Could you add a way to use internal ffmpeg for gnash and maybe the hwdecode-demos as I definitely do not intent to install patched ffmpeg libs globally?

There will be a maintenance problem. The better intermediate approach is probably to have some extra tarball (e.g. an ffmpeg-vaapi-20090715.tar.bz2 or whatever) that glues itself in the top_srcdir and that is used if available? Something ? la GCC or binutils.

The "patched ffmpeg libs globally" shall not be a real problem because the goal is that it's no longer patched but fully integrated within the upstream FFmpeg sources. I'd prefer to focus on this approach.

e) Could you provide a working patch against latest vlc with internal ffmpeg?

VLC developers sent me the patches, but I hadn't had the time to check it out yet. That seemed to be generated from the current GIT tree though.

[Kano]

a) I only tested your version when you look at my script. You are correct that it needs just libdrm, it build on a slightly upgraded lenny too. I guess upstream is:

http://cgit.freedesktop.org/libva/

But there the debian packageing is broken, I would like to see a working one. Why are your patches kept only on your site and not in that git?

b) That's not really what i like, i need subtitles and such things. vdpau is much better than. I have got no problem to specify overrides in a config file, but you need to provide at least one solution to let it enabled all the time with fallback for unsupported codecs.

c) You need new hardware. G92 is too old, i know that because i have got a 8800 GTS 512 (G92) myself. I also want a new card.

d) I really like that idea, you could do it similar to the mplayer checkout script too - did you have it first or nvidia

e) Well the only patch i found applied and i changed some things in the code, but as it needed external ffmpeg it was not successfull.

http://forum.videolan.org/viewtopic.php?f=13&p=216296

[gbeauche]

a) I only tested your version when you look at my script. You are correct that it needs just libdrm, it build on a slightly upgraded lenny too.

Yes, libdrm2.4 builds fine on Lenny but I wanted to provide basic and generic builds.

Why are your patches kept only on your site and not in that git?

If you look at the GIT changes, you will realize that the latest ones come from my tree. The VA compat code is not suitable for upstream libVA. The usual procedure is people rebuild their applications. Upstream projects rarely provide compatibility glues for older API. When something is obsoleted, it's gone. I have not posted other patches yet. VA/GLX extensions are being discussed.

I won't propose the libdrm patches because IMHO this currently is a hacky workaround for the latest fglrx driver changes. I have not investigated yet whether this was AMD's fault or linker/loader fault.

b) That's not really what i like, i need subtitles and such things. vdpau is much better than. I have got no problem to specify overrides in a config file, but you need to provide at least one solution to let it enabled all the time with fallback for unsupported codecs.

The fallback for unsupported codecs will automagically work with the new approach I have in mind and if I don't mess with my implementation. For subtitles, this will require dedicated code that would happen when I have testcases. Hey, I am not an mplayer user, so I don't know how to use it and/or how people usually use it.

[Kano]

Maybe you could fix the packaging at least in upstream git so a simple checkout and build is possible. Btw. vainfo reports:

libva: libva version 0.31.0-sds3
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/va/drivers/i965_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA API version: 0.31
vainfo: Driver version: i965 Driver 0.1
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD

But package is called:

ii libva1 0.31.0-1+sds4