[FFmpeg-devel] [RFC] Split libavformat

Luca Abeni lucabe72
Tue Dec 11 10:09:56 CET 2007

Hi all,

M?ns Rullg?rd wrote:
>>> whats left are OSs which just wont be fixed ...
>>> for these and until the others are fixed, libossupport can provide missing
>>> stuff, its not a duplication per app but rather factorizing this duplication
>>> out into a seperate lib which could be used by (m)any applications
>> I'd actually go one step further and make libossupport completely
>> independent of FFmpeg
> I second that.

Ok, so I guess my last patch was wrong (it just moved os-dependent code in
libossupport, making libavformat depend on it).

So what should be done? I understand that everyone is against having things
like the poll() emulation, the inet_aton() emulation, the lrintf() emulation
(I am just citing the existing code) in libav*, and that code can be easily
removed (but I am not interested in maintaining a library external to ffmpeg...
So, if that code is removed users who need it will need to find or maintain
an external library providing the missing functionalities).
But what do we want to do, for example, with ff_socket_(non)block()?
Just leave it in libavformat? Move it somewhere else? Convert it to use
fcntl(), and provide an fcntl() replacement for OSs that do not support it?
(or assuming that fcntl() will be provided by an external library?).

Also, some systems need to include different headers for using the network...
So, we have some os-dependent #includes and $defines in network.h. Is it ok
to leave that os-dependent code in libavformat? If not, how do we want to
address this problem?


More information about the ffmpeg-devel mailing list