[FFmpeg-devel] [PATCH] Allow linking to an external libpostproc

[James Almer]

On 10/28/2024 3:28 PM, Michael Niedermayer wrote:
> Hi everyone
> 
> On Mon, Oct 28, 2024 at 01:24:48AM +0100, Michael Niedermayer wrote:
>> Sponsored-by: Sovereign Tech Fund
>> Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
>> ---
>>   Makefile             |  3 +--
>>   configure            | 18 ++++++++----------
>>   fftools/ffprobe.c    |  1 -
>>   fftools/opt_common.c |  1 -
>>   4 files changed, 9 insertions(+), 14 deletions(-)
> 
> the other side of this is here:
> 
> https://github.com/michaelni/libpostproc
> 
> it should build and install and link
> but expect bits from ffmpeg remaining in it (most not intentional, some maybe are)
> 
> It contains libavutil because after decades of API rewrites, we still
> are not capable to write working and usable APIs.
> This is not a issue of libpostproc its an issue of libavutil API
> which is not treated like a library with a public API, but like a
> random subdirectory that randomly gets used by other bits of code.
> 
> Ranting a little more, i do have to mention that libavutil and
> libavcore or what it was called, did split a general library and the
> multimedia parts apart. That was still a better design than now.
> where i need to leave a copy of libavutil in the split out libpostproc
> and no the system installed libavutil doesnt even build
> as it tries to include headers that are not even installed with
> HAVE_AV_CONFIG_H
> 
> ok one last rant bit,
> a library has a public API
> and NOTHING outside the library should use anything else
> there should not be headers or features enabled in ffmpegs tree
> that can be used by other libs. That is wrong.
> If its usefull to us it is usefull to others, it should be a
> proper public API or it should not be there at all
> 
> rant end
> 
> Ahh and forks and pull requests of libpostproc are very welcome!
> 
> and if you want to improve libpostproc, up to the point of making
> it a full replacement of a full filter framework, thats IS welcome
> 
> thx
> 
> [...]

I didn't look too in depth, but a quick grep in git head gives me

 > ~/FFmpeg/libpostproc
> $ git grep avutil
> Makefile:FFLIBS = avutil
> postprocess.c:#include "libavutil/common.h"
> postprocess.c:#include "libavutil/cpu.h"
> postprocess.c:#include "libavutil/intreadwrite.h"
> postprocess.c:#include "libavutil/mem.h"
> postprocess.c:#include "libavutil/avstring.h"
> postprocess.c:#include "libavutil/ppc/util_altivec.h"
> postprocess_altivec_template.c:#include "libavutil/avutil.h"
> postprocess_altivec_template.c:#include "libavutil/mem_internal.h"
> postprocess_internal.h:#include "libavutil/avutil.h"
> postprocess_internal.h:#include "libavutil/intmath.h"
> postprocess_internal.h:#include "libavutil/log.h"
> postprocess_internal.h:#include "libavutil/mem_internal.h"
> postprocess_template.c:#include "libavutil/mem_internal.h"
> postprocess_template.c:#include "libavutil/x86/asm.h"
> postprocres.rc:#include "libavutil/ffversion.h"
> version.c:#include "libavutil/ffversion.h"
> version.h:#include "libavutil/version.h"

Of those, mem_internal.h, intmath.h, x86/asm.h, ppc/util_altivec.h and 
ffversion.h are not installed.

mem_internal.h is all defines, which can be trivially copied to an 
internally header in postproc.
intmath.h seems to have a lot of inline functions, so it's a matter of 
also copying the header and removing the arch includes (or copying them 
too).
x86/asm.h and ppc/util_altivec.h are defines and inline functions, so 
also possible to copy.
ffversion.h is used postproc_ffversion, which should IMO be removed from 
the standalone library.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20241028/7e7385fb/attachment.sig>