Re: [codec] #8: Sample rates?

[Marc Petit-Huguenin <[e-mail]>]

On 04/13/2010 09:41 AM, Roman Shpount wrote:
> I am not sure if this was decided, but should this new CODEC support
> music encoding? If we don't plan to support music, we should probably
> stick to 16 Khz sampling rate. If we need music, I would suggest to have
> a 24 Khz (or higher sampling rate) variant. I am not sure how many
> people here care about a non-voice CODEC. For all the practical purposes
> I don't. 

I do.

> I would argue,  at least, for a fixed 16 KHz sampling rate
> CODEC variant.
> 
> P.S. On the same note, does anybody here cares about using this CODEC
> with multicast? Is there a single commercial multicast voice deployment?
> From what I've seen all multicast does is making IETF voice standards
> harder to understand or implement.

I think that would be a mistake to ignore multicast - not because of multicast
itself, but because of Xcast (RFC 5058) which is a promising technology to
replace centralized conference bridges.

> 
> P.P.S. RTCP is almost universally not implemented. The biggest VoIP
> gateway on the market does not generate RTCP. If we will rely on any
> RTCP functionality for bandwidth control it will probably be ignored.

Why is the opinion of gateway vendors relevant for an *Internet* codec?  Our
(S)AVP/RTP stack, that will implement this codec as soon we have a
specification, implements RTCP.

> ______________________________
> Roman Shpount -  www.telurix.com <http://www.telurix.com>
> 
> 
> On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     TCP is a different case, since for this we are using RTCP to signal
>     our feedback, and I don't think it has the facility you are
>     envisioning. 
> 
>     Also, I disagree with your presumption that multicast is out of
>     scope.  I don't know of any other packetization RFCs that expressly
>     rule out multicast, and multicast can be used for interactive
>     applications.
> 
>     This concept seems pretty theoretical to me.  If we need to manage
>     complexity / quality tradeoffs, why not just use profiles (as
>     AVC/H.264 does) or create a low complexity variant (like G.729A).  I
>     really don't see the need for dynamic complexity management.
> 
>     BTW, you seem to be assuming that a lower sample rate results in
>     significantly less complexity.  The savings there might not be as
>     great as you think, especially if the receiver needs to resample
>     anyway (to prevent those sound card limitations you were talking
>     about before).
> 
>     Stephen Botzko
> 
>     On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene
>     <[e-mail] <mailto:[e-mail]>> wrote:
> 
>         Hi,
> 
>          
> 
>         comments inline:
> 
>          
> 
>          
> 
>         * From: * stephen botzko [mailto:[e-mail]
>         <mailto:[e-mail]>]
>         *Sent:* Tuesday, April 13, 2010 4:56 PM
>         *To:* Christian Hoene
>         *Cc:* [e-mail] <mailto:[e-mail]>
> 
>         *Subject:* Re: [codec] #8: Sample rates?
> 
>          
> 
>         This would make the signaling more complicated - personally I am
>         not convinced it is worth it. 
> 
>         CH: It is a difficult tradeoff. However, signaling overload is
>         done in Skype.  Such as signaling might be very useful for
>         mobile devices, which want to save power and thus lower their
>         CPU clock. Or wireless IP based headphones which do not have
>         large batteries. I am thinking of signaling the states:
>         overloaded, fine, and low. That should be enough for most
>         operational cases.
> 
> 
>         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).
> 
>         CH: I just like to remind that the good old TCP does support
>         both: congestion control to adapt to network conditions and flow
>         control take into account an overloaded (=full) receiver.
> 
>         You can't dynamically negotiate complexity in many scenarios
>         anyway - for instance it makes no sense if you are using multicast.
> 
>         CH: Multicast is out of scope anyhow. We are considering an
>         interactive codec.
> 
>         CH: The conferencing scenario might be some more difficult to
>         handle but will not a big problem.
> 
>         Christian
> 
> 
> 
>         Stephen Botzko
> 
>         On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene
>         <[e-mail] <mailto:[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]
>         <mailto:[e-mail]>]
>         *Sent:* Tuesday, April 13, 2010 3:21 PM
>         *To:* Kevin P. Fleming
>         *Cc:* Christian Hoene; [e-mail] <mailto:[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] <mailto:[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.

-- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org