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

From: [email-masked]
Date: Thu, 20 Sep 2001 17:25:58 +0200

I am not sure to understand your reply ?

my proposition is not  to merge the solutions:

1. for DTS delta (the difference between CTS and DTS)
I explained how a simple rule of computing "absolute" 
values can solve the problem.

2. for CTS Delta (difference between CTS and RTP time stamp)
I want to simply forbid roll over inside a packet

the reason is that the only consequence is a smaller packet *when RTP TS 
roll overs*
,since RTP TS is 32 bits ==> *normaly* this is an extremely rare event

I understand that if you use a CTS encoded on very few bits,
the RTP time stamp encoding this CTS will roll over very fast too
(and BTW this may look strange for a lot of existing RTP devices ...)

this new rule (no CTS roll over inside a RTP packet)
simply means that you will not be able to cram
many SL packets into one RTP packet ....

>> the *ONLY* consequence will be that such a SL stream will 
be transported with a bit more RTP header overhead...

I am not much concerned about that in the sense that
*it would still work* ... and if you want to decrease the RTP overhead,
then you can use more 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

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

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.
>"Senders MUST NOT assemble RTP packets
> 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
Personal Internet Computing Team
Samsung Electronics
82-31-200-3746
[email-masked]

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

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

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