[FFmpeg-devel] [PATCH] libmpcodecs support

[Michael Niedermayer]

On Sat, Jan 15, 2011 at 03:17:24AM +0100, Luca Barbato wrote:
> 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.

We should work on libavfilter NOT libmpcodecs. Filters should be ported
to libavfilters not cleaned up in libmpcodecs thats time wasted on a "going
to be removed" system.
thats then even adding more burden on me to merge idiotic cleanup back and
forth between libavfilter/libmpcodecs and mplayer


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 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.

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- 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/d1a5bc48/attachment.pgp>