[FFmpeg-devel] How ffplay resolves bad timestamps?

[Michael Niedermayer]

On Fri, Dec 10, 2010 at 08:10:36AM +0100, Reimar D?ffinger wrote:
> 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...

the alternative is no timestamps at all, that is not better than a 1hour vs
discontinuitiy.
We can add a flag that indicates a discontinuity if the demuxer knows

in the case of known relative timestamps, a demuxer can use a large base
timestamp so that the discontinuity will be negative, avoiding the theoretical
1hour problem (which isnt one, especially not with rtp, even less so with
mpeg1/2 as that has limits on frame duration. And random access / keyframe
intervall requirements should make it impossible for many more cases
as well unless you have also one hour into which you cannot seek. What remains
doesnt support discontinuities.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/42bf006b/attachment.pgp>