[FFmpeg-devel] [PATCH] rtsp: Handling of dynamic rate aka Instant-On aka overbuffering

[Martin Storsjö]

On Sun, 2 Jan 2011, Michael Niedermayer wrote:

> On Sun, Jan 02, 2011 at 03:49:42PM +0200, Martin Storsj? wrote:
> > Hi,
> > 
> > DSS has the feature "dynamic rate" aka Instant-On aka overbuffering, for 
> > feeding packets faster than realtime, for starting playback faster.
> > 
> > This is enabled automatically without explicitly requesting, if using 
> > something named "Reliable RTP", or if using TCP interleaving.
> > 
> > The issue with it being enabled automatically is that it screws with 
> > timestamps based on RTCP NTP (which is the only official way of syncing 
> > streams afaik). When serving packets faster than realtime, DSS still sends 
> > RTCP packets with the current realtime NTP timestamp, but with the current 
> > RTP stream timestamp.
> > 
> > In practice, this leads to emitted timestamps jumping backwards at each 
> > RTCP packet. To test it, try this and watch the time counter:
> > 
> > ffplay rtsp://albin.abo.fi:8554/sample_100kbit.mp4?tcp
> > 
> > First the timestamps go from 0 to about 14, then jumps back to about 7. 
> > This, since the second RTCP packet is sent 7 seconds in the stream, after 
> > the server has sent about 14 seconds worth of RTP data.
> > 
> > I'm not sure how to best fix the RTP timestamping code to cope with this - 
> > I'm not sure how to use RTCP at all in this setup, and without RTCP, 
> > there's no proper way of syncing the streams together.
> 
> how does the official code handle syncing with this?

This is a QuickTime specific extension (of which only the server is 
opensourced), so I'm not aware of any official reference player actually 
dealing with it.

I could try to check other open source code bases such as live555 and 
gstreamer to see if they handle it sensibly.

> > The attached patchset requests the server to disable it, since we're not 
> > really ready to cope with it currently.
> 
> this isnt a very nice solution

Nope, but unless we figure out a good way of dealing with it, it's the 
best compromise I think.

Also, I'm not sure how to detect it - if we don't explicitly request it 
enabled or disabled, the server might enable it for TCP, but doesn't tell 
us that it did.

But I'll look into what others do.

// Martin