[FFmpeg-devel] [PATCH] Make ff_url_split() and ff_url_join() public.

[Michael Niedermayer]

On Sun, May 23, 2010 at 05:28:03PM +0300, Martin Storsj? wrote:
> On Sun, 23 May 2010, Ronald S. Bultje wrote:
> 
> > On May 23, 2010, at 6:15 AM, Martin Storsj? <martin at martin.st> wrote:
> > >
> > > For what it's worth, a dynamically linked build of ffserver references
> > > these non-public functions from lavf:
> > >
> > >    ff_inet_aton
> > 
> > This one will never be made public, ffserver should use generic ipv6  
> > functions.
> 
> Yeah. But even in that case, we have a bit of a dilemma. If on a system 
> where no getaddrinfo is available, should the fallbacks from lavf be 
> exported so that ffserver can use them?
> 
> Or should they all be moved out (including ff_network_init) to a separate 
> libbrokenos, where all of them can be exported, as suggested every now and 
> then?

people prefer to spend many days of bikesheding and flaming and pushing hacks
to other peoples code over creating libbrokenos and putting all the mess
there.


> 
> > >    ff_socket_nonblock
> > 
> > This is one of those where win32 is posix-incompatible right? Ramiro  
> > should tell us if it is sufficient and then it can be made public  
> > maybe, or something...?
> > 
> > >    ff_url_split
> > 
> > So if people like the current ff_url_join/split API, we should  
> > probably make it public. I personally don't object, in fact I think  
> > the API is quite nice.
> > 
> > >    ff_rtsp_parse_line
> > >    rtp_get_local_rtcp_port
> > >    rtp_get_local_rtp_port
> > 
> > These we might have to think about a little, exporting these functions  
> > literally is likely a bad idea.
> 
> Except for these, it also uses 
> ffm_read_write_index/ffm_write_write_index/ffm_set_write_index, but these 
> actually are in avformat.h, since SVN rev 5. Using (de)muxer internal code 
> like this without using the proper external interfaces isn't all that 
> nice, but I'm not familiar enough with it to say how hard it would be to 
> clean it up. And e.g. the RTSP header parsing code would have to be 
> duplicated if we don't want to expose such things through public APIs.

shouldnt be hard to replace ffm by nut :)
patch welcome :)

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

Thouse who are best at talking, realize last or never when they are wrong.
-------------- 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/20100523/27b8c6d7/attachment.pgp>