Kshitij Kulshreshtha <kkhere.geo+suse@...> writes: > > > Do they explicitly require static > > > linking with ffmpeg, instead of just using private header files? > > > > You cannot solve the problem you claim to have (I do not understand it) by > > including internal headers: They are internal because you must not include > > them to build a project that uses shared libavcodec. > > Fortunately it is not a problem or a bug. The aim of the patch was to simply > reduce build load on the pmbs. If packman packagers don't want to use it for > whatever reasons, that's their choice. > > If internal headers are internal, and you're so opposed to them being included > in external packages, why have you (you are a mplayer and ffmpeg developer) > still included them in these filters?
The filters need FFmpeg internals for their purpose: At the time they were written, no FFmpeg filter layer existed, so they could only be written the way they are. > > > If you look into the patch in my last email, you will notice that all > > > files that were conditioned on defining FFMPEG_A are still built with > > > this patch using private header-files from the local copy of ffmpeg, but > > > ffmpeg itself is not compiled. > > > > So you suggest to provide users with a MPlayer version that is guaranteed to > > break if they decide to update their libavcodec library? I don't think that > > would be a good idea. > > If a user uses packman's MPlayer it is almost certain that they're also using > packmans ffmpeg (libavcodec etc). (Disclaimer: I don't know much about shared libraries.) I believe the general idea is that you compile an application against a shared library, and if you update the library later, you do not have to recompile the application. If you build MPlayer with the filters (not) mentioned above, and you update libavcodec later, you have no guarantee that MPlayer still works because some of the used functions are not part of the public API. (I know that one of the negative effects of the traitor's fork is that some API breaks from the fork are pulled into FFmpeg, and my argument is therefore partly void, but I currently see no easy solution for this problem. Please report all regressions you see.) Note that there is a (very small) performance penalty for using shared libavcodec, and I believe MPlayer is one of the few applications where you want to avoid it. Carl Eugen _______________________________________________ Packman mailing list [email protected] http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
