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 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/ccrtp-devel
