Re: [rtcweb] Video codec selection - way forward

Maik Merten <maikmerten@googlemail.com> Wed, 20 November 2013 08:57 UTC

Return-Path: <maikmerten@googlemail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20211AC7EE for <rtcweb@ietfa.amsl.com>; Wed, 20 Nov 2013 00:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.979
X-Spam-Level:
X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgHJmW10i8QX for <rtcweb@ietfa.amsl.com>; Wed, 20 Nov 2013 00:57:25 -0800 (PST)
Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 761341AC4AB for <rtcweb@ietf.org>; Wed, 20 Nov 2013 00:57:25 -0800 (PST)
Received: by mail-ea0-f169.google.com with SMTP id l9so3766045eaj.28 for <rtcweb@ietf.org>; Wed, 20 Nov 2013 00:57:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=q9b70LNVhfQFD9XiESzrlr6A6CUl1reVrtVZ9fRoCGY=; b=0l+UdI5ZL4PvMLXkJmob+FE9v9EwxPau0fCF/CxUWA5kVWTEpzhWowOeMQhiZy5iSa M34JxIe000i0Pg0kuanAju/VQhjU74RYTK3RjKKMBTr0fMj7YRecxJ+ShsUr+aHhONZU 6ZatQyo36ykUodSqksBeDOfkCTf6fqtn7gZHrI2rBnP69/gvzWVksVhMKeHZVcG205w+ xobg83O9z+pDaCu5+9H17Fk241FBte/u/5e/rDZfcxPsnOglkXoXEtvEPk9VGuF6zIKJ axQHbpx2xejXuPxpCv41U4jTIwzBib6rzDgCTpj9KG+K0aJUia8xfFN52EKn9IjtnqDL AmKg==
X-Received: by 10.14.6.134 with SMTP id 6mr725097een.66.1384937838728; Wed, 20 Nov 2013 00:57:18 -0800 (PST)
Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id v45sm7155878eef.11.2013.11.20.00.57.16 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 00:57:17 -0800 (PST)
Message-ID: <528C79AD.10608@googlemail.com>
Date: Wed, 20 Nov 2013 09:58:21 +0100
From: Maik Merten <maikmerten@googlemail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
CC: "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1@gbplmail03.genband.com>, <52891EDB.2050607@googlemail.com>, <D0698C9F-967F-4797-A9F3-E461B9DAE8EB@apple.com>, <528B2ABE.4040701@googlemail.com> <BLU169-W24713EECAF0BE76A85E94B93E60@phx.gbl>
In-Reply-To: <BLU169-W24713EECAF0BE76A85E94B93E60@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 20 Nov 2013 08:57:27 -0000

Am 20.11.2013 04:27, schrieb Bernard Aboba:
> Maik said:
>
>  > - implementing the codec of "the other codec camp" is more desirable
>  > - the end-users will appreciate spuriously failing video calls
>
> [BA] The above are not the only choices, because it is not necessary to
> "implement the codec of the other codec camp" in order to provide
> support for it.  The Cisco offer of an H.264 encoder/decoder is only one
> example.

I meant "implementing" as in "implementing and deploying support for".

Cisco's offer, while certainly useful in some (or even many) application 
contexts, cannot cover all relevant deployment scenarios. This not only 
concerns WebRTC implementation providers, but also users (for instance, 
what licensing status do machines have that are recovered from disk 
images that happen to include the binary blob implementing H.264?).


> So really, the choice is more between "support codec extensibility and
> allow 'the other codec camp' to take risks they are comfortable with"
> and "implement an inferior codec no one wants".

Without a fallback codec there will be negotiation failure in ways that 
are out of control of the affected users. I think this is undesirable 
for all involved parties. Implementing support for an "IPR-safe", 
unsophisticated, well-understood, albeit sadly low-performing codec to 
me sounds like a manageable requirement for implementers to guarantee a 
minimal level of video interoperability. It's for sure an inconvenience, 
but so is firewall traversal.


Maik