Re: [FFmpeg-devel] patch for x32 for libpostproc
On Mon, Sep 08, 2014 at 08:13:48AM -0400, Reinhard Tartler wrote: On Sun, Sep 7, 2014 at 5:30 PM, Michael Niedermayer michae...@gmx.at wrote: On Fri, Sep 05, 2014 at 08:18:57AM +0200, Reimar Döffinger wrote: On 05.09.2014, at 03:46, Reinhard Tartler siret...@gmail.com wrote: On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer michae...@gmx.at wrote: At the end of the day, I need a source tarball that contains maintained sources of a stand-alone libpostproc. I don't care too much how it is created, as long as it doesn't result in code-duplication with existing sources in Debian. would it work if libpostproc could be build and installed standalone from ffmpeg git / ffmpeg release tarballs? That would be exactly the code-duplication I referred to in the text you've quoted. Combined with a release script doing rm of libav*? I think the problem is that libpostproc just isn't a viable stand-alone program, mostly due to complete lack of stand-alone testability not to mention test infrastructure. Keeping the separate git up-to-date certainly is an option but involves extra effort (though a lot less than making libpostproc testable stand-alone). I don't see a good way to split the libraries into separate repositories that does not involve either at least maintaining configure in each or seriously harming bisecting/regression testing. Release scripts that generate multiple tarballs seems more realistic than splitting the repository, in case that sounds like helpful to anyone... Heres a proof of concept updated libpostproc https://github.com/michaelni/FFmpeg/tree/separated_libpostproc this is simply a clone of ffmpeg with everything unneeded droped and the build system from the libpostproc repository it builds successfully but is completely untested beyond that It seems the old buildsystem lacks HAVE_MMX*_INLINE support, this would need to be added, as well as updating README and all that as well as testing That repo looks promising. However, the README and installations instructions still refer to FFmpeg which seems rather confusing to me. Also, the licensing needs to be clarified. AFAIUI, libpostproc is GPL only, so adding a LGPL license is also confusing at best. right, yes, ive removed them, COPYING* still contains to the GPL so that should do ive also fixed the MMX/SSE2 build, its still completey untested though beyond a simple make [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes 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: [FFmpeg-devel] patch for x32 for libpostproc
On Fri, Sep 05, 2014 at 08:18:57AM +0200, Reimar Döffinger wrote: On 05.09.2014, at 03:46, Reinhard Tartler siret...@gmail.com wrote: On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer michae...@gmx.at wrote: At the end of the day, I need a source tarball that contains maintained sources of a stand-alone libpostproc. I don't care too much how it is created, as long as it doesn't result in code-duplication with existing sources in Debian. would it work if libpostproc could be build and installed standalone from ffmpeg git / ffmpeg release tarballs? That would be exactly the code-duplication I referred to in the text you've quoted. Combined with a release script doing rm of libav*? I think the problem is that libpostproc just isn't a viable stand-alone program, mostly due to complete lack of stand-alone testability not to mention test infrastructure. Keeping the separate git up-to-date certainly is an option but involves extra effort (though a lot less than making libpostproc testable stand-alone). I don't see a good way to split the libraries into separate repositories that does not involve either at least maintaining configure in each or seriously harming bisecting/regression testing. Release scripts that generate multiple tarballs seems more realistic than splitting the repository, in case that sounds like helpful to anyone... Heres a proof of concept updated libpostproc https://github.com/michaelni/FFmpeg/tree/separated_libpostproc this is simply a clone of ffmpeg with everything unneeded droped and the build system from the libpostproc repository it builds successfully but is completely untested beyond that It seems the old buildsystem lacks HAVE_MMX*_INLINE support, this would need to be added, as well as updating README and all that as well as testing also the differences in aboves repo could possibly be used to construct a script to create a split out libpostproc for debian if thats whats wanted. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. 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: [FFmpeg-devel] patch for x32 for libpostproc
Hi Reinhard On Wed, Sep 03, 2014 at 11:33:48PM -0400, Reinhard Tartler wrote: On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote: On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer michae...@gmx.at wrote: On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote: Hi, as discussed in IRC, I was trying to minimal-invasively port libpostproc (the Debian source package) to x32¹. I could not test it (for lack of a stand-alone test program) yet, but at least I got it to build. you could try to test by buiding ffmpeg as a whole but disable asm everywhere except libpostproc that might allow easy testing though fate or ffmpeg with libavfilter Is http://git.videolan.org/?p=libpostproc.git still maintained? AFAIK, no, it seems the last commit is 2 years ago The Debian package tracks that repository, and ideally we could collect the postproc patches there. libpostproc was and is maintained in git://source.ffmpeg.org/ffmpeg.git So the promise given in https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html doesn't hold anymore? Can you be a bit more specific ? what promise by whom exactly do you speak of ? Any chance to make you reconsider reviving the standalone libpostproc.git? From what i remember there where some problems with that repository so actually maintaining it would probably imply first recreating it for example try to build a old revission: git checkout a792a836e3d9ef6f1f311604b38095e587282ca7 (this is libpostproc/master~20 ATM) ./configure -bash: ./configure: No such file or directory this is a problem for anyone maintaining the code as for example git bisect would not be usable at all or if you do a git show commit a792a836e3d9ef6f1f311604b38095e587282ca7 Merge: 1d261c2 7f1c286 7391383 8f2dfd0 8cf4ef5 59d8d9c Its a commit with 6 ancestors, no commit in FFmpeg or Libav has 6 ancestors So really, if someone wants to maintain or use libpostproc.git, first these things need to be fixed but i dont understand why you dont just take libpostproc from where its developed, tested and used ? but if it helps i guess we could copy the libpostproc from FFmpeg over the one in libpostproc.git (which is what reimar suggested) libpostproc.git was only intended to be a copy of FFmpeg with libs other than libpostproc removed anyway. Would this help you ? please use that for the debian package I fear that's not feasible at this point. Why ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. 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: [FFmpeg-devel] patch for x32 for libpostproc
On Thu, Sep 04, 2014 at 07:42:00PM -0400, Reinhard Tartler wrote: On Thu, Sep 4, 2014 at 7:27 AM, Michael Niedermayer michae...@gmx.at wrote: Hi Reinhard On Wed, Sep 03, 2014 at 11:33:48PM -0400, Reinhard Tartler wrote: On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote: On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer michae...@gmx.at wrote: On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote: Hi, as discussed in IRC, I was trying to minimal-invasively port libpostproc (the Debian source package) to x32¹. I could not test it (for lack of a stand-alone test program) yet, but at least I got it to build. you could try to test by buiding ffmpeg as a whole but disable asm everywhere except libpostproc that might allow easy testing though fate or ffmpeg with libavfilter Is http://git.videolan.org/?p=libpostproc.git still maintained? AFAIK, no, it seems the last commit is 2 years ago The Debian package tracks that repository, and ideally we could collect the postproc patches there. libpostproc was and is maintained in git://source.ffmpeg.org/ffmpeg.git So the promise given in https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html doesn't hold anymore? Can you be a bit more specific ? what promise by whom exactly do you speak of ? The promise of having a maintained stand-alone libpostproc. Any chance to make you reconsider reviving the standalone libpostproc.git? From what i remember there where some problems with that repository so actually maintaining it would probably imply first recreating it for example try to build a old revission: git checkout a792a836e3d9ef6f1f311604b38095e587282ca7 (this is libpostproc/master~20 ATM) ./configure -bash: ./configure: No such file or directory this is a problem for anyone maintaining the code as for example git bisect would not be usable at all or if you do a git show commit a792a836e3d9ef6f1f311604b38095e587282ca7 Merge: 1d261c2 7f1c286 7391383 8f2dfd0 8cf4ef5 59d8d9c Its a commit with 6 ancestors, no commit in FFmpeg or Libav has 6 ancestors So really, if someone wants to maintain or use libpostproc.git, first these things need to be fixed but i dont understand why you dont just take libpostproc from where its developed, tested and used ? but if it helps i guess we could copy the libpostproc from FFmpeg over the one in libpostproc.git (which is what reimar suggested) libpostproc.git was only intended to be a copy of FFmpeg with libs other than libpostproc removed anyway. Would this help you ? At the end of the day, I need a source tarball that contains maintained sources of a stand-alone libpostproc. I don't care too much how it is created, as long as it doesn't result in code-duplication with existing sources in Debian. would it work if libpostproc could be build and installed standalone from ffmpeg git / ffmpeg release tarballs? i havent really investigated it but it seems with the 2 line patch below one can achive that with ./configure --enable-gpl --disable-all --enable-shared --enable-postproc make (it also would need changing #includes ... to ... to use system installed libavutil headers) this seems a easier path than maintaining libpostproc.git if it would work for debian, if not iam sure we will find another solution like updating libpostproc.git. diff --git a/Makefile b/Makefile index 57f6a91..63423bf 100644 --- a/Makefile +++ b/Makefile @@ -48,7 +48,7 @@ FFLIBS-$(CONFIG_POSTPROC) += postproc FFLIBS-$(CONFIG_SWRESAMPLE) += swresample FFLIBS-$(CONFIG_SWSCALE)+= swscale -FFLIBS := avutil +FFLIBS-$(CONFIG_AVUTIL) += avutil DATA_FILES := $(wildcard $(SRC_PATH)/presets/*.ffpreset) $(SRC_PATH)/doc/ffprobe.xsd EXAMPLES_FILES := $(wildcard $(SRC_PATH)/doc/examples/*.c) $(SRC_PATH)/doc/examples/Makefile $(SRC_PATH)/doc/examples/README diff --git a/configure b/configure index 7de07c3..7a3764f 100755 --- a/configure +++ b/configure @@ -2614,7 +2614,7 @@ avdevice_deps=avformat avcodec avutil avfilter_deps=avutil avformat_deps=avcodec avutil avresample_deps=avutil -postproc_deps=avutil gpl +postproc_deps=gpl swresample_deps=avutil swscale_deps=avutil [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates 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: [FFmpeg-devel] patch for x32 for libpostproc
On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote: On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer michae...@gmx.at wrote: On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote: Hi, as discussed in IRC, I was trying to minimal-invasively port libpostproc (the Debian source package) to x32¹. I could not test it (for lack of a stand-alone test program) yet, but at least I got it to build. you could try to test by buiding ffmpeg as a whole but disable asm everywhere except libpostproc that might allow easy testing though fate or ffmpeg with libavfilter Is http://git.videolan.org/?p=libpostproc.git still maintained? AFAIK, no, it seems the last commit is 2 years ago The Debian package tracks that repository, and ideally we could collect the postproc patches there. libpostproc was and is maintained in git://source.ffmpeg.org/ffmpeg.git please use that for the debian package We also have a testing infrastructure in place for ffmpeg.git which tests libpostproc on a wide varity of platforms, libpostproc.git lacks that. And anyone using postprocessing with FFmpeg also tests the code so bugs in postproc in ffmpeg.git should be quickly found, reported and fixes. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu 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: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi On Sun, Aug 10, 2014 at 09:10:23AM -0400, Reinhard Tartler wrote: On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs matth...@urlichs.de wrote: [...] IMHO it's reasonable to expect core APIs to be upwards-compatible and keep deprecated interfaces around for another release or two. This is exactly what Libav is doing: The deprecation process for symbols, APIs, enums, etc. takes *years*, because so many software packages in Debian and else where use them, and it is so believably painful to change them. Just have a look at the last two Libav transitions, and the massive amount of patches it took to get packages fixed and eventually to get Debian to the new Libav release. Now enter FFmpeg. FFmpeg has a significant higher release frequency, (it seems to me about every 3-4 months), so that you would get a deprecation cycle that is considerably less than a year. In practice, the deprecation cycle more or less seems to match Libav's cycle, because at least right now, FFmpeg tracks Libav's API. If that were not the case (and I promise you FFmpeg would stop tracking Libav as soon as it replaces Libav in Debian), I can almost guarantee [1] you that FFmpeg would very much prefer to resume to the deprecation cycle the project before: None, i.e., every piece of software is expected to keep up with FFmpeg's master branch for reasons Jean-Yves outlines. These fears are unfounded and these predictions not only do not match reality they also lack any reason or motive for FFmpeg. We would be shooting us in our own foot if we randomly broke API or stopped integrating improvments It has always been my wish to provide the best multimedia software to the world. And sure us including all improvments and bugfixes from Libav is in line with that. also you have write access to FFmpeg git ... and iam happy to work together with andreas and anyone else on debian lifecycle releases. And you are certainly welcome too [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato 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: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Jul 28, 2014 at 04:05:46PM +0200, Andreas Cadhalpun wrote: On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote: On Mon, 28 Jul 2014, Norbert Preining wrote: On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. Michael Niedermayer from FFmpeg upstream volunteered to help with any future security issues in FFmpeg packages in debian [1]. Yes, i do! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus 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: on package duplication between Debian and debian-multimedia
Hi Stefano Ive been pointed to this thread ... Not taking any sides here, and iam not sure if this conflict is related to FFmpeg or if it is, how it is. But if there is any problem or bug in FFmpeg, i would be happy to fix it. bugreports on https://ffmpeg.org/trac/ffmpeg or in my inbox surely are welcome! Also if theres any feature in any fork/clone of ffmpeg that isnt in ffmpeg.org master git then as well iam interrested to hear about that so it can be integrated. And if theres anything i can do to get FFmpeg (+ffplay+libavcodec+ libavformat+libavfilter+libswresample+...) back into debian as official package, please tell me. The FFmpeg project definitly wants to be a official package in debian again! [...] Thanks! -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle 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: FFmpeg package in Debian/Ubuntu
Hi Fabian, Dominik, Debian developers On Wed, Oct 05, 2011 at 11:43:19AM +0200, Fabian Greffrath wrote: Dear Dominik, Am 23.09.2011 18:03, schrieb Dominik 'Rathann' Mierzejewski: Dear All, I'm sending this (Bcc) to Debian/Ubuntu package maintainers who are listed under Original Maintainers on http://packages.ubuntu.com/oneiric/ffmpeg and who seem to be doing something at least a bit related still. You seem to have missed Debian multimedia packages maintainers pkg-multimedia-maintainers@lists.alioth.debian.org. Shifting this mail there as I am not going to discuss this with you in private. Thank you for moving this to a public mailing list. Dominik has pointed me to this mail, and i think its something i should as main author of ffmpeg/libav, reply to. libav forked off ffmpeg in the begin of this year. Since then libav has fallen behind ffmpeg very significantly. Also due to the unfortunate choice of the name of the fork, i should probably clarify that the ffmpeg libraries libavcodec, libavformat, libavfilter and so on are developed and maintained within the ffmpeg project. Their maintainers, reviewers and authors are still predominantly in the ffmpeg project, in some cases like libavfilter and libpostproc all authors are to 100% on the ffmpeg side of the fork. In terms of features: ffmpeg has 17 additional decoders, 11 encoders, 11 demuxers, 5 muxers, 19 native av filter and 51 non native filters that libav does not have. You only have to diff the libav*/all*.c files between ffmpeg and libav git to see this. There is no single feature in libav that ffmpeg does not have. All improvments and bugfixes from libav are always merged into ffmpeg. But changes from ffmpeg are only sometimes merged into libav, this includes some security relevant changes. In terms of bugs: Both projects in the past used roundup to track bugs. With the fork we were forced to switch to a new serverhosting and with that also choose to use trak as tracker while libav, for reasons unknown to me switched to bugzilla. Due to this, its very easy to compare the bug fixing activity as both projects started with fresh trackers. ffmpeg has 280 fixed bugs, see: https://ffmpeg.org/trac/ffmpeg/query?resolution=fixed libav has 17 fixed bugs see: http://bugzilla.libav.org/buglist.cgi?query_format=advancedresolution=FIXED Given above, and especially the security issues, i would strongly suggest debian to reconsider the decission to package just libav. The ffmpeg team as well as I are of course happy to help with maintaining debian packages if such help is needed or wanted! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch 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
