Re: [codec] #8: Sample rates?

[stephen botzko <[e-mail]>]

All negotiation should be done with SDP (and should *never* be done in-band)

And the RTP transport should be robust enough to permit seamless changes to
any mode that is consistent with the negotiation (with no signaling).

The first point I think is essential.  The second reflects my own view on
how RTP packetization should be done.

Stephen Botzko

On Wed, Apr 14, 2010 at 8:08 AM, Christian Hoene <[e-mail]>wrote:

>  Hi,
>
>
>
> I am fine with dropping any SDP negotiation on codec parameters including
> sampling rate and channels. I like the idea of splitting signaling and
> transportation issues.
>
>
>
> But one question remain. We had the question on limiting the complexity for
> some kind of devices by choosing a lower sampling rate or a low number of
> channels. Shall this negotiation be done with SDP or inband?
>
>
>
> 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:* Wednesday, April 14, 2010 1:52 PM
> *To:* Roni Even
> *Cc:* Christian Hoene; [e-mail]
>
> *Subject:* Re: [codec] #8: Sample rates?
>
>
>
> Good points, thanks for clarifying..
>
> Personally I favor carrying those H.264 parameter sets on the media path,
> since there are situations (switched multipoint calls for one) where the
> timing matters.  With that use case, if reliable-but-too-late delivery
> occurs, there are decoding errors even if there is no packet loss.
>
> Though of course SDP transmission alone may be suitable for other
> applications, and it is perfectly legal to send them both ways.
>
> Stephen Botzko
>
> 2010/4/14 Roni Even <[e-mail]>
>
> Hi,
>
> Negotiation of codec parameters is not a tradition it  is needed if there
> are optional modes that the decoder can support in order to allow the sender
> to know if the receiver can receive the specific mode. If there are
> mandatory modes you may be able to provide the information in-band but this
> is not negotiation. Also note that while the signaling may use reliable
> channel the media path is not reliable and may suffer packet loss that may
> cause the loss of important parameters. We have such example in the H.264
> parameter sets where they can be carried in the SDP for reliability on
> in-band as part of the payload.
>
>
>
> Roni Even
>
>
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Christian Hoene
> *Sent:* Wednesday, April 14, 2010 1:59 PM
> *To:* 'stephen botzko'
>
>
> *Cc:* [e-mail]
> *Subject:* Re: [codec] #8: Sample rates?
>
>
>
> Hi ,
>
>
>
> comments inline:
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *stephen botzko
> *Sent:* Wednesday, April 14, 2010 4:55 AM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [codec] #8: Sample rates?
>
>
>
> When I said signaling I meant SDP, not anything in the bitstream itself.  I
> was not excluding audio bandwidth changes mid-call as part of network
> adaptation.  Though as we all agree this needs to be carefully designed.
>
> I agree it is best if the decoder does not require any knowledge of the SDP
> negotiation (or any other information beyond the RTP packet stream itself)
> in order to correctly decode the audio -- which I think is what you were
> concerned about.
>
> CH: Negotiating codec parameters with SDP has a long tradition. Take for
> example µLaw (RTP payload type 0): Here you negotiate the sampling rate.
> Also, the number of channels are negotiated for many codecs. I think
> sampling rate and number of channels can be done with SDP. However, I would
> avoid other codec specific parameters. Especially, in case of AMR the
> negotiation is quite complex should be avoided for the Internet  CODEC.
>
> Christian
>
> It would be a nice property if reducing the acoustic bandwidth also allowed
> the MIPS to be reduced, but I do not think it is a requirement;  I'd
> personally rather manage complexity with a Low Complexity profile (if that
> is really needed), since then I could keep the acoustic bandwidth (accepting
> a higher bit rate instead).
>
>
> Stephen Botzko
>
> On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz <
> [e-mail]> wrote:
>
> Koen Vos wrote:
> > Quoting "Benjamin M. Schwartz":
> >> 1. Why would high frequencies be unheard?  Cheap speakers and
> microphones
> >> have difficulties with low frequencies, but not high frequencies, and
> >> routinely go all the way up past the limit of hearing.
> >
> > Not all hardware supports arbitrary/high sampling rates.  PSTN gateways
> > don't go above 8 kHz.  Same for some mobile devices.
>
> True.
>
>
> >> 2. Why would it need to be negotiated?  For a suitably designed format,
> >> the encoder could choose not to waste bits on high frequencies without
> >> any
> >> negotiation or extra signalling.
> >
> > Without signaling, how would the encoder know that the farend decoder
> > will not take advantage of frequencies above a certain threshold?
>
> When I say signalling, I mean signalling within the codec bitstream.  The
> encoder can change its behavior based on knowledge of the receiver's
> configuration, but the bitstream does not need any extra signalling to
> indicate the change in behavior.
>
>
> >>> Signaling the bandwidth, and defining the
> >>> internal codec rate as fullband should let us lock down the RTP
> >>> timestamp
> >>> rate at 48 kHz (which I think is desirable).
> >>
> >> I do agree that having "only one mode" would be ideal, to maximize
> >> interoperability.  I wonder whether we can achieve high enough
> >> computational efficiency for this to be viable.
> >
> > Changing the RTP timestamp sampling rate causes no computational
> > complexity, does it?  Perhaps an extra multiplication for each packet or
> > so?  The point was that RTP timestamp sampling rate should disconnected
> > from the actual audio signals.
>
> Right, but Stephen also suggested "defining the internal codec rate as
> fullband".  From this, I imagined a scenario in which all (compliant) IWAC
> implementations MUST decode all IWAC streams, which always have a sampling
> rate of 48 KHz.  I think this is a great idea, to achieve really good
> interoperability.
>
> If the receiver is a PSTN gateway, then an "internal codec rate" of 8 KHz
> would presumably produce as good quality/bitrate with lower encoder and
> decoder complexity.  However, if we can make IWAC sufficiently
> low-complexity, operating at 48 KHz may be acceptable.  It will help if we
> can structure the codec so that operating at lower bandwidth is very
> efficient.  For example, it may be possible to structure a transform codec
> such that unneeded high frequencies can cheaply be zero'd on encode and
> ignored on decode.
>
> --Ben
>
>
>
>
>