[FFmpeg-devel] [RFC] Split libavformat

[Michael Niedermayer]

On Mon, Nov 26, 2007 at 05:26:36PM +0100, Luca Abeni wrote:
> Hi Michael,
> 
> Michael Niedermayer wrote:
> [...]
> >> Anyway, I am more than willing to change things so that mplayer (or other
> >> applications) can use more easily our networking and grabbing code. If my
> >> original idea was wrong, just let me know what must be changed and I'll try
> >> to work on it...
> > 
> > iam not sure what is best ...
> > comments and ideas are welcome ...
> 
> At this point, I obviously have not good ideas about this issue...
> I'll just wait to see what other people think.

i have a bad feeling about this, because i as well planed to wait for
comments from others ...

the whole started due to people dislikeing grabing code in lavf, but the
grabing code are demuxers and it doesnt look like that can be changed easily
and demuxers do belong in lavf
its split out now and i guess nothing terrible will happen if we leave it like
that, i just dont think it achieved much beyond making people feel better


> 
> 
> > but i think that at least the os support code / the code providing missing
> > standard functions should be split into its own lib instead of being spread
> > over 3 libs into which it doesnt belong ...
> > that of course is somewhat orthogonal to the net/device/protocol question
> 
> Ok. At least, this change should be reasonably uncontroversial... I'll start
> having a look at the OS-dependent code. After a first look, I think that:
> 1) There is nothing OS-dependent in libavutil (or do you think the memalign hack
>     should go in the OS support library? In this case, can I just use the
>     CONFIG_MEMALIGN_HACK code to implement memalign()?)

no i think the memalign should stay in lavu


> 2) The only OS-dependent code in libavcodec is the threading code, but I do
>     not see any easy way to move it in a separate library. Ideas?
> 3) The remaining part of the work is to move os_support* from libavformat to
>     the new library (and I think network.h contains some OS-dependent code too).
> 
> I still need to have a better look at all the libav* code, but these are my
> first impressions. Anything obvious I am missing?

*rintf() is missing on some platforms, we dont do anything about it but it
would fit nicely in a libossupport
of course if there are existing libs which provide such missing functions
like ronald suggested then using them (if we can) would be even better then
reinventing the wheel ...


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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071126/6af321f7/attachment.pgp>