[FFmpeg-devel] [PATCH] libmpcodecs support

[Michael Niedermayer]

On Sat, Jan 15, 2011 at 10:26:25PM +0100, Luca Barbato wrote:
> 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.

tabs are long gone on mplayers side in all critical files and i could detab
them before git commit


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

phaseing out of reality to avoid my flames is cheating ;)

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/20110116/c9656406/attachment.pgp>