[FFmpeg-devel] How ffplay resolves bad timestamps?
Thu Dec 9 21:06:34 CET 2010
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
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.)
More information about the ffmpeg-devel