[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

Colin,

I think this is all because of VMR-WB's unique built-in "rate normalization" capability. This sort of makes the codec operation __rate independent__, as already talked about repeatedly in this discussion. Personally, I think this as an advancement in codec design. Among other advantages, this allows some simplification in session setup signaling, additional flexibility in sys architecture, and enhanced interoperability, and people in 3GPP2 want to take advantage of this.

Now the question is how to effectively support this in the payload (I think the current draft has crippled this capability).

regards,
-Qiaobing

Colin Perkins wrote:

On 10 Sep 2004, at 20:17, sassan.ahmadi at nokia.com wrote:

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. 

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.

Looks like that we have reached to an agreement. I will include some text in the draft to address your point, something like " although a 16000 Hz RTP clock rate is used for VMR-WB, the injection and processing of 8000 Hz narrowband media is also allowed and can be handled by VMR-WB decoder". 

We have not reached agreement on this.

Colin



_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt