Subject: [rohc] Question about TS encoding and packet choice

From: "LI_JING" <[email-masked]>
Date: Tue, 6 Dec 2005 12:44:31 +0800

Dear Rohcers,

       In  4.5.3  Scaled RTP Timestamp encoding  , page29 of  Rohc protocol ,
 following  words as 

 "In the case of video, ........ Note that a video frame is often divided into
several RTP packets to increase robustness against packet loss. In this case 
several RTP packets will carry the same TS."

      My question is :
1>  Is it possible for a packet stream with changed TS Stride ? Or, can we draw a conclusion
that if the TS Stride of the packet stream changed, the the packet stream  in fact changed to another kind of packet stream ?

2> If  answer for 1> is YES, how to differ following difference ?　    
    2.1>  as 4.5.3 words said, two consecutive packets use same TS, so TS stride here change to Zero. 
    2.2>  In fact, two consecutive packet use different TS,and TS stride here change to a value(not equal to zero) ,which not equal to privous packets'  fixed TS stride .In a word , 
TS stride value actual changed.

3>If  answer for 1> is NO,   how to understand  above words in 3.5.3 ?
    When TS stride " change to zero",we don't think it really changed .Is it right ?

      Furthermore, packet choice is a real problem.
      For Ts changed as above 3.5.3 words, how to transfer this "same TS  and zero value TS stride" to decompressor? What is proper packet type and/or extension type ? 
     In my opinion ,ext3 has to be the choice to send the same TS and changed TS stride.Refered with 4.1 in <<Implementer's Guide-15>>,　TS must be encoded with WLSB and SDVL.
    Here I feel no use to use WLSB for a "new" TS(same as privous packet TS).SDVL encoding is 
enough and practical.
    What's more, words in above 3.5.3 give a regular change pattern for video frames.Is it effective approach that we have to send almost every packet with ext3 ? It's awful I know.

     In a summary, for video frames,how to cope with its TS change pattern and use which kind
