Re: [Ccrtp-devel] SR when transmitting prerecorded content

[Martin Runge]

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 <address@hidden> 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