[FFmpeg-devel] How ffplay resolves bad timestamps?

[Stas Oskin]

Hi.

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://192.168.253.153/ch0_unicast_firststream/ 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://
192.168.253.153/ch0_unicast_firststream/track1;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 :).

Regards.