of packet type and extension type is proper ?

     I hope to share your ideas.
　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　
BR
LI JING  
TEL: (+86)029-87916666-6075
Mail: [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: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 6 Dec 2005 13:19:37 +0100

Li Jing,

See inline for my comments.
Hope this helps.

Regards,

/Ghyslain

[email-masked] wrote:
> Dear Rohcers,
> 
>        In  4.5.3  Scaled RTP Timestamp encoding  , page29 of
> Rohc protocol ,  following  words as
> 
>  "In the case of video, ........ Note that a video frame is
> often divided into several RTP packets to increase robustness
> against packet loss. In this case several RTP packets will
> carry the same TS."
> 
>       My question is :
> 1>  Is it possible for a packet stream with changed TS Stride ?

My understanding is that the increase in timestamp between two consecutive packets is expected to be an integral multiple of some unit, i.e. the TS_STRIDE, but that the RTP protocol does not mandate anything more then that the TS reflects the sampling instant of the first octet of the data grouped as a logical unit, and that this be derived from a monotonically and linearly increasing clock. When data is sampled is up to the application.

In other words, while a change in the TS_STRIDE is not likely expected in general, it is not impossible either.

> Or, can 1> we draw a conclusion
> that if the TS Stride of the packet stream changed, the the
> packet stream  in fact changed to another kind of packet stream ?

The compressor can convey a new TS_STRIDE value for the same packet flow by sending EXT-3 in a UOR-2, or by sending IR/IR-DYN packet. As long as the STATIC-DEF fields (i.e. IPv6 Flow Label, IP source and destination addresses, UDP source and destination ports, SSRC) remains unchanged, the compressor normally does not consider other changes to be a different packet stream.
 
> 2> If  answer for 1> is YES, how to differ following difference ?

See implementer's guide, section 4.4.

>     2.1>  as 4.5.3 words said, two consecutive packets use
> same TS, so TS stride here change to Zero.

My understanding is that the compressor would set TS_STRIDE to 0, and then update the offset when the TS changes in this case, using e.g. UOR2-EXT-3.

>     2.2>  In fact, two consecutive packet use different
> TS,and TS stride here change to a value(not equal to zero)
> ,which not equal to privous packets'  fixed TS stride .In a
> word , TS stride value actual changed.

Same as above.
 
>       For Ts changed as above 3.5.3 words, how to transfer
> this "same TS  and zero value TS stride" to decompressor?
> What is proper packet type and/or extension type ?

UOR2-EXT-3 can convey both a new value for TS_STRIDE and this "same TS" by sending the unscaled TS (i.e. tsc = 0)

>      In my opinion ,ext3 has to be the choice to send the
> same TS and changed TS stride.Refered with 4.1 in
> <<Implementer's Guide-15>>,　TS must be encoded with WLSB and SDVL.

Correct.

>     Here I feel no use to use WLSB for a "new" TS(same as
> privous packet TS).SDVL encoding is enough and practical.

W-lsb encoding is used for the TS to increase robustness against packet losses.

>     What's more, words in above 3.5.3 give a regular change
> pattern for video frames.Is it effective approach that we
> have to send almost every packet with ext3 ? It's awful I know.

In U/O-mode, at least n packets (corresponding to your optimistic approach) will have to be sent, in order to update the offset.
In R-mode, until an ACK is received. Yes, it's awful.
 
>      In a summary, for video frames,how to cope with its TS
> change pattern and use which kind of packet type and
> extension type is proper ?

See above. Hope it helps.
 
> 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.

---

From: "LI_JING" <[email-masked]>
Date: Wed, 7 Dec 2005 14:52:11 +0800

hi,rohcers,

     Let's we discuss further on this topic.
     Suppose there are consecutive 2 packets with same TS.
     Then compress side find No.2 packet get same TS as No.1 packet,that means TS_stride is
Zero. Then we get to use extension3 to send unscaled TS and TS_stride for No.2 packet.
     
     But for value of TS_stride here to fill in ext3, problem comes.

     In RFC3095 protocol,5.7.5, page85 for ext3, words said

    "Tsc: Tsc = 0 indicates that TS is not scaled;
    Tsc = 1 indicates that TS is scaled according to section
    4.5.3, using value(TS_STRIDE).
    Context(Tsc) is always 1. If scaling is not desired, the
    compressor will establish TS_STRIDE = 1." 

     here tell us to fill "TS_STRIDE = 1 " into ext3 for No.2 packet,because here we would
use TSC = 0;

    But, in <Implementer's guide-15>,4.7,page 10,words said
   "When a compressor uses Extension 3 to re-establish a new value for
   TS_STRIDE, it must send unscaled TS together with TS_STRIDE for some
   packets until decompressor confidence is obtained."
    
    Obviously, here TS_Strid already change to Zero.According to above
description, we have to send TS_STRIDE. I do think here it should be 
TS_STRIDE's real vaue,that is zero.

    So, how to understand above two paragraph ? 
    For scenario of "TS_stride = 0", I feel relative description isn't 
enough so far.

　　Any ideas will be appreciated.

======= 2005-12-06 20:19:37 您在来信中写道：=======

>> <<Implementer's Guide-15>>,$B!!(JTS must be encoded with WLSB and SDVL.
>
>Correct.
>

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

                    致
礼！
				 
               LI_JING
               [email-masked]
					2005-12-07 

TEL: 029-87916666-6075

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

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Wed, 7 Dec 2005 14:45:56 +0100

Hi,

Please see my comments inline.

Regards,

/Ghyslain 

> -----Original Message-----
> From: LI_JING [mailto:[email-masked]] 
> Sent: den 7 december 2005 07:52
> To: rohc
> Cc: Ghyslain Pelletier (LU/EAB)
> Subject: Re: RE: [rohc] Question about TS encoding and packet choice
> 
> hi,rohcers,
> 
>      Then compress side find No.2 packet get same TS as No.1 
> packet,that means TS_stride is Zero. Then we get to use 
> extension3 to send unscaled TS and TS_stride for No.2 packet.
>      
>      here tell us to fill "TS_STRIDE = 1 " into ext3 for No.2 
> packet,because here we would use TSC = 0;

My understanding is that the text does not say that TS_STRIDE
must be TS_STRIDE = 1 when Tsc = 0.

Rather, I believe that what the text says is that (together
with the text in section 4.7 of the implementer's guide):
o Tsc is set to 0 when TS bits in the packet are not scaled
o Tsc is set to 1 when TS bits in the packet are scaled
o if TSS = 1 (i.e the TS_STRIDE is present in the extension 3),
  then Tsc must be Tsc = 0

Then, if the compressor wants to establish a context value
for TS_STRIDE (where TS_STRIDE=1 means that scaling is not
used when TS bits are sent in formats where there is no Tsc
flag), the compressor must send TS unscaled until it is
confident that the decompressor has the new TS_STRIDE value.
In other words, when TS_STRIDE gets updated, TS must be
unscaled, and this is done for every extension 3 where
TSS = 1.
 
>     Obviously, here TS_Strid already change to Zero.According 
> to above description, we have to send TS_STRIDE. I do think 
> here it should be TS_STRIDE's real vaue,that is zero.

... and according to what I wrote above, it would be correct to set TS_STRIDE = 0 in the extension 3 in that case. That same extension 3 would set Tsc = 0 and the TS bits in the packet would not be scaled.
 
>     For scenario of "TS_stride = 0", I feel relative 
> description isn't enough so far.
> 

I hope that my answer helps. Let me know if it does not make sense
 
> >>        In  4.5.3  Scaled RTP Timestamp encoding  , page29 of Rohc 
> >> protocol ,  following  words as
> >> 
> >>  "In the case of video, ........ Note that a video frame is often 
> >> divided into several RTP packets to increase robustness against 
> >> packet loss. In this case several RTP packets will carry the same 
> >> TS."
> >> 
> >>       My question is :
> >My understanding is that the increase in timestamp between 
> two consecutive packets is expected to be an integral 
> multiple of some unit, i.e. the TS_STRIDE, but that the RTP 
> protocol does not mandate anything more then that the TS 
> reflects the sampling instant of the first octet of the data 
> grouped as a logical unit, and that this be derived from a 
> monotonically and linearly increasing clock. When data is 
> sampled is up to the application.
> >
> >In other words, while a change in the TS_STRIDE is not 
> likely expected in general, it is not impossible either.
> >
> >> that if the TS Stride of the packet stream changed, the the packet 
> >> stream  in fact changed to another kind of packet stream ?
> >
> >The compressor can convey a new TS_STRIDE value for the same 
> packet flow by sending EXT-3 in a UOR-2, or by sending 
> IR/IR-DYN packet. As long as the STATIC-DEF fields (i.e. IPv6 
> Flow Label, IP source and destination addresses, UDP source 
> and destination ports, SSRC) remains unchanged, the 
> compressor normally does not consider other changes to be a 
> different packet stream.
> > 
> >My understanding is that the compressor would set TS_STRIDE 
> to 0, and then update the offset when the TS changes in this 
> case, using e.g. UOR2-EXT-3.
> >
> >>     2.2>  In fact, two consecutive packet use different TS,and TS 
> >> stride here change to a value(not equal to zero) ,which 
> not equal to 
> >> privous packets'  fixed TS stride .In a word , TS stride 
> value actual 
> >> changed.
> >
> >Same as above.
> > 
> >>     When TS stride " change to zero",we don't think it 
> really changed 
> >> .Is it right ?
> >>
> this "same 
> >> TS  and zero value TS stride" to decompressor?
> >UOR2-EXT-3 can convey both a new value for TS_STRIDE and 
> this "same TS" 
> >by sending the unscaled TS (i.e. tsc = 0)
> >
> same TS and 
> >> changed TS stride.Refered with 4.1 in <<Implementer's 
> >> Guide-15>>,$B!!(JTS must be encoded with WLSB and SDVL.
> >
> >Correct.
> >
> >>     Here I feel no use to use WLSB for a "new" TS(same as privous 
> >> packet TS).SDVL encoding is enough and practical.
> >
> >>     What's more, words in above 3.5.3 give a regular 
> change pattern 
> >> for video frames.Is it effective approach that we have to 
> send almost 
> >> every packet with ext3 ? It's awful I know.
> >
> >In U/O-mode, at least n packets (corresponding to your 
> optimistic approach) will have to be sent, in order to update 
> the offset.
> >>      In a summary, for video frames,how to cope with its TS change 
> >> pattern and use which kind of packet type and extension type is 
> >> proper ?
> >
> 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.