Subject: [rohc] about TS in Type zero for RTP profile ?

From: "LI_JING" <[email-masked]>
Date: Tue, 13 Sep 2005 16:59:57 +0800

Hi,experts,

    There is a question which I feel puzzled on relization of RHC3095:

    As in 5.2.7 in RFC3095, 
    "Packet type zero: R-0, R-0-CRC, UO-0.
       This, the minimal, packet type is used when parameters of all SN-
       functions are known by the decompressor, and the header to be
       compressed adheres to these functions. Thus, only the W-LSB
       encoded RTP SN needs to be communicated."

    here,how to define "function relationship between SN and TS" ? 

    Sure we know if TS in every RTP packet changes,we could get clear

function relationship between SN and TS, no matter TS is scaled or not.

And only send SN in  Packet type zero, and get correct TS in decompress side.

　　But trouble comes when send vedio packets, one vedio frame devide into several

several RTP  packets to increase robustness.So how to cope with the case ? Would it

mean we cann't use  packet type zero because function between SN and TS changes in these

RTP  packets with same TS and changed SN ?

   In a word, no possibility to use packet type zero  when several consecutive using same

TS ?  Or Only when TS isn't changed in above several packets, we could use packet type zero

to aim at getting SN and IPID ?

    Your any ideas would be appreciated.
　　　　　　　　　　　
> Regards
> 
> LI JING
> [email-masked]
> *****************************************************************
> This e-mail and its attachments contain confidential 
> information from DATANG MOBILE, which is intended only for the 
> person or entity whose address is listed above. Any use of 
> the information contained herein in any way (including, but 
> not limited to, total or partial disclosure, reproduction, or 
> dissemination) by persons other than the intended 
> recipient(s) is prohibited. If you receive this e-mail in 
> error, please notify the sender by phone or email immediately 
> and delete it!  Thank you.
> *****************************************************************

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 14 Sep 2005 16:10:36 +0200

Have you checked the implementer's guide?
http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-15.txt

If you can't find the answer there, let us know and we'll try to answer.

BR
/L-E

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of LI_JING
> Sent: den 13 september 2005 11:00
> To: rohc
> Subject: [rohc] about TS in Type zero for RTP profile ?
> 
> 
> 
> Hi,experts,
>

---

From: "LI_JING" <[email-masked]>
Date: Thu, 15 Sep 2005 14:24:53 +0800

I reviewed the implementer's guide again,especially on 4.2.

Indeed, it tell us how to  infer the TS from the SN,with 
following words 

"  When no TS bits are transmitted in the compressed header, the encoded
   TS value (scaled or unscaled) is to be decompressed assuming a linear
   extrapolation from the SN, i.e. delta_TS = delta_SN * default-slope.

   Section 5.7 defines the potential values for default-slope as:

     If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
     compression (see section 4.5.3), and default-slope(TS) = 1.

     If value(Tsc) = 0, the Timestamp value is compressed as-is, and
     default-slope(TS) = value(TS_STRIDE). "

  But above words has a precondition: TS always change continuously with

every RTP packets. For video packets ,vedio frame could divide into several

RTP packets to increase robustness.

     So the guide seems not cover the my puzzle.

     Hope to share your ideas. 

BR
LI JING

======= 2005-09-14 22:10:36 you wrote=======

>>     Your any ideas would be appreciated.

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

                    致
礼！
				 
               LI_JING
               [email-masked]
					2005-09-15 

TEL: 029-87916666-6075

大唐移动通信设备有限公司西安分公司
陕西省西安市翠华路275号（710061）

---

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Thu, 15 Sep 2005 08:31:14 +0200

What you need to do is to set TS_STRIDE=0, and when the TS changes, you need to update the TS_OFFSET by sending an _unscaled_ timestamp. And as soon as you have established the new TS_OFFSET, you can go back to sending UO-0 packets until the next change in TS.

So basically, your ability to send type 0 packets depend on how many packets your TS remains constant and what your optimistic approach condition is.

BR,
	Kristofer

> Sent: den 15 september 2005 08:25
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: rohc
> Subject: RE: [rohc] about TS in Type zero for RTP profile ?
> 
> 
>