[FFmpeg-devel] [RFC] rtsp.c EOF support

Michael Niedermayer michaelni
Sat Feb 28 14:19:13 CET 2009


On Sat, Feb 28, 2009 at 12:56:29AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Feb 27, 2009 at 4:17 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Fri, Feb 27, 2009 at 02:56:46PM -0500, Ronald S. Bultje wrote:
> >> On Fri, Feb 27, 2009 at 1:29 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> >> Index: ffmpeg-svn/libavformat/avio.h
> >> >> ===================================================================
> >> >> --- ffmpeg-svn.orig/libavformat/avio.h ? ? ? ?2009-02-21 09:39:45.000000000 -0500
> >> >> +++ ffmpeg-svn/libavformat/avio.h ? ? 2009-02-27 08:54:57.000000000 -0500
> >> >> @@ -384,4 +384,7 @@
> >> >> ?int udp_get_local_port(URLContext *h);
> >> >> ?int udp_get_file_handle(URLContext *h);
> >> >>
> >> >> +/* tcp.c */
> >> >> +int tcp_get_file_handle(URLContext *h);
> >> >> +
> >> >> ?#endif /* AVFORMAT_AVIO_H */
> >> >
> >> > 1. missing prefix
> >> > 2. id prefer a generic way to get a file handle, dont we have one?
> >> > 3. as is this does not belong in a public header
> >>
> >> Thanks for the comment. I was actually wondering the same thing,
> >> forgot to mention it, it'd be nice to be able to get a file handle
> >> using generic API indeed. This does currently not exist.
> >>
> >> Here's what I know:
> >> - there's three protocols for which it's implemented (including my
> >> patch): UDP, RTP (2x UDP, one for RTP and one for RTCP) and TCP
> >> - it could be implemented for HTTP (=TCP), file:// etc. as well but is
> >> currently unused
> >> - you'd need an API that can return more than one integer, since RTP
> >> for example has two integers, not one
> >> - udp/rtp also don't have a prefix :-) and are also declared (in fact,
> >> right above this insert) in avio.h :-), so I'd have to fix all of them
> >> (and prefix them)
> >>
> >
> >> I could implement a function int av_get_file_handle(URLContext*); and
> >> just keep rtp_get_file_handles() as is (since RTP is the only one
> >> returning two fds). would that be OK? Then after that, I can keep this
> >> tidbit into avio.h as public API.
> >
> > sounds acceptable
> > the old ones need to be deprecated and put under #if VERSION <
> > though
> 
> OK, attached is a try. Turns out we never actually use the RTCP file
> descriptor so I placed rtp_get_file_handles() under an #if version as
> well. I am not completely sure if that's good but I guess we can
> always remove the #if later again.
> 
> Ronald

[...]

> Index: ffmpeg-svn/libavformat/avio.h
> ===================================================================
> --- ffmpeg-svn.orig/libavformat/avio.h	2009-02-27 23:58:45.000000000 -0500
> +++ ffmpeg-svn/libavformat/avio.h	2009-02-28 00:08:00.000000000 -0500
> @@ -78,6 +78,15 @@
>  int64_t url_filesize(URLContext *h);
>  
>  /**
> + * Return the file descriptor associated with this URL. For RTP, this
> + * will return only the RTP file descriptor, not the RTCP file descriptor.
> + * To get both, use rtp_get_file_handles().
> + *

> + * @return the file descriptor associated with this URL, or -1 on error.

in ffmpeg negative is error, i would like to have this consistent
also it allows E* codes

[..]
> Index: ffmpeg-svn/libavformat/file.c
> ===================================================================
> --- ffmpeg-svn.orig/libavformat/file.c	2009-01-23 20:03:59.000000000 -0500
> +++ ffmpeg-svn/libavformat/file.c	2009-02-28 00:12:52.000000000 -0500
> @@ -82,6 +82,11 @@
>      return close(fd);
>  }
>  
> +static int file_get_handle(URLContext *h)
> +{
> +    return (size_t)h->priv_data;
> +}

why size_t -> int ?
these types arent the same, which is wrong for the handle?


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

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/20090228/e90c8533/attachment.pgp>



More information about the ffmpeg-devel mailing list