Re: [rtcweb] codec and connection negotiation
Harald Alvestrand <harald@alvestrand.no> Mon, 08 August 2011 13:09 UTC
Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2010121F8ACA for <rtcweb@ietfa.amsl.com>; Mon, 8 Aug 2011 06:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5mzp5JaTb5y for <rtcweb@ietfa.amsl.com>; Mon, 8 Aug 2011 06:08:59 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3C08921F86D8 for <rtcweb@ietf.org>; Mon, 8 Aug 2011 06:08:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 20E1039E0F5; Mon, 8 Aug 2011 15:08:14 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grt74XCAnD17; Mon, 8 Aug 2011 15:08:13 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 108D339E0BC; Mon, 8 Aug 2011 15:08:13 +0200 (CEST)
Message-ID: <4E3FE002.4060006@alvestrand.no>
Date: Mon, 08 Aug 2011 15:09:22 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Matthew Kaufman <matthew.kaufman@skype.net>
References: <4E3C377A.5090105@skype.net> <4E3C3C2C.4020808@skype.net>
In-Reply-To: <4E3C3C2C.4020808@skype.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] codec and connection negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2011 13:09:00 -0000
Trying to doodle on the opinions (the alternative lists were quite useful to clear the mind - I liked them a lot, and will return to them!) On 08/05/11 20:53, Matthew Kaufman wrote: > Now, to follow up on my previous message with a bit of opinion... > > I think we should not use SDP as the API, and we should not have the > browser implementing SDP offer-answer. > > 1. If SDP offer-answer is all that is available to the Javascript > programmer (and server programmer), it becomes very difficult to know > what the full capability set is without complex probing. This > significantly complicates the building of future innovative > applications on top of the browser as platform. Many of the current > applications that show off browser capabilities do so by using > capabilities that were already present for other reasons, and we can > expect the same innovation to occur here, if we provide the tools. This may be heretical ... but do we actually need to enumerate all capabilities? It seems to me that we'll have exactly 2 groups of capabilities: - Routine ones, which are generated automagically when saying "I want something working" - Ones needed to "show off" specific new capabilities The platforms, which are likely reusing code from outside WebRTC, may support many capabilities that are never required for any scenario (especially those that have been added over the years to support backwards compatibility in very baroque scenarios). Exposing those will just add clutter, not add quality. The "show-offs" will be capable of probing. > > 2. Using SDP offer-answer has the advantage of reusing all the IETF > standards work that occurs to define SDP when a new codec comes along. > But it also has the *disadvantage* of having to wait for the IETF to > produce these standards, which may be incomplete, or unable to control > parameters which are necessary for web applications. Hmmm.... since when have people *actually* waited for the IETF process to finish before starting to use newly defined capabilities? This may argue for looking again at the IANA procedures for SDP, and institute something like the "provisional registries" that were introduced for email/web. > > 3. Anything that is missing in SDP (example: forcing the Opus codec to > "music" mode for encoding) will still need to be exposed as a > Javascript API on the encoder. Thus we end up with a mix of > possibly-conflicting settings that are adjusted via the explicit API > and the opaque SDP API. Won't these be things people want in SDP too? See above. > > 4. Other work in browsers (like recording camera and microphone to > disk) will require the ability to directly control the encoders. If > these APIs exist then there will definitely be conflicting settings. > What happens if you feed in an SDP answer that requires VP8 encoding > and then set the encoder to H.264 mode via the Javascript? Transcoding? :-) The same problem exists today when trying to use cameras for multiple things concurrently. > > > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >
- [rtcweb] codec and connection negotiation Matthew Kaufman
- Re: [rtcweb] codec and connection negotiation Matthew Kaufman
- Re: [rtcweb] codec and connection negotiation Parthasarathi R (partr)
- Re: [rtcweb] codec and connection negotiation Bernard Aboba
- Re: [rtcweb] codec and connection negotiation Sohel Khan
- Re: [rtcweb] codec and connection negotiation Henry Sinnreich
- Re: [rtcweb] codec and connection negotiation Sohel Khan
- Re: [rtcweb] codec and connection negotiation Harald Alvestrand
- Re: [rtcweb] codec and connection negotiation Colin Perkins
- Re: [rtcweb] codec and connection negotiation Parthasarathi R (partr)
- Re: [rtcweb] codec and connection negotiation Harald Alvestrand
- Re: [rtcweb] codec and connection negotiation Paul Kyzivat
- Re: [rtcweb] codec and connection negotiation Paul Kyzivat
- Re: [rtcweb] codec and connection negotiation Bernard Aboba
- Re: [rtcweb] codec and connection negotiation Henry Sinnreich
- Re: [rtcweb] codec and connection negotiation Harald Alvestrand
- Re: [rtcweb] codec and connection negotiation Markus.Isomaki
- Re: [rtcweb] codec and connection negotiation Paul Kyzivat
- Re: [rtcweb] codec and connection negotiation Randell Jesup