Re: Transport related API need

On 2013-08-12 10:41, Roman Shpount wrote:
> On Mon, Aug 12, 2013 at 2:38 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     On 2013-08-12 02:57, Roman Shpount wrote:
>      >If  browser implements iLBC codec, it would most likely need to
>     list iLBC
>      > codec twice, one with with codec format parameter mode=20 and another
>      > with format parameter mode=30. Here is an example:
>      >
>      > m=audio 49120 RTP/AVP 97 98
>      > a=rtpmap:97 iLBC/8000/1
>      > a=rtpmap:98 iLBC/8000/1
>      > a=fmtp:97 mode=20
>      > a=fmtp:98 mode=30
>
>     I haven't followed that discussion, so I don't understand why. Is this
>     something specific to iLBC? And what is the use case.
>
>
> This particular example is specific to iLBC. In this particular offer,
> the party specifies that it can support iLBC with 20 and 30 ms ptimes
> and remote party can switch between those two ptimes at will be sending
> packets with different payload types.

I still don't get the purpose of this. But if this is something that is 
commonly used for iLBC I would expect browsers that support iLBC to use 
it in the offer - without any specific input from the application.

>
> The concept itself is more generic though and applies to any codec
> parameters. If you can specify the same codec with different parameters,
> you generally let the remote party know that you support receiving an
> audio codec with any of those parameter combinations and that remote
> party can switch between those parameter combinations at will by
> changing payload type. This does not apply to Opus/VP8/G.711, so if no
> other codecs are implemented this would not make a difference, but would
> be quite common otherwise. For example, listing iLBC with two different
> payload types is something I commonly see with SIP end points supporting
> this codec.
>
> P.S. All of those examples are just to point out that we would need
> constraints to provide a prioritized list of codecs with parameters,
> where codecs may repeat with different parameter values, i.e. I need a
> constraint where I would prefer Opus to iLBC 20 ms, and iLBC 20ms to
> G.729, and G.729 to iLBC 30 ms.

It seems to me that the browser is in a much better position than the 
application to prioritize between codecs in many cases. For example, the 
browser could know which of the video codecs available are HW 
accelerated, and which uses SW encoding/decoding.

> _____________
> Roman Shpount

Received on Tuesday, 27 August 2013 05:49:12 UTC