Subject: Re: [AVT] Re: CTS mapping to RTP TS

From: [email-masked]
Date: Thu, 27 Sep 2001 13:54:30 +0200

Dear Sang-ug Kang,

I confess I had not understood your ideas in their full extend !

Great!

*******
1.

I am glad we agree on this solution of using RTP TS with always 32 *full* 
bits !

the fact that we also cover 64 bit time stamps is nice, I know that
for network people 64 bit time stamps sound crazy but for
content people they are not !

time has come when we store videos of several weeks and the way to manage 
such content
is to have 64 bits TS: you dont need to worry about roll over at all !!!
(roll over is manageable when streaming, but *jumping* 
in a content where time stamps roll over is a nightmare !)

still for network streaming 32 bit will be enough: packet transport  time 
context is
never *hours* !!! (or maybe in some very far future full of relativistic 
vehicules ???? ;-)

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

2.

About the general sentence on roll over:

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

I aggree that with the above (1) time stamps are "less" affected than 
before

however this sentence is still useful to cover other pathological cases:

Multiple AU per RTP packet described with too few bits for CTSDelta 
*could* roll over.
I agree with your description that a decoder may detect/compensate roll 
over ... in the non interleaved case !

BUT In the interleaved case there are situations where *consecutive* AU
in the same RTP packet would be separated by a larger CTS difference
that CTSDeltaLength bits can encode ...
(how can a receiver detect roll over then ?)

>>> that would create a fantastic mess indeed !

Similarily for IndexDelta !!

This is the reason why this sentence is useful ...

I am making sense ?

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:     "Austin Lobo" <[email-masked]>
"AVT" <[email-masked]>
"M4IP" <[email-masked]> 
Subject:        [AVT] Re: CTS mapping to RTP TS
Classification: 

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]

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, September 27, 2001 4:37 PM
Subject: CTS mapping to RTP TS

> 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

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