[FFmpeg-devel] Additional RTSP issues

Luca Abeni lucabe72
Wed Jul 15 09:06:14 CEST 2009

Stas Oskin wrote:
> Hi.
> the player (basically, you cannot receive reliable timestamps until the
>> first
>> RTCP SR packet has been received).
> Just a question about design - why to keep these packets buffered (as it
> seems to happen now), and not return them immediately to user, for his
> decision?
Well, the RTSP demuxer does not keep packets buffered. I guess they are
buffered by libavformat during av_find_stream_info().
So, I suspect this is application's decision (I think you can avoid calling
av_find_stream_info(), and fill all the codecs' parameters by yourself...).

>  Other RTSP implementation don't seem to have this issue.
Other RTSP implementation return unreliable PTSs.

> Some players return fake timestamps until the first RTCP SR packet is
>> received
>> (for example, if receiving a multicast stream with "vlc file.sdp" you can
>> see
>> a discontinuity in the audio or in the video after few seconds).
> Thanks for the explanation, this clarifies the matter indeed.
> Any good scheme to fake these timestamps?
You can modify libavformat/rtpdec.c:finalize_packet(), and write some random
value in pkt->pts if s->last_rtcp_ntp_time == AV_NOPTS_VALUE (for example,
you can add an "else pkt->pts = timestamp;).
But then be prepared to see timestamps discontinuities and all kinds of

> Maybe just taking the first X correct timestamps, then approximate backwards
> for the non-stamped packets?
Well, after receiving the first RTCP SR (and having the first reliable timestamp),
you can do some kind of backward extrapolation...
But this is something that the application must do, not something for libavformat.


More information about the ffmpeg-devel mailing list