[FFmpeg-devel] [PATCH] libmpcodecs support

[Michael Niedermayer]

On Fri, Jan 14, 2011 at 08:04:01AM +0100, Luca Barbato wrote:
> On 1/14/11 5:37 AM, Michael Niedermayer wrote:
>> Hi
>>
>> Attached patchset makes libavfilter support most libmpcodecs filters
>> The libmpcodecs filters are practically unmodified and for keeping it
>> maintainable id like to keep them unmodified.
>
> In order to keep things sane, please DO NOT.

I cannot maintain the code if changed cosmetically relative to mplayers so
its technically not possible. (noone else would maintain it either then so its
also not just me ...)

Also noone of the ffmpeg team is supposed to add optimizations in there nor
debug it nor anything so its also not needed to fit our style.
its part of mplayer ...

Of course if someone wants to optimize that code anyway or change its style
its a matter that belongs to mplayer-dev ...



> 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

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?



>
>> Ahh before i can commit this, libmpcodecs and subdirectories must not get
>> blocked by the tab&  trailing whitespace checkin scripts.
>
> Are you joking? If you are _really_ serious I'd suggest (or even I'd do  
> myself) to clean it up at least to be properly indented in mplayer.
>
> So in short, to cut all the bikeshed and in the as calm as possible tone:
>
> since directly importing code from mplayer collides with:
> - coding style
> - basic respect for structured code
> - people that might be interested in contribute optimizations
>
> I'd rather have it polished before, either in mplayer or here, if you  
> are itching to commit it, make a branch and advertise it so before it  
> hits the master those 3 points might be addressed already.

If you want to do cleanup, you can do it in mplayer svn if the mplayer devels
agree
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.


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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- 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/20110114/bce49d36/attachment.pgp>