[FFmpeg-devel] [PATCH] libmpcodecs support

[Luca Barbato]

On 1/15/11 6:57 PM, Michael Niedermayer wrote:
> 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.

My idea is the following, let's use swscale or proto2 as example.

I need certain features (neon yuv2rgb and rgb2yuv, network protocols 
with polling threads), those feature require some work that might be 
controversial and will require another pair of eyes while it should have 
no impact, forcing it on master isn't uncalled, putting it on a branch 
to make the interesting parties contribute on it while the rest would be 
involved once the branch is ready (e.g. the swscale x86 template code 
rewritten in yasm, no function duplication etc).

That's why I'd rather have to this mpcodecs import on a topic branch, 
having it worked on w/out adding code that would require whitelisting 
even on our normal style checks.

lu - still with spotty networking on a random non-home-place in a random 
non-home-region of Italy