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

From: [email-masked]
Date: Thu, 9 Sep 2004 14:21:08 -0700

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: [email-masked] [mailto:[email-masked]]On 
> Behalf Of ext
> Qiaobing Xie
> Sent: Thursday, September 09, 2004 12:55 AM
> To: Magnus Westerlund
> Cc: [email-masked]; [email-masked]; 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 10 Sep 2004 15:40:10 +0800

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

---

From: Colin Perkins <[email-masked]>
Date: Sat, 11 Sep 2004 13:02:30 +0100

On 9 Sep 2004, at 22:21, [email-masked] wrote:
> 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.

Exactly. And it uses the RTP timestamp in the standard manner.

> 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.

Exactly. This is why the RTP timestamp rate should be either 8kHz or 
16kHz, depending on the input source.

Colin

---

From: Randell Jesup <[email-masked]>
Date: 12 Sep 2004 03:11:09 -0400

Colin Perkins <[email-masked]> writes:
>Exactly. This is why the RTP timestamp rate should be either 8kHz or 16kHz,
>depending on the input source.

        Well, this (having the RTP timestamp rate be the sampling
frequency) isn't the case for a number of non-audio RTP streams (such as
video streams, which typically use 90000 regardless of pixel, line, or
frame rate), so there's precedent for a "fixed" timestamp rate.

        There's no reason all the audio codecs couldn't have used
any value (even 90000); it's convention that it be the sampling rate.
It avoids a multiply/divide to convert a timestamp into a sample-time,
and there's no error involved (which there would be if sample and
timestamps didn't convert cleanly), but that's about it.

        Having timestamp rate be sampling rate can allow implicit
determination of the packetization-interval, but that should be provided
separately anyways.  This implicit packetization-interval only adds
something if the packetization-interval is non-static within a session (and
most if not all audio codecs disallow that excluding silence-supression).

        Not that such things exist currently, but playing devil's advocate,
one could create a codec that takes a variable-sampling-rate input
depending on current conditions.  (Similar to video codecs that vary the
frame rate, resolution, and/or bitrate within a stream.)

        The important thing about timestamps is that they provide
*enough* resolution to accurately know when to play the date contained
within.  For example, for professional audio work, one might have a real
need for an N-times multiple of the sample rate.  The reason is that
sample rate defines the bandwidth of the signal, but the timing of the
signal required might be tighter, such as if it needs to be mixed with
other streams (especially other higher-bandwidth streams).  Back in the
Amiga video days we had a ~1400x480i video mode, even though NTSC
monitors were lucky to show anything approaching 640.  The reason was
that fine control of where a signal started (such as the curve of a
'C') produced better, smoother diagonals and curves.  (anti-aliasing of
a sort, if you like.)

        While I don't see a _need_ for a multi-rate audio codec to use
a fixed timestamp rate, I also don't see a _need_ for the timestamp rate
to be the sample rate for audio, other than tradition.  Perhaps I'm
missing something.

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Thu, 23 Sep 2004 10:11:46 +0200

> frame rate), so there's precedent for a "fixed" timestamp rate.

Video has different timestamp rules, so that doesn't apply. MPEG audio 
uses a fixed rate, for compatibility with other MPEG content. It's 
problematic when building a multi-format media tool, since unlike other 
codecs it doesn't use the sampling rate.

> frame rate, resolution, and/or bitrate within a stream.)

Sure, one could. I don't think it would be a good idea though: the 
convention that the sampling rate equals the timestamp rate is very 
helpful when building multi-format systems.

> to be the sample rate for audio, other than tradition.  Perhaps I'm

It's a very useful convention, not a requirement. I don't see anything 
in this codec that justifies breaking that convention.

Colin

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 24 Sep 2004 20:16:45 +0800

Hi, Colin,

Colin Perkins wrote:

<snip>
> helpful when building multi-format systems.

The practical need in 3GPP2 (and possibly other systems) to feed mixed sampling rate input 
(depending on conditions in the call flow) to vmr-wb codec in a single session has already 
been explained in this discussion. I think it is quite equivalent to the scenario depicted 
by Randell.

regards,
-Qiaobing

---

From: Randell Jesup <[email-masked]>
Date: 24 Sep 2004 15:33:15 -0400

Colin Perkins <[email-masked]> writes:
>>         Not that such things exist currently, but playing devil's
>> advocate, one could create a codec that takes a variable-sampling-rate
>> input depending on current conditions.  (Similar to video codecs that
>> vary the frame rate, resolution, and/or bitrate within a stream.)
>
>convention that the sampling rate equals the timestamp rate is very helpful
>when building multi-format systems.

        Actually, such a codec could be VERY useful.  One of the big
problems with audio codecs nowadays is that they're situation-specific.
A "good" codec for speech is not a good codec for music, and a good music
codec may not do as well at covering packet loss and uses a lot more
bandwidth when the stream has plain speech.

        You could define a codec that generates (effectively) two or more
internal encodings depending on the audio data at that point in time
(perhaps switching per-packet or even more often), and could switch the
input sample rate to support that on a frame-by-frame basis.  The likely
logical solution for that would be to have the decoder output the highest
frequency that could be needed, and to use that same rate for all the RTP
timestamps, regardless if the encoder was currently doing the (say) 32KHz
sampling or 16KHz or 8KHz sampling.

        Such a codec might be a nice thing - it'd use extra bandwidth
only when needed.  Music-on-hold would sound good (though it might handle
packet loss less smoothly), and speech would use less bits and might be
more robust to packet loss (such as with iLBC).

        By insisting on the point that "timestamp rate == sample rate",
you close off a series of possibilities such as this, or make them much
more painful (like requiring dual synchronized streams at different
rates), or frequent (expensive) renegotiations of RTP stream parameters.

>It's a very useful convention, not a requirement. I don't see anything in
>this codec that justifies breaking that convention.

        And I guess that's the crux - you see it as a convention to be
followed unless there's a VERY strong argument.  I and others seem to feel
that it's at most a minor convention which gives minimal benefit, and given
a reasonable argument that there's some advantage breaking the convention
that we should do so.