This is a feature request to enable the postproc filter to be compiled as a shared lib with the --enable-shared-pp option in mplayer, so that transcode can be compiled with this option. It's a very good deinterlacer that I use regularly, and not having it in the ebuild means i have to compile my own with the option or edit the ebuild every time there's a new ebuild for mplayer. Thanks
Mplayer builds a static version, which transcode make use of if found ... anything wrong with this ?
I did some testing without the --enable-shared-pp and when transcode is configured, it says it will not use mplayer's postproc filter. I am not home now, so I can't paste exactly what it says. I saw the line in the transcode ebuild about looking for libpostproc.a, but I don' think that works anymore. You may know more about it, but I think they changed the api for the postproc filter not too long ago. When I run transcode, it says it fails to find the filter_pp (I think that's what it's called) and it doesn't use it. Again, I can post the output of the transcode attempt when I get home tonight.
Havent looked at it in a while to be honest. Have a look, and let me know ... I will try and have a look in the next day or two.
I just did some checking into this as I suspected that it wasn't working correctly either and it seems that mplayer is not built with enable-shared-pp. This is really an mplayer ebuild bug. I tested it by adding enable-shared-pp to the mplayer ebuild and transcode then detected libpostproc.a correctly.
Ok, this is fixed in rc3, please test and let me know.
Seems like we have some issues with it .. bug #14479.
--enable-shared-pp make mplayer 0.90 rc4 seg fault at launch.
Actually postproc is part of ffmpeg. Mplayer just imports the ffmpeg sources into it's tree. If you want libpostproc you should actually look at the enabling it in ffmpeg. mplayer import almost all it's sources, and besides itself really shouldn't produce any dynamic libraries (or in this case it's probably the header that was the problem, since transcode uses ffmpeg, which in turn is statically linked with libpostproc, but does not provide the header). See also http://bugs.gentoo.org/show_bug.cgi?id=27051
Well, this is fixed with 0.91, but as you poinged out, it does make sense to rather have it in ffmpeg ...
I submitted the change to install libpostproc in ffmpeg in the 20040222 and greater snapshot ebuild. It appears to work for me with transcode version 0.6.11. Version 0,6.12 no longer has the --with-libpostproc-builddir option for configure. Regardless, I believe this bug is resolved. It's not clear to me from the problem description how to test this exactly, however transcode 0.6.11 is definitely finding the libpostproc library that ffmpeg installs. If this isn't an adequate solution to this request, please re-open with more information about how to validate that the feature is actually there or not.
