[FFmpeg-devel] [PATCH] libmpcodecs support
Fri Jan 14 20:49:31 CET 2011
On Fri, Jan 14, 2011 at 01:53:59PM -0500, Ronald S. Bultje wrote:
> On Fri, Jan 14, 2011 at 1:49 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > 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
> So basically what you're saying is that we cannot possibly disagree with this?
You can disagree!
What is it that you disagre with?
Do you want libavfilter to not move forward, get 3 times as many filters?
Do you want libmpcodecs to be reindented?
Do you want libmpcodecs in an external repository?
Do you think a libavfilter without libmpcodecs support would be more successfull
used by more users, would cause more developers to join the effort?
Do you think a project that doesnt care what its users want should be forked?
Do you think we should care about what our users want?
Do you think our users would prefer to have all the libmpcodecs filters
Personally as maintainer of libavfilter, i want it to move forward, the FF in
ffmpeg also stands for "fast forward" not for filosophical bikeshed
If people dont clearly say what they want, its difficult for me to act in line
of what the people want.
I see several vocal people who express their dislike of this patchset but i
dont really see what they do want. The comments are negative "do not do" not
"please do instead because"
and a seperate branch, i dont mind a "full_featured" branch with libmpcodecs
ffmpeg-mt and dll loader. and leave trunk without these features.
But please when you calmly thought about it explain me what we would gain?
users want features they will, if they know about it use the most feature packed
branch. And this is the branch most developers will likely work on as well i
suspect but i might be wrong.
And we have no right to hide from our users which is the most feature packed
> I think this is similarly stupid as adding a DLL loader to lavcodec
> because that gives us access to codecs that will take years to RE, but
> have working DLLs using mplayer's DLL loader. How is that different?
I always wanted a DLL loader, its mere historic that we didnt get one many years
ago. (years ago noone would have objected i suspect)
now lets please try to work toward a solution.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel