NVIDIA To Create Protocol For VDPAU

[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

[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]

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]

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]

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]

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

[greg]

Deinterlacing is indeed missing from the API, but this can be added. Why is blending not very powerful?

It's only possible to use a fixed blending equation (or does it even support chroma-keying only? I'm not sure... would be great if the documentation sucked less... seriously). OpenGL of course is powerful indeed, but it also complicates things a lot.

Well, are you going to add deinterlacing to the API? Sure, this could be done with OpenGL as well, but then every application would probably reimplement this again.

Native implementation or not does not really matter since the goal is to support the underlying chip.

If that is what you care about I have to ask again why you settled for VA-API, since a API that is not used anywhere isn't helpful and application support for VA-API is barely existing. VDPAU pretty much is the only video decode API relevant in practice at the moment.

[gbeauche]

Post-processing, especially deinterlacing better than bob; blending in VA-API is not very powerful.

Deinterlacing is indeed missing from the API, but this can be added. Why is blending not very powerful? BTW, it is now even possible to use OpenGL, so I hope this one is powerful enough in blending for your taste.

No, I'm not. I'm aware that only NVidia and S3 implement VDPAU at the moment, but where do you get these 6 VA-API implementations from? As far as I know, only Intel and S3 have native implementations.

Actually, I even forgot to count a few other implementations but those were not announced yet. Native implementation or not does not really matter since the goal is to support the underlying chip. In no particular order: Intel chips (US15W and G45 for 3 drivers, more to come), S3 chips, NVIDIA chips, AMD chips. I think this covers most what users have.

[greg]

What functionality do you think is missing in VA API?

Post-processing, especially deinterlacing better than bob; blending in VA-API is not very powerful.

You seem to confuse API and implementation. There are more than 6 VA drivers available now. VDPAU does not have that many implementations.

No, I'm not. I'm aware that only NVidia and S3 implement VDPAU at the moment, but where do you get these 6 VA-API implementations from? As far as I know, only Intel and S3 have native implementations.

Sure, there are probably more players supporting VDPAU but if they don't cover many user base because their GPU or VPU is not supported, that won't be very useful.

That's also why I think wrapping to VDPAU instead of VA-API might a better idea.

[gbeauche]

First simply because it's a nice API and well-documented, second because there's a lot of application support already and third because it offers some functionality that is missing in VA-API.

What functionality do you think is missing in VA API?

Why are you advocating VA-API, what it makes it more suitable for this task in your opinion?

You seem to confuse API and implementation. There are more than 6 VA drivers available now. VDPAU does not have that many implementations. Sure, there are probably more players supporting VDPAU but if they don't cover many user base because their GPU or VPU is not supported, that won't be very useful.