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

[Qiaobing Xie <Qiaobing.Xie at motorola.com>]

Hi, Sassan,

Whether to call it "internal" or not is all relative IMO and I believe I fully understand 
the sampling rate manipulation part of the codec operation (I've read your paper :-)). Of 
cause I would appreciate it if you could point out to me if I still got something wrong.

Using a single 16k tiemstamp rate is fine with me, although it may seem strange in some 
cases as I mentioned earlier, but I don't see a better alternative here.

regards,
-Qiaobing

sassan.ahmadi at nokia.com wrote:

> 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