[FFmpeg-devel] [PATCH] Merge libavcore into libavutil

[Luca Barbato]

On 2/16/11 2:19 AM, Alexander Strasser wrote:
> Hi
>
> Luca Barbato wrote:
>> On 02/14/2011 01:15 AM, Alexander Strasser wrote:
>>>    The first library mentioned is lavc and the split library is lavu.
>>> So as you can conclude for yourself there is at least one application
>>> that depends only on lavu but not necessarily on lavc. Finding out the
>>> name of that application is left as an exercise to the reader.
>>
>> The readers couldn't find it so far... That's one of the requests that
>> cropped up and had been deserted...
>
>    That application is MPlayer.

that's stretching it... So what avcore provided would hamper mplayer now?

>> Beside that, could you tell me which are the content of libavutils that
>> are useful for your application? My ideal usage for libavutils would be
>> as replacement of glib or eina, Reimar's is as replacement of libcrypto.
>
>    Sorry I am not 100% sure I understood your question correctly. I will
> from here on assume with "useful for your application?" you meant thoughts
> on usage of libavutil and not application in the sense of a program suite
> (executable code) that I am the author of.

I mean. libavutil has functions that you can group in sets, which set is 
useful and which one you aren't using or you deem out question for it.

>    So to answer your question I will first take my turn describing lavu:
> (NOTE: I will not be to formally nor fully complete here to get the
>         idea across and to be faster in getting this mail out.)
>
>    I think of lavu as an addition to the ISO standard C library.
> It provides additional routines in following main categories:
>    * crypto
>    * mathematics
>    * data structures/algorithms
>    * auxiliary routines of all sorts
>      (I should probably mention some subcategories here, but I am
>       afraid I am to tired for that)

What's particularly off in those 100k of tables and accessors avcore 
provided?

>    Now to answer the usage question: lavu can potentially be used in
> every application the same way you usually use parts of the C standard
> library in most applications.

the bits you have in libavcore aren't preventing that.

>    What I have written above also applies here. If someone wants to argue
> for some of the lavco stuff to be included in lavu she should pick one
> of those things and make a new thread where it can be discussed separately.
> If it is approved to be useful to have in lavu, the re-design (if needed)
> and other steps necessary for inclusion can be worked out there.

We are talking about mostly dumb tables, it's the equivalent of metric 
conversion tables for locales...

>    The mentality of just merging lavco into lavu because we want to get
> rid of lavco is not fair in respect to lavu. Also there might very well
> be other ways to get rid of lavco if it is really such a big problem.
> Of course that would require careful thinking and rethinking through
> the problem and its possible solutions. But unfortunately pressuring a
> merge of lavco into lavu is working into the opposite direction :(

Could you point me an item for each, what you dislike of the function 
that got merged? And possibly why this long rationale happened now and 
not before?

lu