Chuck, Thank for the hint to IEEE P1733, I will watch it. Until it gets some results, I need to somehow implement my own small control protocol for the NTP offset.
regards Martin Am Donnerstag 27 Dezember 2007 21:27:00 schrieben Sie: > 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
