[FFmpeg-devel] [PATCH] Add protocol documentation on RTSP
Stefano Sabatini
stefano.sabatini-lala
Sun Oct 3 22:45:13 CEST 2010
On date Sunday 2010-10-03 13:18:09 +0300, Martin Storsj? encoded:
> On Sun, 3 Oct 2010, Stefano Sabatini wrote:
[...]
> > > +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?
I double checked the doxy, and still can't understand what's the
meaning of AVStream.discard.
More information about the ffmpeg-devel
mailing list