Subject: [AVT] Re: My summary on DTS and CTS

From: [email-masked]
Date: Tue, 18 Sep 2001 13:28:49 +0200

Dear AVTers,

this is about: >>draft-ietf-avt-mpeg4-multiSL-01.txt<<

Dear Sang-ug Kang,

Indeed there is a roll-over problem for CTS delta ...

I would think that the resonalble thing to do is to
forbid such occurance by forbidding to packetize
SL packets in the same RTP packets when the
CTS rolls over across these SL packets...

the sentence would be

"Senders MUST NOT assemble RTP packets
for which the CTS of the contained SL packets
rolls over"

anyone has a better idea ?
or a better english (can one use "rolls over" like this ?) ?

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

"Sang-ug Kang" <[email-masked]> on 18-09-2001 08:40:03

To:     Philippe Gentric/LIM/CE/PHILIPS@EMEA1
cc:     "Austin Lobo" <[email-masked]>
Subject:  My summary on DTS and CTS
Classification:

Dear Mr. Philippe Gentric,

Here it is my summary on CTS and DTS.
We've been talking on those several days ago. I found that some clarification on CTSDelta is needed as well.

=========================================================================================
Let's assume that there are two kinds of CTSs, Original CTS(OCTS) and Encoded CTS(ECTS).
OCTS has unlimited precision so that we don't have to wrap around the number generated.
ECTS has limited length so that we need to wrap around the number generated.
This is also applied to DTS and RTP TimeStamp cases.
Then, we can have
    OCTS(1~15) = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
    ODTS(1~15) = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}
If TimeStampLength = 3, then
    ECTS(1~15) = {1, 2, 3, 4, 5, 6, 7, 0, 1, 2, 3, 4, 5, 6, 7}
    EDTS(1~15) = {0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, 3, 4, 5, 6}

The following four equations are used to determine CTSDelta and DTSDelta. (Let the size of RTP TimeStamp be 3)
    E_RTP TimeStamp(encoded) := O_RTP TimeStamp = OCTS of the first SL packet in a RTP payload;
    RTP TimeStamp = E_RTP TimeStamp;
    CTSDelta(i) = OCTS(i) - O_RTP TimeStamp;
    DTSDelta(i) = OCTS(i) - ODTS(i);

Assumming that 5 SL packets are mapped on a single RTP packet,
    for the first RTP packet
        RTP TimeStamp = 1
        CTSDelta(1~5) = {0, 1, 2, 3, 4}
        DTSDelta(1~5) = {1, 1, 1, 1, 1}
    for the second RTP packet
        RTP TimeStamp = 6
        CTSDelta(6~10) = {0, 1, 2, 3, 4}
        DTSDelta(6~10) = {1, 1, 1, 1, 1}
    for the third RTP packet
        RTP TimeStamp = 3
        CTSDelta(1~5) = {0, 1, 2, 3, 4}
        DTSDelta(1~5) = {1, 1, 1, 1, 1}

Now at the receiver's side, we can decode all the values correctly by using following equations.
    CTS0 = CTS of the first SL packet in a RTP payload = RTP TimeStamp;
    CTS(i) = CTS0 + CTSDelta(i), for the rest of SL packets;
    DTS(i) = CTS(i) - DTSDelta(i), for the rest of SL packets;

    for the first RTP packet
        CTS = {1, 2, 3, 4, 5} ,                          DTS = {0, 1, 2, 3, 4}
    for the second RTP packet
        CTS = {6, 7, 8, 9, 10} ,                        DTS = {5, 6, 7, 8, 9}
    for the first RTP packet
        CTS = {11, 12, 13, 14, 15} ,               DTS = {10, 11, 12, 13, 14}

=========================================================================================

     The reason why I used 3 as the size of RTP TimeStamp is to show you that RTP TimeStamp(size of 32 bits actually) can have also wrap around confusion if Original one and Encoded one are not treated differently. Also
CTSDelta can not be represented in reduced size especially when wrap around occurs.
In real world, CTSDelta can have a very big value at the edge if TimeStampLength is 32 and E_RTP TimeStamp is used. For example,
    E_RTP TimeStamp = 2^32 -2;
    CTSDelta(i) = E_RTP TimeStamp - OCTS(i)  ---> CTSDelta = {0, 1, -2^32+2, -2^32+3, -2^32+4}

Please let me know, if I am missing some thing here.
Thank you very much.

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

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

---

From: "Sang-ug Kang" <[email-masked]>
Date: Wed, 19 Sep 2001 18:30:07 +0900

Dear Philippe,

I think your modified sentence can resolve the problem.

However, it's a kind of intrim solution avoiding exceptional cases. For
DTSDelta, we need another similar statement as well.
> for which the "DTS" of the contained SL packets
> rolls over"

With that, the encoder always needs to check if it happens or not (actually
the increment of CTS and DTS is not one :-).
I believe that the first reader of this ID might be confusing with this
statement.

The suggestion in my previous mail can resolve CTSDelta, DTSDelta confusion
clearly.
It would be helpful to provide the draft with some examples also.
What do you think of that?

Regards,

Sang-ug Kang

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 18, 2001 8:28 PM
Subject: Re: My summary on DTS and CTS

> We've been talking on those several days ago. I found that some
> clarification on CTSDelta is needed as well.
>
>
============================================================================
=============
>         CTS = {11, 12, 13, 14, 15} ,               DTS = {10, 11, 12, 13,
============================================================================
=============
>
>      The reason why I used 3 as the size of RTP TimeStamp is to show you
> that RTP TimeStamp(size of 32 bits actually) can have also wrap around
> confusion if Original one and Encoded one are not treated differently.
> Also
> In real world, CTSDelta can have a very big value at the edge if
> TimeStampLength is 32 and E_RTP TimeStamp is used. For example,