Scratch built:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4016470

Related components:
(Open)
Review Request: libva-vdpau-driver - HW video decode support for VDPAU platforms
https://bugzilla.redhat.com/show_bug.cgi?id=771254

(Closed)
gstreamer-plugins-bad-free can enable libvdpau-devel
https://bugzilla.redhat.com/show_bug.cgi?id=734242

*** Bug 768145 has been marked as a duplicate of this bug. ***

The previous report was worded as VA-API activation but was searching for libvdpau_r600.so which is the result of the VDPAU activation. VA-API state tracker is marked as un-maintained in mesa-8.0.x. So I guess VDPAU was actually intended in this previous report.

Hello I would like to use vdpau with nouveau too.
Currently my F17 has:
mesa-dri-drivers-8.0.3-1.fc17.x86_64
mesa-libOSMesa-8.0.3-1.fc17.x86_64
mesa-libGL-8.0.3-1.fc17.x86_64
mesa-libxatracker-8.0.3-1.fc17.x86_64
mesa-libglapi-8.0.3-1.fc17.x86_64
mesa-libGLU-8.0.3-1.fc17.x86_64
mesa-dri-filesystem-8.0.3-1.fc17.x86_64

I'm going to test with 
- Asus U36sd and hybrid graphics (nVidia is GeForce GT520M):
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
01:00.0 VGA compatible controller: nVidia Corporation Device 1050 (rev ff) (prog-if ff)

- pc with GeForce 9600GT

I have not understood how to download mesa-8.0.2-4.fc18.src.rpm as in comment#1 and compare the spec file with current F17 one.
Is it possible to rebase the source?
Or can you give the changes to put inside the F17 spec file, so that I can recompile myself and test?
Thanks in advance

