Subject: [AVT] Syncronization of co-located clients?

From: Greg Herlein <[email-masked]>
Date: Sat, 2 Jul 2005 21:14:18 -0700 (PDT)

I've got a scenario where I need to multicast RTP streams to 
multiple clients, and some of those may be within visual (and 
worse, audible) range of another client.

Is there a profile or other trick to help ensure syncronization 
*between* the clients?  In other words, ensure that the 
presentation of the material from one client is in sync with the 
others nearby?

I have some approaches to this, and have been hunting for other 
ideas.

Any links, references, research papers - whatever - would be 
appreciated.

Greg

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Stephen Casner <[email-masked]>
Date: Sun, 3 Jul 2005 11:01:32 -0700 (PDT)

> Any links, references, research papers - whatever - would be

The following paper describes a nice synchronization protocol
developed by Julio Escobar and colleagues at BBN which allows
specifying the synchronization goals and dynamically determining the
offsets needed to achieve sync:

    Julio Escobar, Craig Partridge, Debra Deutsch, "Flow
    Synchronization Protocol" IEEE/ACM Transactions on Networking,
    Vol.2, No. 2, pp.111-121, April 1994.

This may be more academic than you want; it defines a synchronization
model and what information needs to be communicated, rather than
providing a detailed protocol specification.  This protocol was
discussed in AVT for a while to consider whether RTP itself needed any
changes to support more general synchronization, but we concluded that
it did not.

This synchronization protocol was used in a demonstration of
distributed music performance that I helped implement at the ACM
Multimedia Conference 1994.  The music was a Haydn trio performed from
three different locations across the country.  Since only two
performers were available, one part was recorded.  That part was
transmitted over the network and played out simultaneously at the two
other locations.  The two live performers played their parts along
with that first one, not hearing each other.  All three parts were
multicast to multiple receivers, each of which synchronized the three
streams to play out the trio in unison.  The synchronization was
achieved through the timestamps on the media packets in combination
with delay offsets calculated by the synchronization protocol.

The synchronization goal for this demo is different from yours, but
the protocol is general.  You may find that you need to implement
something specific for your application, and this paper will give you
the theory behind it so you know what information needs to be
communicated where.

                                                        -- Steve

---

From: Greg Herlein <[email-masked]>
Date: Sun, 3 Jul 2005 12:10:04 -0700 (PDT)

I found this as well - might provide a mechanism for sync based 
on SMPTE time code:

http://www.ietf.org/internet-drafts/draft-singer-smpte-rtp-01.txt

Assuming all clients controlled the playout buffer using the 
SMPTE time code, this could likely do it.  My particular 
application is on a local LAN (a controlled VLAN actually) so I 
am not expecting the network to present significant problems.

I've yet to review the recommended reading and products - I very 
much look forward to it.  If possible, I'd like to generalize a 
solution to this problem - which may indeed be something that the 
wider AVT audience wants to participate in.  I'd welcome that.

I'll also be shifting my participation in AVT to my work email 
([email-masked]) since this project is work and not 
personal.  I'd been active here using this email before so 
thought I'd use personal mail for my initial posts.

Greg

---

From: Chuck Harrison <[email-masked]>
Date: Sun, 03 Jul 2005 14:45:54 -0700

Greg,

This is definitely an area of interest to me. Let's continue
the discussion here on AVT.

Peace,
  Chuck

Greg Herlein wrote:
[...]>

---

From: <[email-masked]>
Date: Sun, 3 Jul 2005 16:08:14 -0700

> presentation of the material from one client is in sync with the

I may be oversimplifying your problem, but have you looked into using
the NTP and RTP timestamp information in RTCP sender/receiver reports
to synchronize? These RTCP reports allow you to determine the relative
offset of each client to the reference clock of the sender. Using
this, each client can adjust its playout delay to play at an absolute
time that is the same as the other clients.

I'm certainly not an expert, but this is what I am doing to play an
RTP audio stream in sync to multiple clients within audible range of
each other. What I found helpful is the book "RTP: Audio and Video for
the Internet" by Colin Perkins (ISBN 0-672-32248-8). The chapter on
Lip Synchronization describes the process of syncing streams using
RTCP reports.

It would be great to hear about other techniques, experiences, and
reading material.

---

From: Stephen Casner <[email-masked]>
Date: Sun, 3 Jul 2005 16:21:58 -0700 (PDT)

> am not expecting the network to present significant problems.

I don't think the SMPTE timecodes help unless they are representing an
absolute time in the future, where the sender has made a prediction
about the amount of time needed for propagation to all receivers and
buffering time within each receiver.  That might work in a controlled
LAN environment, but it is not a general solution.

The BBN Synchronization Protocol that I mentioned is based on using
synchronized clocks at the receivers (e.g., using NTP).  Each receiver
relates its earliest possible playout time for a media timestamp to
real time, and communicates that back to the controller.  The
controller finds the latest of these times and informs all the
receives so they can choose the same playout time.  There's more to it
than that, of course.  Sync "epochs" were used to deal with media
clock drifts, etc.

[I state the above without having read the paper in a long time.  I
seem to remember a centralized controller, but it could be done in a
distributed manner as well.]

                                                        -- Steve