Subject: [AVT] CTS roll over

From: [email-masked]
Date: Wed, 26 Sep 2001 11:42:29 +0200

Dear Sang-ug Kang,

you write:

    In all cases, the sender SHALL always make sure that RTP time stamps
   are identical only for RTP packets transporting fragments of the
   same Access Unit.
   ==> What if RTP TimeStamp rolls over? It can have the same value again.
            Also if CTS rolls over, RTP TS can have the same value 
again...

*************************

I agree the sentence is not mathematically true even with 32 bit CTS ...

>>> they DO roll over, everything does ... ;-)

the points are:

1) being able to reconstruct a fragmented Access Unit USING the fact
that all fragments are transported with the same RTP TS
(and conversely different TS means different AU)

my "stupid" example with timeStampLength=1 "almost works" in this respect
because AU do get different RTP TS ... except that in case of losses
and if AU start flag is not used it is not possible for a receiver
to reconstruct correctly the sequence....

so you want at least a few bits for that purpose ...
the exact number depends on the network loss characteristics ...

2) being able to SYNCHRONIZE 2 streams (A + V for example)

in this case you *need* some *more* margin 
because if your TS rolls over every 3 seconds
(which satisfies issue 1) on a lot of cases)
you may end up with audio and video mis-synchronised by 3 seconds,
or 6, or any multiple of 3 seconds !!!!!!!!!!!!

****************************

I want to cover this issue by documenting it,
rather than by fixing too many things, because
the actual numbers (of bits) to use are
extremely application dependant ...

In the end it is always the sender *responsability* to configure
the thing so that it can be received/parsed/decoded/synchronized,
right ?

So I have the new text:

*************************

Timestamp: Set to the value in the compositionTimeStamp
field of the first SL packet in the RTP packet, if present.

If compositionTimeStamp has less than 32 bits length, 
the MSBs of timestamp MUST be set to zero. 
If compositionTimeStamp has more than 32 bits length, 
this payload format cannot be used. 
When making SL streams specifically for usage with this payload format 
it is RECOMMENDED to use timeStampLength=32. Senders MUST use suitably 
large values of timeStampLength to insure that RTP timestamps do not 
roll over too often to be useful (for example for multiple streams 
synchronization using RTCP Sender Reports). Existing SL streams 
that do not conform to this requirement cannot be synchronized 
when transported with this payload format. 

**************************************

Regards,

Philippe Gentric
Software architect
Philips Digital Networks - MP4Net
51 rue Carnot B.P. 301
92156 Suresnes FRANCE
tel: +33(0)147283740
fax: +33(0)147283725
[email-masked]
http://www.mpeg-4.philips.com

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 26 Sep 2001 12:03:46 -0400

--> [email-masked] writes:
...
>So I have the new text:

I believe that the use of timestamps less than 32 bits will cause problems
with RTP. Why don't you extend short timestamps out to 32 bits?

Colin