[FFmpeg-devel] [PATCH] rtsp: Handling of dynamic rate aka Instant-On aka overbuffering
Sun Jan 2 19:40:41 CET 2011
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.
More information about the ffmpeg-devel