[FFmpeg-devel] Additional RTSP issues

Luca Abeni lucabe72
Thu Jul 16 08:00:38 CEST 2009


Baptiste Coudurier wrote:
[...]
>> - data prefetch (imagine wanting an internal buffer, skipping the
>> first 3sec b/c of delay and then having to wait an *additional* 3
>> seconds to build up the internal buffer; of course the 3s is a random
>> number but you get the idea)
> 
> What's the frequency of RTCP SR ?

There is no fixed frequency, but the minimum distance between two RTCP SR
packets is 5s (in practice, packets will arrive at the maximum possible
frequency, so you will very likely see an RTCP SR every 5s).


> I also wonder how other implementations manage to somehow returns
> timestamps better (even if unreliable) than libavformat

They don't (it is impossible :). What libavformat does is to return
AV_NOPTS_VALUE until a correct PTS can be computed. Other applications
have no "no PTS" concept and generally return unreliable timestamps. This
means that the first 2 or 3 seconds of live streams will be out of A/V
synch, and a timestamp discontinuity will be seen as soon as the first RTCP
SR packet arrives.

Note that this only happens with live streams: most of the "rtsp://" streams
are VoD, and in this case there is no problem (libavformat immediately returns
correct PTSs)


>> - not all RTSP streams are live
> 
> I could understand the RTCP SR problem when it is live, but I cannot
> when it's not live, can you please explain the principles ?

The problem does not happen for non-live streams (at least: I use libavformat's
RTP demuxer on daily basis, and I only see this delay with live streams).


> Though I wonder why the first thing the server send is not a RTCP SR, I
> guess I'm not understanding the concept.

For broadcast-like streams sent over multicast, there is no concept of "first
packet"... So, servers generally send the RTCP SR periodically (note that
there also might be other delays when receiving live streams, because the
first received frame generally is not a reference frame).


				Luca



More information about the ffmpeg-devel mailing list