[FFmpeg-devel] How ffplay resolves bad timestamps?
Fri Dec 10 12:58:29 CET 2010
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
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
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel