[FFmpeg-devel] [RFC] New library for shared non-generic libav* utils

[Baptiste Coudurier]

On 07/09/2010 09:48 AM, M?ns Rullg?rd wrote:
> Michael Niedermayer<michaelni at gmx.at>  writes:
>
>> On Fri, Jul 09, 2010 at 04:41:59PM +0100, M?ns Rullg?rd wrote:
>>> Michael Niedermayer<michaelni at gmx.at>  writes:
>>>
>>>> On Fri, Jul 09, 2010 at 09:54:11AM -0400, Ronald S. Bultje wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, Jul 8, 2010 at 7:07 PM, Stefano Sabatini
>>>>> <stefano.sabatini-lala at poste.it>  wrote:
>>>>> [.. cut ..]
>>>>>> This new lib will contain all code/utils which need to be shared
>>>>>> between more libav* libs, and are not enough generic to deserve a
>>>>>> place in libavutil, which is to be considered a collection of
>>>>>> generic/non-multimedia-related utilities.
>>>>>
>>>>> Disregard me if majority says otherwise, I just wanted to
>>>>> bikesheddishly note that my personal humble opinion is that less libs
>>>>> is good, so I'd not have any problems with media-related stuff going
>>>>> into libavutil. I think the chance that people use a FFmpeg lib for
>>>>> something unrelated to multimedia is relatively small and should not
>>>>> be our main focus. Reminds me of not allowing media-specific stuff in
>>>>> libgstreamer.so. It only causes headaches and distractions. There is
>>>>> no practical advantage.
>>>>
>>>> as maintainer of libavutil i object.
>>>
>>> You are not the sole maintainer.
>>>
>>>> We can have a seperate lib for common code.
>>>
>>> If ever there were an exercise in work creation, this is it.
>>
>> for us yes, but libavutil is usefull to other projects, ive myself
>> used code from it for many things unrelated to ffmpeg. Its not used
>> much by outsiders but i think thats more because its not well known.
>>
>>>> Iam not stopping people from having their common lib which prior to
>>>> libavfilter was libavcodec. But now due to libavfilter not depending
>>>> on libavcodec this is no longer possible.
>>>>
>>>> But trying to kill my effort of a util lib
>>>
>>> Perhaps conducting that effort inside FFmpeg, the most
>>> multimedia-focused project the world has ever known, wasn't such a
>>> bright idea.
>>
>> it depends, we do need all the code in libavutil anyway, putting it in a
>> seperate lib that others can use too doesnt seem all that wrong.
>> and it is now available in most distros, thus it can actually be used
>
> If others can use it, that's good for them.  We should still think
> about whom we are doing this work for.  Is it for ourselves or for
> hypothetical external users we do not even know about?
>
>>>> I spended alot of time on libavutil and its only goal was to become
>>>> a general utils lib
>>>
>>> Said who?  It wasn't even your idea to begin with.  It was suggested
>>> and implemented by Alexander Strasser.
>>
>> svn blame of *.c *.h says:
>> ...
>>      102      ramiro
>>      108       takis
>>      110      benoit
>>      111      lucabe
>>      123     bellard
>>      126   michaelni
>>      157          al
>>      185    gpoirier
>>      285      kostya
>>      351       aurel
>>      918      reimar
>>     1295       diego
>>     1349         mru
>>     1616     stefano
>>     2398     michael
>
> I get some rather different numbers with git's more accurate blame
> (tracking lines across moves within or between files):
>
>     2635 michael
>     2043 mru
>     1664 diego
>     1464 stefano
>      949 reimar
>      354 aurel
>      279 kostya
>      252 lu_zero
>      147 michaelni
>      126 bellard
>      121 astrange
>      116 lucabe
>      105 benoit
>      101 takis
>      101 ramiro
>
>> so id say, yes iam still the primary maintainer and author, even if
>> we consider that blame is not the worlds most idiot proof way to
>> check this
>
> Yes, you wrote more lines than anyone else, but not by any large
> margin.  Of the total ~11k lines, you only contributed roughly 25%.
> If lines were votes, you'd be losing.  You seem to like votes...

Nah, this is heavily biased. A lot of lines are defines and macros in 
*.h, not talking about the recent controversial documentation commits.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org