Subject: [rohc] Timer-based compression question

From: "Klaus Warnke" <[email-masked]>
Date: Mon, 5 Dec 2005 13:22:42 +0100 (CET)

Dear RoHClers,

a short question about timer-based compression.
The implementer's guide said: timer-based compression can be used, if the
timestamp can not be inferred from the SN. I am not an RTP guru, so I am
not quite sure about the scenario when this occurs.
Is this realistic, maybe on interactive speech, that the timestamp follows
the SN until a silent period. Than the SN stops increasing, but the TS
not.
If the next talk spurt starts, the compressor sees a jump in the TS, but
not in SN. But the TS follows the time of day, so the compressor can use
the timer-based compression (the compressor knows the clock resolution of
the decompressor). After that, the TS follow the SN linear while speaking.
Is this a correct scenario?
Should the compressor switch back to W-LSB encoding or continue
timer-based compression?
When does the decompressor should communicate its clock-resolution? Is the
feedback packet on the IR-packete a good point in time?

Best regards
-- 
Klaus Warnke
[email-masked]

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

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Mon, 5 Dec 2005 15:41:31 +0100

Hi,

> Is this a correct scenario?

In my opinion, the scenario that you describe is a fair scenario:
timer-based compression will allow the compressor to send less w-lsb
encoded bits after a silence period then it would with scaled-TS
encoding -- i.e when the TS jumps yet follows the time of the day but
when the SN shows no jump.

> Should the compressor switch back to W-LSB encoding or 
> continue timer-based compression?

Here I am not sure that I understand the question exactly as you put it.

My understanding is that TS bits are always w-lsb encoded when the TS is
sent compressed, but that the encoding method first applied to the TS is
either scaled TS encoding or Timer-based TS encoding. I assume that if a
compressor is using Timer-based TS compression -- and when it is
possible to continue doing so -- then the compressor would simply
continue with Timer-based TS compression.

> When does the decompressor should communicate its 
> clock-resolution? Is the feedback packet on the IR-packete a 
> good point in time?

It is the compressor that always decides whether Timer-based TS
compression or Scaled TS encoding is used. For the compressor to use
Timer-based TS encoding, the decompressor must have informed the
compressor of its clock resolution using the proper feedback option
prior to doing so. This means that if the decompressor wishes to use
Timer-based TS compression, then it should send back the option to the
compressor as soon as possible, so sending it as feedback for (one or
more of) the initial IR packet(s) would be correct praxis. Note however
that despite this, the decompressor still has no guarantee that a
compressor implementation will switch to Timer-based TS compression ...

As a side note, my understanding is that Timer-based compression
provides very little gains compared to Scaled TS encoding, i.e some bits
may be saved for some packets only -- for example in the scenario you
describe above.

Best regards,

/Ghyslain

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Klaus Warnke
> Sent: den 5 december 2005 13:23
> To: [email-masked]
> Subject: [rohc] Timer-based compression question
> 
> Dear RoHClers,
> 
> The implementer's guide said: timer-based compression can be 
> used, if the timestamp can not be inferred from the SN. I am 
> not an RTP guru, so I am not quite sure about the scenario 
> when this occurs.
> Is this realistic, maybe on interactive speech, that the 
> timestamp follows the SN until a silent period. Than the SN 
> stops increasing, but the TS not.
> If the next talk spurt starts, the compressor sees a jump in 
> the TS, but not in SN. But the TS follows the time of day, so 
> the compressor can use the timer-based compression (the 
> compressor knows the clock resolution of the decompressor). 
> After that, the TS follow the SN linear while speaking.
> Should the compressor switch back to W-LSB encoding or 
> continue timer-based compression?
> When does the decompressor should communicate its 
> clock-resolution? Is the feedback packet on the IR-packete a 
> good point in time?
> 
> Best regards
> --
> Klaus Warnke