Re: [rtcweb] Video codec selection - way forward

Bernard Aboba <bernard_aboba@hotmail.com> Wed, 20 November 2013 17:44 UTC

Return-Path: <bernard_aboba@hotmail.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 0C99A1AE082 for <rtcweb@ietfa.amsl.com>; Wed, 20 Nov 2013 09:44:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level:
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
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 rWkrXp5c7UAy for <rtcweb@ietfa.amsl.com>; Wed, 20 Nov 2013 09:44:14 -0800 (PST)
Received: from blu0-omc2-s7.blu0.hotmail.com (blu0-omc2-s7.blu0.hotmail.com [65.55.111.82]) by ietfa.amsl.com (Postfix) with ESMTP id 52DE61ADFF9 for <rtcweb@ietf.org>; Wed, 20 Nov 2013 09:44:14 -0800 (PST)
Received: from BLU169-W19 ([65.55.111.71]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Nov 2013 09:44:08 -0800
X-TMN: [C33yy3ePv7w6k5HhBFppmeoY3jO6LQGPMzv8L3CAOMk=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W19675CF49C4FAF3F889E4793E60@phx.gbl>
Content-Type: multipart/alternative; boundary="_e48e23b2-122c-4dec-a2bb-4f7d9f9a73cf_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Maik Merten <maikmerten@googlemail.com>
Date: Wed, 20 Nov 2013 09:44:07 -0800
Importance: Normal
In-Reply-To: <528C79AD.10608@googlemail.com>
References: <D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1@gbplmail03.genband.com>, , <52891EDB.2050607@googlemail.com>, , <D0698C9F-967F-4797-A9F3-E461B9DAE8EB@apple.com>, , <528B2ABE.4040701@googlemail.com>, <BLU169-W24713EECAF0BE76A85E94B93E60@phx.gbl>, <528C79AD.10608@googlemail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Nov 2013 17:44:08.0259 (UTC) FILETIME=[1D206930:01CEE618]
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 17:44:16 -0000

Maik said: 

> Cisco's offer, while certainly useful in some (or even many) application 
> contexts, cannot cover all relevant deployment scenarios. 
[BA] I'd note that the current IETF discussion of MTI video codecs is somewhat similar to a previous discussion in W3C relating to the MTI codec for streaming video.   In that previous discussion, advocates of the potential MTI codecs offered to implement their preferred codec for other browsers.  So if past is prologue, other offers may emerge over time. 

> Without a fallback codec there will be negotiation failure in ways that are out of control of the affected users. 

[BA] In practice, negotiation failure is annoying enough that customers and users are going to demand that it be addressed in some fashion.  This could be via native implementation of multiple codecs, via codec plugins as Cisco has proposed, or via on-premise or cloud-based transcoding solutions as Justin has described.   Given the penalties that the marketplace will impose on services that don't address interoperability in some fashion, it seems to me that the issue is very likely to be addressed in practice, at least for commercial services.  
On the other hand,  attempting to impose a solution that has no real consensus could do real damage, by diverting resources away from implementing leading edge codecs (e.g. VP9 and HEVC) or polishing the WebRTC protocol specifications so as to fully enable multi-codec support, which is going to necessary whichever camp you're in.