[rtcweb] where that h264 plugin can be used

Tim Panton <tim@phonefromhere.com> Wed, 13 November 2013 10:35 UTC

Return-Path: <tim@phonefromhere.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AC9BE11E8100 for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 02:35:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AT+Pgy-xxq6U for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 02:34:55 -0800 (PST)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net []) by ietfa.amsl.com (Postfix) with ESMTP id 0906311E80E7 for <rtcweb@ietf.org>; Wed, 13 Nov 2013 02:34:54 -0800 (PST)
Received: (qmail 68173 invoked from network); 13 Nov 2013 10:34:52 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 3475
Received: from unknown (HELO zimbra003.verygoodemail.com) ( by smtp002.apm-internet.net with SMTP; 13 Nov 2013 10:34:52 -0000
Received: from zimbra003.verygoodemail.com (localhost []) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 8230718A04E3; Wed, 13 Nov 2013 10:34:50 +0000 (GMT)
Received: from limit.westhawk.co.uk (limit.westhawk.co.uk []) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 4CD8018A0176; Wed, 13 Nov 2013 10:34:50 +0000 (GMT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <5056AF7E-5C2C-4094-B77D-1BC52B792C03@apple.com>
Date: Wed, 13 Nov 2013 10:34:48 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <55F043DB-3AF6-4A33-B504-F5B316273DDB@phonefromhere.com>
References: <5282A340.7010405@gondwanaland.com> <5056AF7E-5C2C-4094-B77D-1BC52B792C03@apple.com>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1816)
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>
Subject: [rtcweb] where that h264 plugin can be used
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: Wed, 13 Nov 2013 10:35:01 -0000

Since the MTI video codec discussion I've been mulling over the h264 plugin kindly offered by cisco.

I think that there are many places where it will be useful, and I thank cisco for that.

I've come up with some problems which will need to addressed for it to meet the needs of rtcweb.

1) Appstores: No program that is destined to be sold or distributed in an app store will be able to use it.
As far as I can tell the Mac, win8, ios and android app stores all specifically ban the use of downloaded
This means that no 3rd party browser can use it - except those browsers that have their own distribution channel.
Like it or not, the appstore model is taking over the world. Many people don't feel comfortable (or just can't)
install apps that don't come from the official app stores.

This also means that no native app can include webRTC compatible video functionality using the plugin, if it wants 
to be sold/distributed via an app store.

2) Secure platforms: Platforms that only run authorised, signed code, (eg OSX by default) may have trouble running this, depending
on exactly how the install-and-download-plugin sequence works.  

3) Cloud platforms: A common usage in cloud land is to build a server image, and then boot multiple clones
of that image as service demand rises, then deleting them as load falls. Now consider a cloud video service that uses
the plugin as part of it's code. If I understand it correctly, each image boot
would need to separately download and install the plugin or risk breaching the license terms. This breaks the 
easy scalability model of having pre-pickeled images ready to roll.

4) Dark installs: It is common practice in some environments to require an install that can be made entirely from a DVD.
This won't be possible with the plugin.

Sure there are possible work arounds for some of these issues, but all are somewhat unsatisfactory, and highlight the extent to which
the h264 plugin puts engineering decisions into the hands of lawyers.