Re: [rtcweb] Video codec selection - way forward

Ross Finlayson <finlayson@live555.com> Mon, 18 November 2013 06:59 UTC

Return-Path: <finlayson@live555.com>
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 11A6911E85AF for <rtcweb@ietfa.amsl.com>; Sun, 17 Nov 2013 22:59:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 d7g2t30XFLfU for <rtcweb@ietfa.amsl.com>; Sun, 17 Nov 2013 22:58:58 -0800 (PST)
Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3791111E85AB for <rtcweb@ietf.org>; Sun, 17 Nov 2013 22:58:16 -0800 (PST)
Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id rAI6wExF054607 for <rtcweb@ietf.org>; Sun, 17 Nov 2013 22:58:15 -0800 (PST) (envelope-from finlayson@live555.com)
From: Ross Finlayson <finlayson@live555.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_13DCF512-89ED-4FE8-A0B0-84C2D6DD37A2"
Message-Id: <565DE5B9-89A1-4BAF-BBC7-F179B381D837@live555.com>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Date: Sun, 17 Nov 2013 22:58:14 -0800
References: <D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1@gbplmail03.genband.com> <52891EDB.2050607@googlemail.com>
To: rtcweb@ietf.org
In-Reply-To: <52891EDB.2050607@googlemail.com>
X-Mailer: Apple Mail (2.1822)
Subject: Re: [rtcweb] Video codec selection - way forward
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, 18 Nov 2013 06:59:03 -0000

> just wondering if something like
> 
> "9. All entities SHOULD support both H.264 and VP8. All entities MUST at least implement one of those. Entities that do not support both H.264 and VP8 MUST implement H.261."
> 
> has already popped up. My reasoning is that implementations supporting both high performance codecs will always negotiate to use on of those - H.261 should never be relevant there.

This looks promising.  To summarize: You're proposing that each implementation MUST implement (at least) one of the following sets of codecs:
	{VP8, H.264}
	{VP8, H.261}
	{H.264, H.261}

This guarantees that there'll never be negotiation failure (between a pair of implementations), because the intersection of any two of these sets is non-empty.

It also allows the H.264 camp to avoid any alleged additional IPR risk from implementing VP8, because they won't need to implement VP8 (they'll need to implement H.261 instead).

Similarly, it also allows the VP8 camp to avoid any H.264 licensing requirements, because they won't need to implement H.264 (they'll need to implement H.261 instead).

And people who are willing to implement both VP8 and H.264 will know that they'll always be able to negotiate high-quality video.

Who knows - this may well be something that we could reach consensus on (provided that everyone agrees that there's little IPR risk from H.261)...


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/