Martin, As far as I know there is no standard way of synchronizing RTP playback across multiple stations in a network, although there is considerable interest in it.
IEEE has started a group for high-quality realtime media applications, and participation in it is open. You might contact Aidan Williams <[EMAIL PROTECTED]> or search on the IEEE P1733 project. Anyone else interested in Martin's question, also please take note. Cheers, Chuck ---- begin included text ---- Designation: P1733 Sponsor: Microprocessor Standards Committee Title: Standard for Layer 3 Transport Protocol for Time Sensitive Applications in Local Area Networks Status: New Standard Project Project scope: This standard specifies the protocol, data encapsulations, connection management and presentation time procedures used to ensure interoperability between audio and video based end stations that use standard networking services provided by all IEEE 802 networks meeting Quality of Service requirements for time-sensitive applications by leveraging the Real-time Transport Protocol (RTP) family of protocols and IEEE 802.1 Audio/Video Bridging (AVB) protocols. Project purpose: This standard will facilitate interoperability between stations that stream time-sensitive audio and/or video across bridged and routed LANs providing time synchronization and latency/bandwidth services by defining the packet format and stream setup, control, synchronization and teardown protocols by leveraging Real-time Transport Protocol (RTP) family of protocols and IEEE 802.1 AVB protocols. ---- end included text ---- Martin Runge wrote: > > 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 > _______________________________________________ Ccrtp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/ccrtp-devel
