Select provider of libav* libraries

[Bálint Réczey]

Hi All,

2015-06-21 12:24 GMT-07:00 Andreas Cadhalpun <andreas.cadhalpun at googlemail.com>:
> Hi Reinhard,
>
> On 19.06.2015 23:50, Reinhard Tartler wrote:
>> On Jun 18, 2015 7:15 PM, "Andreas Cadhalpun" <andreas.cadhalpun at googlemail.com> wrote:
>>> The altivec optimizations on powerpc are still disabled, but I don't think
>>> this should delay the transition. I intend to fix this one way or another
>>> before stretch is released anyway.
>>
>> That is something that the libav package handles just fine.
>> May I ask how you intend to address the altivec issue?
>
> Preferably the upstream build system would be changed to (optionally) only build
> the parts actually using hand-written altivec optimizations with '-maltivec', but
> not the others. This would make it possible to rely on runtime cpu detection also
> on powerpc.
> I looked into this a bit now and it's not trivial to do that, because not all
> uses of altivec.h are well separated from the rest of the code:
>  * The SwsContext in libswscale's swscale_internal.h uses some vector variables
>    and thus needs altivec.h. This and the corresponding code in libswscale/utils.c
>    would need to get factored out into the ppc subdirectory.
>  * The libpostproc library includes the postprocess_altivec_template.c
>    directly in the main postprocess.c, which would also have to be factored
>    out into a ppc subdirectory.
> Help with above would be very welcome. ;)
>
> If this would turn out to be infeasible in the end, we could still build a separate
> altivec flavor, as currently done by the libav package.
Andreas changed packaging to ship the altivec flavor, too, until
runtime CPU detection is fixed.
Is there anything left to be fixed before we can start the transition?

Cheers,
Balint