Subject: RE: [rohc] encoding and compression schemes should be used for RT P TSfor Vi deo

From: "Trabelsi, Chokri (Chokri)" <[email-masked]>
Date: Tue, 20 Sep 2005 10:59:50 -0400

L-E,

Yes, I am quite familiar with the implementer's guide. There is no recommendation on what encoding/compression scheme should be used for TS for video and also no recommendation for TS_STRIDE and TIME_STRIDE. As I mentioned in my previous email there is a recommendation  in RFC-3095 to use TS_STRIDE of 160 and TIME_STRIDE of 20 msec for voice which I think a reasonable recommendation and I am looking for similar recommendation for video (MPEG-4 type).

-----Original Message-----
From: Lars-Erik Jonsson [mailto:[email-masked]]
Sent: Tue, September 20, 2005 10:40 AM
To: Trabelsi, Chokri (Chokri); [email-masked]
Subject: Re: [rohc] encoding and compression schemes should be used for
RTP TSfor Vi deo 

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: "Trabelsi, Chokri (Chokri)" <[email-masked]>
To: <[email-masked]>
Sent: Monday, September 19, 2005 10:30 PM
Subject: [rohc] encoding and compression schemes should be used for RTP 
TSfor Vi deo

>
> I am interested to know if anyone has any suggestion on what encoding and 
> compression schemes should be used for RTP TS field for Video (MPEG-4 or 
> H.263).
> -For voice, It seems the recommendation is to use the Scaled RTP TS + 
> Timer-Based Compression per RFC-3095 Section 4.5.3 and 4.5.4 and the 
> recommended value of TS_STRIDE=20 msec and TIME_STRIDE=160 seems to be 
> acceptable.
> -For video, since the video sampling rate and video frame rate are 
> variable, I am not sure if the Scaled RTP TS and Timer-Based Compression 
> can be used. If yes, anyone has a suggestion of what value of TS_STRIDE 
> and TIME_STRIDE one may consider?
>
>
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
>
> 

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

---

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Tue, 20 Sep 2005 17:22:48 +0200

Kristofer answered a similar question last week (see attachment).

/L-E

----- Original Message ----- 
From: "Trabelsi, Chokri (Chokri)" <[email-masked]>
To: "Lars-Erik Jonsson" <[email-masked]>; "Trabelsi, Chokri (Chokri)" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, September 20, 2005 4:59 PM
Subject: RE: [rohc] encoding and compression schemes should be used for RTP 
TSfor Vi deo

> L-E,
>
> Yes, I am quite familiar with the implementer's guide. There is no 
> recommendation on what encoding/compression scheme should be used for TS 
> for video and also no recommendation for TS_STRIDE and TIME_STRIDE. As I 
> mentioned in my previous email there is a recommendation  in RFC-3095 to 
> use TS_STRIDE of 160 and TIME_STRIDE of 20 msec for voice which I think a 
> reasonable recommendation and I am looking for similar recommendation for 
> video (MPEG-4 type).
>

Subject: RE: [rohc] about TS in Type zero for RTP profile ?
From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
To: <[email-masked]>
Cc: rohc <[email-masked]>
Date: Thu, 15 Sep 2005 08:31:14 +0200
List-Id: Robust Header Compression <rohc.ietf.org>

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

> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of LI_JING
> 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 ?
> 
> 
> 
> 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=======
> 
> >> 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,
> >> 
> >>     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.
> >> > *****************************************************************
> >> 
> >>   
> >> 
> >> 
> >> 
> = = = = = = = = = = = = = = = = = = = =
> 			
> 
>                     致
> 礼！
> 				 
>                LI_JING
>                [email-masked]
> 					2005-09-15 
> 
> TEL: 029-87916666-6075
> 
> 大唐移动通信设备有限公司西安分公司
> 陕西省西安市翠华路275号（710061）
> 
>