[FFmpeg-devel] [PATCH] Merge libavcore into libavutil
Wed Feb 16 03:23:16 CET 2011
On 2/16/11 2:19 AM, Alexander Strasser wrote:
> 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
> 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
More information about the ffmpeg-devel