[FFmpeg-devel] [PATCH] libmpcodecs support
Michael Niedermayer
michaelni
Fri Jan 14 19:49:56 CET 2011
On Fri, Jan 14, 2011 at 01:11:10PM -0500, compn wrote:
> On Fri, 14 Jan 2011 17:20:23 +0100, Michael Niedermayer wrote:
> >On Fri, Jan 14, 2011 at 03:55:31PM +0100, Janne Grunau wrote:
> >> On Fri, Jan 14, 2011 at 01:58:15PM +0100, Michael Niedermayer wrote:
> >> > 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:
> >> > > 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.
> >>
> >> I'm very much convinced that copying source files and maintaining them in
> >> more than one place is a sure path to insanity. And I'm coming from a project
> >> which makes unfortunately heavy use of that technique. It's just not going to
> >> work, is much more effort than expected and I would expect that the copy will
> >> stay there for ever.
> >
> >So in the very worst case predictions its still the best we can do to move
> >forward.
>
> we could always move libmpcodecs into a seperate repo like swscale.
There are differences between mplayers libmpcodecs and libavfilters libmpcodecs
libswscale was a seperate and selfcontained lib, libmpcodecs as used by mplayer
has far reaching dependancies into half of all of mplayer. The code does NOT
compile without changes outside mplayer.
I have no interrest at all in spending weeks working on turning libmpcodecs
into a seperate lib. And then redoing the whole integration
libmpcodecs is outdated technology Its insane to waste time on improving it
And id like to ask others to also spend their time on usefull things, port
filters to become native libavfilter filters, there are performance advantages
under some circumstances to the closer integration. And replacing mplayers
libmpcodecs with a libavfilter that has all the libmpcodecs filters natively
would also be a huge step forward for mplayer, the arbitrary filter graphs
are just one nice feature ...
If people have so much energy as to make libmpcodecs become an independant lib
its much better spend porting a dozen filters from libmpcodecs to libavfilter.
OTOH if you suggest to just drop the libavfilter/libmpcodecs as is in a
seperate repo then i dont see the point, it just makes things harder to work
with while the code could not be used by anything but libavfilter
anyway if there are constructive suggestions left i very much would like to
hear them if not id like to apply this, and if people want with tabs removed
and reindented but later requires this to be approved by reimar and also
reindented in mplayer svn
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
There will always be a question for which you do not know the correct awnser.
-------------- 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/d4b955e9/attachment.pgp>
More information about the ffmpeg-devel
mailing list