Hi Reinhard, On 19.06.2015 23:50, Reinhard Tartler wrote: > On Jun 18, 2015 7:15 PM, "Andreas Cadhalpun" > <andreas.cadhal...@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 _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
