Bug#702762: Fwd: Re: [FFmpeg-devel] patch for x32 for libpostproc
There seems to be at least some activity here. Maybe we can update the Debian libpostproc package to Michael's new branch. Derek, just to clarify since you worked on the branch the package is currently based on: What are your thoughts on this? Are you interested in continuing this effort? What would you recommend to use for the Debian package? Is it useful to have libpostproc in Debian? (see also the backlog of this bug). Please advise. Thanks 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. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers signature.asc Description: 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: [FFmpeg-devel] patch for x32 for libpostproc
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. 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. Debian already does ship a split out libpostproc. I'm happy to upgrade it to some newer version if a tarball appeared. May I ask out of curiosity, what in FFmpeg actually uses libpostproc other than than libavfilter/vf_pp.c? You said that you prefer to maintain libpostproc inside FFmpeg because that way you can apply the FFmpeg test system on it. I wonder what automated tests cover code in libpostproc? -- 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: [FFmpeg-devel] patch for x32 for libpostproc
On Mon, Sep 08, 2014 at 08:13:48AM -0400, Reinhard Tartler wrote:
[..]
May I ask out of curiosity, what in FFmpeg actually uses libpostproc
other than than libavfilter/vf_pp.c? You said that you prefer to
maintain libpostproc inside FFmpeg because that way you can apply the
FFmpeg test system on it. I wonder what automated tests cover code in
libpostproc?
70% of pp is covered[1], through that vf_pp filter, see
fate-filter-pp{,2,3,4,5,6}. AFAIK that's the only code using libpostproc
so far in FFmpeg.
[1]: http://coverage.ffmpeg.org/ffmpeg/libpostproc/index.html
[...]
--
Clément B.
pgpsu6HZLAyuv.pgp
Description: 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: [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
Le duodi 22 fructidor, an CCXXII, Reinhard Tartler a écrit :
May I ask out of curiosity, what in FFmpeg actually uses libpostproc
other than than libavfilter/vf_pp.c? You said that you prefer to
maintain libpostproc inside FFmpeg because that way you can apply the
FFmpeg test system on it. I wonder what automated tests cover code in
libpostproc?
http://coverage.ffmpeg.org/ffmpeg/libavfilter/vf_pp.c.gcov.html
I suppose the relevant tests are filter-pp{,2,3,4,5,6}.
Regards,
--
Nicolas George
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
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... ___ 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 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. -- 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: [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 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. 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: [FFmpeg-devel] patch for x32 for libpostproc
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? The Debian package tracks that repository, and ideally we could collect the postproc patches there. -- 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: [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] patch for x32 for libpostproc
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? Any chance to make you reconsider reviving the standalone libpostproc.git? please use that for the debian package I fear that's not feasible at this point. -- 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
