Select provider of libav* libraries

[Andreas Cadhalpun]

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.

> The new packaging for sure builds faster, but is build time really a problem?

Unnecessarily letting the build take longer than it needs is certainly not good.
For example building the ffmpeg package on m68k takes about half a day and if the
tests are run a full day, while the libav package takes about 3-5 days.
And this is also a problem, when building with qemu for different architectures.

>> And currently FFmpeg 2.7 failed to build on ppc64 (due to changes in configure,
>> fixed upstream) and sparc (unaligned access causing SIGBUS, problem has been
>> there for ages, but the test coverage increased recently, patch sent upstream).
>> I expect FFmpeg 2.7.1 will fix those, so once that is in unstable, it would
>> be a good time to upload the package for the transition to experimental.
> 
> I'm not sure if we had consensus on what packaging should be used.

Well, I have no intention of maintaining a pre-dh7-style debian/rules file.
That pretty much settles the question for me.

> In the new packaging, libavcodec-extra is a virtual package, while the jessie

This is done, so that the GPLv2-only packages can build-conflict with
libavcodec-extra.

> shipped with a real package. How will that play with backports, that is, is
> there any chance that apt would prefer the libavcodec-extra package that drags
> in the old packages over the libavcodec-extra-NN package, which provides
> libavcodec-extra?

That's a good catch.
I tried it and apt would install the old libavcodec-extra package. So it seems
we'd need to provide a transitional libavcodec-extra package from src:ffmpeg
for one cycle.

Best regards,
Andreas