[FFmpeg-devel] How ffplay resolves bad timestamps?
Fri Dec 10 04:55:28 CET 2010
On Thu, Dec 09, 2010 at 10:06:34PM +0200, Martin Storsj? wrote:
> 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.)
if you know relative timestamps in the demuxer, output them instead of
handling timestamp discontinuities is easier than reordering and summing
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
There seems to be only one solution to NIH syndrom, ... a shooting squad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel