RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: sampling rate
Harinath Garudadri <hgarudad@qualcomm.com> Fri, 10 September 2004 08:08 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02123 for <avt-archive@ietf.org>; Fri, 10 Sep 2004 04:08:48 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5gWi-0000Pz-Fq for avt-archive@ietf.org; Fri, 10 Sep 2004 04:13:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5gP5-0002YS-JN; Fri, 10 Sep 2004 04:05:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Xgv-0006gO-29 for avt@megatron.ietf.org; Thu, 09 Sep 2004 18:46:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12497 for <avt@ietf.org>; Thu, 9 Sep 2004 18:46:53 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Xkr-0007Zs-64 for avt@ietf.org; Thu, 09 Sep 2004 18:51:01 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i89MkI1i004396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Sep 2004 15:46:19 -0700 (PDT)
Received: from HGARUDAD.qualcomm.com (hgarudad.qualcomm.com [129.46.75.112]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i89MkDWY013240 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 9 Sep 2004 15:46:13 -0700 (PDT)
Message-Id: <6.0.0.20.2.20040909152932.02c68918@m3.qualcomm.com>
X-Sender: hgarudad@m3.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.20 (Beta)
Date: Thu, 09 Sep 2004 15:46:11 -0700
To: sassan.ahmadi@nokia.com, magnus.westerlund@ericsson.com
From: Harinath Garudadri <hgarudad@qualcomm.com>
Subject: RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: sampling rate
In-Reply-To: <0B08EA1BF5F6304992CDC985EE02209E02A74362@sdebe002.americas .nokia.com>
References: <0B08EA1BF5F6304992CDC985EE02209E02A74362@sdebe002.americas.nokia.com>
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1
X-Mailman-Approved-At: Fri, 10 Sep 2004 04:04:24 -0400
Cc: Qiaobing.Xie@motorola.com, csp@csperkins.org, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0277767263=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3
At 02:21 PM 9/9/2004, sassan.ahmadi@nokia.com wrote: >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. 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. > > 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 >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt Dr. Hari Garudadri Qualcomm Inc. work : 858-651-6383 mobile : 858-229-2801
_______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… sassan.ahmadi
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Qiaobing Xie
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Magnus Westerlund
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Qiaobing Xie
- RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… sassan.ahmadi
- RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… sassan.ahmadi
- RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… sassan.ahmadi
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Magnus Westerlund
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Qiaobing Xie
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Qiaobing Xie
- RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Harinath Garudadri
- RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… sassan.ahmadi
- RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… sassan.ahmadi
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Qiaobing Xie
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Randell Jesup
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Magnus Westerlund
- [AVT] Open Speech Repository Alan Clark
- RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Scribano Gino-QA1087
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Qiaobing Xie
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Magnus Westerlund
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Qiaobing Xie
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Randell Jesup
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Randell Jesup
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Colin Perkins
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Qiaobing Xie
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Qiaobing Xie
- Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:… Randell Jesup