[FFmpeg-devel] [RFC] Split libavformat

[Luca Abeni]

Hi Ronald,

Ronald S. Bultje wrote:
>> Anyway, for the moment the only ffmpeg code that should be moved to
>> libossupport
>> is libavformat/os_support.* (and maybe some part of network.h?), right?
> 
> 
> I think the question is: do we need/want libossupport?

I think yes, unless we want to cause big regressions for some OSs...

> 
> Let's look at os_support.c; once we move to ipv4-indep. code, we can get rid
> of inet_aton() in favour of inet_pton() or getnameinfo(),

Ok. What about systems that do not provide getnameinfo() (and/or getaddrinfo())?
I think libossupport goal is to remove ugly replacements for missing functions
from libav* while not dropping support for OSs that need them (it seems OS/2
is one of them, for example).

For example, when I agreed that directly using getaddrinfo in networking code
is the right way to go, it was explicitly said that emulating such function
for systems missing it should be easy. And I think such emulation should go
in libossupport. Of course, if existing libraries already provide the needed
functionalities, then there is no need for libossupport.


> resolve_host[_ipv6]() isn't an os_support function and would move to
> network.c (new). Imo, ff_socket_nonblock() could move as static inline to
> network.h (even though the implementation is different in the win-case, I
> don't think it justifies itself being in a "OS support" library, because
> it's not a missing function in that OS; it is just implemented differently,
> kind of like BE vs. LE).

I have no preferences about it... Let's hear Michael's opinion. I think that
he did not like the
"define lseek(f,p,w) _lseeki64((f), (p), (w))" line remaining in
libavformat/os_support.h after my last libavnet proposal, so I am not sure
if ff_socket_nonblock() in libavformat is ok.

BTW, where should the lseek define needed by windows go?


> So that only leaves poll(), which is used in dv1394 (which should use
> select(), not poll())
Why?

Anyway, dv1394 is a linux thing, so poll() is not a problem.


> and in ffserver. Interestingly, poll() is right now
> under CONFIG_FFSERVER, maybe that has to be fixed

I think that is ok... ffserver is the only poll() user that is supposed to
work on systems that do not provide poll().


> but you really want an OS support lib for this one function?

I do not know. Currently, libav* do not contain much code that should go in
libossuport, but we can add more in the future, to support more systems.



			Luca