ccrtp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chuck Harrison
Subject: Re: [Ccrtp-devel] SR when transmitting prerecorded content
Date: Thu, 27 Dec 2007 12:27:00 -0800

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
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]