Re: [codec] #8: Sample rates?

[stephen botzko <[e-mail]>]

This would make the signaling more complicated - personally I am not
convinced it is worth it.

I think a better avenue is to bound overall complexity, and to focus on
dynamically adapting to network conditions (as opposed to dynamic complexity
management).

You can't dynamically negotiate complexity in many scenarios anyway - for
instance it makes no sense if you are using multicast.

Stephen Botzko


On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <[e-mail]>wrote:

>  Hi,
>
>
>
> It still might make sense to negotiate the maximal supported sampling rate
> via SDP or, if possible, to select one out of multiple sampling rates, if
> the audio receiver can cope with multiple rates well. The internal sampling
> frequency of the codec NEEDS NOT to be affected by the external sampling
> frequency.
>
>
>
> However, the decoder might want to signal to the encoder that the decoding
> is requiring too many computational resources and that a less complex coding
> mode (or a lower sampling frequency) should be taken.
>
>
>
> Christian
>
>
>
>
>
> ---------------------------------------------------------------
>
> Dr.-Ing. Christian Hoene
>
> Interactive Communication Systems (ICS), University of Tübingen
>
> Sand 13, 72076 Tübingen, Germany, Phone [phone]
> http://www.net.uni-tuebingen.de/
>
>
>
> *From:* stephen botzko [mailto:[e-mail]]
> *Sent:* Tuesday, April 13, 2010 3:21 PM
> *To:* Kevin P. Fleming
> *Cc:* Christian Hoene; [e-mail]
> *Subject:* Re: [codec] #8: Sample rates?
>
>
>
> Though I generally avoid MAY, this could be a case where it makes sense.
>
> Something like:
>
> CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to
> optimize audio quality.
>
> This is free of any technology assumption about *how* the acoustic
> bandwidth is reduced.  The MAY indicates that it is permissible.  But if the
> CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we are
> making no statement that it SHOULD (or SHOULD NOT).
>
> Kevin is distinguishing dynamic changes to the sample rate (for bandwidth
> management) from multiple fixed sample rates; and I agree that is a key
> distinction.
>
> I have not heard any clear application requirement for more than one fixed
> sampling rate.  Though if there is such a requirement, IMHO we would have to
> negotiate the rate within SDP in the usual way, and it would affect the RTP
> timestamps, jitter buffers, etc.  G.722.1 / G.722.1C is one precedent - it
> is the same core codec, but can run at two different sample rates
> (negotiated by SDP).
>
> Stephen Botzko
>
> On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming <[e-mail]>
> wrote:
>
> stephen botzko wrote:
>
> > Dynamically changing sample rates on the system level adds some
> > complexity for RTP, since the timestamp granularity is supposed to be
> > the sample rate.
>
> And jitter buffers, and anything else that is based on timestamps and
> sample rates/counts. If the desire is for the codec to be able to change
> sample rates to adjust to network conditions, then I agree with
> Stephen... the 'external' sample rate (input to the encoder and output
> from the decoder) should be fixed, and this is what would be negotiated
> in SDP and used for RTP timestamps. The codec can downsample in the
> encoder and upsample in the decoder if it has decided to transmit fewer
> bits across the network.
>
> --
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> skype: kpfleming | jabber: [e-mail]
> Check us out at www.digium.com & www.asterisk.org
>
>
>