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

Ronald S. Bultje rsbultje
Sun May 23 15:07:33 CEST 2010


Hi,

On May 23, 2010, at 6:15 AM, Martin Storsj? <martin at martin.st> wrote:
> On Sat, 22 May 2010, Stefano Sabatini wrote:
>> On date Saturday 2010-05-22 21:57:21 +0200, Stefano Sabatini encoded:
>>> ---
>>> libavformat/avformat.h  |   45 ++++++++++++++++++++++++++++++++++++ 
>>> ++++++++
>>> libavformat/internal.h  |   42 ++ 
>>> +-------------------------------------
>>> libavformat/rtmpproto.c |    4 +-
>>> libavformat/utils.c     |   48 ++++++++++++++++++++++++++++++++++++ 
>>> +++++-----
>>> 4 files changed, 93 insertions(+), 46 deletions(-)
>>
>> In particular this fixes the infamous ffserver warning.
>
> That could actually be fixed by simply including libavformat/ 
> internal.h,
> too - but that's adding more depenency on lavf-internal stuff, when  
> it in
> this case very well could be public instead, as you're proposing.
>
> 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.

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

>> And maybe the names:
>> av_split_url()
>> av_join_url()
>>
>> would be even better.
>
> Hmm, I'm not sure, somehow I like the current "hierarchical" naming  
> with
> having ff_url_* as a prefix.
>
> Ronald, what do you think about the naming?

av_url_*() is better, but if more people like it the other way around  
then that is also OK.

Ronald



More information about the ffmpeg-devel mailing list