RE: Interpretation intervals for TS encoding
Lars-Erik Jonsson (LU/EAB <lars-erik.jonsson <at> ericsson.com>
2006-06-12 09:21:46 GMT
Ghyslain, Endre, others,
I fully agree with your conclusions.
This paragraph originates from the initial individual version
of this draft, dated November 2001. It had its own section
called "4.2. Transition to timer-based compression", but the
text was later incorporated into the section about
interpretation intervals (added in rev 02, Oct 2002).
When now looking into this again, I agree with the conclusion
that 1) is clear from section 5.7 of RFC 3095. It is a mystery
to me how and why anyone would interpret this differently.
>From the mail archive we can find some discussions with
interpretations in line with the questioned paragraph in the
implementer's guide, but without arguments *why* that
should be needed (see thread titled "What is p value for TS?"
from September-October 2002).
So, I agree with the suggestion to remove this paragraph from
section 4.3 of the current draft. Since I have not seen any
objections, I will do this change to the draft right now.
/L-E
> Hi Endre,
>
> It strikes me that the text that you are addressing in
> draft-ietf-rohc-rtp-impl-guide-19.txt is rather old, it probably
> comes from a version prior to this draft becoming a WG draft.
> Therefore I think it is sound to revisit it.
>
> I think that this sums up to answering to the following:
>
> 1) When does the HD start using TB decoding
> 2) What happens to the interpretation interval during
> transitions between Scaled TS encoding and TB encoding?
> (i.e. does the HC have to send more bits for some reason?)
>
> My understanding is that if the answer to 1) is clear, than 2) is
> irrelevant as, as you wrote yourself, the compressor will use a
> reference that it has confidence that the decompressor has,
> and it will use the correct interpretation interval as per
> section 4.3.
>
> The answer to 1) is also clear, as you wrote yourself again, i.e.
> the decompressor uses TB decoding as soon as it sees
> TIME_STRIDE>0, as per section 5.7:
>
> TS: The compressed RTP Timestamp value.
>
> If value(TIME_STRIDE) > 0, timer-based compression of the
> RTP Timestamp is used (see section 4.5.4).
>
> So, as a result of your comment, my proposal is to remove the
> last paragraph in the text of section 4.3, i.e.:
>
> Since two different p-values are used, the compressor must
> take this into account throughout the process of enabling
> timer-based compression (see section 4.8 of this document).
> During transition from window-based compression to timer-
> based compression, it is thus necessary that the compressor
> keep k large enough to cover both interpretation intervals.
>
> as it is not relevant (besides that it was in itself rather
> unclear in its own magical ways!).
>
> Thanks
>
> /Ghyslain
>
> Endre Szalai (IJ/ETH) wrote:
>> Hi ROHCers,
>>
>> reading the "Corrections and Clarifications to RFC 3095"
>> (draft-ietf-rohc-rtp-impl-guide-19.txt) document, the last paragraph
>> of section 4.3 is not really clear for me.
>>
>> "Since two different p-values are used, the compressor must take this
>
>> into account throughout the process of enabling timer-based
>> compression (see section 4.8 of this document).
>> During transition from window-based compression to timer-based
>> compression, it is thus necessary that the compressor keep k large
>> enough to cover both interpretation intervals."
>>
>> When the HC wants to use timer based compression, it will start
>> sending a positive TIME_STRIDE value (after of course a valid CLOCK
>> option is propagated from the HD). If the HD receives such a packet,
>> it will switch to timer based compression immediately. This means,
>> that the HD will use the value for "p" as specified in section 4.5.4
>> in RFC 3095) when decompressing received TS bits (if any), and not
>> the
>
>> "p"
>> value for the W-LSB encoding.
>>
>> Why and how the HC should consider the "p" value for W-LSB encoding
>> in
>
>> this case ?
>>
>> The HC keeps track of all possible references the HD may have, and
>> the
>
>> HC will simply apply timer based compression with the proper "p"
>> value. Since HD will use the same "p" value (TIME_STRIDE > 0), how
>> could the 2 different interpretation intervals interfere ?
>>
>> Could someone give a clarification on this (maybe an example) ?
>>
>> Thanks,
>> Endre
RSS Feed