Re: [codec] #8: Sample rates?

[stephen botzko <[e-mail]>]

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