[FFmpeg-devel] How ffplay resolves bad timestamps?

[Reimar Döffinger]

On Fri, Dec 10, 2010 at 04:55:28AM +0100, Michael Niedermayer wrote:
> 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

I disagree, there is no way to _properly_ handle timestamp discontinuities
if there's no way to even detect them. While it usually is fine to just assume
that kind of thing is not intended you can't know if that frame isn't actually
supposed to show for 1 hour for example...