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

On 5 Oct 2011, at 18:20, Roman Shpount wrote:
> On Wed, Oct 5, 2011 at 7:00 AM, Neil Stratford <neils@belltower.co.uk> 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.

I'm not convinced that exposing all possible codec parameter combinations is an appropriate goal. There is simply too much flexibility present with many of the codecs, especially in combination, for the signalling to be reasonable if all the flexibility is exposed. Better, I think, for the browser to expose a set of known-reasonable combinations, and parameter ranges, from which the most appropriate choice is picked.

> 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Colin Perkins
http://csperkins.org/