[FFmpeg-devel] [PATCH] libmpcodecs support

[Luca Barbato]

On 1/14/11 3:19 PM, Michael Niedermayer wrote:
> Of course if someone wants to optimize that code anyway or change its style
> its a matter that belongs to mplayer-dev ...

I have uses for swscale so I'll do something.

>> The swscale experience is fresh again for me and I'd rather not.
>>
>>> I will commit this soon but wont enable it yet. That way others can help
>>> cleanup the wraper (minus code that for maintainability should stay identical
>>> to the original), fix bugs, rename all global functions so they wont conflict
>>> with mplayers if they ever include this and generally help.
>>
>>> Please dont bikeshed this to death.
>>
>> Mind keeping that in a branch so people interested may get it and people
>> scared can live w/out? I'm not sure if that code is less scary than
>> swscale BUT your following comment says much.
>
> its much more scary ;)
> There are 10 times more people who vanished without a trace there than in the
> bermuda triangle

Ouch...

> and even more scary is gnu libc there noone ever came out alive and still sane.
> Should we drop useage of libc as a result and place all calls to libc in a
> branch until libc source has been cleaned up?

libc has a clean interface to add optimized/specialized versions and 
overall there isn't much to be scared if you stay away from the public 
headers machineries =P

> If you want to do cleanup, you can do it in mplayer svn if the mplayer devels
> agree

I'll check soon, swscale first ^^

> i can just merge the changes in, but IMHO if it takes you more than a few days
> to run indent or sed over the code and get it approved then waiting longer has
> zero sense. Because indent takes seconds, and getting it approved either will
> happen or will not happen. And its twice as much code than there is in swcale so
> doing anything by hand is (from experience of swscale) something taking years
> and i think we all agree that blocking 80% of functionality of libavfilter
> for years is not worth the style changes to code that is semantically not even
> part of ffmpeg.

I'd rather have clean and maintainable code in ffmpeg. I could accept 
this kind of devils deal only if it gets first a full regression test so 
trying to clean it up later would be half of the work.

lu