(In reply to comment #4)
> Or can you give the changes to put inside the F17 spec file, so that I can
> recompile myself and test?
> Thanks in advance

Nicolas's scratch builds have expired.  I have built a F17 RPM; you can download it and the SRPM at http://koji.fedoraproject.org/koji/taskinfo?taskID=4150636 .  You will also want the libva-vdpau radeon driver RPM/SRPM at http://koji.fedoraproject.org/koji/taskinfo?taskID=4150630 .

I missed that scratch build... I don't know if current updates include vdpau support
At this moment my packages from standard F17 repo are:
mesa-dri-drivers-8.0.3-3.fc17.x86_64
libva-vdpau-driver-0.7.3-2.fc17.x86_64
libvdpau-0.4.1-7.fc17.x86_64
mesa-libGL-8.0.3-3.fc17.x86_64
mesa-libGLU-8.0.3-3.fc17.x86_64
mesa-libOSMesa-8.0.3-3.fc17.x86_64
libvdpau-docs-0.4.1-7.fc17.x86_64
vdpauinfo-0.0.6-4.fc17.x86_64
mesa-libGL-8.0.3-3.fc17.i686
mesa-dri-filesystem-8.0.3-3.fc17.x86_64
mesa-libglapi-8.0.3-3.fc17.x86_64
mesa-libxatracker-8.0.3-3.fc17.x86_64
mesa-libglapi-8.0.3-3.fc17.i686
libva-utils-1.0.15-2.fc17.x86_64
libva-1.0.15-2.fc17.x86_64


$ sudo optirun /usr/bin/vdpauinfo
display: :0   screen: 0
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
Error creating VDPAU device: 1

While I see in libva-vdpau-driver rpm only

/usr/lib64/dri/nvidia_drv_video.so
/usr/lib64/dri/s3g_drv_video.so
/usr/lib64/dri/vdpau_drv_video.so
/usr/share/doc/libva-vdpau-driver-0.7.3
/usr/share/doc/libva-vdpau-driver-0.7.3/AUTHORS
/usr/share/doc/libva-vdpau-driver-0.7.3/COPYING
/usr/share/doc/libva-vdpau-driver-0.7.3/NEWS
/usr/share/doc/libva-vdpau-driver-0.7.3/README

Do I have to create any soft link to have it working?

I have an r600 based video card and while I can build mesa with the --enable-vdpau and get some support, I would prefer if mesa came with this feature enabled.

vdpauinfo currently reports the following

vdpauinfo 
display: :0   screen: 0
Failed to open VDPAU backend libvdpau_r600.so: cannot open shared object file: No such file or directory
Error creating VDPAU device: 1

Any update on mesa being built with the --enable-vdpau option? Would be nice to have for F18

The method to add this as noted in the patch is extremely trivial. What's the hold up? This is not enabled on 16,17,or 18. 

Adding to f18-nth to get some response here.

I have not looked at the code but there is a potential problem here:

If the vdpau support is implemented using the hardware decoders it should be fine but if it is implemented using shaders we can't due to patents. That would be the same as allowing ffmpeg in.

(In reply to comment #10)
> I have not looked at the code but there is a potential problem here:
> 
> If the vdpau support is implemented using the hardware decoders it should be
> fine but if it is implemented using shaders we can't due to patents. That
> would be the same as allowing ffmpeg in.

Please look at the patch and comment, it's very a simple patch to the spec file.

(In reply to comment #11)
> (In reply to comment #10)
> > I have not looked at the code but there is a potential problem here:
> > 
> > If the vdpau support is implemented using the hardware decoders it should be
> > fine but if it is implemented using shaders we can't due to patents. That
> > would be the same as allowing ffmpeg in.
> 
> Please look at the patch and comment, it's very a simple patch to the spec
> file.

It has nothing to do with the spec file itself. But with the VDPAU code in mesa that gets enabled.

If that code implements patented codecs using shaders we cannot enable it in fedora.

It doesn't look like it does. I will attempt a scratch build and see what happens.

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > I have not looked at the code but there is a potential problem here:
> > > 
> > > If the vdpau support is implemented using the hardware decoders it should be
> > > fine but if it is implemented using shaders we can't due to patents. That
> > > would be the same as allowing ffmpeg in.
> > 
> > Please look at the patch and comment, it's very a simple patch to the spec
> > file.
> 
> It has nothing to do with the spec file itself. But with the VDPAU code in
> mesa that gets enabled.
> 
> If that code implements patented codecs using shaders we cannot enable it in
> fedora.


https://koji.fedoraproject.org/koji/taskinfo?taskID=4820643

Scratch build successful. Not seeing any licensing issues here. Please double check it or let me know how I can check if there is an issue.

I have no idea how you can conclude that there is a no license issue by doing a scratch build. You have to checkout and review the *code* and verify that the implementation is actually just sending and getting frames from dedicated hardware rather then implement the decoding using shaders.

Yeah I have no idea how to do that offhand. The rpmbuild just generated some libs. I guess I'll have to look at the code that generated those libs. Thanks.

Looking at the code with an untrained eye it looks like it does direct hardware rendering (briefly looked at r600).

spot, can you take a look?

Created attachment 673465 [details]
Add --with=vdpau option to mesa.spec

I understand that Fedora has problems with legally encumbered code. But what about a solution so that, e.g. RPMFusion, could rebuild the Fedora SRPM and *only* generate the VDPAU driver package? If Fedora integrates the attached patch to the mesa package then there would be no need to fork the package downstream.

I've opened a discussion about this solution on the RPMFusion bugzilla:

   https://bugzilla.rpmfusion.org/show_bug.cgi?id=2633

spot is working on this.

Any update on this?

I build some package and create a repo for UVD VDPAU hardware decoding. 

Here is the repo URL. All the RPMs, SRPMs and SPECs are there.
http://www.liangsuilong.info/repo/

I wrote a blog post to describe the repo.
http://www.liangsuilong.info/?p=1609

I fetch the latest mesa master branch code. but fails to compile mesa-libOSMesa. I just drop it in this build. All pacakges are not built on koji, just built on my local machine. Because mesa-git requires libdrm-2.4.44. At this time, Fedora 18 just contains libdrm-2.4.42.

Without much response from maintainers it looks like this is getting enabled in Fedora 19 officially.

Looks like they enabled vdpau, but disabled all the decoders. 

Video surface:

name   width height types
-------------------------------------------
420     8192  8192  NV12 YV12 
422     8192  8192  NV12 YV12 UYVY YUYV 
444     8192  8192  NV12 YV12 Y8U8V8A8 V8U8Y8A8 

Decoder capabilities:

name               level macbs width height
-------------------------------------------

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8          8192  8192    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
R8G8B8A8          8192  8192    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
R10G10B10A2       8192  8192    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
B10G10R10A2       8192  8192    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8