[FFmpeg-devel] How ffplay resolves bad timestamps?

[Michael Niedermayer]

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
AV_NOPTS_VALUE
handling timestamp discontinuities is easier than reordering and summing
durations

[...]
-- 
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
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101210/88b8267a/attachment.pgp>