[FFmpeg-devel] How ffplay resolves bad timestamps?

Stas Oskin stas.oskin
Wed Dec 22 12:42:07 CET 2010


I've got some unfinished code for emitting timestamps from the beginning,
> if the server sends the start RTP timestamp with a RTP-Info header in
> response to the PLAY request. Do your servers send RTP-Info headers?
Yes, for example:

PLAY rtsp:// RTSP/1.0
Range: npt=0.000-
CSeq: 4
Session: 52

RTSP/1.0 200 OK
CSeq: 4
Date: Wed, Dec 22 2010 10:32:24 GMT
Range: npt=0.000-
Session: 52
RTP-Info: url=rtsp://;seq=56954;rtptime=372642415

if you provide me with the patch, I will be happy to test it.

> I guess the RTSP demuxer could output some kind of timestamp from the very
> beginning, too, (by setting the first received packet to pts=0 in each
> stream), but that might also result in non-monotone timestamps for some
> streams once they're synced properly at the first RTCP packet. (On the
> other hand, there's always the risk for non-monotone timestamps whenever
> the sync is adjusted when a RTCP packet is received, regardless of which
> way the initial sync is achieved.)

As majority of servers (in my experience at least) send the RTP-Info header,
I think that using it should cover most of cases out there. The minority
left, might handled via the method I do (i.e. dropping anything up to first
good key-frame timestamp).

Recovering from non-monotone is quite difficult, and I think that adding
more possible causes is not an optimal solution :).


More information about the ffmpeg-devel mailing list