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

Roman Shpount <> Wed, 05 October 2011 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DC101F0C52 for <>; Wed, 5 Oct 2011 10:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.647
X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9dNE1oMGcfiP for <>; Wed, 5 Oct 2011 10:17:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5E50321F8CB1 for <>; Wed, 5 Oct 2011 10:17:47 -0700 (PDT)
Received: by gyd12 with SMTP id 12so2169132gyd.31 for <>; Wed, 05 Oct 2011 10:20:55 -0700 (PDT)
Received: by with SMTP id t4mr15029489yhm.121.1317835255592; Wed, 05 Oct 2011 10:20:55 -0700 (PDT)
Received: from ( []) by with ESMTPS id n67sm3274696yhi.9.2011. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Oct 2011 10:20:54 -0700 (PDT)
Received: by qadb12 with SMTP id b12so1822374qad.31 for <>; Wed, 05 Oct 2011 10:20:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id q10mr20081765pbb.37.1317835253291; Wed, 05 Oct 2011 10:20:53 -0700 (PDT)
Received: by with HTTP; Wed, 5 Oct 2011 10:20:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 05 Oct 2011 13:20:50 -0400
Message-ID: <>
From: Roman Shpount <>
To: Neil Stratford <>
Content-Type: multipart/alternative; boundary="bcaec5314ad12518de04ae906eee"
Subject: Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Oct 2011 17:17:53 -0000

On Wed, Oct 5, 2011 at 7:00 AM, Neil Stratford <>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