[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: sampling rate
Hi
Hari,
Yes,
both narrowband and wideband operation of VMR-WB under cdma2000 Service Option
62 have been specified by 3GPP2 C.S0052-0 v1.0 (see Section 2 of this
specification).
Narrowband processing has been one of the mandatory
requirements of the cdma2000 wideband speech codec (see 3GPP2 S.R0080 v1.0 for
more details).
Furthermore, VMR-WB has been proposed as wideband and narrowband
multimode codec for 3GPP2 multimedia streaming and messaging
applications.
Moreover, the use of narrowband processing in conjunction with narrowband
processing is optional. You may opt not to use narrowband processing of VMR-WB,
but it does not mean that this feature should not be specified in the
RFC.
I
believe using one RTP timestamp of 16000 Hz and the new optional MIME parameter
would resolve all of the confusions.
Regards
-Sassan Ahmadi
At 02:21 PM 9/9/2004,
sassan.ahmadi at 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 at 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 at ietf.org
https://www1.ietf.org/mailman/listinfo/avt