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

[sassan.ahmadi at nokia.com]

Hi Qiaobing,

I think you are confusing people by frequently referring to the internal sampling frequency of VMR-WB. As I said in my previous reply, AMR-WB has the same internal frequency and NO where in RFC 3267 it is mentioned or referred.

The fact that VMR-WB is capable of processing narrowband (8 kHz) or wideband (16 kHz) media does not have anything to do with its internal sampling frequency. 

This confusion is caused by lack of knowledge about VMR-WB and its operation.

Please see my reply to Magnus on the same topic as it may clear this issue.

Regards

-Sassan Ahmadi


> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org]On 
> Behalf Of ext
> Qiaobing Xie
> Sent: Thursday, September 09, 2004 12:55 AM
> To: Magnus Westerlund
> Cc: csp at csperkins.org; avt at ietf.org; Ahmadi Sassan (Nokia-TP/SanDiego)
> Subject: Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: 
> sampling rate
> 
> 
> Hello, Magnus,
> 
> Magnus Westerlund wrote:
> 
> > Hi Sassan,
> > 
> > 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. 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.
> 
> Right on! You nailed the issue perfectly.
> 
> > 
> > To avoid the unnecessary function I would propose that VMR-WB only 
> > defines 16kHz as RTP timestamp rate. 
> 
> Agreed. This would effectively remove the interoperability 
> barrier you pointed out above.
> 
> My only concern is that this may create some interesting 
> situations. Let's consider an 
> example - original speech of 8k rate is passed to vmr-wb 
> encoder and the decoder is set to 
> output speech at 8k rate.
> 
> Here, we would then have:
> 
>   - source sampling rate = 8k
>   - actually sampling rate of the bit stream sent over RTP = 12.8k
>   - sampling rate output from vmr-wb = 8k
>   - RTP header timestamp rate = 16k!!!
> 
> I am not sure this will cause any problem, but it seems strange.
> 
>  > 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. 
> 
> I, too, would like to first see some use case here. If we 
> don't know how the information is 
> going to be used, it makes no sense to specify a mechanism in 
> RTP or even SDP to pass it around.
> 
> regards,
> -Qiaobing
> 
 

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