On Sep 16, 2009, at 6:32 AM, Nicolas Chauvet wrote:
2009/9/16 Jarod Wilson <jarod(a)rpmfusion.org>:
> Author: jarod
>
> Update of /cvs/free/rpms/mythtv/devel
> In directory se02.es.rpmfusion.net:/tmp/cvs-serv19341
>
> Modified Files:
> mythtv.spec
> Log Message:
> * Tue Sep 15 2009 Jarod Wilson <jarod(a)wilsonet.com>
> 0.22-0.3.svn.r21864
> - Oops, no libvdpau for powerpc
You missed that Mythtv should not BuildRequires it either.
Gah. I knew something was still amiss, as the build failed on ppc
again. I was thinking maybe mock wasn't honoring the %ifarch flag for
BR, neglected to notice that I'd failed to wrap the BR with that.
Fixing now.
But at least it is present on x86_64 which the %ix86 arch macro
doesn't contain.
D'oh, I fail again. Adding x86_64 too.
Now libvdpau itelf can probably be built on ppc and other arches;
and
unless ffmpeg vdpau codecs relies on x86 specifics asm , they should
built within ffmpeg.
I was gonna ask. I'd assumed it was being built for all arches
initially, since one of the arguments for getting libvdpau into fedora
instead of rpm fusion was that it was a generic spec, not a vendor-
specific or arch-specific one, and thus a ppc (or any arch) driver
with vdpau support *could* crop up.
But It probably doesn't make sense if at least
possible for now... (using and x86* X server on a ppc host?!).
It could also be used on ppc hosts for talking to a remote X server,
which was another argument for letting it into fedora. But that said,
I'm perfectly fine with it not being built for ppc. Not even sure what
would happen if I tried building vdpau support into mythtv on ppc, but
I wouldn't be surprised if it fell down somewhere.
Also ffmpeg lack support for the very new libvdpau enhancement
(using
vdpau Feature Set C, which hardware are still very rare). So I may
downgrade to the previous snapshoot.
It doesn't gracefully handle code lacking support for the enhancement?
--
Jarod Wilson
jarod(a)wilsonet.com