[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ccrtp-devel] SR when transmitting prerecorded content
From: |
Martin Runge |
Subject: |
[Ccrtp-devel] SR when transmitting prerecorded content |
Date: |
Thu, 27 Dec 2007 16:36:37 +0100 |
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
- [Ccrtp-devel] SR when transmitting prerecorded content,
Martin Runge <=