Re: [MMUSIC] Wisdom sought: Prioritization of codecs

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 19 November 2012 06:17 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6336521F841C for <mmusic@ietfa.amsl.com>; Sun, 18 Nov 2012 22:17:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.332
X-Spam-Level:
X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPLhGI4DWpQS for <mmusic@ietfa.amsl.com>; Sun, 18 Nov 2012 22:17:49 -0800 (PST)
Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by ietfa.amsl.com (Postfix) with ESMTP id CFF2D21F8593 for <mmusic@ietf.org>; Sun, 18 Nov 2012 22:17:48 -0800 (PST)
Received: from BLU169-DS7 ([65.55.111.72]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Nov 2012 22:17:48 -0800
X-Originating-IP: [24.16.96.166]
X-EIP: [eh+oP/pH8a0F+Up+WL/UaauZ273r+0fg]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-DS717A86AC1DDB910BC700A93560@phx.gbl>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: 'Adam Roach' <adam@nostrum.com>
References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A55F78.4010603@alum.mit.edu> <50A5644F.4010809@nostrum.com>
In-Reply-To: <50A5644F.4010809@nostrum.com>
Date: Sun, 18 Nov 2012 22:18:58 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIY0NCXfQL/jr3BC5sqZUn4Hq7olwG+Ww+KAdBghisCwzAqgwK1Mx+aAqFoSRiW/U4zUA==
Content-Language: en-us
X-OriginalArrivalTime: 19 Nov 2012 06:17:48.0295 (UTC) FILETIME=[98C41170:01CDC61D]
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Wisdom sought: Prioritization of codecs
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2012 06:17:49 -0000

Adam Roach said:

"I need to catch up on CLUE before I can talk to that very much. I'd been
pretty much ignoring CLUE; but in Atlanta, it became clear that CLUE's
impact was going to seep out into every other working group in RAI."

[BA] I think it is probably correct to say that the questions asked in CLUE
are relevant to many other working groups in RAI, including RTCWEB.   Today
even a moderately priced computer can support multiple monitors, as well as
multiple cameras, each of which can support a layered codec, and the cost of
business-grade telepresence systems has come down by an order of magnitude
in the last few years.  Given these trends, it is inevitable that WebRTC
will eventually support these scenarios.  Thinking that through now will
avoid a lot of pain later. 

Adam said:

"I just think we're rushing down a path of throwing out a lot of good to get
rid of a little bit of bad. I'd like to see more discussion around less
radical changes to SDP to achieve the goals of CLUE and RTCWEB."

[BA]  It certainly makes sense to ensure that the WebRTC architecture can
handle CLUE scenarios.   In fact, I do believe that some basic CLUE
scenarios (such as support for multiple cameras and monitors) are already
implementable in some WebRTC implementations, without much in the way of SDP
or API changes.