[Ccrtp-devel] SR when transmitting prerecorded content

[Martin Runge]

Hi all,

I want to transmit prerecorded audio (mp3 files) to several receivers 
(multicast). The receivers shall play back audio in sync with each other.

>From the ccRTP sources I read, that the SR package is NTP timestamped with the 
>sender's wallclock time when generating the SR RTCP packet and the 
>corresponding RTP timestamp is calculated from initialTime. So the NTP-RTP 
>relation from the SR defines defines the wallclock time when each sampling 
>instant was sent (or recorded), which is correct for streaming live audio like 
>telephony.
RFC3550 suggests when streaming prerecorded media, the NTP-RTP relation should 
specify the presentation time instead of the sampling or sending time.

Back to my problem: I see two possibilities to play back the audio on all 
receivers in sync:

1) All receivers see the same NTP time for the same RTP timestamp, and 
therefore can play back in sync, but only if they all #define the same network 
latency and playback buffer size. If there is one receiver connected with a 
higher latency, there is no easy way to tell the other receivers to increase 
their playback buffers to a common new value.

2) When the sender would specify the presentation time in the SR, all receivers 
could try to play back at exactly that NTP time. The sender would choose a time 
offset between sending time and presentation time which is long enough to cover 
network latency plus playback buffer. If there are receivers connected with a 
network latency that is so high that the playback buffer is not sufficient any 
more, the sender can adjust the offset for all clients (either via the senders 
config file or even dynamically by using information from the RRs).

Here is my question:

Would you consider to accept a patch introducing the possibility to optionally 
specify a RTP timestamp offset for SR packets similar to this:

setPresentationOffset(int offset_in_ms)

- If the function is not called by the application, the behaviour stays 
unchanged.
- specifying an offset would imply, that the initial RTP timestamp which is now 
0 would become negative, respectively the RTP timestamp overflow situation.
- On the receiver side, some convenience function be necessary to get the 
presentation time out of the SR.

What do you think? Does anybody see a simpler way?

regards
Martin




_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220