Subject: [AVT] CTS mapping to RTP TS

From: [email-masked]
Date: Thu, 27 Sep 2001 09:37:06 +0200

Colin, all,

I propose the new wording :

****************************************************
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 RTP timestamp is incremented to extend it out to 32 bits.
If compositionTimeStamp has more than 32 bits length,
the RTP timestamp uses the 32 LSB of it. The resolution of
the timestamp (timeStampLength) is available from the SL
configuration data and shall be used by receivers to
reconstruct compositionTimeStamps with the original bit length.
When making SL streams specifically for usage with this payload
format it is RECOMMENDED to use timeStampLength=32.

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

I will also correct the pseudo code in section 5.1 to reflect that change.

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

Implementers of all countries please check if this causes problems
(I would not think so, all the implementations I know use 32 bits anyway)

This new solution has 2 advantages:

*  roll over on less than 32 bits of the RTP TS would be a *dangerous* thing to try
* we also accomodate now more than 32 bits for CTS

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

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: "Sang-ug Kang" <[email-masked]>
Date: Thu, 27 Sep 2001 18:41:01 +0900

Dear Mr. Philippe Gentric and all,

Now I think you and Mr. Colin Perkins are approaching the same way
I suggested in my previous emails.
I used the term "Original values" and "making use of 32-bit RTP TS"
I hope you didn't miss it....I believe...:-)

{Excerpts of the previous mail}
        [Ex2]
        if you assume 5 bytes per AU  (low bit rate audio codec)
        > and a network with 5000 bytes path MTU
        > you can have 1000 AUs per RTP packet:
        > ==> timeStampLength=10 bits is MUCH too small !!
        [Sang-ug]
        Instead of  creating the minimum length of timeStampLength which
will
        limit the use of  SL streams with size less than the "minimum"
recommended
        timeStampLength, we can use the original values and make use of
32-bit long
        RTP TS.

Also your statement for avoiding all Delta problems
{Excerpts of the previous mail}
        "In the multiple-SL modes senders MUST make sure that no fields
undergo
        roll over inside one RTP packet. This may limit the number of SL
packets
        inside one RTP packet and, when interleaving, may limit the
interleaving
        period."
is NOT necessary if you use original (unlimited precision) values to
construct Delta values.

I want to give you an explanation on "original value". To make a multipleSL
RTP payload,

[Current way]
SL packet consists of :                          CTS,    DTS,
PacketSeqNum            and so on..
Through MultiSl
          ------------------------------------------------------------------
MultiSL packetized RTP payload        RTP TS,    CTSDelta,    DTSDelta,
IndexDelta..

[Original-value way]
SL packet consists of :                         CTS,    DTS,    PacketSeqNum
and so on..   (TimeStampLength is not that important in this case.)
Through Origianl value
rator     ---------------------------------------------------------------
                                                                 Original
CTS,    Original DTS,    Original PacketSeqNum
Through MultiSl
          ------------------------------------------------------------------
-------
MultiSL packetized RTP payload       RTP TS,    CTSDelta,    DTSDelta,
IndexDelta..

If this is not clear, please read my previous email titled as "My summary on
CTS, DTS".

I hope this helps  make a better standard.

Regards,

Sang-ug Kang
Personal Internet Computing Team
Samsung Electronics
82-31-200-3746
[email-masked]