[FFmpeg-devel] [RFC] Split libavformat

[Michael Niedermayer]

On Tue, Nov 27, 2007 at 08:35:07AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Nov 27, 2007 2:59 AM, Luca Abeni <lucabe72 at email.it> 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?

the question is is there any platform which we want to support which lacks
any function we can emulate and which we need
looking at the current code seems to strongly point to yes
also looking at the mailinglists theres no lack of people who submitted
code to emulate various things for their platform these have been nearly
all rejected because we do not have libossupport

people have clearly failed to get rid of the existing os_support code
so IMO the people saying its unneeded should send patches removing it
not arguing why a clean and simple solution should not be implemented


> 
> 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(),

> resolve_host[_ipv6]() isn't an os_support function and would move to
> network.c (new). 

it seems you dont get it, lavf WILL NOT provide an externally vissible 
resolve_host() no matter what API or implementation, ffserver seems to need
it though


> 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).

no form of an externally vissible ff_socket_nonblock() does belong into lavf
tcp.c as well as ffserver.c need it
duplication is not ok, and a static in a header would be duplication as well


> 
> So that only leaves poll(), 

doesnt seem so


[...]


> 
> I agree lavf is not the right place for poll(), I agree that if it existed,
> libossupport would be the right place for it, but is libossupport the right
> thing to set up and maintain? Can someone tell me what OSes lack poll() so I

it will be maintained by whoever wants support for an OS which lacks a
specific function

of course as i already said if there is another lib providing all these
missing functions thats fine as well
until now though ive just seen one for poll()
we still need lrintf(), llrint(), ...

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- 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/20071127/37003cc3/attachment.pgp>