Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list

[Roman Shpount <[e-mail]>]

On Wed, Oct 5, 2011 at 7:00 AM, Neil Stratford <[e-mail]>wrote:

> I'm not sure I understand why this is such a problem. XMPP/Jingle defines
> it's own mapping, which is a common VoIP protocol that is widely supported.
> I'd much rather that the JS API is as expressive as possible in codec
> specific matters - for example even to the point of providing callbacks to
> the JS on certain codec level events, such as decoding a DTMF digit.
>
>
What we need is some way to expose all possible codec parameter combinations
to JavaScript API. MMUSIC/PAYLOAD specifications for codec typically define
CODEC parameters and how they are encoded in SDP/MIME content type, but they
fall short of defining a way to list all the capabilities. For instance,
there is no way for SILK codec to specify valid bit rates range for a given
sampling rate. This means JavaScript would need intimate knowledge of each
codec implementation in the browser in order to implement codec negotiation.
If a different codec implementation is provided by the browser (for instance
SILK codec that supports more restricted bit rates for the same sampling
rate), JavaScript will not be able to produce valid negotiation results. As
far as I can see, there are two possible solutions: better uniform
description of codec capabilities to JavaScript API or delegating at least
some portion of codec negotiation to actual codec implementation.

Again, if it's required I don't see why we can't support asymmetric codecs
> in the low level API. In my view a lot of this codec manipulation is much
> better controlled by the JS which has application specific knowledge about
> how to adapt to given situations than the browser itself. How would you
> signal to the browser to dynamically lower framerate rather than image size,
> or colour depth depending on the application use case? Giving the
> application direct control over codec parameters seems a better option.
>

I believe in current API we provide one codec with one set of parameters to
the API. We should at least be able to provide two codec groups -- one for
transmit/another to receive, with two sets of parameters. Even if we handle
all the negotiations in JavaScript, we should be able to provide the result
for both directions to the stream (may be with default value for the second
codec group to be the same as first since this is a much more common).
______________
Roman Shpount