[FFmpeg-devel] How ffplay resolves bad timestamps?

[Martin Storsjö]

On Thu, 9 Dec 2010, Stas Oskin wrote:

> This happens due to media source sending several first packets with NOPTS
> timestamps, which get corrected in middle between the 1st and 2nd
> key-frames, thus breaking ffmpeg parsing.

Yes - the RTSP demuxer starts emitting timestamps once it receives the 
first RTCP packet (which may come anywhere, not necessarily between any 
specific keyframes).

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?

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.)

// Martin