Subject: Re: [AVT] accepting draft-lakaniemi-avt-rtp-evbr-02 as WG

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 3 Sep 2008 07:37:01 +0200

> Date: Tue, 2 Sep 2008 13:02:59 +0100
> From: Colin Perkins <[email-masked]>
> Subject: Re: [AVT] accepting draft-lakaniemi-avt-rtp-evbr-02 as WG
> 	item
> To: Stefan D?hla <[email-masked]>
> Cc: [email-masked], [email-masked],
> 	"<[email-masked]>" <[email-masked]>, [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
> 
> On 2 Sep 2008, at 12:53, Stefan D?hla wrote:
> > Is it guaranteed that RTCP SRs allow sample-accurate alignment of  
> > the streams?
> 
> Yes, if implemented correctly.

As I see it it should be possible to achieve very good synchronization
if the media that is to be synchronized comes from the same host (same
wallclock) and where there is no clockdrift between these. 

As I see it there are atleast three levels of difficulty when it comes
to synchorize.
1) Same host, same media (may be multichannel or layered coding):
For this particular case I would assume that one will be able to achieve
exact sample synchronization as one afterall do the encoding on one host
and it is the same media that is encoded in different layers, or
channels. Reason is that there is no clockdrift between the layers or
channels.
2) Same host, several different media: 
For synchronizing e.g audio and video I would assume that you cannot
achieve exact synchronization as e.g the sample rate for the audio may
be 48010Hz and this will build up a delta-time in one media relative to
the other (which is corrected by different methods). On the average you
will achieve synchronization however. Anyway I don't believe that it is
critical to achieve exact synch between audio and video as the lipsynch
tolerance is relatively high.
3) Different hosts:
Synchroning media from different hosts requires that you synch the
wallclock to e.g NTP and here it is up to the accuracy of NTP (ms?). For
really professional applications I would guess that one can provide with
exact wallclocks here aswell.

On the issue whether or not to add an extra sycnhronization element
while waiting for all SR's for the different layers to arrive: 
I can understand need but then one also need to consider that SR's are
sent regularly and that the lack of synch will in practice only prevail
for the first 1-2 seconds and maybe one can live with just one layer
meanwhile ?.
I don't however see any big issue with the synch element other than that
you eventually to the same thing using two mechanisms.

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

---

From: <[email-masked]>
Date: Wed, 3 Sep 2008 10:14:13 +0300

>wallclock) and where there is no clockdrift between these. 

However, you cannot ensure 1) both the wallclock and sampling clock
themselves have no drift, OR 2) they are drifed in a synchronized way. 

If you use the RTP timestamp aligned method, which has nothing to do
with the wallclokc, even the sampling clock has drift, exact sync can be
achived, as the drift amount is exactly the same for all portions of one
sample/frame. 

BR, YK

---

From: Colin Perkins <[email-masked]>
Date: Wed, 3 Sep 2008 08:40:33 +0100

> themselves have no drift, OR 2) they are drifed in a synchronized way.

You don't need to ensure that to make it work. That's why everything  
is related to a single wallclock, to give a common reference.

> achived, as the drift amount is exactly the same for all portions  

Only if you're deriving everything from the exact same clock, which  
you cannot guarantee even for layered/MDC codecs.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Wed, 3 Sep 2008 08:43:29 +0100

> tolerance is relatively high.

You can estimate the skew relative to the wallclock, and compensate.  
This should give accurate synchronisation (at least, once the  
estimators have settled; it's no worse than aligned timestamps up  
until that time).

> exact wallclocks here aswell.

You need a common wall clock between sending hosts in this case.

-- 
Colin Perkins
http://csperkins.org/

---

From: <[email-masked]>
Date: Wed, 3 Sep 2008 11:19:43 +0300

Examples would be definitely helpful here. 
 
When you use the (only) wallclock (i.e. the RTCP SR based method is in
use), at certain time between two RTCP SRs, assume that the wallclock
skew amout since the previous RTCP SR is t1 , and the sampling clock
skew amount since the RTP timestamp value included in the previous RTCP
SR is t2. If t1-t2 is not equal to zero, the NTP timestamps calculated
for two portions of the same sample are not identical (with a difference
equal to |t1-t2|). When the difference is big enough, sample-level sync
will be lost. 
 
When you don't use wallclock (i.e. the RTP timestamp aligned method is
in use), at certain time, assume that the sampling clock skew amount is
again t2. The difference between the RTP timestamp values of two
portions of the same sample are still identical (both shifted by t2
compared to if there was no clock skew). Therefore, perfect sync can
still be achieved.
 
BR, YK

________________________________

	From: ext Colin Perkins [mailto:[email-masked]] 
	Sent: 03 September, 2008 10:41
	To: Wang Ye-Kui (Nokia-NRC/Tampere)
	Cc: [email-masked]; [email-masked]
	Subject: Re: [AVT] accepting draft-lakaniemi-avt-rtp-evbr-02 as
WG

				Is it guaranteed that RTCP SRs allow
sample-accurate alignment of  
				the streams?

			As I see it it should be possible to achieve
very good synchronization
			if the media that is to be synchronized comes
from the same host (same
			wallclock) and where there is no clockdrift
between these. 

		However, you cannot ensure 1) both the wallclock and
sampling clock
		themselves have no drift, OR 2) they are drifed in a
synchronized way. 

	You don't need to ensure that to make it work. That's why
everything is related to a single wallclock, to give a common reference.

		If you use the RTP timestamp aligned method, which has
nothing to do
		with the wallclokc, even the sampling clock has drift,
exact sync can be
		achived, as the drift amount is exactly the same for all
portions of one
		sample/frame. 

	Only if you're deriving everything from the exact same clock,
which you cannot guarantee even for layered/MDC codecs.

	-- 
	Colin Perkins
	http://csperkins.org/

---

From: Thomas Schierl <[email-masked]>
Date: Wed, 03 Sep 2008 10:46:34 +0200

[email-masked] wrote:
> skew amount since the RTP timestamp value included in the previous 
> RTCP SR is t2. If t1-t2 is not equal to zero, the NTP timestamps 
> calculated for two portions of the same sample are not identical (with 
> a difference equal to |t1-t2|). When the difference is big enough, 
> sample-level sync will be lost.
>  
> in use), at certain time, assume that the sampling clock skew amount 
> is again t2. The difference between the RTP timestamp values of two 
An implementer will  force the NTP timestamps calculated from RTP 
timestamp + RTCP SR to be the same for the same frame. Taking into 
account the difference between the packet and the last SR or not (in the 
case of RTP times tamp alignment) does not make a difference here. With 
the SR, there is just an offset.

-- 
Thomas Schierl
--------------
Fraunhofer HHI

----
Visit us at

IBC 2008 / Amsterdam (NL), 12 - 16 September 2008 / Hall 8 Booth C81
http://www.hhi.fraunhofer.de/index.php?id=2399&L=1

insite 2008 / Johannesburg (South Africa), Sandton Convention Centre / 15 - 17 September 2008 
http://www.insitex.co.za
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Wed, 3 Sep 2008 11:57:09 +0300

>the SR, there is just an offset.

The difference must be less than half the time difference between any
two contiguous RTP timestamp values, then you can round the calculated
NTP timestamp to the closest RTP timestamp (and this rounding itself is
not complaint to conventional calculation of NTP timestamps), otherwise
you have trouble. 

BR, YK

---

From: Thomas Schierl <[email-masked]>
Date: Wed, 03 Sep 2008 11:14:05 +0200

> not complaint to conventional calculation of NTP timestamps), otherwise

You have to make sure that rounding at the receiver will not lead to a 
wrong value. That's it!

-- 
Thomas Schierl
--------------
Fraunhofer HHI

----
Visit us at

---

From: <[email-masked]>
Date: Wed, 3 Sep 2008 12:32:35 +0300

>You have to make sure that rounding at the receiver will not lead to a 

You cannot make sure that rounding at the receiver will not lead to a
wrong value, as long as the drift is not less than half the time
difference between any two contiguous RTP timestamp values, that's it!

BR, YK

---

From: Thomas Schierl <[email-masked]>
Date: Wed, 03 Sep 2008 11:38:39 +0200

> difference between any two contiguous RTP timestamp values, that's it!

Why should you not be able to pre-calculate the rounding at the 
receiver? The sender knows about the wallclock and the RTP timestamps 
sent by himself.

-- 
Thomas Schierl
--------------
Fraunhofer HHI

----
Visit us at