[FFmpeg-devel] [PATCH] libmpcodecs support
Fri Jan 14 12:32:01 CET 2011
On date Friday 2011-01-14 08:04:01 +0100, Luca Barbato encoded:
> On 1/14/11 5:37 AM, Michael Niedermayer wrote:
> >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
> 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
* 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
FFmpeg = Fierce and Fiendish Miracolous Pitiless Ecstatic Gem
More information about the ffmpeg-devel