Subject: RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: sampling rate

From: [email-masked]
Date: Thu, 9 Sep 2004 14:21:05 -0700

Hi Magnus,

Please find my response to your comments below:

> Based on what you write in the previous mail. It seems that the only 
> reason for using different RTP timestamp rate between 8000 
> and 16000 Hz 
> is to indicate the sampling rate of the source material. 

This is correct. The only reason that I defined two RTP clock rates was to differentiate between narrowband and wideband media in the encoder and the decoder.

If your original media is narrowband, since the decoder does not care about the input sampling frequency, you generate a wideband output, unless somehow the decoder is informed. I initially thought that this could be achieved by the RTP clock rate.

> If the codec 
> does not need any indication at all if the source material is 
> 8k or 16k 
> then, I think the usage of different RTP timestamp rates is creating 
> unnecessary interoperability barriers. The barrier is that 
> one actually 
> needs to indicate the rate of the source material, and cope with RTP 
> timestamp switching.

Agreed. 

> To avoid the unnecessary function I would propose that VMR-WB only 
> defines 16kHz as RTP timestamp rate. If there is desire to have 
> knowledge about source sampling rate that will be used, then 
> one should 
> define a parameter that indicates that. But I am not certain 
> it really 
> is needed. Such a parameter is declarative and does not matter in 
> regards to any interoperability and can be ignored without 
> consequence. 
> Or is it something else about the codec that prevents this? I 
> would not 
> think so as the file format can be fine without an explicit 
> indication 
> of the source sampling rate.
 
This is a good suggestion. We need to define the RTP timestamp as 16000 Hz to maintain compatibility with RFC 3267 and the AMR-WB interoperable mode. But it is still important to have a declarative MIME parameter "sampling-frequency" for the RTP payload to inform the encoder and decoder when a narrowband media is processed. That parameter is going to be optional and if not present that output of the decoder will be wideband regardless of the input sampling frequency.

Now if someone injects some narrowband tones or announcements, that does not affect the RTP timestamp and does not affect the decoding.

If you agree, I make the following changes to the VMR-WB I-D:

1- Only one RTP timestamp clock rate of 16000 Hz is used throughout the I-D.
2- A new optional MIME parameter "sampling-frequency" is defined with the following description:

sampling-frequency:    The input/output media sampling frequency. Permissible values are 8000 (narrowband) or 16000 (wideband, default). If 16000 or not present, indicates that the input/output media sampling frequency is 16000 Hz.

The reason that I used the term media is that the input to the encoder or the decoder output could be speech, audio (e.g., music, tone, etc.).

If this is acceptable, I will make the necessary changes in the I-D and submit a new draft shortly.

Regards

-Sassan Ahmadi

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Sep 2004 08:52:57 +0200

Hi Sassan,

see below:

[email-masked] wrote:

>>is needed.

[snip]

> 1- Only one RTP timestamp clock rate of 16000 Hz is used throughout the I-D.

I think this is a good change that simplify things.

> sampling-frequency:    The input/output media sampling frequency. Permissible values are 8000 (narrowband) or 16000 (wideband, default). If 16000 or not present, indicates that the input/output med…

As I indicated above, I am not certain what the usage of knowing the 
sampling frequency of the source material. Can you please provide some 
use cases when this actually is useful information. If you can motivate 
why there is good reason to have this information I don't see a problem 
of doing as you suggest. However I like to avoid defining things that 
are not really useful.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 10 Sep 2004 15:28:15 +0800

Hi, Magnus/Sassan,

<snip>

> I think this is a good change that simplify things.

Agreed. I'd also like to suggest that some new text be added to capture the essence of this 
sampling rate discussion... we don't want further readers of the RFC to get the wrong 
impression that only 16k speech/music can be passed through vmr-wb codec. Some explanation 
over why only 16k timestamp rate is defined for the payload and how one can still work with 
8k media would definitely help, especially to those who are unfamiliar with the codec 
internal operation.

regards,
-Qiaobing

---

