[FFmpeg-devel] [PATCH] libmpcodecs support

[Michael Niedermayer]

On Fri, Jan 14, 2011 at 12:32:01PM +0100, Stefano Sabatini wrote:
> On date Friday 2011-01-14 08:04:01 +0100, Luca Barbato encoded:
> > On 1/14/11 5:37 AM, Michael Niedermayer wrote:
> > >Hi
> > >
> > >Attached patchset makes libavfilter support most libmpcodecs filters
> > >The libmpcodecs filters are practically unmodified and for keeping it
> > >maintainable id like to keep them unmodified.
> > 
> > In order to keep things sane, please DO NOT.
> > The swscale experience is fresh again for me and I'd rather not.
> > 
> > >I will commit this soon but wont enable it yet. That way others can help
> > >cleanup the wraper (minus code that for maintainability should stay identical
> > >to the original), fix bugs, rename all global functions so they wont conflict
> > >with mplayers if they ever include this and generally help.
> > 
> > >Please dont bikeshed this to death.
> > 
> > Mind keeping that in a branch so people interested may get it and
> > people scared can live w/out? I'm not sure if that code is less
> > scary than swscale BUT your following comment says much.
> > 
> > >Ahh before i can commit this, libmpcodecs and subdirectories must not get
> > >blocked by the tab&  trailing whitespace checkin scripts.
> > 
> > Are you joking? If you are _really_ serious I'd suggest (or even I'd
> > do myself) to clean it up at least to be properly indented in
> > mplayer.
> > 
> > So in short, to cut all the bikeshed and in the as calm as possible tone:
> > 
> > since directly importing code from mplayer collides with:
> > - coding style
> > - basic respect for structured code
> > - people that might be interested in contribute optimizations
> > 
> > I'd rather have it polished before, either in mplayer or here, if
> > you are itching to commit it, make a branch and advertise it so
> > before it hits the master those 3 points might be addressed already.
> 
> Before to pronounce I would like to know which is the long term plan.
> Do we want to keep an unsynched branch of MPlayer in FFmpeg?, will
> MPlayer get rid of libmpcodecs filters and use libavfilter instead?,
> or we'll have to keep this code and burden duplication forever?

We will try to keep the libmpcodecs code as similar to mplayers as possible
and update our copy whenever there are significant changes in mplayers
libmpcodecs. This makes cleanup inside our libmpcodecs impossible, it would
conflict with future merges.

If you, luca or someone else want to do cleanup in libmpcodecs thats possible
inside MPlayers libmpcodecs and discussion about that should go to mplayer-dev


The long term plan is definitly to have all libmpcodecs filters changed to
native libavfilter filters but that depends alot on volunteers, and i dont
consider it high priority for myself to do such work

Either way, every filter that becomes fully portet can be droped from our
libmpcodecs copy.


> 
> I suppose the plan of the MPlayer crew was to start to support
> libavfilter through libmpcodecs, and eventually switch completely to
> libavfilter.
> 
> Some considerations:
> 
> * pros: having libmpcodecs in libavfilter through a wrapper will
>   greatly help to test and port them as "native" filters
> 
> * pros: having libmpcodecs in libavfilter *right now* would be a big
>   enhancement, and may help the adoption of FFmpeg+libavfilter.
> 

> * cons: the burden of code duplication, code will have to be
>   maintained both in MPlayer and in ffmpeg/libavfilter/libmpcodecs.

Ill do that maintaince


> 
> * cons: libmpcodecs code is generally unformatted, neither
>   particularly readable and maintainable nor well documented, having
>   that into FFmpeg is a little scary for me.

its unfortunatly unavoidable unless libmpcodecs becomes compileable into a
lib from mplayers svn and headers needed to interface become installed similarly


> 
> * cons: people will consider to use (and eventually fix) the
>   libmpcodecs filters rather than port them into libavfilter (which

I wont accept any changes in our libmpcodecs copy relative to mplayers original
unless they are needed for our wraper to work. Such changes belong in mplayer
svn


>   usually results in much cleaner and readable and maintainable code),
>   thus hindering the long term plan. This consideration is just
>   hypotetical, as the external contributions to libavfilter (apart
>   GSOC and GCI) have been practically neglectable.
> 
> As I already said, I'm not motivated to maintain libmpcodecs code and
> I *won't*, and I'm rather for a clean altough possibly slow port. If
> the long term plan is to get rid of the libmpcodecs filters (both from
> MPlayer and libavfilter) in favor of libavfilter, then I'm not against
> this patchset.

Its of course the long term plan to get rid of it

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

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110114/49beae9c/attachment.pgp>