[FFmpeg-devel] [PATCH] libmpcodecs support

[Michael Niedermayer]

On Sat, Jan 15, 2011 at 04:44:08PM +0100, Luca Barbato wrote:
> On 1/15/11 5:30 AM, Michael Niedermayer wrote:
>> About regression tests, the idea is not bad if someone wants to do it. But
>> Asking  to do that (unrelated) work as condition for this patch feels a bit
>> offensive IMHO. Ive not seen others make unrelated requests since a long time
>> and i have even asked for help many times and there are
>> important issues id like to work on like the malloc/free speed issue.
>
> I think we are probably misunderstanding your purpose for this wrapper.
>
> If The idea is to have it to ease the porting to libavfilter I think  
> makes sense keep it in a separate branch and not work on it if you think  
> we can't get that code clean enough to be merged as libavfilter.
>
> I, and probably others, considered that as a quick route to give  
> features to our users. And reacted on this idea. Having had experience  
> with swscale peculiarities I'm more than wary about such imports.
>
>> I prefered the past where comments where based on technical issues and not
>> philosophical ones. And where maintainers could work on their code without
>> everyone bikesheding every change.
>
> If you think that is useful have it on master and we can make clear that  
> this code will disappear it could stay for that time. But I will have it  
> removed within this year at most (an hard limit helps avoiding eternal  
> temporary solutions) and have it depend on flag experimental so it would  
> not crawl to our userbase that easily.
>
> I hope that helps clear why I'm this against this code import.

To elaborate on what my ideas behind this patch are.

Its for libavfilter to be successfull, to have a competetive feature set and
not be an academic toy without features, not used by anyone because it lacks
the most basic filters. I want to give these features to our users ...

But i dont want this code to stay like this in SVN for ever, i do have eyes
and i do too see its not pretty but for me the cosmetic aspect is very minor.
The much bigger aspect or me is that using these filters through the wraper
is technically annoying, the APIs are far from mapping 1:1 onto each other
porting filters to libavfilter is technically a good idea not only cosmetically
and i want it to happen. But i do want to make the features available to our
users during all the time and not keep 50 filters that are ready but ugly
away from our users for 2 years. That really would be very nasty from us to do
to our users

If you want the filters ported to native quickly, theres SOC, theres code in,
theres funding by the foundation, theres contributing patches yourself or
talking other people into helping.
But i dont think a big "we will remove it in a year" is going to achive anything
a fork is easier than porting the filters. And in FOSS its "you want it, you do
it" not "you dont want it, you can prevent others from doing it"
And once someone of us is fed up enough and just forks, the official tree of
libavfilter will perish, no users, no bugreports, noone will port anything in
it. I also would leave and contribute where i can work freely without these
philosophically loaded discussions.

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- 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/20110115/14def8de/attachment.pgp>