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
Announcement
Collapse
No announcement yet.
NVIDIA To Create Protocol For VDPAU
Collapse
X
-
Originally posted by Kano View Posta) 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.
Why are your patches kept only on your site and not in that git?
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.
Leave a comment:
-
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:
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.
Leave a comment:
-
Originally posted by Kano View PostWhy 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 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?
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?
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?
Leave a comment:
-
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?
Leave a comment:
-
Originally posted by greg View PostIf that is what you care about I have to ask again why you settled for VA-API.
Leave a comment:
-
Originally posted by gbeauche View PostDeinterlacing is indeed missing from the API, but this can be added. Why is blending not very powerful?
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.
Leave a comment:
-
Originally posted by greg View PostPost-processing, especially deinterlacing better than bob; blending in VA-API is not very powerful.
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.
Leave a comment:
-
Originally posted by gbeauche View PostWhat functionality do you think is missing in VA API?
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.
Leave a comment:
-
Originally posted by greg View PostFirst 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.
Why are you advocating VA-API, what it makes it more suitable for this task in your opinion?
Leave a comment:
Leave a comment: