Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reinhard Tartler]

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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Nicolas George]

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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reimar Döffinger]

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...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Nicolas George]

L'octidi 18 fructidor, an CCXXII, wm4 a écrit :
 And in general, it's a good idea to move optional libraries out of
 ffmpeg.git. (In fact, ffmpeg.git should be split into several git
 repos, one for each lib.)

That is a terrible idea. We already have too many difficulties maintaining
binaries compatibility between libraries hosted within a single source tree
(look at the number of avpriv functions in the source), splitting the source
would worsen that exponentially. And that causes users problems too,
especially when they have to deal with systems with braindead linking
mechanisms (android, I am looking at you).

The only reasonable way to go is on the contrary to merge the libraries.

(I have started working on that that summer, but I need to read
documentation on symbols versioning to get it working in a compatible way.)

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[wm4]

On Wed, 3 Sep 2014 23:33:48 -0400
Reinhard Tartler siret...@gmail.com 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?
 
 Any chance to make you reconsider reviving the standalone libpostproc.git?

Yes, let me add my protest against this bullshit of still maintaining
libpostproc as part of ffmpeg.git in FFmpeg.

  please use that for the debian package
 
 I fear that's not feasible at this point.
 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Michael Niedermayer]

On Thu, Sep 04, 2014 at 03:53:55PM +0200, wm4 wrote:
 On Wed, 3 Sep 2014 23:33:48 -0400
 Reinhard Tartler siret...@gmail.com 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?
  
  Any chance to make you reconsider reviving the standalone libpostproc.git?
 
 Yes, let me add my protest against this bullshit of still maintaining
 libpostproc as part of ffmpeg.git in FFmpeg.

Can you elaborate / explain why 14496-2 Part 2: Visual Annex F.3
Postprocessing for Coding Noise Reduction
(which is about half of what libpostproc is)

Aka a part of the implementation of the MPEG4 ASP video specification
is insane to maintain in the same git repository as the
MPEG4 ASP video decoder and encoder ?

Iam not saying iam against it, just that it seems very strange to me

If people want we could revive libpostproc.git, it just seemed easier
to me if people use libpostproc from FFmpeg

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Derek Buitenhuis]

On 9/4/2014 4:33 AM, Reinhard Tartler wrote:
 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?

Guilty party here.

I kinda just neglected it because 0 people care about.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[wm4]

On Thu, 4 Sep 2014 16:30:14 +0200
Michael Niedermayer michae...@gmx.at wrote:

 On Thu, Sep 04, 2014 at 03:53:55PM +0200, wm4 wrote:
  On Wed, 3 Sep 2014 23:33:48 -0400
  Reinhard Tartler siret...@gmail.com 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?
   
   Any chance to make you reconsider reviving the standalone libpostproc.git?
  
  Yes, let me add my protest against this bullshit of still maintaining
  libpostproc as part of ffmpeg.git in FFmpeg.
 
 Can you elaborate / explain why 14496-2 Part 2: Visual Annex F.3
 Postprocessing for Coding Noise Reduction
 (which is about half of what libpostproc is)
 
 Aka a part of the implementation of the MPEG4 ASP video specification
 is insane to maintain in the same git repository as the
 MPEG4 ASP video decoder and encoder ?

Even if it somehow implements part of that spec, the decoders don't
actually use libpostproc. I don't know anyone except you and maybe some
MPlayer+FFmpeg devs who consider libpostproc an important component.

And in general, it's a good idea to move optional libraries out of
ffmpeg.git. (In fact, ffmpeg.git should be split into several git
repos, one for each lib.)

 
 Iam not saying iam against it, just that it seems very strange to me
 
 If people want we could revive libpostproc.git, it just seemed easier
 to me if people use libpostproc from FFmpeg
 
 [...]

Feel free to create your own separate libpostproc git repo based on
ffmpeg.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Michael Niedermayer]

On Thu, Sep 04, 2014 at 05:23:12PM +0200, wm4 wrote:
 On Thu, 4 Sep 2014 16:30:14 +0200
 Michael Niedermayer michae...@gmx.at wrote:
 
  On Thu, Sep 04, 2014 at 03:53:55PM +0200, wm4 wrote:
   On Wed, 3 Sep 2014 23:33:48 -0400
   Reinhard Tartler siret...@gmail.com wrote:
[...]
  
  Iam not saying iam against it, just that it seems very strange to me
  
  If people want we could revive libpostproc.git, it just seemed easier
  to me if people use libpostproc from FFmpeg
  
  [...]
 
 Feel free to create your own separate libpostproc git repo based on
 ffmpeg.

If people are happy with libpostproc.git as it is, i surely can try to
remember to cherry pick changes into it, but i dont know how to
test it beyond build testing, also i dont volunteer to work on commits
which dont apply cleanly or dont work when applied

ATM, theres some version.h related commit that doesnt apply, that
would need to be ported

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reinhard Tartler]

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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reinhard Tartler]

On Thu, Sep 4, 2014 at 11:23 AM, wm4 nfx...@googlemail.com wrote:

 And in general, it's a good idea to move optional libraries out of
 ffmpeg.git. (In fact, ffmpeg.git should be split into several git
 repos, one for each lib.)

That idea seems very interesting to me. If coordinated and implemented
well, it could pave a way out of the mess caused by the split.

-- 
regards,
Reinhard
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Michael Niedermayer]

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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reinhard Tartler]

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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Michael Niedermayer]

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

also tried to apply locally to test on x86_64 but it doesnt apply:
ffmpeg/.git/rebase-apply/patch:7: trailing whitespace.
x32
ffmpeg/.git/rebase-apply/patch:16: trailing whitespace.
test $subarch = x86_32  check_cpp_condition sys/types.h \
ffmpeg/.git/rebase-apply/patch:17: trailing whitespace.
'defined(__x86_64__)  defined(__ILP32__)'  subarch=x32
ffmpeg/.git/rebase-apply/patch:18: trailing whitespace.
if test $subarch = x86_64 || test $subarch = x32; then
ffmpeg/.git/rebase-apply/patch:29: trailing whitespace.
#if (ARCH_X32 || ARCH_X86_64)  defined(PIC)

fatal: sha1 information is lacking or useless (configure).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 patch for x32 for libpostproc
When you have resolved this problem run git am --resolved.
If you would prefer to skip this patch, instead run git am --skip.
To restore the original branch and stop patching run git am --abort.


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reimar Döffinger]

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.
 
 As requested, the patch I used is attached. It’s not optimal
 as the arch could use the wider registers, but probably good
 enough, should it do what it’s supposed to ;-)

Wouldn't it make more sense to define ARCH_X86_64, at least in addition?
For the CPU after that is exactly what is being executed.
Fixing up the (hopefully few) places where we assume pointer size
should be easier than this approach?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reinhard Tartler]

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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reinhard Tartler]

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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reimar Döffinger]

On 04.09.2014, at 05:33, Reinhard Tartler siret...@gmail.com 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?
 
 Any chance to make you reconsider reviving the standalone libpostproc.git?

Seems a bit bit pointless when it has exactly 0 contributors.

 please use that for the debian package
 
 I fear that's not feasible at this point.

Brute-force sync with cp then? Or better just merge, it seems to have been 
created with git filter-branch so that might just work, but I don't know how 
much effort that would be.
But with no contributors it doesn't seem particularly viable as a stand-alone 
project.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] patch for x32 for libpostproc

[Thorsten Glaser]

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.

As requested, the patch I used is attached. It’s not optimal
as the arch could use the wider registers, but probably good
enough, should it do what it’s supposed to ;-)

bye,
//mirabilos

① https://wiki.debian.org/X32Port
-- 
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”# DP: Port to x32
# DP: There is no GCC documentation about the asm præficēs except
# DP: in http://stackoverflow.com/a/17825185/2171120 – go figure…

--- a/configure
+++ b/configure
@@ -811,6 +811,7 @@ ARCH_LIST='
 sparc
 sparc64
 tomi
+x32
 x86
 x86_32
 x86_64
@@ -2190,7 +2191,9 @@ case $arch in
 check_cc EOF  subarch=x86_64
 int test[(int)sizeof(char*) - 7];
 EOF
-if test $subarch = x86_64; then
+test $subarch = x86_32  check_cpp_condition sys/types.h \
+'defined(__x86_64__)  defined(__ILP32__)'  subarch=x32
+if test $subarch = x86_64 || test $subarch = x32; then
 spic=$shared
 fi
 ;;
--- a/libpostproc/postprocess_template.c
+++ b/libpostproc/postprocess_template.c
@@ -29,7 +29,7 @@
 
 #define MANGLE(a) EXTERN_PREFIX LOCAL_MANGLE(a)
 
-#if ARCH_X86_64  defined(PIC)
+#if (ARCH_X32 || ARCH_X86_64)  defined(PIC)
 #define LOCAL_MANGLE(a) #a (%%rip)
 #else
 #define LOCAL_MANGLE(a) #a
@@ -1142,10 +1142,10 @@ FIND_MIN_MAX((%0, %1, 8))
 #endif
 movq %%mm6, %%mm0  \n\t // max
 psubb %%mm7, %%mm6 \n\t // max - min
-push %4  \n\t
+pushq %q4  \n\t
 movd %%mm6, %k4\n\t
 cmpb MANGLE(deringThreshold), %b4\n\t
-pop %4   \n\t
+popq %q4   \n\t
  jb 1f \n\t
 PAVGB(%%mm0, %%mm7)   // a=(max + min)/2
 punpcklbw %%mm7, %%mm7 \n\t
--- a/libpostproc/x86/asm.h
+++ b/libpostproc/x86/asm.h
@@ -64,14 +64,34 @@ typedef int32_t x86_reg;
 #define REGcecx
 #define REGdedx
 #define REGSP   esp
+#elif ARCH_X32
+
+#define OPSIZE l
+#define REG_a eax
+#define REG_b ebx
+#define REG_c ecx
+#define REG_d edx
+#define REG_D edi
+#define REG_S esi
+#define PTR_SIZE 4
+typedef int32_t x86_reg;
+
+/* do not define REG_SP so code using it fails */
+#define REG_BP ebp
+#define REGBP   ebp
+#define REGaeax
+#define REGbebx
+#define REGcecx
+#define REGdedx
+/* do not define REGSP so code using it fails */
 #else
 typedef int x86_reg;
 #endif
 
-#define HAVE_7REGS (ARCH_X86_64 || (HAVE_EBX_AVAILABLE  HAVE_EBP_AVAILABLE))
-#define HAVE_6REGS (ARCH_X86_64 || (HAVE_EBX_AVAILABLE || HAVE_EBP_AVAILABLE))
+#define HAVE_7REGS (ARCH_X32 || ARCH_X86_64 || (HAVE_EBX_AVAILABLE  
HAVE_EBP_AVAILABLE))
+#define HAVE_6REGS (ARCH_X32 || ARCH_X86_64 || (HAVE_EBX_AVAILABLE || 
HAVE_EBP_AVAILABLE))
 
-#if ARCH_X86_64  defined(PIC)
+#if (ARCH_X32 || ARCH_X86_64)  defined(PIC)
 #define BROKEN_RELOCATIONS 1
 #endif
 
@@ -99,7 +119,7 @@ typedef int x86_reg;
 #define LABEL_MANGLE(a) EXTERN_PREFIX #a
 
 // Use rip-relative addressing if compiling PIC code on x86-64.
-#if ARCH_X86_64  defined(PIC)
+#if (ARCH_X32 || ARCH_X86_64)  defined(PIC)
 #define LOCAL_MANGLE(a) #a (%%rip)
 #else
 #define LOCAL_MANGLE(a) #a
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel