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

[Martin Storsjö]

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.

The attached patchset requests the server to disable it, since we're not 
really ready to cope with it currently.

// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-rtsp-Parse-the-x-Accept-Dyanmic-Rate-header.patch
Type: text/x-diff
Size: 1305 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110102/3d90cb15/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-rtsp-Request-that-dynamic-rate-is-disabled.patch
Type: text/x-diff
Size: 1130 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110102/3d90cb15/attachment-0001.patch>