Re: Select provider of libav* libraries
https://wiki.debian.org/DebianMultimedia/FFmpeg/Statement I'd like to send this to devel-announce by Tuesday, any objections? -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On 05.07.2015 11:04, Alessio Treglia wrote: https://wiki.debian.org/DebianMultimedia/FFmpeg/Statement I'd like to send this to devel-announce by Tuesday, any objections? Fine for me. 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
Re: Select provider of libav* libraries
Shall we draft a brief public statement? https://wiki.debian.org/DebianMultimedia/FFmpeg/Statement Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Alessio, On 01.07.2015 20:05, Alessio Treglia wrote: Shall we draft a brief public statement? https://wiki.debian.org/DebianMultimedia/FFmpeg/Statement What do you think about the following? --- After a careful review of all the pros and cons we have finally decided to switch from Libav to FFmpeg. The main arguments for using FFmpeg are summarized on the wiki [1], while the full discussion can be found on the pkg-multimedia-maintainers mailing list, starting at [2]. 1: https://wiki.debian.org/Debate/libav-provider/ffmpeg 2: https://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-April/043928.html --- 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
Re: Select provider of libav* libraries
On Wed, Jul 1, 2015 at 7:28 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: What do you think about the following? Fine to me, please do edit the wiki page! We'll let others review it then. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On 01.07.2015 20:54, Alessio Treglia wrote: On Wed, Jul 1, 2015 at 7:28 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: What do you think about the following? Fine to me, please do edit the wiki page! We'll let others review it then. OK, done. 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
Re: Select provider of libav* libraries
Hi! On 2015-06-29 at 13:16 (CEST), Alessio Treglia wrote: [...] It must also be noted that Matteo F. Vescovi (namely the blender most's active human maintainer) said that he would second a switch to FFmpeg too [1] - that was at least my interpretation, Matteo please correct me, if I am mistaken. [...] Exactly. Cheers. -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi again, On Mon, Jun 29, 2015 at 12:16 PM, Alessio Treglia ales...@debian.org wrote: Two votes for Libav: Jonas [8] and Alessio [9]. I've forgotten to clarify that FWIW, despite of my vote in favor of libav, I am not in a strong opposition against the switch over. Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Alessio, On 29.06.2015 13:16, Alessio Treglia wrote: I think it's time to wrap all this up and share our opinion with the rest of the Debian project. Fine for me. [...] I understand that FFmpeg's current uploaders would also continue to maintain FFmpeg under the Multimedia team's umbrella. Andreas, Balint, please do correct me if I am wrong. That's correct. 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
Re: Select provider of libav* libraries
Hi, On 28.06.2015 06:24, Bálint Réczey wrote: I have prepared the upload for gpac in git which fixes the FTBFS for both Libav and FFmpeg. Alessio or I will upload it. Thanks. The other reverse deps are there for refence only. They are broken for reasons not related to this transition which I now marked accordingly. I've just filed #790356 [1] about the missing libavresample-dev build-depenency of gst-libav1.0. taoframework can't be binNMUed anyway, because it is Architecture: all. If you find anything to fix related to the transition, comments are still welcome. Please check the new experimental banch in ffmpeg's packaging repo as well. I think we're ready for an upload to NEW/experimental and requesting a transition slot from the release team. A remaining question is, whether or not we should rename the lib*-dev packages from src:libav and src:libpostproc to lib*-libav-dev. Best regards, Andreas 1: https://bugs.debian.org/790356 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Thu, Jun 18, 2015, 7:15 PM Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: Hi, On 18.06.2015 18:57, Bálint Réczey wrote: 2015-06-09 21:53 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: I have now implemented this and it works fine. It's in the extra branch of the ffmpeg git repository [1]. I have tested the branch and it works nicely for me. Thanks for testing it. :) Is there any other open issue? 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. It seems that you have now reimplemented the flavors logic in the ffmpeg package. Nice. The only thing that I spotted so far is the issue with libavcodec-extra. I've put my transition plan on the wiki [1]. 1: https://wiki.debian.org/Debate/libav-provider/ffmpeg#How_Debian_should_switch_to_FFmpeg I'm not sure if I understand that wiki correctly, but it seems to be that you plan on keep on using the package names libavXXX-ffmpegNN. That seems unnecessary to me, why wouldn't you want to co stright to libavXXXNN? I guess the reason is because that matches the actual soname, that is, libavcodec is currently installed with the SONAME libavcodec-ffmpeg.so. This is to ensure co-installability with libav, but do we really need to keep this? I think everyone is rather in favor of not having to have both around. Unless there is a good reason (such as making the transition significantly easier, I'd rather avoid those names. Best, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Reinhard, On 28.06.2015 21:56, Reinhard Tartler wrote: It seems that you have now reimplemented the flavors logic in the ffmpeg package. Yes. Nice. Well, I'd call it a necessary evil, needed until runtime cpu detection works for altivec and FFmpeg has a native nb/wb AMR encoder. The only thing that I spotted so far is the issue with libavcodec-extra. That should be fixed in the current experimental branch by providing a transitional libavcodec-extra package. Or is there something else? I'm not sure if I understand that wiki correctly, but it seems to be that you plan on keep on using the package names libavXXX-ffmpegNN. Yes, until the next SOVERSION bump or after the next release, whichever comes first. That seems unnecessary to me, why wouldn't you want to co stright to libavXXXNN? I'd want to use those names very much, but I think that wouldn't work well. I guess the reason is because that matches the actual soname, that is, libavcodec is currently installed with the SONAME libavcodec-ffmpeg.so. Yes, the package name should reflect the SONAME, as recommended by policy. This is to ensure co-installability with libav, but do we really need to keep this? It's also to ensure that packages keep working. See below. I think everyone is rather in favor of not having to have both around. So you think we shouldn't rename the -dev libraries from src:libav/src:libpostproc, but rather remove these packages after the transition? Unless there is a good reason (such as making the transition significantly easier, I'd rather avoid those names. Building a program against the Libav libraries and using it with the FFmpeg libraries is practically never done, so we'd be the ones to find out how well it works for most programs. (Building against FFmpeg and using with these libraries is done by a lot of people in other distributions, so I'm reasonably sure it works well.) Actually deb-multimedia.org builds the FFmpeg libraries with the same names as the Libav ones in the archive and I have seen bug reports that things break. For example, bug #785650 [1] shows that mpv refuses to work in such a situation: mpv was compiled and linked against a mixture of Libav and FFmpeg versions. This won't work and will most likely crash at some point. Exiting. Thus we have to treat the FFmpeg libraries as ABI-incompatible to the Libav ones. Best regards, Andreas 1: https://bugs.debian.org/785650 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi, 2015-06-23 13:59 GMT-07:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: Hi Matteo, On 23.06.2015 21:51, Matteo F. Vescovi wrote: On 2015-06-23 at 17:56 (CEST), Bálint Réczey wrote: [...] Is there anything left to be fixed before we can start the transition? Yes, the total disappearance of FTBFS in [1]. Most of those FTBFS are completely unrelated to this transition. Thus the affected packages will either get fixed by their maintainers or auto-removed from testing, totally independently of the transition to FFmpeg. Only gpac, gst-libav1.0 and taoframework would FTBFS due to the transition. The first two can be fixed at any time (patches exist), but taoframework hardcodes the sonames and thus can only be updated after the transition has started. If I was a Release Team member, I wouldn't allow anything to happen before all that mess is fixed. Calling this a mess is a little bit exaggerated, when comparing with previous Libav transitions... Feel free to retry a call for transition once the list is empty. It's quite unreasonable to expect this list to get empty. It hasn't been empty at any point during the past year and I don't expect gstreamer0.10-ffmpeg will ever get fixed. (That aside, taoframework will always be on the list, as it hardcodes the sonames...) Patches for all FTBFS issues caused by the transition to FFmpeg are available/trivial, so the affected packages could be NMUed, once the transition starts. This should be all preparation the Release Team could possibly want. I have prepared the upload for gpac in git which fixes the FTBFS for both Libav and FFmpeg. Alessio or I will upload it. The other reverse deps are there for refence only. They are broken for reasons not related to this transition which I now marked accordingly. If you find anything to fix related to the transition, comments are still welcome. Please check the new experimental banch in ffmpeg's packaging repo as well. Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi, On 23.06.2015 18:07, Alessio Treglia wrote: We are then migrating away from libav, I've created an experimental ffmpeg branch [1] with the changes for the transition. Comments/testing/review are welcome. ;) Best regards, Andreas 1: https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/log/?h=experimental ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi All, 2015-06-21 12:24 GMT-07:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: 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. 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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Tue, Jun 23, 2015 at 4:42 PM, Bálint Réczey bal...@balintreczey.hu wrote: 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? Please give people few more days to speak up, I'd say until the end of this week. Team, We are then migrating away from libav, if you don't think this is the right thing to do or intend to propose alternatives, just speak up right now. Cheers! -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi! On 2015-06-23 at 18:07 (CEST), Alessio Treglia wrote: [...] Team, We are then migrating away from libav, if you don't think this is the right thing to do or intend to propose alternatives, just speak up right now. Blender (my main package involved in libav/ffmpeg fight) has been adapted by kind upstream developers in BF to work just fine with libav, while they're mainly supporting ffmpeg as primary A/V tool. At this point, the switch to ffmpeg could help avoiding all the trouble in porting the upstream changes to allow the build on libav-based systems. So, while I was happy with libav for its stability, I could appreciate spending less efforts in getting things work and use the saved energy to improve the packaging, hopefully. Just my two cents on the topic. Cheers. -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi! On 2015-06-23 at 17:56 (CEST), Bálint Réczey wrote: [...] Is there anything left to be fixed before we can start the transition? Yes, the total disappearance of FTBFS in [1]. If I was a Release Team member, I wouldn't allow anything to happen before all that mess is fixed. Feel free to retry a call for transition once the list is empty. Cheers. [1] https://wiki.debian.org/Debate/libav-provider/ffmpeg#Implementing_the_Transition -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Matteo, On 23.06.2015 21:51, Matteo F. Vescovi wrote: On 2015-06-23 at 17:56 (CEST), Bálint Réczey wrote: [...] Is there anything left to be fixed before we can start the transition? Yes, the total disappearance of FTBFS in [1]. Most of those FTBFS are completely unrelated to this transition. Thus the affected packages will either get fixed by their maintainers or auto-removed from testing, totally independently of the transition to FFmpeg. Only gpac, gst-libav1.0 and taoframework would FTBFS due to the transition. The first two can be fixed at any time (patches exist), but taoframework hardcodes the sonames and thus can only be updated after the transition has started. If I was a Release Team member, I wouldn't allow anything to happen before all that mess is fixed. Calling this a mess is a little bit exaggerated, when comparing with previous Libav transitions... Feel free to retry a call for transition once the list is empty. It's quite unreasonable to expect this list to get empty. It hasn't been empty at any point during the past year and I don't expect gstreamer0.10-ffmpeg will ever get fixed. (That aside, taoframework will always be on the list, as it hardcodes the sonames...) Patches for all FTBFS issues caused by the transition to FFmpeg are available/trivial, so the affected packages could be NMUed, once the transition starts. This should be all preparation the Release Team could possibly want. 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
Re: Select provider of libav* libraries
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
Re: Select provider of libav* libraries
Quoting Andreas Cadhalpun (2015-06-21 14:24:43) On 19.06.2015 23:50, Reinhard Tartler wrote: On Jun 18, 2015 7:15 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: 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. Then use a post-dh-style debian/rules file instead, as done with libav. Embedding negative connotations rarely help in discussions. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On 21.06.2015 22:09, Jonas Smedegaard wrote: Quoting Andreas Cadhalpun (2015-06-21 14:24:43) Well, I have no intention of maintaining a pre-dh7-style debian/rules file. That pretty much settles the question for me. Then use a post-dh-style debian/rules file instead, as done with libav. That doesn't make any difference. Embedding negative connotations rarely help in discussions. This has nothing to do with connotations. The problem is that libav's debian/rules file contains a lot of boilerplate and is rather complex. Thus it is hard to maintain. 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
Re: Select provider of libav* libraries
On Jun 18, 2015 7:15 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: Hi, On 18.06.2015 18:57, Bálint Réczey wrote: 2015-06-09 21:53 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: I have now implemented this and it works fine. It's in the extra branch of the ffmpeg git repository [1]. I have tested the branch and it works nicely for me. Thanks for testing it. :) Is there any other open issue? 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? The new packaging for sure builds faster, but is build time really a problem? 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. I would happily sponsor an upload to experimental with the new -extra package possibly with also providing libav-dev and friends to if libav maintainers agree and we decide to start the transition. Any thoughts? In the new packaging, libavcodec-extra is a virtual package, while the jessie 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? Best, Reinhard Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi All, 2015-06-09 21:53 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: Hi IOhannes, On 09.06.2015 09:03, IOhannes m zmölnig (Debian/GNU) wrote: On 2015-06-09 06:35, Fabian Greffrath wrote: Am Dienstag, den 09.06.2015, 00:26 +0200 schrieb Andreas Cadhalpun: So one can just use two directories, first run configure in both (with the different options), then compile the GPLv2 variant, copy the object files (without allcodecs.o) to the GPLv3 folder, build the remaining GPLv3 de-/encoders there and link the libraries again. this sounds like a good idea to start with. I have now implemented this and it works fine. It's in the extra branch of the ffmpeg git repository [1]. I have tested the branch and it works nicely for me. Is there any other open issue? I would happily sponsor an upload to experimental with the new -extra package possibly with also providing libav-dev and friends to if libav maintainers agree and we decide to start the transition. Any thoughts? Cheers, Balint ... 1: https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/commit/?h=extraid=1d1bf4062035d6a6c12f40fcaadbf09f74d6db1b 2: https://lists.debian.org/debian-legal/2015/06/msg5.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi, On 18.06.2015 18:57, Bálint Réczey wrote: 2015-06-09 21:53 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: I have now implemented this and it works fine. It's in the extra branch of the ffmpeg git repository [1]. I have tested the branch and it works nicely for me. Thanks for testing it. :) Is there any other open issue? 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. 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 would happily sponsor an upload to experimental with the new -extra package possibly with also providing libav-dev and friends to if libav maintainers agree and we decide to start the transition. Any thoughts? I've put my transition plan on the wiki [1]. Best regards, Andreas 1: https://wiki.debian.org/Debate/libav-provider/ffmpeg#How_Debian_should_switch_to_FFmpeg ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Am Mittwoch, den 10.06.2015, 18:02 +0200 schrieb Andreas Cadhalpun: So I guess I'll wait until someone specifically asks for it. That's a good idea. In the libavcodec case the missing -extra package would be considered a regression, but in the libavformat case noone asked for smb support before. - Fabian signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Am Dienstag, den 09.06.2015, 21:53 +0200 schrieb Andreas Cadhalpun: Or does someone also want a libavformat-extra flavor for the samba support? While you are at it... ;) No, seriously, I have no idea how usefull this is or if there is a demand for it. - Fabian signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On 10.06.2015 10:17, Fabian Greffrath wrote: Am Dienstag, den 09.06.2015, 21:53 +0200 schrieb Andreas Cadhalpun: Or does someone also want a libavformat-extra flavor for the samba support? While you are at it... ;) It would be easy to add, ... No, seriously, I have no idea how usefull this is or if there is a demand for it. ... but I think there is even less demand for it than for libavcodec-extra. And I don't know of an easy way to (autopkg)test it. So I guess I'll wait until someone specifically asks for it. 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
Re: Select provider of libav* libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015-06-09 06:35, Fabian Greffrath wrote: Hi Andreas, Am Dienstag, den 09.06.2015, 00:26 +0200 schrieb Andreas Cadhalpun: So one can just use two directories, first run configure in both (with the different options), then compile the GPLv2 variant, copy the object files (without allcodecs.o) to the GPLv3 folder, build the remaining GPLv3 de-/encoders there and link the libraries again. this sounds like a good idea to start with. it sounds quite fragile to me. while reducing build time is generally a good idea, i don't think it's worth the additional hassle needed to manually track whichever files are affected by enabling/disabling a given build option. unless we hit a brick wall (e.g. cancelled builds due to timeouts on the build servers), i would recommend to keep it simple. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVdo+9AAoJELZQGcR/ejb4N+AP/18HlF2ireoxptoHy4uEVEMP jHYPOr20gjdeH+aj/UFqt8bUMa4mEM1B24iYFMm+hkZ5iB47425geD1p6d27ozeE 3sX3CHqa72qn8aJVBlx47q4ftHOfjhUClqHA5vkfxDM12kOxyHOwyxmZZbkEiiea TgLn4+3hcuPJWOYD3otutlRpngyvok/1SdfknXpZFtle3nGyOvGbWVCVcGAyNo9G QdyCERRG0hX576MYlmcwGbZng+M68ri/pAoIM7yRJ/AVmLqM7kOdIJWw70EyE9wt SIISjN2kJrg6kYw2zBAtnlr3xlfJ7g2Yy+10On+7gv0zQVD/fJWHobLsNt7ZXnM7 xGEXt7Npo5FygZrrqA6Y798aBNe1CdOgVFiVHhBRiIMozSfc8q/uA60yeAC18S78 ZfL+ilbTInzH6mUIH7DmGi/qsNuKmk3a+/Ou2rBT6puNQbPXlBjBFL8XGR4gGNFz H5+zgvtg7Q1cint7WLqDIrTCDsuEl3wHdE9hE4XBAHT6vtR6g4KbMJupe+5P0Jfw IZh0yiuCpTqr+vJnlQKVIZ4+1jPRFSxAkFi6kOr7WSIjaPXTwrWloitvKKhl6Qqh G7JW+6JqS9AQVmfPxyk90ZAFxAfxDYF6orHiJ+AIh65nmFkzJugZoS0O+wYKukP4 3rMg1ORvz4LRxOU5tdNf =sy9d -END PGP SIGNATURE- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi IOhannes, On 09.06.2015 09:03, IOhannes m zmölnig (Debian/GNU) wrote: On 2015-06-09 06:35, Fabian Greffrath wrote: Am Dienstag, den 09.06.2015, 00:26 +0200 schrieb Andreas Cadhalpun: So one can just use two directories, first run configure in both (with the different options), then compile the GPLv2 variant, copy the object files (without allcodecs.o) to the GPLv3 folder, build the remaining GPLv3 de-/encoders there and link the libraries again. this sounds like a good idea to start with. I have now implemented this and it works fine. It's in the extra branch of the ffmpeg git repository [1]. it sounds quite fragile to me. You have a point there, but I think it's good enough for practical use. while reducing build time is generally a good idea, i don't think it's worth the additional hassle needed to manually track whichever files are affected by enabling/disabling a given build option. There is no additional hassle in tracking which files are affected by enabling the additional codecs: These are only the files containing the additional codecs and libavcodec/allcodecs.c, which (as the name suggests) contains a list of all codecs. I'm quite sure this is not going to change. If this would ever be a problem, we'll notice soon enough, because I added an autopkgtest for the extra flavor. unless we hit a brick wall (e.g. cancelled builds due to timeouts on the build servers), i would recommend to keep it simple. How often do you build the ffmpeg package? Or have you ever tried to build it with qemu on, say, armel or sparc64? If you'll ever do, I'm sure you'll appreciate that it doesn't take twice as long as it already does. Simon McVittie seems to think the extra flavor is not a legal problem [2] and nobody on debian-legal objected so far. While I'm still not totally convinced that having the extra flavor is a good idea, I think that the way I implemented it should make everyone here reasonable happy. Or does someone also want a libavformat-extra flavor for the samba support? Best regards, Andreas 1: https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/commit/?h=extraid=1d1bf4062035d6a6c12f40fcaadbf09f74d6db1b 2: https://lists.debian.org/debian-legal/2015/06/msg5.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Fabian, On 08.06.2015 11:18, Fabian Greffrath wrote: Am Sonntag, den 07.06.2015, 20:45 +0200 schrieb Andreas Cadhalpun: It seems it doesn't really work, because calling configure again causes make to rebuild everything. Actually only if one changes the configure arguments things get rebuild and only those including config.h. That's somehow stupid, isn't it? Not really, because a large part of the code can be influenced with configure options. But if one just enables additional codecs, rebuilding is not really necessary (only libavcodec/allcodecs.o has to be rebuilt then.) So one can just use two directories, first run configure in both (with the different options), then compile the GPLv2 variant, copy the object files (without allcodecs.o) to the GPLv3 folder, build the remaining GPLv3 de-/encoders there and link the libraries again. 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
Re: Select provider of libav* libraries
Hi Reinhard, On 07.06.2015 22:08, Reinhard Tartler wrote: On Sat, Jun 6, 2015 at 3:05 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com mailto:andreas.cadhal...@googlemail.com wrote: The problem I see is run-time linking a GPLv2-only program with a GPLv3+ library. I think this makes such a Live DVD undistributable, because the licenses are not compatible. The problem is that neither of the involved licenses talk about run-time nor compile-time linking. The point is the creation of a derived work. Yes. You are right that in this situation, it is not clear at all of the live cd is a derived work, or a compilation of independent works. The former would be rather problematic, but my understanding is that a live cd is rather the latter. OK, in that case build-conflicts from the GPLv2-only programs on libavcodec-extra* should be totally sufficient. Would it be hard to patch the build system? To do what exactly? To implement this in a dh7-style debian/rules file. I do appreciate the dh7-style brevity for simple packages. But for complex packages, such as libav that makes use of multiple compilation passes, I found the provided abstractions that make it so attractive to use get quickly in the way. I don't think so. Since in the dh7-style everything can be overridden, it is just as flexible as the pre-dh7-style, but contains less boilerplate. Not having the libavcodec-extra flavor is not only a regression (having no AMR encoder), but also an improvement (simpler debian/rules, no license incompatibility to worry about, faster build, ...). I happen to think the improvement factor is bigger than the regression factor, but others may disagree. As Fabian points out, it is not only AMR, but (currently) also libvo-aacenc. I think the native aac encoder is better than the libvo-aacenc encoder, but if we provide a libavcodec-extra flavor, we can enable that as well. Best regards, Andreas 1: https://lists.debian.org/debian-legal/2015/06/msg5.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Andreas, Am Dienstag, den 09.06.2015, 00:26 +0200 schrieb Andreas Cadhalpun: So one can just use two directories, first run configure in both (with the different options), then compile the GPLv2 variant, copy the object files (without allcodecs.o) to the GPLv3 folder, build the remaining GPLv3 de-/encoders there and link the libraries again. this sounds like a good idea to start with. - Fabian signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Am Sonntag, den 07.06.2015, 20:45 +0200 schrieb Andreas Cadhalpun: It seems it doesn't really work, because calling configure again causes make to rebuild everything. That's somehow stupid, isn't it? signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Bálint, On 07.06.2015 19:17, Bálint Réczey wrote: 2015-06-07 15:24 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: Hi Fabian, On 07.06.2015 14:39, Fabian Greffrath wrote: Am Samstag, den 06.06.2015, 21:29 +0200 schrieb Andreas Cadhalpun: Maybe we could even find a reasonable way to implement this in a dh7-style debian/rules file without doubling the build-time. yes, most probably. I do strongly believe that it is not necessary to clean the source and rebuild *everything* from scratch because of the additional codecs. I am sure it would be sufficient to back up the regular built library and merely call ./configure and make again with the extra rules to build the extra variant. Yes, something like that should work. It seems it doesn't really work, because calling configure again causes make to rebuild everything. I think implementing the changes upstream instead of in debian/rules would help other distributions, too, and keep the packaging simple. I'm not sure how they handle this problem to be honest, but they may have faced it, too. I don't think that could be implemented easily. So rebuilding twice would be necessary. 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
Re: Select provider of libav* libraries
Hi Andreas, 2015-06-06 21:29 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: Hi Bálint, On 06.06.2015 21:00, Bálint Réczey wrote: 2015-06-06 20:10 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: That's not how I interpret DFSG §1 [1]: 1. Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. I think this applies to Debian Live DVDs. I'm pretty sure it does not. I can create a Live DVD which links some existing GPLv3 packages with incompatible packages and this is nat a fault of package maintainters. If you believe your interpretation is correct you can ask for confirmation on debian-legal. Maybe, but I don't really look forward to more legal discussions. (One reason to avoid the libavcodec-extra flavor.) Would you be willing to ask debian-legal for clarification? I did, please see the thread starting here: https://lists.debian.org/debian-legal/2015/06/msg4.html Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Sat, Jun 6, 2015 at 3:05 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: Hi Reinhard, On 06.06.2015 20:30, Reinhard Tartler wrote: On Sat, Jun 6, 2015 at 1:51 PM, Bálint Réczey bal...@balintreczey.hu wrote: The problem is that Debian users must be allowed to redistribute it, but as far as I understand it, it is not allowed to distribute e.g. a live DVD with hedgewars and libavcodec-extra installed. I also pointed this out in the previous discussion [1]. I'm not absolutely sure, but IMO yes, such Live DVD-s would not be allowed, but it is a problem of live DVD makers to care about. Package maintainers can't and should not prevent this usage. Why would you think that distributing the packages libavcodec-extra and hedgewars on the same Live media would create a derived work that must fulfill all licenses? I fail to spot the problem here. The problem I see is run-time linking a GPLv2-only program with a GPLv3+ library. I think this makes such a Live DVD undistributable, because the licenses are not compatible. The problem is that neither of the involved licenses talk about run-time nor compile-time linking. The point is the creation of a derived work. You are right that in this situation, it is not clear at all of the live cd is a derived work, or a compilation of independent works. The former would be rather problematic, but my understanding is that a live cd is rather the latter. If you want to be extra careful, just install the regular GPLv2+ libavcodec package, which according to the dependencies of the hedgewars package should work just fine. This wouldn't work if you also want to install devede, which depends on libavcodec-extra. (This dependency should probably be a recommends at most, anyway.) I tend to agree. I'm OK with disabling AMR encoder in ffmpeg and stay GPLv2 compatible with the packages since I have no packages requiring it nor use-cases as a user requiring it, but I prefer the choice provided by by current libav packaging. Thanks for the support! Would it be hard to patch the build system? To do what exactly? To implement this in a dh7-style debian/rules file. I do appreciate the dh7-style brevity for simple packages. But for complex packages, such as libav that makes use of multiple compilation passes, I found the provided abstractions that make it so attractive to use get quickly in the way. The current libav packaging already implements this in a way that the user can choose what packages to install. On a personal note: The libav packaging can surely be improved and simplified. But throwing away years of work just because, and knowing about the regressions for the sake of simplicity feels wrong. The main modernization would be a rewrite of the debian/rules file in dh7-style. This naturally replaces the previous one. The rest of the packaging is mainly declarative and can't be varied that much anyway. Not having the libavcodec-extra flavor is not only a regression (having no AMR encoder), but also an improvement (simpler debian/rules, no license incompatibility to worry about, faster build, ...). I happen to think the improvement factor is bigger than the regression factor, but others may disagree. As Fabian points out, it is not only AMR, but (currently) also libvo-aacenc. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Andreas, 2015-06-07 15:24 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: Hi Fabian, On 07.06.2015 14:39, Fabian Greffrath wrote: Am Samstag, den 06.06.2015, 21:29 +0200 schrieb Andreas Cadhalpun: Maybe we could even find a reasonable way to implement this in a dh7-style debian/rules file without doubling the build-time. yes, most probably. I do strongly believe that it is not necessary to clean the source and rebuild *everything* from scratch because of the additional codecs. I am sure it would be sufficient to back up the regular built library and merely call ./configure and make again with the extra rules to build the extra variant. Yes, something like that should work. I think implementing the changes upstream instead of in debian/rules would help other distributions, too, and keep the packaging simple. I'm not sure how they handle this problem to be honest, but they may have faced it, too. Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Andreas, Am Samstag, den 06.06.2015, 21:29 +0200 schrieb Andreas Cadhalpun: Maybe we could even find a reasonable way to implement this in a dh7-style debian/rules file without doubling the build-time. yes, most probably. I do strongly believe that it is not necessary to clean the source and rebuild *everything* from scratch because of the additional codecs. I am sure it would be sufficient to back up the regular built library and merely call ./configure and make again with the extra rules to build the extra variant. BTW, we are not talking about a single AMR encoder here: $ LANG=C apt-cache show libavcodec-extra-56 [...] This package is a replacement for the regular libavcodec56 library package; it contains the following additional codecs: . * OpenCORE Adaptive Multi-Rate (AMR) Narrow-Band (Encoder/Decoder) * OpenCORE Adaptive Multi-Rate (AMR) Wide-Band (Decoder) * Android VisualOn AAC (Encoder) * Android VisualOn Adaptive Multi-Rate (AMR) Wide-Band (Encoder) So, please do not play down the importance of this additional package! Thanks! - Fabian signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Bálint, On 07.06.2015 15:36, Bálint Réczey wrote: 2015-06-06 21:29 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: Maybe, but I don't really look forward to more legal discussions. (One reason to avoid the libavcodec-extra flavor.) Would you be willing to ask debian-legal for clarification? I did, please see the thread starting here: https://lists.debian.org/debian-legal/2015/06/msg4.html Thanks a lot! Now let's see what those more experienced with such license matters think about this. 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
Re: Select provider of libav* libraries
Hi Reinhard, Am Mittwoch, den 03.06.2015, 20:32 -0400 schrieb Reinhard Tartler: I think the statistics indicate that the situation is much worse than I expected. Please keep in mind that because of the daily merges, all commits that are made in Libav also appear in FFmpeg, but not the other way round. With a finger-in-the-wind estimate of subtracting the numbers in the Libav table from the FFmpeg table, the distance between Michael and the other FFmpeg developers because even more extreme. yes, so what? FFmpeg has a single main contributor. Like so many other project out there. That fact that you consider this a problem shows that the whole libav vs. ffmpeg debate is still much more a personal than a technical one. - Fabian signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Fabian, On 07.06.2015 14:39, Fabian Greffrath wrote: Am Samstag, den 06.06.2015, 21:29 +0200 schrieb Andreas Cadhalpun: Maybe we could even find a reasonable way to implement this in a dh7-style debian/rules file without doubling the build-time. yes, most probably. I do strongly believe that it is not necessary to clean the source and rebuild *everything* from scratch because of the additional codecs. I am sure it would be sufficient to back up the regular built library and merely call ./configure and make again with the extra rules to build the extra variant. Yes, something like that should work. BTW, we are not talking about a single AMR encoder here: $ LANG=C apt-cache show libavcodec-extra-56 [...] This package is a replacement for the regular libavcodec56 library package; it contains the following additional codecs: . * OpenCORE Adaptive Multi-Rate (AMR) Narrow-Band (Encoder/Decoder) * OpenCORE Adaptive Multi-Rate (AMR) Wide-Band (Decoder) * Android VisualOn AAC (Encoder) * Android VisualOn Adaptive Multi-Rate (AMR) Wide-Band (Encoder) FFmpeg has a native NB/WB AMR decoder as well as a native AAC encoder. So the only missing functionality without the extra flavor is encoding NB/WB AMR. (Since Narrow-Band and Wide-Band AMR are closely related, I'm talking about 'an' encoder, even though they are implemented as two different ones, provided by two different libraries.) So, please do not play down the importance of this additional package! I'm not trying to play down the importance of the libavcodec-extra flavor, but rather trying to find a reasonable assessment of it and this seems to be quite low importance. Another option of providing an AMR encoder in the Debian ffmpeg package would be to write a native implementation for FFmpeg. 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
Re: Select provider of libav* libraries
Hi, On 06.06.2015 02:01, Bálint Réczey wrote: GPL imposes no restrictions on _using_ software, but on distributing it without properly licensed source, i.e. distributing a binary compiled from GPLv3 source without also providing the source under GPLv3 is prohibited. Compiling hedgewars without libavcodec-extra creates a GPLv2 binary which is distributable. The user can install libavcodec-extra which would also work with hedgewars, but no one violated GPLv3 up to this point AFAIK. On 06.06.2015 02:07, Reinhard Tartler wrote: The keyword in this sentence is using. I do NOT think we need to prevent users from doing stupid things, but we must ensure that Debian as a (re-)distributor does not violate any licenses. The dependencies are set up in a way that ensures that all packages build against the GPLv2+ variants, and nowhere on the buildds or on any other Debian machine we distribute a piece of software that would be in violation here. And that was the point of this exercise. The problem is that Debian users must be allowed to redistribute it, but as far as I understand it, it is not allowed to distribute e.g. a live DVD with hedgewars and libavcodec-extra installed. I also pointed this out in the previous discussion [1]. Since the hassle makes more work for active ffmpeg maintainers and while I sponsored a few uploads I don't consider myself one I should not make the call, but it would be really nice to provide the AMR encoder as well in Debian and also keeping hedgewars in the archive. Maybe there is a way of providing libavcodec-extra and having modern packaging scripts. Maybe patching the build could help, but I have not checked this idea. The AMR encoder is anyway just a wrapper around libopencore/libvo. Gstreamer also has similar wrappers and since they are plugins, the license is less of a problem. Thus anyone really wanting to encode AMR can use gstreamer. Best regards, Andreas 1: https://lists.debian.org/debian-multimedia/2014/11/msg00018.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Reinhard, On 06.06.2015 02:07, Reinhard Tartler wrote: As you can see from above numbers, even in the uttermost worst case, that is if both Michael and the Libav developers stopped working on the codebase, FFmpeg would still have more commits than Libav currently does. Comparing an individual developer with a development team seems inappropriate to me. Also, the chosen development processes of both projects significantly affect the rate of commits. That comparison does not appear useful. I find the comparison quite telling. 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
Re: Select provider of libav* libraries
Hi Andreas, 2015-06-06 19:15 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: Hi, On 06.06.2015 02:01, Bálint Réczey wrote: GPL imposes no restrictions on _using_ software, but on distributing it without properly licensed source, i.e. distributing a binary compiled from GPLv3 source without also providing the source under GPLv3 is prohibited. Compiling hedgewars without libavcodec-extra creates a GPLv2 binary which is distributable. The user can install libavcodec-extra which would also work with hedgewars, but no one violated GPLv3 up to this point AFAIK. On 06.06.2015 02:07, Reinhard Tartler wrote: The keyword in this sentence is using. I do NOT think we need to prevent users from doing stupid things, but we must ensure that Debian as a (re-)distributor does not violate any licenses. The dependencies are set up in a way that ensures that all packages build against the GPLv2+ variants, and nowhere on the buildds or on any other Debian machine we distribute a piece of software that would be in violation here. And that was the point of this exercise. The problem is that Debian users must be allowed to redistribute it, but as far as I understand it, it is not allowed to distribute e.g. a live DVD with hedgewars and libavcodec-extra installed. I also pointed this out in the previous discussion [1]. I'm not absolutely sure, but IMO yes, such Live DVD-s would not be allowed, but it is a problem of live DVD makers to care about. Package maintainers can't and should not prevent this usage. Since the hassle makes more work for active ffmpeg maintainers and while I sponsored a few uploads I don't consider myself one I should not make the call, but it would be really nice to provide the AMR encoder as well in Debian and also keeping hedgewars in the archive. Maybe there is a way of providing libavcodec-extra and having modern packaging scripts. Maybe patching the build could help, but I have not checked this idea. The AMR encoder is anyway just a wrapper around libopencore/libvo. Gstreamer also has similar wrappers and since they are plugins, the license is less of a problem. Thus anyone really wanting to encode AMR can use gstreamer. I'm OK with disabling AMR encoder in ffmpeg and stay GPLv2 compatible with the packages since I have no packages requiring it nor use-cases as a user requiring it, but I prefer the choice provided by by current libav packaging. Would it be hard to patch the build system? Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Bálint, On 06.06.2015 19:51, Bálint Réczey wrote: 2015-06-06 19:15 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: On 06.06.2015 02:01, Bálint Réczey wrote: The problem is that Debian users must be allowed to redistribute it, but as far as I understand it, it is not allowed to distribute e.g. a live DVD with hedgewars and libavcodec-extra installed. I also pointed this out in the previous discussion [1]. I'm not absolutely sure, but IMO yes, such Live DVD-s would not be allowed, but it is a problem of live DVD makers to care about. Package maintainers can't and should not prevent this usage. That's not how I interpret DFSG §1 [1]: 1. Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. I think this applies to Debian Live DVDs. I'm OK with disabling AMR encoder in ffmpeg and stay GPLv2 compatible with the packages since I have no packages requiring it nor use-cases as a user requiring it, but I prefer the choice provided by by current libav packaging. Would it be hard to patch the build system? It'd probably be doable, but there are also other downsides like e.g. a doubled build-time. Best regards, Andreas 1: https://www.debian.org/social_contract.en.html#guidelines ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Andreas, 2015-06-06 20:10 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: Hi Bálint, On 06.06.2015 19:51, Bálint Réczey wrote: 2015-06-06 19:15 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: On 06.06.2015 02:01, Bálint Réczey wrote: The problem is that Debian users must be allowed to redistribute it, but as far as I understand it, it is not allowed to distribute e.g. a live DVD with hedgewars and libavcodec-extra installed. I also pointed this out in the previous discussion [1]. I'm not absolutely sure, but IMO yes, such Live DVD-s would not be allowed, but it is a problem of live DVD makers to care about. Package maintainers can't and should not prevent this usage. That's not how I interpret DFSG §1 [1]: 1. Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. I think this applies to Debian Live DVDs. I'm pretty sure it does not. I can create a Live DVD which links some existing GPLv3 packages with incompatible packages and this is nat a fault of package maintainters. If you believe your interpretation is correct you can ask for confirmation on debian-legal. I'm OK with disabling AMR encoder in ffmpeg and stay GPLv2 compatible with the packages since I have no packages requiring it nor use-cases as a user requiring it, but I prefer the choice provided by by current libav packaging. Would it be hard to patch the build system? It'd probably be doable, but there are also other downsides like e.g. a doubled build-time. I'm OK with doubled build-time, but I hoped we would need only doubled link-time. Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Reinhard, On 06.06.2015 20:30, Reinhard Tartler wrote: On Sat, Jun 6, 2015 at 1:51 PM, Bálint Réczey bal...@balintreczey.hu wrote: The problem is that Debian users must be allowed to redistribute it, but as far as I understand it, it is not allowed to distribute e.g. a live DVD with hedgewars and libavcodec-extra installed. I also pointed this out in the previous discussion [1]. I'm not absolutely sure, but IMO yes, such Live DVD-s would not be allowed, but it is a problem of live DVD makers to care about. Package maintainers can't and should not prevent this usage. Why would you think that distributing the packages libavcodec-extra and hedgewars on the same Live media would create a derived work that must fulfill all licenses? I fail to spot the problem here. The problem I see is run-time linking a GPLv2-only program with a GPLv3+ library. I think this makes such a Live DVD undistributable, because the licenses are not compatible. If you want to be extra careful, just install the regular GPLv2+ libavcodec package, which according to the dependencies of the hedgewars package should work just fine. This wouldn't work if you also want to install devede, which depends on libavcodec-extra. (This dependency should probably be a recommends at most, anyway.) Since the hassle makes more work for active ffmpeg maintainers and while I sponsored a few uploads I don't consider myself one I should not make the call, but it would be really nice to provide the AMR encoder as well in Debian and also keeping hedgewars in the archive. Maybe there is a way of providing libavcodec-extra and having modern packaging scripts. Maybe patching the build could help, but I have not checked this idea. The AMR encoder is anyway just a wrapper around libopencore/libvo. Gstreamer also has similar wrappers and since they are plugins, the license is less of a problem. Thus anyone really wanting to encode AMR can use gstreamer. Except those that want or need to use the avconv or ffmpeg command-line utilities. How many would that be? I'm OK with disabling AMR encoder in ffmpeg and stay GPLv2 compatible with the packages since I have no packages requiring it nor use-cases as a user requiring it, but I prefer the choice provided by by current libav packaging. Thanks for the support! Would it be hard to patch the build system? To do what exactly? To implement this in a dh7-style debian/rules file. The current libav packaging already implements this in a way that the user can choose what packages to install. On a personal note: The libav packaging can surely be improved and simplified. But throwing away years of work just because, and knowing about the regressions for the sake of simplicity feels wrong. The main modernization would be a rewrite of the debian/rules file in dh7-style. This naturally replaces the previous one. The rest of the packaging is mainly declarative and can't be varied that much anyway. Not having the libavcodec-extra flavor is not only a regression (having no AMR encoder), but also an improvement (simpler debian/rules, no license incompatibility to worry about, faster build, ...). I happen to think the improvement factor is bigger than the regression factor, but others may disagree. 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
Re: Select provider of libav* libraries
Hi Reinhard, 2015-06-06 20:30 GMT+02:00 Reinhard Tartler siret...@gmail.com: On Sat, Jun 6, 2015 at 1:51 PM, Bálint Réczey bal...@balintreczey.hu wrote: ... I'm OK with disabling AMR encoder in ffmpeg and stay GPLv2 compatible with the packages since I have no packages requiring it nor use-cases as a user requiring it, but I prefer the choice provided by by current libav packaging. Thanks for the support! Would it be hard to patch the build system? To do what exactly? The current libav packaging already implements this in a way that the user can choose what packages to install. On a personal note: The libav packaging can surely be improved and simplified. But throwing away years of work just because, and knowing about the regressions for the sake of simplicity feels wrong. According to Andreas run-time CPU detection can replace some of the complexities of libav's current packaging. It there is a simpler way of covering the rest I think the scripts should not be kept just because we worked on it for several years. What matters is the future maintenance cost, not the cost we paid in the past. Cheers, Balint PS: I think the current libav packaging served us well in the past and it was not a waste of time at all. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Andreas, 2015-06-06 21:05 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: The current libav packaging already implements this in a way that the user can choose what packages to install. On a personal note: The libav packaging can surely be improved and simplified. But throwing away years of work just because, and knowing about the regressions for the sake of simplicity feels wrong. The main modernization would be a rewrite of the debian/rules file in dh7-style. This naturally replaces the previous one. The rest of the packaging is mainly declarative and can't be varied that much anyway. Not having the libavcodec-extra flavor is not only a regression (having no AMR encoder), but also an improvement (simpler debian/rules, no license incompatibility to worry about, faster build, ...). I happen to think the improvement factor is bigger than the regression factor, but others may disagree. IMO there is a big problem in this reasoning. Our primary focus should be our users' needs and non of them would perceive any of the advantages directly, only the missing encoder. :-( Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Bálint, On 06.06.2015 21:00, Bálint Réczey wrote: 2015-06-06 20:10 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: That's not how I interpret DFSG §1 [1]: 1. Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. I think this applies to Debian Live DVDs. I'm pretty sure it does not. I can create a Live DVD which links some existing GPLv3 packages with incompatible packages and this is nat a fault of package maintainters. If you believe your interpretation is correct you can ask for confirmation on debian-legal. Maybe, but I don't really look forward to more legal discussions. (One reason to avoid the libavcodec-extra flavor.) Would you be willing to ask debian-legal for clarification? Would it be hard to patch the build system? It'd probably be doable, but there are also other downsides like e.g. a doubled build-time. I'm OK with doubled build-time, but I hoped we would need only doubled link-time. I think the implementation in the current libav package doubles the build-time, though technically that should not be necessary. On 06.06.2015 21:14, Bálint Réczey wrote: 2015-06-06 21:05 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: Not having the libavcodec-extra flavor is not only a regression (having no AMR encoder), but also an improvement (simpler debian/rules, no license incompatibility to worry about, faster build, ...). I happen to think the improvement factor is bigger than the regression factor, but others may disagree. IMO there is a big problem in this reasoning. Our primary focus should be our users' needs and non of them would perceive any of the advantages directly, only the missing encoder. :-( If there is actually a legal problem with the libavcodec-extra flavor and GPLv2-only programs, our users would benefit from the reduced legal risk. But if we would get confirmation from debian-legal that the libavcodec-extra package as currently implemented in src:libav is not a problem I'd be much less opposed to having the extra flavor. Maybe we could even find a reasonable way to implement this in a dh7-style debian/rules file without doubling the build-time. 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
Re: Select provider of libav* libraries
On Sat, Jun 6, 2015 at 1:51 PM, Bálint Réczey bal...@balintreczey.hu wrote: The problem is that Debian users must be allowed to redistribute it, but as far as I understand it, it is not allowed to distribute e.g. a live DVD with hedgewars and libavcodec-extra installed. I also pointed this out in the previous discussion [1]. I'm not absolutely sure, but IMO yes, such Live DVD-s would not be allowed, but it is a problem of live DVD makers to care about. Package maintainers can't and should not prevent this usage. Why would you think that distributing the packages libavcodec-extra and hedgewars on the same Live media would create a derived work that must fulfill all licenses? I fail to spot the problem here. If you want to be extra careful, just install the regular GPLv2+ libavcodec package, which according to the dependencies of the hedgewars package should work just fine. Since the hassle makes more work for active ffmpeg maintainers and while I sponsored a few uploads I don't consider myself one I should not make the call, but it would be really nice to provide the AMR encoder as well in Debian and also keeping hedgewars in the archive. Maybe there is a way of providing libavcodec-extra and having modern packaging scripts. Maybe patching the build could help, but I have not checked this idea. The AMR encoder is anyway just a wrapper around libopencore/libvo. Gstreamer also has similar wrappers and since they are plugins, the license is less of a problem. Thus anyone really wanting to encode AMR can use gstreamer. Except those that want or need to use the avconv or ffmpeg command-line utilities. I'm OK with disabling AMR encoder in ffmpeg and stay GPLv2 compatible with the packages since I have no packages requiring it nor use-cases as a user requiring it, but I prefer the choice provided by by current libav packaging. Thanks for the support! Would it be hard to patch the build system? To do what exactly? The current libav packaging already implements this in a way that the user can choose what packages to install. On a personal note: The libav packaging can surely be improved and simplified. But throwing away years of work just because, and knowing about the regressions for the sake of simplicity feels wrong. Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi, On 01.06.2015 17:06, Felipe Sateler wrote: You can check what /git/pkg-multimedia/setup-repository does. I would suggest to create the repository using that script, and then do: cd ffmpeg.git ; git fetch /git/collab-maint/ffmpeg.git I had to specify all branches explicitly (master:master etc.) to create these in the new repository. Otherwise this seems to have worked just fine. Thanks again for the suggestion. 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
Re: Select provider of libav* libraries
Hi Bálint, On 05.06.2015 17:25, Bálint Réczey wrote: 2015-06-05 0:28 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: ... That's not only because of optimization, but also for licensing issues: The lib*-extra-* packages are licensed with GPLv3+, which is not acceptable for the majority of applications in debian. Note that it does not matter whether or not there are GPLv3+ applications in the archive. These -extra- package do provide additional functionality that users do appreciate. However, we cannot provide that in the standard libav* packages because we do have GPLv2-only applications that we must not link against a GPLv3 libavcodec. The current implementation of the extra flavor doesn't prevent using it with a GPLv2-only program and thus is effectively nearly as bad as just enabling the GPLv3 code in the standard build. Adding a mechanism to prevent this would make the extra flavor even more complex. The aim is not preventing GPLv3 usage, but offering a choice for reverse dependencies. The problem is that using a GPLv2-only program like hedgewars [1] with the GPLv3+ libavcodec-extra is not legally allowed, but currently possible, because hedgewars depends on: libavcodec56 (= 6:11~beta1) | libavcodec-extra-56 (= 6:11.1) This has been discussed some month ago on the debian-multimedia list [2]. GPLv2 only packages can build-depend on only the GPLv2 compatible -dev packages, while packages compatible with GPLv3 can include FFmpeg's GPLv3 -dev packages in the build dependencies as well. I don't think having different build-dependencies would help, because the API is the same for GPLv2+ and GPLv3+. The possible solutions discussed back then were around manually adding binary package dependencies. I don't have the numbers on the GPLv2-only packages, There are a few, at least those mentioned in [3]. but if there are important ones which can't be relicensed this may make a good reason for providing separate GPLv2 and GPLv3 compatible libraries. The thing is that the only additional functionality of the GPLv3+ libavcodec is an AMR encoder. I think this is not enough to justify the hassle with the extra variant. Best regards, Andreas 1: https://tracker.debian.org/media/packages/h/hedgewars/copyright-0.9.20.5-12 2: https://lists.debian.org/debian-multimedia/2014/11/msg0.html 3: https://lists.debian.org/debian-multimedia/2014/11/msg4.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
[short answer, I'm on the run] On Thu, Jun 4, 2015 at 6:28 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: I had considered producing optimized flavors, but I came to the conclusion that it would complicate debian/rules without much benefit, because the flavors are mostly unnecessary: That's not only because of optimization, but also for licensing issues: The lib*-extra-* packages are licensed with GPLv3+, which is not acceptable for the majority of applications in debian. Note that it does not matter whether or not there are GPLv3+ applications in the archive. These -extra- package do provide additional functionality that users do appreciate. However, we cannot provide that in the standard libav* packages because we do have GPLv2-only applications that we must not link against a GPLv3 libavcodec. The current implementation of the extra flavor doesn't prevent using it with a GPLv2-only program and thus is effectively nearly as bad as just enabling the GPLv3 code in the standard build. The keyword in this sentence is using. I do NOT think we need to prevent users from doing stupid things, but we must ensure that Debian as a (re-)distributor does not violate any licenses. The dependencies are set up in a way that ensures that all packages build against the GPLv2+ variants, and nowhere on the buildds or on any other Debian machine we distribute a piece of software that would be in violation here. And that was the point of this exercise. Adding a mechanism to prevent this would make the extra flavor even more complex. I don't think this is necessary. I doubt that many users would find such a check actually helpful. As you can see from above numbers, even in the uttermost worst case, that is if both Michael and the Libav developers stopped working on the codebase, FFmpeg would still have more commits than Libav currently does. Comparing an individual developer with a development team seems inappropriate to me. Also, the chosen development processes of both projects significantly affect the rate of commits. That comparison does not appear useful. Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Andreas, 2015-06-05 17:53 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: Hi Bálint, On 05.06.2015 17:25, Bálint Réczey wrote: 2015-06-05 0:28 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: ... That's not only because of optimization, but also for licensing issues: The lib*-extra-* packages are licensed with GPLv3+, which is not acceptable for the majority of applications in debian. Note that it does not matter whether or not there are GPLv3+ applications in the archive. These -extra- package do provide additional functionality that users do appreciate. However, we cannot provide that in the standard libav* packages because we do have GPLv2-only applications that we must not link against a GPLv3 libavcodec. The current implementation of the extra flavor doesn't prevent using it with a GPLv2-only program and thus is effectively nearly as bad as just enabling the GPLv3 code in the standard build. Adding a mechanism to prevent this would make the extra flavor even more complex. The aim is not preventing GPLv3 usage, but offering a choice for reverse dependencies. The problem is that using a GPLv2-only program like hedgewars [1] with the GPLv3+ libavcodec-extra is not legally allowed, but currently possible, because hedgewars depends on: libavcodec56 (= 6:11~beta1) | libavcodec-extra-56 (= 6:11.1) This has been discussed some month ago on the debian-multimedia list [2]. GPL imposes no restrictions on _using_ software, but on distributing it without properly licensed source, i.e. distributing a binary compiled from GPLv3 source without also providing the source under GPLv3 is prohibited. Compiling hedgewars without libavcodec-extra creates a GPLv2 binary which is distributable. The user can install libavcodec-extra which would also work with hedgewars, but no one violated GPLv3 up to this point AFAIK. GPLv2 only packages can build-depend on only the GPLv2 compatible -dev packages, while packages compatible with GPLv3 can include FFmpeg's GPLv3 -dev packages in the build dependencies as well. I don't think having different build-dependencies would help, because the API is the same for GPLv2+ and GPLv3+. The possible solutions discussed back then were around manually adding binary package dependencies. I don't have the numbers on the GPLv2-only packages, There are a few, at least those mentioned in [3]. but if there are important ones which can't be relicensed this may make a good reason for providing separate GPLv2 and GPLv3 compatible libraries. The thing is that the only additional functionality of the GPLv3+ libavcodec is an AMR encoder. I think this is not enough to justify the hassle with the extra variant. Since the hassle makes more work for active ffmpeg maintainers and while I sponsored a few uploads I don't consider myself one I should not make the call, but it would be really nice to provide the AMR encoder as well in Debian and also keeping hedgewars in the archive. Maybe there is a way of providing libavcodec-extra and having modern packaging scripts. Maybe patching the build could help, but I have not checked this idea. Cheers, Balint Best regards, Andreas 1: https://tracker.debian.org/media/packages/h/hedgewars/copyright-0.9.20.5-12 2: https://lists.debian.org/debian-multimedia/2014/11/msg0.html 3: https://lists.debian.org/debian-multimedia/2014/11/msg4.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Reinhard, On 04.06.2015 02:32, Reinhard Tartler wrote: On Sun, May 31, 2015 at 7:21 AM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: and would rather propose to just rename the current libav source package to ffmpeg and package the latest ffmpeg source tarball. Then that ffmpeg source package would take over the binary package names as well. If you think it's not necessary to preserve the development packages from src:libav, my proposal becomes even simpler: Just rename lib*-ffmeg-dev to lib*-dev in the current ffmpeg source package. That'd work, because src:ffmpeg has a higher epoch. That's not what I'm proposing. It would certainly help if you would explain in more detail what you are proposing. I'd rather keep the packaging of the package that is currently called libav, because on many architectures, it compiles multiple flavors with hardware optimized flavors (on i386 for instance, there is a flavor without latest SEE, etc). I had considered producing optimized flavors, but I came to the conclusion that it would complicate debian/rules without much benefit, because the flavors are mostly unnecessary: That's not only because of optimization, but also for licensing issues: The lib*-extra-* packages are licensed with GPLv3+, which is not acceptable for the majority of applications in debian. Note that it does not matter whether or not there are GPLv3+ applications in the archive. These -extra- package do provide additional functionality that users do appreciate. However, we cannot provide that in the standard libav* packages because we do have GPLv2-only applications that we must not link against a GPLv3 libavcodec. The current implementation of the extra flavor doesn't prevent using it with a GPLv2-only program and thus is effectively nearly as bad as just enabling the GPLv3 code in the standard build. Adding a mechanism to prevent this would make the extra flavor even more complex. the only additional functionality of the extra variant is limited to an AMR encoder [3]. Thus I don't think this justifies the additional complexity of the extra variant. I disagree with this assessment, Well, you could file a bug report against src:ffmpeg. If enough users agree that having the AMR encoder available is important, I might reconsider my position. and can easily imagine future functionality that requires a GPLv3 build. If that happens, we can reevaluate the situation. * On i386 all the SSE etc. optimizations are guarded by runtime CPU detection, so that even when compiled with SSE the libraries work fine on CPUs without SSE. The only optimization were this doesn't apply are the i686 optimizations, which currently amount to a dozen assembler lines. So I don't think this justifies shipping two flavors. Have a look at #688384 - the conclusion was to compile for i586, which seems absurd to me for most users, even if most optimizations are indeed the runtime selected hand-written assembler parts. The libav packaging solves this with multiple compilation passes. The SIGILL in bug #688384 was caused by an MMX instruction (emms), which should have been guarded by runtime CPU detection. Since the bug reporter provided no additional information, it is impossible to say what the actual problem was. Anyway, this problem doesn't exist in the current ffmpeg package. At least I couldn't produce any SIGILL crash with 'qemu-system-i386 -cpu pentium,-mmx', which I think is the lowest supported CPU for i386. * The situation for arm*, where the neon/vfp optimizations are runtime guarded, is similar. I don't think so, have a look at #657885, which shows a SIGILL in cmdutils.c. This can hardly be caught at runtime. Thanks for pointing me to bug #657885, which is an excellent example for the problems that can be caused by building multiple flavors. The problem here was the the ffmpeg binary from the build with ARMv7 compiler optimizations was installed instead of the one with only ARMv4 instructions. This does not happen in the current ffmpeg package, which only builds the ARMv4 variant of the ffmpeg binary, while still having optimized code in the libraries, guarded by runtime CPU detection. The only SIGILL crash I could find with 'qemu-system-arm -M versatilepb' is caused by a bug in the have_setend detection. I've sent a patch fixing this upstream [1]. * This leaves powerpc, where configure would enable '-maltivec' together with the hand-written altivec optimizations, which are guarded by runtime CPU detection. This causes gcc to add some altivec instructions, which are not guarded and thus cause SIGILL. Looking into fixing this in the configure script is on my TODO list. It is impossible to fix (or rather not worth the effort to fix properly). Either you disable altivec completely, or you need need to pass -maltivec which allows you to use the altivec optimizations and break on non-altivec
Re: Select provider of libav* libraries
Hi Stuart, On 03.06.2015 11:14, Stuart Prescott wrote: 1: https://wiki.debian.org/Debate/libav-provider/ffmpeg thanks for this -- it's good to see a summary of where we are. It would be good if you also include information on: Thanks for the feedback. * the API stability promise of upstream (do we need a library transition each time a minor update is uploaded?) No API/ABI should ever change with bugfix releases, i.e. 2.6.* releases all have the same. With most new major upstream releases 2.* only new API is introduced and private API/ABI changed. So only buggy programs that use private API need to be fixed (see e.g. #783879 [1]). With some new major upstream releases the soversions get increased, at which point we need a library transition. * assuming there is an API stability promise within each branch, the frequency at which new releases are made that will require transitions The upstream tracker [2] gives a good overview about this. The last soversion bumps were: * 2.4 (2014-09-14) * 2.2 (2014-03-24, only libavfilter) * 2.0 (2013-07-10) * 1.1 (2013-01-07) * 1.0 (2012-09-28, only libavfilter) So transitions would be about once every half year and if one doesn't count libavfilter, because it only has a handful of reverse-dependencies, it's more like once per year. * the detailed plan on how Debian would get from the current packages to these packages. The libav→ffmpeg plan is in various places on this and the debian-release mailing lists, but it would be good to see it in one place for easy reference. I think the most relevant mail is [3]. I think we need to see a good overview of: - what source and binary package names will be uploaded to which releases There are three source packages, whose binaries should be changed to: * src:ffmpeg: - ffmpeg, ffmpeg-doc, ffmpeg-dbg, qt-faststart - lib*-ffmpegN - lib*-dev - lib*-ffmpeg-dev (transitional, to be removed before stretch release) - libav-tools-links (transitional, to be removed after stretch release) * src:libav: - libav-tools, libav-doc, libav-dbg - lib*N - libavcodec-extra* - lib*-libav-dev * src:libpostproc: - libpostproc52 - libpostproc-libav-dev I have patches implementing these changes, which I plan to send to the BTS soon. The uploads will first go to experimental and after passing NEW and getting a transition slot from the release team, to unstable. - which binary packages would disappear (and what to do about that) Short term: none For stretch: everything still built from src:libav and src:libpostproc and lib*-ffmpeg-dev. What we'll do about that is the library transition and what's mentioned in the point below. - what will be required from maintainers of rdeps Most will have to do nothing special, only those mentioned in above mail [3] need to adapt their packages, e.g. change dependencies on libav-tools to ffmpeg (list in [3]) and drop dependencies on libavcodec-extra (from devede and dvd-slideshow). - what sort of time periods the transition would take Well, the actual library transition will probably take about 5 days, which is the time after which britney propagates the binNMUs to testing. When it will happen depends on how long NEW processing will take and when a suitable transition slot is available. Changing the dependencies/recommends/suggests from libav-tools to ffmpeg should be done before stretch is released. - the results of the rebuilds you have done These are available in above mail [3]. blender, mpd and paraview are resolved in the meantime. - (I'd guess a ben file for the transition tracker would be handy too) I think the following should work: title = ffmpeg; is_affected = .depends ~ libavcodec56|libavcodec-extra-56|libavdevice55|libavfilter5|libavformat56|libavresample2|libavutil54|libpostproc52|libswscale3 | .depends ~ libavcodec-ffmpeg56|libavdevice-ffmpeg56|libavfilter-ffmpeg5|libavformat-ffmpeg56|libavresample-ffmpeg2|libavutil-ffmpeg54|libpostproc-ffmpeg53|libswresample-ffmpeg1|libswscale-ffmpeg3; is_good = .depends ~ libavcodec-ffmpeg56|libavdevice-ffmpeg56|libavfilter-ffmpeg5|libavformat-ffmpeg56|libavresample-ffmpeg2|libavutil-ffmpeg54|libpostproc-ffmpeg53|libswresample-ffmpeg1|libswscale-ffmpeg3; is_bad = .depends ~ libavcodec56|libavcodec-extra-56|libavdevice55|libavfilter5|libavformat56|libavresample2|libavutil54|libpostproc52|libswscale3; I'm aware that the plan is somewhat orthogonal to the actual decision about libav providers but I think the feasibility of the plan also informs us about the feasibility of making the change and gives confidence that the ffmpeg maintainers are aware of the size of the task they are volunteering for. OK, so I'll try to put this information on the Wiki. Best regards, Andreas 1: https://bugs.debian.org/783879 2: http://upstream-tracker.org/versions/ffmpeg.html 3:
Re: Select provider of libav* libraries
On Sun, May 31, 2015 at 7:21 AM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: and would rather propose to just rename the current libav source package to ffmpeg and package the latest ffmpeg source tarball. Then that ffmpeg source package would take over the binary package names as well. If you think it's not necessary to preserve the development packages from src:libav, my proposal becomes even simpler: Just rename lib*-ffmeg-dev to lib*-dev in the current ffmpeg source package. That'd work, because src:ffmpeg has a higher epoch. That's not what I'm proposing. I'd rather keep the packaging of the package that is currently called libav, because on many architectures, it compiles multiple flavors with hardware optimized flavors (on i386 for instance, there is a flavor without latest SEE, etc). I had considered producing optimized flavors, but I came to the conclusion that it would complicate debian/rules without much benefit, because the flavors are mostly unnecessary: That's not only because of optimization, but also for licensing issues: The lib*-extra-* packages are licensed with GPLv3+, which is not acceptable for the majority of applications in debian. Note that it does not matter whether or not there are GPLv3+ applications in the archive. These -extra- package do provide additional functionality that users do appreciate. However, we cannot provide that in the standard libav* packages because we do have GPLv2-only applications that we must not link against a GPLv3 libavcodec. * On i386 all the SSE etc. optimizations are guarded by runtime CPU detection, so that even when compiled with SSE the libraries work fine on CPUs without SSE. The only optimization were this doesn't apply are the i686 optimizations, which currently amount to a dozen assembler lines. So I don't think this justifies shipping two flavors. Have a look at #688384 - the conclusion was to compile for i586, which seems absurd to me for most users, even if most optimizations are indeed the runtime selected hand-written assembler parts. The libav packaging solves this with multiple compilation passes. * The situation for arm*, where the neon/vfp optimizations are runtime guarded, is similar. I don't think so, have a look at #657885, which shows a SIGILL in cmdutils.c. This can hardly be caught at runtime. * Sparc is on it's way out, possibly going to be replaced by sparc64. So building a sparc64 flavor on sparc isn't really useful. * This leaves powerpc, where configure would enable '-maltivec' together with the hand-written altivec optimizations, which are guarded by runtime CPU detection. This causes gcc to add some altivec instructions, which are not guarded and thus cause SIGILL. Looking into fixing this in the configure script is on my TODO list. It is impossible to fix (or rather not worth the effort to fix properly). Either you disable altivec completely, or you need need to pass -maltivec which allows you to use the altivec optimizations and break on non-altivec machines. So you either make all multimedia package unusably slow for altivec machines because altivec is not enabled, or you exclude all uses of non-altivec machines. Are there good reasons to produce these optimized flavors? Yes, there are, at least on i386, arm and powerpc. I would consider not having them a serious regression. Andreas, would that approach be acceptable to you? I'd rather continue with the packaging of the current ffmpeg source package, because the one from src:libav uses a pre-dh7 debian/rules, and a quite complicated one at that. I'm happy to simplify or refactor the packaging, but I fear I have to insist to continue using the current src:libav packaging. It also seems easier to conduct the resulting transition if the package names of what application packages depend on don't change. Please let's not overcomplicate these things. If so, then I'd propose to get a test package ready in Git, and I'd then do a mass-rebuild on my amd64 box to see how many packages fail to build. I already did a mass-rebuild for my proposal and the results can be found in my mail [1] mentioned above. The blender and paraview FTBFS bugs have been resolved and the new mpd version is now in sid, so unless new, unrelated FTBFS bugs were introduced, only 7 packages would fail to build. Three of those FTBFS already (dvswitch has a patch in #747868, gstreamer0.10-ffmpeg should be removed and jitsi is fixed in NEW since 8 months). Two (gpac and xbmc) would require changes for the next Libav version as well, because they use private API, which was changed. The hardcoded sonames in taoframework have to be updated, like in every Libav transition. (Maybe someone can fix taoframework to use the sonames present in the build environment?) So only gst-libav1.0 needs a FFmpeg specific change, which is an additional build-dependency on libavresample-dev, because it
Re: Select provider of libav* libraries
Hi Andreas, 1: https://wiki.debian.org/Debate/libav-provider/ffmpeg thanks for this -- it's good to see a summary of where we are. It would be good if you also include information on: * the API stability promise of upstream (do we need a library transition each time a minor update is uploaded?) * assuming there is an API stability promise within each branch, the frequency at which new releases are made that will require transitions * the detailed plan on how Debian would get from the current packages to these packages. The libav→ffmpeg plan is in various places on this and the debian-release mailing lists, but it would be good to see it in one place for easy reference. I think we need to see a good overview of: - what source and binary package names will be uploaded to which releases - which binary packages would disappear (and what to do about that) - what will be required from maintainers of rdeps - what sort of time periods the transition would take - the results of the rebuilds you have done - (I'd guess a ben file for the transition tracker would be handy too) I'm aware that the plan is somewhat orthogonal to the actual decision about libav providers but I think the feasibility of the plan also informs us about the feasibility of making the change and gives confidence that the ffmpeg maintainers are aware of the size of the task they are volunteering for. cheers Stuart -- Stuart Prescott ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Alessio, On 01.06.2015 18:14, Alessio Treglia wrote: On Mon, Jun 1, 2015 at 5:07 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: I hope creating these wiki pages won't delay the switch. And it'll save me from having to explain my point of view another time, because I can just point to the wiki. We should have created such pages long ago actually. I agree. Better late than never though. I've just created the FFmpeg page [1]. There isn't much new for those who followed the discussion on the list, because I mainly copied from the mails. If something is wrong/missing, feel free to fix that, but please notify me, so that I can double-check it. I encourage those who prefer Libav to put their arguments on the corresponding Libav wiki page. Best regards, Andreas 1: https://wiki.debian.org/Debate/libav-provider/ffmpeg ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Sun, May 31, 2015 at 1:25 PM, Jonas Smedegaard d...@jones.dk wrote: No, neither the new input in the past couple weeks nor repition of old input have made me change opinion on the matter. Not mine, either. However, It seems pretty clear to me that the majority of those people who kindly took some time to reflect and speak about the matter would second a switch over to FFmpeg, so here is what will happen next: * Team members will have time until mid-week to speak up in favor or against this move. * If nothing relevant happens, I'll be sending a brief informal announce to debian-devel to share our opinion. Only one question now remains: is this team going to maintain FFmpeg? Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Mon, Jun 1, 2015 at 4:00 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: What about the git hooks sending the commit mails to the list? I can't imaging it'll just work, or will it? Ah, nice catch. I haven't played too much with the hooks, that's why I'd feel more comfortable in: 1. creating the empty repo 2. add a new remote 3. push everything to the new remote I can create the new empty pkg-multimedia/ffmpeg.git for you if you wish so, so that you can handle the rest eventually. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Felipe, On 01.06.2015 17:06, Felipe Sateler wrote: On 1 June 2015 at 12:00, Andreas Cadhalpun What about the git hooks sending the commit mails to the list? I can't imaging it'll just work, or will it? You can check what /git/pkg-multimedia/setup-repository does. Ah, thanks for the pointer. I would suggest to create the repository using that script, Like the following? /git/pkg-multimedia/setup-repository ffmpeg and then do: cd ffmpeg.git ; git fetch /git/collab-maint/ffmpeg.git Yes, I think that should work. Thanks again. I don't think a simple cp/move will do the right thing to permissions. That'd be another point. 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
Re: Select provider of libav* libraries
Hi Bálint, On 01.06.2015 17:57, Bálint Réczey wrote: 2015-06-01 17:45 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: I think having the arguments on the wiki isn't such a bad idea, because reading a long mailing list thread (where the arguments tend to go around in circles) consumes a lot of time. It'd also be nice for posterity, e.g. these sysvinit/systemd/upstart/openrc pages give a nice overview over available init systems. IMO the options here are way simpler than in the init system case and don't warrant the administrative overhead. Maybe, but still the discussion has been rather long already. I will not and can not stop anyone from editing wiki pages about the topic but fixing hundreds of security problems in unstable by actually making the switch earlier instead makes more sense to me. I hope creating these wiki pages won't delay the switch. And it'll save me from having to explain my point of view another time, because I can just point to the wiki. 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
Re: Select provider of libav* libraries
Hi Bálint, On 01.06.2015 17:37, Bálint Réczey wrote: 2015-06-01 15:33 GMT+02:00 Sebastian Ramacher sramac...@debian.org: On 2015-05-30 17:54:46, Reinhard Tartler wrote: - Sebastian, you made the most recent uploads of the Libav package where I handed off upstream releases to you, but I don't recall you participating in this thread. I also know that you have been interacting with Libav upstream in the past. I'd be very curious to hear your thoughts on this issue, would you mind sharing them? I have lost track of all the discussion happening around this topic. Can we get wiki pages that give a nice overview like we had for the systemd/sysvinit/upstart discussion [1]? Where can I find the current transition plan? Please read the thread on the list archive, both the discussion and the transition plan is there or opt out from the decision. I really can't understand your request to set up a wiki page just because you don't want to read the thread. I think having the arguments on the wiki isn't such a bad idea, because reading a long mailing list thread (where the arguments tend to go around in circles) consumes a lot of time. It'd also be nice for posterity, e.g. these sysvinit/systemd/upstart/openrc pages give a nice overview over available init systems. 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
Re: Select provider of libav* libraries
Hi Andreas, 2015-06-01 17:45 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: Hi Bálint, On 01.06.2015 17:37, Bálint Réczey wrote: 2015-06-01 15:33 GMT+02:00 Sebastian Ramacher sramac...@debian.org: On 2015-05-30 17:54:46, Reinhard Tartler wrote: - Sebastian, you made the most recent uploads of the Libav package where I handed off upstream releases to you, but I don't recall you participating in this thread. I also know that you have been interacting with Libav upstream in the past. I'd be very curious to hear your thoughts on this issue, would you mind sharing them? I have lost track of all the discussion happening around this topic. Can we get wiki pages that give a nice overview like we had for the systemd/sysvinit/upstart discussion [1]? Where can I find the current transition plan? Please read the thread on the list archive, both the discussion and the transition plan is there or opt out from the decision. I really can't understand your request to set up a wiki page just because you don't want to read the thread. I think having the arguments on the wiki isn't such a bad idea, because reading a long mailing list thread (where the arguments tend to go around in circles) consumes a lot of time. It'd also be nice for posterity, e.g. these sysvinit/systemd/upstart/openrc pages give a nice overview over available init systems. IMO the options here are way simpler than in the init system case and don't warrant the administrative overhead. I will not and can not stop anyone from editing wiki pages about the topic but fixing hundreds of security problems in unstable by actually making the switch earlier instead makes more sense to me. Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On 2015-06-01 17:29:13, Sebastian Ramacher wrote: Hi Andreas On 2015-06-01 16:59:13, Andreas Cadhalpun wrote: On 01.06.2015 15:33, Sebastian Ramacher wrote: On 2015-05-30 17:54:46, Reinhard Tartler wrote: - Sebastian, you made the most recent uploads of the Libav package where I handed off upstream releases to you, but I don't recall you participating in this thread. I also know that you have been interacting with Libav upstream in the past. I'd be very curious to hear your thoughts on this issue, would you mind sharing them? I have lost track of all the discussion happening around this topic. Can we get wiki pages that give a nice overview like we had for the systemd/sysvinit/upstart discussion [1]? If you tell me where and how, I can put my arguments on a wiki page. I've created [1]. [2] and [3] can be used to list arguments for libav respectively ffmpeg. Correct URLs: [1] https://wiki.debian.org/Debate/libav-provider [2] https://wiki.debian.org/Debate/libav-provider/libav [3] https://wiki.debian.org/Debate/libav-provider/ffmpeg Cheers -- Sebastian Ramacher signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
2015-06-01 17:37 GMT+02:00 Bálint Réczey bal...@balintreczey.hu: Hi Sebastian, 2015-06-01 15:33 GMT+02:00 Sebastian Ramacher sramac...@debian.org: On 2015-05-30 17:54:46, Reinhard Tartler wrote: - Sebastian, you made the most recent uploads of the Libav package where I handed off upstream releases to you, but I don't recall you participating in this thread. I also know that you have been interacting with Libav upstream in the past. I'd be very curious to hear your thoughts on this issue, would you mind sharing them? I have lost track of all the discussion happening around this topic. Can we get wiki pages that give a nice overview like we had for the systemd/sysvinit/upstart discussion [1]? Where can I find the current transition plan? Please read the thread on the list archive, both the discussion and the transition plan is there or opt out from the decision. I really can't understand your request to set up a wiki page just because you don't want to read the thread. If you want to collect what you read on a wiki page I'm fine with that but it seemed you were asking others to collect the information for you. Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Sebastian, On 01.06.2015 17:29, Sebastian Ramacher wrote: On 2015-06-01 16:59:13, Andreas Cadhalpun wrote: If you tell me where and how, I can put my arguments on a wiki page. I've created [1]. [2] and [3] can be used to list arguments for libav respectively ffmpeg. [1] https://wiki.debian.org/Debate/initsystem/libav-provider [2] https://wiki.debian.org/Debate/initsystem/libav-provider/libav [3] https://wiki.debian.org/Debate/initsystem/libav-provider/ffmpeg I'll try to fill the ffmpeg page at: https://wiki.debian.org/Debate/libav-provider/ffmpeg Will ffmpeg build the LGPL and GPL variants as libav did or are all reverse dependencies suddenly compatible with the GPL variant? Currently Libav only builds GPL-2+ and with libavcodec-extra* GPL-3+ libraries. Ah yes, got that mixed up. Since the only additional functionality of the extra variant is limited to an AMR encoder [3]. Thus I don't think this justifies the additional complexity of the extra variant. But it'd be a regression. Is there any data on how many people use that encoder? I don't have any data beyond the popularity contest [4]: libavcodec5649010 libavcodec-extra-56 1628 That's about 3%, though I doubt that all who have libavcodec-extra-56 installed actually need it. (I used to install it because the named implied it might be useful.) Best regards, Andreas 4: https://qa.debian.org/popcon.php?package=libav ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Mon, Jun 1, 2015 at 5:07 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: I hope creating these wiki pages won't delay the switch. And it'll save me from having to explain my point of view another time, because I can just point to the wiki. We should have created such pages long ago actually. Better late than never though. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Bálint On 2015-06-01 17:37:36, Bálint Réczey wrote: 2015-06-01 15:33 GMT+02:00 Sebastian Ramacher sramac...@debian.org: On 2015-05-30 17:54:46, Reinhard Tartler wrote: - Sebastian, you made the most recent uploads of the Libav package where I handed off upstream releases to you, but I don't recall you participating in this thread. I also know that you have been interacting with Libav upstream in the past. I'd be very curious to hear your thoughts on this issue, would you mind sharing them? I have lost track of all the discussion happening around this topic. Can we get wiki pages that give a nice overview like we had for the systemd/sysvinit/upstart discussion [1]? Where can I find the current transition plan? Please read the thread on the list archive, both the discussion and the transition plan is there or opt out from the decision. I really can't understand your request to set up a wiki page just because you don't want to read the thread. Because some structured source of information is a lot nicer than going through a large thread with over a hundred messages going in circles. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Andreas On 2015-06-01 16:59:13, Andreas Cadhalpun wrote: On 01.06.2015 15:33, Sebastian Ramacher wrote: On 2015-05-30 17:54:46, Reinhard Tartler wrote: - Sebastian, you made the most recent uploads of the Libav package where I handed off upstream releases to you, but I don't recall you participating in this thread. I also know that you have been interacting with Libav upstream in the past. I'd be very curious to hear your thoughts on this issue, would you mind sharing them? I have lost track of all the discussion happening around this topic. Can we get wiki pages that give a nice overview like we had for the systemd/sysvinit/upstart discussion [1]? If you tell me where and how, I can put my arguments on a wiki page. I've created [1]. [2] and [3] can be used to list arguments for libav respectively ffmpeg. [1] https://wiki.debian.org/Debate/initsystem/libav-provider [2] https://wiki.debian.org/Debate/initsystem/libav-provider/libav [3] https://wiki.debian.org/Debate/initsystem/libav-provider/ffmpeg Will ffmpeg build the LGPL and GPL variants as libav did or are all reverse dependencies suddenly compatible with the GPL variant? Currently Libav only builds GPL-2+ and with libavcodec-extra* GPL-3+ libraries. Ah yes, got that mixed up. Since the only additional functionality of the extra variant is limited to an AMR encoder [3]. Thus I don't think this justifies the additional complexity of the extra variant. But it'd be a regression. Is there any data on how many people use that encoder? Cheers -- Sebastian Ramacher signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On 1 June 2015 at 12:00, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: Hi Alessio (and all others who were quick to reply :), On 01.06.2015 16:58, Alessio Treglia wrote: On Mon, Jun 1, 2015 at 3:54 PM, umläute zmoel...@umlaeute.mur.at wrote: On 2015-06-01 16:49, Andreas Cadhalpun wrote: Does someone know what would be the best way to move the repository? $ cd /git/collab-maint $ mv ffmpeg.git /etc/pkg-multimedia $ ln -s /etc/pkg-multimedia/ffmpeg.git . should I do it? Both this and Fabian's should be fine, I'd double check directories and files permissions at the end of the procedure too. What about the git hooks sending the commit mails to the list? I can't imaging it'll just work, or will it? You can check what /git/pkg-multimedia/setup-repository does. I would suggest to create the repository using that script, and then do: cd ffmpeg.git ; git fetch /git/collab-maint/ffmpeg.git I don't think a simple cp/move will do the right thing to permissions. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On 2015-05-31 13:21:07, Andreas Cadhalpun wrote: I'd rather keep the packaging of the package that is currently called libav, because on many architectures, it compiles multiple flavors with hardware optimized flavors (on i386 for instance, there is a flavor without latest SEE, etc). I had considered producing optimized flavors, but I came to the conclusion that it would complicate debian/rules without much benefit, because the flavors are mostly unnecessary: * On i386 all the SSE etc. optimizations are guarded by runtime CPU detection, so that even when compiled with SSE the libraries work fine on CPUs without SSE. The only optimization were this doesn't apply are the i686 optimizations, which currently amount to a dozen assembler lines. So I don't think this justifies shipping two flavors. Besides some assembler lines, the i686 optimized build also allows the compiler to use cmov instructions. Would ffmpeg benefit from using them? Cheers -- Sebastian Ramacher signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Sebastian, On 01.06.2015 17:18, Sebastian Ramacher wrote: On 2015-05-31 13:21:07, Andreas Cadhalpun wrote: I'd rather keep the packaging of the package that is currently called libav, because on many architectures, it compiles multiple flavors with hardware optimized flavors (on i386 for instance, there is a flavor without latest SEE, etc). I had considered producing optimized flavors, but I came to the conclusion that it would complicate debian/rules without much benefit, because the flavors are mostly unnecessary: * On i386 all the SSE etc. optimizations are guarded by runtime CPU detection, so that even when compiled with SSE the libraries work fine on CPUs without SSE. The only optimization were this doesn't apply are the i686 optimizations, which currently amount to a dozen assembler lines. So I don't think this justifies shipping two flavors. Besides some assembler lines, the i686 optimized build also allows the compiler to use cmov instructions. Would ffmpeg benefit from using them? I haven't benchmarked this, but I think ffmpeg gets the most important speedup from the handwritten assembler optimizations. (That's also what I've been told about the altivec optimizations on powerpc, i.e. that the altivec optimizations of the compiler are less important than the handwritten ones.) 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
Re: Select provider of libav* libraries
On Mon, Jun 1, 2015 at 3:54 PM, umläute zmoel...@umlaeute.mur.at wrote: On 2015-06-01 16:49, Andreas Cadhalpun wrote: Does someone know what would be the best way to move the repository? $ cd /git/collab-maint $ mv ffmpeg.git /etc/pkg-multimedia $ ln -s /etc/pkg-multimedia/ffmpeg.git . should I do it? Both this and Fabian's should be fine, I'd double check directories and files permissions at the end of the procedure too. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Mon, Jun 1, 2015 at 3:49 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: Does someone know what would be the best way to move the repository? Just move the directory? Or add a new remote and push everything to it. I'd also suggest to ask for the removal of the old one - to save disk space. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Alessio (and all others who were quick to reply :), On 01.06.2015 16:58, Alessio Treglia wrote: On Mon, Jun 1, 2015 at 3:54 PM, umläute zmoel...@umlaeute.mur.at wrote: On 2015-06-01 16:49, Andreas Cadhalpun wrote: Does someone know what would be the best way to move the repository? $ cd /git/collab-maint $ mv ffmpeg.git /etc/pkg-multimedia $ ln -s /etc/pkg-multimedia/ffmpeg.git . should I do it? Both this and Fabian's should be fine, I'd double check directories and files permissions at the end of the procedure too. What about the git hooks sending the commit mails to the list? I can't imaging it'll just work, or will it? 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
Re: Select provider of libav* libraries
On 2015-05-30 17:54:46, Reinhard Tartler wrote: - Sebastian, you made the most recent uploads of the Libav package where I handed off upstream releases to you, but I don't recall you participating in this thread. I also know that you have been interacting with Libav upstream in the past. I'd be very curious to hear your thoughts on this issue, would you mind sharing them? I have lost track of all the discussion happening around this topic. Can we get wiki pages that give a nice overview like we had for the systemd/sysvinit/upstart discussion [1]? Where can I find the current transition plan? Will ffmpeg build the LGPL and GPL variants as libav did or are all reverse dependencies suddenly compatible with the GPL variant? Cheers [1] https://wiki.debian.org/Debate/initsystem -- Sebastian Ramacher signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On 2015-06-01 16:49, Andreas Cadhalpun wrote: Does someone know what would be the best way to move the repository? $ cd /git/collab-maint $ mv ffmpeg.git /etc/pkg-multimedia $ ln -s /etc/pkg-multimedia/ffmpeg.git . should I do it? fgasdr IOhannes ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Alessio, On 01.06.2015 08:49, Alessio Treglia wrote: On Sun, May 31, 2015 at 1:25 PM, Jonas Smedegaard d...@jones.dk wrote: No, neither the new input in the past couple weeks nor repition of old input have made me change opinion on the matter. Not mine, either. However, It seems pretty clear to me that the majority of those people who kindly took some time to reflect and speak about the matter would second a switch over to FFmpeg, so here is what will happen next: * Team members will have time until mid-week to speak up in favor or against this move. * If nothing relevant happens, I'll be sending a brief informal announce to debian-devel to share our opinion. That procedure works for me. Only one question now remains: is this team going to maintain FFmpeg? I think it would be a good idea if it did, so I just applied for membership. I also suggested Alexander to do the same. Does someone know what would be the best way to move the repository? 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
Re: Select provider of libav* libraries
Hi Sebastian, On 01.06.2015 15:33, Sebastian Ramacher wrote: On 2015-05-30 17:54:46, Reinhard Tartler wrote: - Sebastian, you made the most recent uploads of the Libav package where I handed off upstream releases to you, but I don't recall you participating in this thread. I also know that you have been interacting with Libav upstream in the past. I'd be very curious to hear your thoughts on this issue, would you mind sharing them? I have lost track of all the discussion happening around this topic. Can we get wiki pages that give a nice overview like we had for the systemd/sysvinit/upstart discussion [1]? If you tell me where and how, I can put my arguments on a wiki page. Where can I find the current transition plan? My proposal is in the mailing list archive [2]. It also contains a summary of the arguments for switching to FFmpeg. Will ffmpeg build the LGPL and GPL variants as libav did or are all reverse dependencies suddenly compatible with the GPL variant? Currently Libav only builds GPL-2+ and with libavcodec-extra* GPL-3+ libraries. Since the only additional functionality of the extra variant is limited to an AMR encoder [3]. Thus I don't think this justifies the additional complexity of the extra variant. Best regards, Andreas 2: https://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/044639.html 3: https://lists.debian.org/debian-multimedia/2014/11/msg8.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Am Montag, den 01.06.2015, 16:49 +0200 schrieb Andreas Cadhalpun: Does someone know what would be the best way to move the repository? Don't know of this is the best way, but it's the hard way. ssh git.debian.org cd /srv/git.debian.org/git mv collab-maint/ffmpeg.git pkg-multimedia ln -s pkg-multimedia/ffmpeg.git collab-maint - Fabian signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Dear Reinhard, Am Samstag, den 30.05.2015, 17:54 -0400 schrieb Reinhard Tartler: - Fabian, you were counted as in favor of switching to FFmpeg. In the light of the most recent posting from Andreas, the mails that Balint kindly forwarded, and my thoughts, would you approve and support moving Debian from Libav in favor of FFmpeg? Yes. I have already expressed my opinion before: http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/044078.html Having a dysfunctional bug tracker online for months, knowingly, and missing a codec that I need for my work was enough for me to get frustrated with the project. Also, I don't buy the it might not get your work done but it has a cleaner API argument. And I also don't think that boring code with less commits is easier to maintain because it is apparently missing many important commits that would actually do good to the code. You mention the bus factor of ffmpeg. First, there are many open-source projects with such a high bus factor, take for example Postfix or the Linux kernel. However, none of these projects will go down the drain if something bad happens to the main developer (god forbid!). They will recover and live on by their other contributors, maybe with a slower pace, but they will not vanish off the face of the earth (ffmpeg has proven very resistant towards such predictions already). Second, what would happen if something bad happened to Michael Niedermeyer (again, god forbid!)? Then ffmpeg wouldn't have a dedicated developer anymore who takes care of security and other issues full-time. But, you know, libav doesn't even have this one developer in the first place. So, it seems like libav has already been hit by the bus that you are afraid may hit ffmpeg one day. The situation would be nearly the same. Cheers, Fabian signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Reinhard, On 30.05.2015 23:54, Reinhard Tartler wrote: On Fri, May 29, 2015 at 9:16 AM, Bálint Réczey bal...@balintreczey.hu wrote: Andeas already proposed a transition plan [1] and already submitted several bugs. If we decide to switch to ffmpeg, I think this is the best proposal so far. [1] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/043980.html That mail proposes to make changes to the libav source package so that the ffmpeg source package can take over binary package names currently produced by libav. That's correct. That seems overly complicated to me, I think this renaming is a rather mechanical change. and would rather propose to just rename the current libav source package to ffmpeg and package the latest ffmpeg source tarball. Then that ffmpeg source package would take over the binary package names as well. If you think it's not necessary to preserve the development packages from src:libav, my proposal becomes even simpler: Just rename lib*-ffmeg-dev to lib*-dev in the current ffmpeg source package. That'd work, because src:ffmpeg has a higher epoch. I'd rather keep the packaging of the package that is currently called libav, because on many architectures, it compiles multiple flavors with hardware optimized flavors (on i386 for instance, there is a flavor without latest SEE, etc). I had considered producing optimized flavors, but I came to the conclusion that it would complicate debian/rules without much benefit, because the flavors are mostly unnecessary: * On i386 all the SSE etc. optimizations are guarded by runtime CPU detection, so that even when compiled with SSE the libraries work fine on CPUs without SSE. The only optimization were this doesn't apply are the i686 optimizations, which currently amount to a dozen assembler lines. So I don't think this justifies shipping two flavors. * The situation for arm*, where the neon/vfp optimizations are runtime guarded, is similar. * Sparc is on it's way out, possibly going to be replaced by sparc64. So building a sparc64 flavor on sparc isn't really useful. * This leaves powerpc, where configure would enable '-maltivec' together with the hand-written altivec optimizations, which are guarded by runtime CPU detection. This causes gcc to add some altivec instructions, which are not guarded and thus cause SIGILL. Looking into fixing this in the configure script is on my TODO list. Are there good reasons to produce these optimized flavors? Andreas, would that approach be acceptable to you? I'd rather continue with the packaging of the current ffmpeg source package, because the one from src:libav uses a pre-dh7 debian/rules, and a quite complicated one at that. If so, then I'd propose to get a test package ready in Git, and I'd then do a mass-rebuild on my amd64 box to see how many packages fail to build. I already did a mass-rebuild for my proposal and the results can be found in my mail [1] mentioned above. The blender and paraview FTBFS bugs have been resolved and the new mpd version is now in sid, so unless new, unrelated FTBFS bugs were introduced, only 7 packages would fail to build. Three of those FTBFS already (dvswitch has a patch in #747868, gstreamer0.10-ffmpeg should be removed and jitsi is fixed in NEW since 8 months). Two (gpac and xbmc) would require changes for the next Libav version as well, because they use private API, which was changed. The hardcoded sonames in taoframework have to be updated, like in every Libav transition. (Maybe someone can fix taoframework to use the sonames present in the build environment?) So only gst-libav1.0 needs a FFmpeg specific change, which is an additional build-dependency on libavresample-dev, because it currently relies on libavcodec-dev to bring this indirectly, but FFmpeg's libavcodec uses libswresample instead of libavresample. If that number seems acceptable, then first upload it to experimental, and then coordinate with the release team to get a transition slot. That's a sensible plan, similar to what I had in mind. Regarding the actual decision whether or not to abandon Libav in favor of FFmpeg: After thinking about this very hard for a couple of weeks, I find we are in a very uncomfortable situation. The whole FFmpeg/Libav user base is in an uncomfortable situation since the split. Neither of the two competing projects is really ideal, but the reality is that there is no one in Debian who has the capacity to significantly contribute to either of those projects - we are effectively dependent on the upstream project to provide a product that we can integrate and redistribute. I have been doing that during the jessie's development, but things have changed in my life and I'm no longer able to keep up with that commitment. Libav has served us very well for years, but the project lost much of its drive from its inception, which is very unfortunate. FFmpeg clearly
Re: Select provider of libav* libraries
On Sun, May 31, 2015 at 10:30 AM, Bálint Réczey bal...@balintreczey.hu wrote: 2015-05-30 23:54 GMT+02:00 Reinhard Tartler siret...@gmail.com: Where is Reinhard's original mail? I can't find it. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
2015-05-30 23:54 GMT+02:00 Reinhard Tartler siret...@gmail.com: ... I'd rather keep the packaging of the package that is currently called libav, because on many architectures, it compiles multiple flavors with hardware optimized flavors (on i386 for instance, there is a flavor without latest SEE, etc). IMO merging the mentioned and other useful parts to ffmpeg:src and a switch would be better than switching libav's upstream again. It would be less confusing for everyone. Why should I always explain that yes, it is FFmpeg but we call it the libav source package and yes, there is a Libav upstream project which is not tracked by any package in Debian anymore. :-) ... Bottom line: I still have some concerns with this move, but I can't claim Libav to be superior to FFmpeg at this point. From the provided product, I still do believe that Libav is the more promising code-base for integrating into a large-scale distribution such as Debian because it has a cleaner code-base that is easier to understand and extend. From the development communities, Libav clearly can't keep up with FFmpeg, who has a defacto full-time developer doing an outstanding amount of work. There is, however, a significant risk in form of a bus-factor: Is Michael replaceable? He has been working on FFmpeg for over 15 years more or less full-time, but is this going to continue like that forever? Most likely not; so is the risk for that acceptable for Debian? - It appears that Balint, Allesandro and Andreas think it clearly is - and I'm not sure why they appear to be so convinced on this point; neither of them has been around when the things escalated and Libav forked from FFmpeg after all. I have explained my professional opinion regarding the situation but I summarize it briefly adding the project management perspective: If Michael stops contributing to FFmpeg, there will be enough people around to continue development from that point in the ffmpeg tree. Forking in advance is a waste of time, but improving and understanding ffmpeg's codebase would be valuable even without considering the bus factor. Libav is full of known secholes while ffmpeg is fuzz-free which calls for an immediate switch. Libav lacks manpower and nothing seems to change it in the near nor the far future. I was not around when Newton discovered gravity, but it worked for me pretty reliably so far. :-) Cheers, Balint PS: Stretch without FFmpeg means Stretch without Kodi almost certainly. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
[CC'ed are the maintainers of reverse (build-)dependencies. Please reply only to pkg-multimedia-maintainers@lists.alioth.debian.org. If you're interested in this discussion, consider subscribing that list.] Hi, On 29.04.2015 20:56, Alessio Treglia wrote: I am afraid that I have to revive this discussion once again now that Jessie is out as we have plenty of time before starting doing any major work for Stretch: it's really the right time to make a final decision about this subject. The need to get this dichotomy solved may be found in Moritz's last email: On Wed, Apr 29, 2015 at 7:22 PM, Moritz Mühlenhoff jmm at inutil.org wrote: To properly migrate over a daemon they need to co-exist for a stable release, while a lib does not. Stretch will only have one of them. [snip] Having both for a year along each other will only waste people's time. Now at the beginning of the release cycle is the time to make a decision, not by dragging things into a year as of today. Picking one of the two won't be any simpler in 12 months. It appears clear to me that the security team wouldn't be too happy to support both FFmpeg and libav: Therefore the question still remains: On Tue, Aug 26, 2014 at 11:36 PM, Benjamin Drung bdrung at debian.org wrote: So I am asking you: Should we ship libav or FFmpeg? Can we reach a consensus on this topic? Currently FFmpeg [1] and Libav [2] packages coexist in unstable without any technical problems. However, unless someone can convince the Debian Security Team that supporting both in a stable release would be acceptable (I couldn't), a decision has to be made. I think FFmpeg should be chosen, because it is better than Libav in practically every way: * It has more features, e.g. it supports more codecs/formats/filters and devices [3]. * Some applications require some of those features and thus don't work with Libav, e.g. chromium, currently using an embedded copy [4]. * Bug fixes in FFmpeg are only rarely cherry-picked to Libav, while most changes in Libav are merged into FFmpeg. Thus Libav contains bugs not present in FFmpeg. (See e.g. #783616 [5] for a typical example.) * The previous point also applies to security fixes. (See e.g. CVE-2015-3417 [6] for a typical example.) Thus I'm proposing a transition from FFmpeg to Libav. The transition consists of two parts: libraries and command line tools. Transitioning the libraries could be done by switching build-dependencies from lib*-dev (built from src:libav) to lib*-ffmpeg-dev (built from src:ffmpeg). But because this would require making source changes to all reverse build-dependencies, I think it would be better to rename the libraries from src:libav to lib*-libav-dev and those from src:ffmpeg to lib*-dev. Then binNMUs would be sufficient for most reverse build-dependencies. Transitioning from the libav-tools to the ffmpeg binary package has to be done for all packages depending on libav-tools. Otherwise they would become uninstallable. Adjusting recommends/suggests would also be good, but is not as important. Reverse build-dependencies requiring work: * blender: FTBFS #783838, fixed in experimental * dvswitch: FTBFS #747868, not in testing * gpac: uses private libavformat define #783879 * gstreamer0.10-ffmpeg: FTBFS #720796, should be removed * gst-libav1.0: needs build-dependency on libavresample-dev * jitsi: FTBFS: #759835, fixed in NEW * mpd: needs version from experimental, see [7] * paraview: FTBFS #783842 * taoframework: hardcoded sonames need to be updated * xbmc: to be replaced by kodi (in NEW), which uses FFmpeg already Reverse dependencies of libav-tools: * devedesupports both * dvd-slideshow drop ffmpeg-avconv.patch * dvdwizard drop port-to-avconv.patch * ffdiaporama supports both * gerrisdrop 04_replace_ffmpeg_by_avconv.patch * ifetch-tools no direct use (why the dependency?) * kdenlive supports both * miro drop 140_use_avconv.patch * performous-tools drop use-avconv.patch * python-satellites needs one-line patch for video.py: avconv - ffmpeg * python3-audioread drop avconv.patch * tribler supports both * videotransdrop 03-ffmpeg_to_avconv.patch * winff-gtk2,winff-qt supports both * zoneminderdrop libav_path.patch * zoomerneeds one-line patch for zoomer: avconv - ffmpeg Other packages needing changes: * x264 avconv - ffmpeg in debian/tests/encode-testimage * imagination drop 30_avconv_port.patch * transcodedrop 07_libav9-preset.patch Please let me know if you have better ideas about this or think that something above is not correct. Best regards, Andreas 1: https://tracker.debian.org/pkg/ffmpeg 2: https://tracker.debian.org/pkg/libav 3: http://lucy.pkh.me/diff 4: https://bugs.debian.org/763632 5: https://bugs.debian.org/783616 6:
Re: Select provider of libav* libraries
Quoting Reinhard Tartler (2015-05-30 23:54:46) - Jonas Allessio, Balint counted both of you as in favor of Libav. Did your opinion/impression change in the last couple of weeks? No, neither the new input in the past couple weeks nor repition of old input have made me change opinion on the matter. Can you think of criteria or assessments that would help with finding a decision on this matter? That seems like a question for us all, not just Alessio and me. No, I have not suggestions for that. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Fri, May 29, 2015 at 9:16 AM, Bálint Réczey bal...@balintreczey.hu wrote: Hi Dmitry, 2015-05-29 12:22 GMT+02:00 Dmitry Smirnov only...@debian.org: Thanks for insight into upstream security situation, Balint. So what would be the next step? Mass bug filings? Shall we draft a template here? Andeas already proposed a transition plan [1] and already submitted several bugs. If we decide to switch to ffmpeg, I think this is the best proposal so far. [1] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/043980.html That mail proposes to make changes to the libav source package so that the ffmpeg source package can take over binary package names currently produced by libav. That seems overly complicated to me, and would rather propose to just rename the current libav source package to ffmpeg and package the latest ffmpeg source tarball. I'd rather keep the packaging of the package that is currently called libav, because on many architectures, it compiles multiple flavors with hardware optimized flavors (on i386 for instance, there is a flavor without latest SEE, etc). Andreas, would that approach be acceptable to you? If so, then I'd propose to get a test package ready in Git, and I'd then do a mass-rebuild on my amd64 box to see how many packages fail to build. If that number seems acceptable, then first upload it to experimental, and then coordinate with the release team to get a transition slot. Regarding the actual decision whether or not to abandon Libav in favor of FFmpeg: After thinking about this very hard for a couple of weeks, I find we are in a very uncomfortable situation. Neither of the two competing projects is really ideal, but the reality is that there is no one in Debian who has the capacity to significantly contribute to either of those projects - we are effectively dependent on the upstream project to provide a product that we can integrate and redistribute. I have been doing that during the jessie's development, but things have changed in my life and I'm no longer able to keep up with that commitment. Libav has served us very well for years, but the project lost much of its drive from its inception, which is very unfortunate. FFmpeg clearly provides more functionality and has definitely more manpower available that provides also updates for earlier releases. The drive for maintaining release branches is something rather new for FFmpeg, and it remains to be seen if that enthusiasm can be held up even without the competition from Libav. What makes me most uncomfortable about this move is that it is rather impossible to reverse - there is no going back. I certainly do hope that we do not open pandora's box - at least http://upstream-tracker.org/versions/ffmpeg.html looks promising, but then FFmpeg comes with a codebase that is hard to maintain, has competing (i.e., multiple) implementations for encoders and decoders, and so on. Bottom line: I still have some concerns with this move, but I can't claim Libav to be superior to FFmpeg at this point. From the provided product, I still do believe that Libav is the more promising code-base for integrating into a large-scale distribution such as Debian because it has a cleaner code-base that is easier to understand and extend. From the development communities, Libav clearly can't keep up with FFmpeg, who has a defacto full-time developer doing an outstanding amount of work. There is, however, a significant risk in form of a bus-factor: Is Michael replaceable? He has been working on FFmpeg for over 15 years more or less full-time, but is this going to continue like that forever? Most likely not; so is the risk for that acceptable for Debian? - It appears that Balint, Allesandro and Andreas think it clearly is - and I'm not sure why they appear to be so convinced on this point; neither of them has been around when the things escalated and Libav forked from FFmpeg after all. For me, that is a par - and I think I stand with my rather neutral position. On a personal note: I think the FFmpeg code base stems for a time where performance was the top-priority - long-term maintainability and security against malicious sources was clearly not. These new requirements are best addressed with a general redesign - ideally in a safer language such as Rust (http://www.rust-lang.org/), or similar. Unfortunately, such a project is not currently in sight, so the best option media playback applications have right now to provide secure and versatile playback capabilities is to sandbox the decoding process like the Chromium browser. This is challenging to implement and not-portable, which is however a stated goal of both Libav and FFmpeg. Also, I would feel much more comfortable if someone could convince me that FFmpeg is really not a one man show, and is taking maintenance of both internal and external APIs seriously. Because of the significance of this issue (this move is rather impossible to revert), I'd also like to
Re: Select provider of libav* libraries
On Fri, May 29, 2015 at 11:22 AM, Dmitry Smirnov only...@debian.org wrote: Thanks for insight into upstream security situation, Balint. So what would be the next step? Mass bug filings? Shall we draft a template here? Wait for Reinhard to come back up with news from libav side. Then, if nothing relevant happens, I think we'll be releasing a sort of team announcement to state that the majority of us would either second or not second the switch over to ffmpeg. Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Thanks for insight into upstream security situation, Balint. So what would be the next step? Mass bug filings? Shall we draft a template here? -- All the best, Dmitry Smirnov --- It is a fine thing to be honest, but it is also very important to be right. -- Winston Churchill signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Dmitry, 2015-05-29 12:22 GMT+02:00 Dmitry Smirnov only...@debian.org: Thanks for insight into upstream security situation, Balint. So what would be the next step? Mass bug filings? Shall we draft a template here? Andeas already proposed a transition plan [1] and already submitted several bugs. If we decide to switch to ffmpeg, I think this is the best proposal so far. Cheers, Balint [1] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/043980.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On 05/24/2015 07:13 PM, Bálint Réczey wrote: Hi All, I have contacted Moritz asking him to share his opinion regarding FFmpeg/Libav. He is not on the list thus asked me to forward his email. Moritz also suggested asking Mateusz Jurczyk. Please see his email: On 05/27/2015 08:21 PM, Mateusz Jurczyk wrote: Hi Balint and others, Sure, I am happy to share my thoughts. First of all apologies for the late reply, I've been quite busy during the last few days. Anyway, since I have already expressed my opinion regarding the subject several times, let me just quote some of them: While the former project [Libav] is doing their best to catch up with the latter, the figures speak for themselves again: there are “only” 413 commits tagged “Jurczyk” or “Coldwind” in Libav, so even though some of the FFmpeg bugs might not apply to Libav, there are still many unresolved issues there which are already fixed in FFmpeg. Consequently, we advise users to use the FFmpeg upstream code where possible, or the latest stable version (currently 2.1.1) otherwise. Source: http://j00ru.vexillium.org/?p=2211 [...] it is not just several bugs Libav is lagging behind on - it's literally hundreds, or potentially thousands, many of which are security problems. Gynvael and I have been fuzzing FFmpeg for ~3 years now, and Michael has been consistently fixing them in his project; so far, this has resulted in a total of 1318 patches in the library (git log | grep j00ru | wc -l). In the meantime, Libav is at 460 fixes, and the two codebases are really not that far off each other (I believe Libav has most of FFmpeg's code, and thus, bugs). We have fuzzed Libav independently and tried to get their maintainers interested in fixing all those issues (or picking patches from FFmpeg), and it has worked, but to very little extent. As a result, we now have this gigantic discrepancy in the security/reliability posture of the two projects, which goes far beyond just a few samples. [...] I'm looking forward to having Debian switched from Libav to FFmpeg - if there is any way I can help with that, let me know. Source: one of my previous e-mails sent to Moritz. Long story short, both FFmpeg and Libav projects contain a number of bugs in the processing of malformed input files, many of which are security vulnerabilities which can lead to arbitrary code execution and system compromise upon opening a specially crafted multimedia file. However, we have been trying to significantly decrease the number of such bugs in both projects via automated fuzz-testing, and specifically to get many of the low hanging fruits fixed so that it is no longer trivial for other people to discover security issues - in other words, to raise the bar for adversaries seeking to attack programs and systems which depend on multimedia handling. We have been quite successful working on the above effort with FFmpeg for the last ~3.5 years: every single issue we have found (even the least severe ones) has been fixed in a timely manner. As a result, after tens of fuzzing iterations, there are currently no bugs in FFmpeg that we are able to find using our current input corpus and mutation algorithms. The situation is entirely different with Libav, which is still affected by hundreds of such bugs, even though we have provided the developers with reproducing testcases a number of times in the past. Therefore, the security posture of Libav as of today is much, much worse than FFmpeg's, and this is the reason I support the transition to the latter library. I don't know anything about other aspects of the two projects, I can only give some insight into the security area. In this field, it is quite clear to me what the right choice is. Let me know if you have any questions. Cheers, Mateusz Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Am Mittwoch, den 27.05.2015, 22:01 +0200 schrieb Balint Reczey: Moritz also suggested asking Mateusz Jurczyk. Please see his email: This was very insightful, thank you! - Fabian signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi All, I have contacted Moritz asking him to share his opinion regarding FFmpeg/Libav. He is not on the list thus asked me to forward his email. Please see his answer inline. 2015-05-18 15:11 GMT+02:00 Alessandro Ghedini gh...@debian.org: On lun, mag 18, 2015 at 01:47:25 +0100, Alessio Treglia wrote: Ciao Alessandro, and thanks for sharing your thoughts, it's genuinely appreciated. On Mon, May 18, 2015 at 1:26 PM, Alessandro Ghedini gh...@debian.org wrote: And it's already clear that libav just doesn't provide enough security coverage, Can you please elaborate? AFAICS the versions in oldstable (0.8.17) and stable (11.3) are actively maintained upstream. Honestly that looks quite enough of security support. The security tracker lists three vulnerabilities that don't have patches in libav.git (but are fixed in ffmpeg in sid): https://security-tracker.debian.org/tracker/source-package/libav ffmpeg also provides a helpful security page that associates CVE ids with git commits for easy cherry-picking (libav doesn't do this): http://ffmpeg.org/security.html Plus see what Moritz (from the Security team) said about ffmpeg security responses (Andreas already mentioned this, but I think it's relevant here as well): I think ffmpeg is doing better in terms of handling security issues; when I contacted Michael Niedermeyer in private we has always quick to reply, while libav-security@ seems understaffed: Several queries in the past needed additional poking, some were left unaddressed until today. Also, the Google fuzzer guys stated that more samples are unfixed in libav compared to ffmpeg. https://lists.debian.org/debian-devel/2014/08/msg00060.html 2015-05-24 12:44 GMT+02:00 Moritz Muehlenhoff j...@inutil.org: ... (part directed to me) - What I wrote at https://lists.debian.org/debian-devel/2014/08/msg00060.html effectively still holds: | I think ffmpeg is doing better in terms of handling security issues; when | I contacted Michael Niedermeyer in private we has always quick to reply, | while libav-security@ seems understaffed: Several queries in the past needed | additional poking, some were left unaddressed until today. Also, the Google | fuzzer guys stated that more samples are unfixed in libav compared to ffmpeg. Several of the recently fixed libav security issues were only fixed because I contacted Michael Niedermeyer for the reproducers and reproduced them with libav git. There's no special Chrome test harness, all you need to do is rebuild libav with asan and exercise the reproducers. libav doesn't do that on it's own which I find disappointing since ffmpeg is obviously a fairly big part of their larger software ecosystem. This seems to caused by two factors: - lack of manpower in libav - a general animosity Another factor in favour of ffmpeg is the support maintenance. As Andreas quoted the libav 0.8 branch we use in wheezy will be EOLed soon. ffmpeg in contrast even made updates to the 0.5 branch in November (i.e. the version in squeeze) So summarising my personal perspective from being in the security team: We could live with either solution, but by now I personally have a preference towards ffmpeg with the lack of manpower in libav being the decisive factor. Also as a user of mpv in jessie I find the lack of external vobsub parsing support rather annoying. It's a frequent issue I personally run into (as a workaround mplayer2 can be used, but that's not ideal). - Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Quoting Dmitry Smirnov (2015-05-19 14:40:51) On Mon, 18 May 2015 16:05:11 Jonas Smedegaard wrote: How would they not be relevant? They recommend users to use ffmpeg and list examples of problems they may encounter if they decide to use mpv with libav (problems that are regularly reported as mpv bugs). Because a) it is not a comparison (as Dmitry introduced it) but a non-exhaustive list now shrunk to a single concrete item (subtitle coverage) that you find wrong to focus on and instead bring a different example of your own, and because b) it is not an assesment of *our* problem but a different problem that can be solved by running a script that recompiles against uptodate FFmpeg statically linked against mpv. Apologies for poor choice of words. Not much of a comparison (call it as you like) this ffmpeg vs. libav page contained some insights into pros and cons. Of course information there was incomplete and that's probably why it was taken down -- it is not mpv developers' job to maintain ffmpeg vs. libav wiki which opens them for criticism about inaccurate/incomplete/biased comparison. I imagine they've made up their minds and that page was not needed any more. Yet it had some useful information (that's why I mentioned it). No need for apology: I appreciate your sharing that page here, and agree that it provides insight potentially valuable to this discussion - no matter if still relevant for those who wrote the text, and no matter if it is/was a comparison or a list or a single point. Thanks! For the record, I do not criticise the authors of that text of it being inaccurate nor incomplete nor biased. On the contrary I appreciate their sharing publicly their notes for others to reuse :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Mon, 18 May 2015 12:16:32 Reinhard Tartler wrote: Interestingly Gentoo recently switched to FFmpeg by default [3] after conducting a survey [4]. About 300 people participated in that survey and the outcome was rather clear: It saddens me to see people organizing votes where people participate that have no idea what they are voting about. How many of the 300 people that participated have tried to cherry pick a fix to libavcodec, or can even tell what the difference between libavcodec and libswscale is? Voting among people who perfectly understands the problem would be unnecessary. But even votes from people who is not deeply into ffmpeg/libav differences are valuable because people have different perspectives. In this particular case the outcome was quite convincing unlike cases where ~51% is for something and ~49% is against (and everybody have a feeling that outcome is a mistake or mere twist of luck). It may be appealing to discredit voters (and invalidate outcome) but in general Gentoo users are not that illiterate... It took very much work and a long time to get were we are today. It would be very sad to see this work undone. We have opportunity to avoid even more work that is likely will be of little value in the future. Sensible for Debian? I'm not sure. You bring a number of good points, but there is a significant long-term risk with relying on a single genius developer. I'd rather love to see people working together than against each other, but that might be wishful thinking. This is another way to explain why I'm so undecided what to recommend: On the one hand, I of course can follow the argument that technically, it appears easy to abandon libav and migrate Debian over to the FFmpeg variant and benefit from all the additional functionality that have accumulated over time. This adds additional significant risks. I can also see the argument that compared to other risks that we take (see mysql/mariadb, openoffice/libreoffice, etc.) this may or may not be acceptable. Over time project with more gravity to attract contributors will evolve faster leaving another project behind with ever increasing gap. It affects long-term maintainability. We need to stay with more active project not only for features but due to pragmatic expectation that more active project will be better maintained. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- In questions of science, the authority of a thousand is not worth the humble reasoning of a single individual. -- Galileo Galilei signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Mon, 18 May 2015 16:05:11 Jonas Smedegaard wrote: How would they not be relevant? They recommend users to use ffmpeg and list examples of problems they may encounter if they decide to use mpv with libav (problems that are regularly reported as mpv bugs). Because a) it is not a comparison (as Dmitry introduced it) but a non-exhaustive list now shrunk to a single concrete item (subtitle coverage) that you find wrong to focus on and instead bring a different example of your own, and because b) it is not an assesment of *our* problem but a different problem that can be solved by running a script that recompiles against uptodate FFmpeg statically linked against mpv. Apologies for poor choice of words. Not much of a comparison (call it as you like) this ffmpeg vs. libav page contained some insights into pros and cons. Of course information there was incomplete and that's probably why it was taken down -- it is not mpv developers' job to maintain ffmpeg vs. libav wiki which opens them for criticism about inaccurate/incomplete/biased comparison. I imagine they've made up their minds and that page was not needed any more. Yet it had some useful information (that's why I mentioned it). -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B --- It is no use saying, 'We are doing our best.' You have got to succeed in doing what is necessary. -- Winston Churchill signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
