[FFmpeg-devel] [PATCH] Add protocol documentation on RTSP

Martin Storsjö martin
Sun Oct 3 12:18:09 CEST 2010


On Sun, 3 Oct 2010, Stefano Sabatini wrote:

> > diff --git a/doc/protocols.texi b/doc/protocols.texi
> > index 4f7b42e..c1ff310 100644
> > --- a/doc/protocols.texi
> > +++ b/doc/protocols.texi
> > @@ -217,6 +217,76 @@ ffplay "rtmp://myserver/live/mystream live=1"
> >  
> >  Real-Time Protocol.
> >  
> > + at section rtsp
> > +
> > +RTSP isn't technically a protocol handler in libavformat, it's a demuxer
> > +and muxer. The demuxer supports both normal RTSP (with data transferred
> 
> Please avoid abbreviations in official docs, that is isn't => is not

Changed

> > +over RTP; this is used by e.g. Apple and Microsoft) and Real-RTSP (with
> > +data transferred over RDT).
> > +
> > +The muxer can be used to send a stream using RTSP ANNOUNCE to a server
> > +supporting it (currently Darwin Streaming Server and Mischa Spiegelmock's
> > +RTSP server, http://github.com/revmischa/rtsp-server).
> 
> @url{http://github.com/revmischa/rtsp-server}

Thanks, didn't know of that texinfo element

> > +
> > +The required syntax for a RTSP url is:
> > + at example
> > +rtsp://@var{hostname}[:@var{port}]/@var{path}[?@var{options}]
> > + at end example
> 
> Specify that @var{options} are a &-separated list of options of the
> form...

Ok, updated

> > +
> > +The following options are supported:
> > +
> > + at table @option
> > +
> > + at item udp
> > +Use UDP as lower transport protocol
> > +
> > + at item tcp
> > +Use TCP (interleaving within the RTSP control channel) as lower
> > +transport protocol
> > +
> > + at item multicast
> > +Use UDP multicast as lower transport protocol
> > +
> > + at item http
> > +Use HTTP tunneling as lower transport protocol, which is useful for
> > +passing proxies.
> 
> Consistency nit: always use a final dot.

Fixed

> > + at end table
> > +
> > +Multiple lower transport protocols may be specified, in that case they are
> > +tried one at a time (if the setup of one fails, the next one is tried).
> > +For the muxer, only the @var{tcp} and @var{udp} options are supported.
> > +
> > +When receiving data over UDP, the demuxer tries to reorder received packets
> > +(since they may arrive out of order, or packets may get lost totally). In
> > +order for this to be enabled, a maximum delay must be specified in the
> > + at var{max_delay} field of AVFormatContext.
> > +
> 
> > +With multi-bitrate streams in Real-RTSP, the streams to receive are chosen
> > +according to the @var{discard} field in AVStream. When watching such streams
> 
> This needs more explanation. How it is possible to see which streams
> are received? What @var{discard} does represent? How can it be set
> via-commandline?

Umm, I'm not sure what you want here. (In my defense: I've never used this 
with Real-RTSP myself, but Ronald has described how it works, roughly, and 
the applehttp demuxer works similarly.) The list of streams is shown on 
startup both in ffplay and ffmpeg, so from that, you can choose video 
stream 0, 1, 2 etc. If you didn't launch it with either one before, it's 
of course hard to guess what values to use :-)

I'm not sure it's necessary to describe how the discard field in AVStream 
works here, it's mostly as a reference for developers so they know what to 
look for. You can control it on commandline via -ast and -vst with ffplay 
at least, as I describe in the next sentence.

So, which part of this do you want in the docs?

> > +with @file{ffplay}, the streams to display can be chosen with -vst @var{n}
> > +and -ast @var{n} for audio and video respectively, and can be switched
> 
> > +on the fly by pressing @var{v} and @var{a}.
> 
> @code{v} and @code{a} are maybe more appropriate.

Ah, yes. I changed some other occurrances of @var{} into @code{}, too, for 
clarity at the places where that literally is what should be typed.

// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-protocol-documentation-on-RTSP.patch
Type: text/x-diff
Size: 3074 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101003/c8531bc7/attachment.patch>



More information about the ffmpeg-devel mailing list