From: Harinath Garudadri <[email-masked]>
Date: Thu, 09 Sep 2004 15:46:11 -0700

At 02:21 PM 9/9/2004, [email-masked] wrote:
>This is correct. The only reason that I defined two RTP clock rates was to 
>differentiate between narrowband and wideband media in the encoder and the 
>decoder.
>
>If your original media is narrowband, since the decoder does not care 
>about the input sampling frequency, you generate a wideband output, unless 
>somehow the decoder is informed. I initially thought that this could be 
>achieved by the RTP clock rate.

Hi Sassan,
I am quite confused by the narrowband operation of VMR-WB. Based on the 
discussions here and in 3GPP2, it is not clear how the D/A convertor and 
other circuitry will handle analog output to the speaker at 16 kHz or 8 kHz 
appropriately. I believe this applies to both streaming and storage of 
VMR-WB data.

Can you tell us if 3GPP2 recommends usage of VMR-WB in narrowband mode? 
Either for circuit switched operation of packet switched services? It is 
not clear from the references in the 3GPP2 IETF dependency list if 
narrowband operation of VMR-WB codec is a requirement.

If narrowband operation of VMR-WB is not a requirement, it will be lot 
cleaner to restrict this draft to wideband only. This would address 
concerns raised by Magnus, Qiaobing and others. Thanks,

hari.

>This is a good suggestion. We need to define the RTP timestamp as 16000 Hz 
>to maintain compatibility with RFC 3267 and the AMR-WB interoperable mode. 
>But it is still important to have a declarative MIME parameter 
>"sampling-frequency" for the RTP payload to inform the encoder and decoder 
>when a narrowband media is processed. That parameter is going to be 
>optional and if not present that output of the decoder will be wideband 
>regardless of the input sampling frequency.
>
>Now if someone injects some narrowband tones or announcements, that does 
>not affect the RTP timestamp and does not affect the decoding.
>
>sampling-frequency:    The input/output media sampling frequency. 
>Permissible values are 8000 (narrowband) or 16000 (wideband, default). If 
>16000 or not present, indicates that the input/output media sampling 
>frequency is 16000 Hz.
>
>The reason that I used the term media is that the input to the encoder or 
>the decoder output could be speech, audio (e.g., music, tone, etc.).
>

Dr. Hari Garudadri
Qualcomm Inc.
work    : 858-651-6383
mobile : 858-229-2801

---

From: Colin Perkins <[email-masked]>
Date: Sat, 11 Sep 2004 13:01:23 +0100

On 9 Sep 2004, at 22:21, [email-masked] wrote:
> Permissible values are 8000 (narrowband) or 16000 (wideband, default). 
> If 16000 or not present, indicates that the input/output media 
> sampling frequency is 16000 Hz.
>
> The reason that I used the term media is that the input to the encoder 
> or the decoder output could be speech, audio (e.g., music, tone, 
> etc.).
>

I object to both changes. Audio payload formats use the sampling rate 
of the original data to derive their timestamp; if the input to the 
codec is 8kHz audio, the sampling rate should be 8000.

Doing otherwise is inconsistent with all other audio formats (except 
G.722 which uses 16kHz for compatibility with a mistake in RFC 1890).

Colin

---

From: Colin Perkins <[email-masked]>
Date: Sat, 11 Sep 2004 13:05:33 +0100

On 10 Sep 2004, at 08:28, Qiaobing Xie wrote:

> Agreed. I'd also like to suggest that some new text be added to 
> capture the essence of this sampling rate discussion... we don't want 
> further readers of the RFC to get the wrong impression that only 16k 
> speech/music can be passed through vmr-wb codec. Some explanation over 
> why only 16k timestamp rate is defined for the payload and how one can 
> still work with 8k media would definitely help, especially to those 
> who are unfamiliar with the codec internal operation.

This is an RTP payload format issue; what the codec does internally is 
not relevant. If the input to the codec is 8kHz, the RTP timestamp rate 
should be 8kHz, as with all other RTP payload formats.

Colin