Subject: [AVT] Re: on CTS, pathological case

From: [email-masked]
Date: Mon, 24 Sep 2001 17:57:55 +0200

Dear Sang-ug Kang, Dear AVTers,dear MPEG-4 systemers

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

Now that I am working on the final draft
I follow the lead Sang-ug Kang has initiated and look systematically for roll over issues ...

I have this pathological example that I want to get your insight about:

The draft says:

"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."

*unfortunately* SL allows time stamps to be defined on an awful short length:
an extreme example  is if  timeStampLength = 1 (!)
In the singleSL mode you get RTP packets with timestamps:  0,1,0,1, ...

Obviously, this is not a very nice solution !

(also see below for a more practical case),
less "stupid" but just as bad)

Therefore I propose to add:

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

"However senders MUST use suitably large values of timeStampLength to insure that
RTP timestamps do not roll over too often to be usefull
(for example for multiple streams synchronisation using RTCP Sender Reports).

Existing SL streams that do not conform to this requirement cannot be synchronized when
transported with this payload format.

When making streams specifically for usage with this payload format
it is RECOMMENDED to use timeStampLength =32."

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

objections?

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

What would be a limit size ?

 I discovered this problem with this even more strange pathology in the multiple SL mode:

let be a SL stream with timeStampLength = 3:
let this stream be:
CTS = 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 8

then let this stream be transported in multipleSl mode

first RTP packet:                                   CTSDelta: 0(implicit)  1 2 3 4 5 6 7
second RTP packet:                           CTSDelta: 0(implicit)  1 2 3 4 5 6 7
etc ........ 123456 nth RTP packet:     CTSDelta: 0(implicit)  1 2 3 4 5 6 7

Question for the attentive readers:  what is the RTP time stamps for these packets ?
Answer: ZERO! all RTP timestamps are then zero according to the current rule in the draft !!!!!!!!
(actually we also have:
"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."
so we would have a contradiction here !)

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 !!

so maybe we could enforce a "minimum" value of 16 bits ?
is this going to be a problem for "existing" SL streams ?

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

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: Wed, 26 Sep 2001 17:52:00 +0900

Dear Mr. Philippe Gentric and all,

There have been several email exchanges between Philippe and me regarding
the roll-over issue.
I initiated the DTSDelta and CTSDelta problems and suggested one solution
that will be shown below.

I am afraid that there's the same kind of problem for IndexDelta as well.

Philippe suggested following solutions.
1. For DTSDelta,
    *computation * has to be performed in "virtual unlimited precision"

2. For CTSDelta,
    A.  "Senders MUST NOT assemble RTP packets or which the CTS of the
contained SL packets rolls over"
    B.  "However senders MUST use suitably large values of timeStampLength
to insure that
RTP timestamps do not roll over too often to be usefull
(for example for multiple streams synchronisation using RTCP Sender
Reports).
 Existing SL streams that do not conform to this requirement cannot be
synchronized when
 transported with this payload format.
When making streams specifically for usage with this payload format
it is RECOMMENDED to use timeStampLength =32."

Also Philippe arised two examples in the previous email from him.
   Ex1. Identical RTP TimeStamp case.
   Ex2. 1000 AUs per RTP packet case.

I agree on the solution for DTSDelta.
The solution for CTSDelta works but limits the use of SL streams with small
TimeStampLength.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"Unfortunately we need another statement for IndexDelta roll-over."

My suggestion is that "Use the original values." (See the below) With this,
we can solve all
the delta problems
and examples Ex1, Ex2 from Philippe as you can see below.

Ex1]
> CTS = 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 8
[Sang-ug] Original CTS = 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
> etc ........ 123456 nth RTP packet:     CTSDelta: 0(implicit)  1 2 3 4 5 6
7
[Sang-ug]
    Guess the RTP TS???  The RTP TSs are not idential. They are 0, 8, 16
respectively.

Ex2]
> ==> 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.

I don't understand why "using the original value" is not suitable for
solving all the exceptional cases.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There are minor mistakes in the draft.
1.  Pseudo code mistake
    In 5.1.
         if (i == 0){ // first SL packet in RTP packet
           SLPacketHeader.packetSequenceNumber(0) = MSLH.Index(0);
         }
         else { // remaining SL packets
           SLPacketHeader.packetSequenceNumber(i+1)=
              SLPacketHeader.packetSequenceNumber(i)
              + MSLH.IndexDelta(i+1) +1;
         }
  should be replaced by the below (see the difference (i+1) , (i-1), (i))

         if (i == 0){ // first SL packet in RTP packet
           SLPacketHeader.packetSequenceNumber(0) = MSLH.Index(0);
         }
         else { // remaining SL packets
           SLPacketHeader.packetSequenceNumber(i)=
              SLPacketHeader.packetSequenceNumber(i-1)
              + MSLH.IndexDelta(i) +1;
         }

2. In 3.1.,
    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...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

My suggestion starts>>>

============================================================================
=============
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}

My suggestion ends<<<

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 25, 2001 12:57 AM
Subject: [AVT] Re: on CTS, pathological case

> "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."
> "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."