[FFmpeg-devel] [PATCH] libmpcodecs support

[Stefano Sabatini]

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?

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.

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

* cons: people will consider to use (and eventually fix) the
  libmpcodecs filters rather than port them into libavfilter (which
  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.
-- 
FFmpeg = Fierce and Fiendish Miracolous Pitiless Ecstatic Gem