[FFmpeg-devel] [PATCH] rtsp: Handling of dynamic rate aka Instant-On aka overbuffering
Sun Jan 2 19:19:09 CET 2011
On Sun, Jan 02, 2011 at 03:49:42PM +0200, Martin Storsj? wrote:
> 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?
> 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
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel