Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees

Ron <ron@debian.org> Thu, 12 December 2013 21:32 UTC

Return-Path: <ron@debian.org>
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 0EB111ADF10 for <rtcweb@ietfa.amsl.com>; Thu, 12 Dec 2013 13:32:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 vCbFuZWwhaW1 for <rtcweb@ietfa.amsl.com>; Thu, 12 Dec 2013 13:32:45 -0800 (PST)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id B930A1ADED5 for <rtcweb@ietf.org>; Thu, 12 Dec 2013 13:32:44 -0800 (PST)
Received: from ppp14-2-56-86.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.56.86]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2013 08:02:37 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id BE8B84F8F3; Fri, 13 Dec 2013 08:02:34 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7KDHFukC4QQJ; Fri, 13 Dec 2013 08:02:34 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 2AB814F902; Fri, 13 Dec 2013 08:02:34 +1030 (CST)
Date: Fri, 13 Dec 2013 08:02:34 +1030
From: Ron <ron@debian.org>
To: Cullen Jennings <fluffy@iii.ca>
Message-ID: <20131212213234.GQ3245@audi.shelbyville.oz>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <A672E2AB-827D-46E8-9EB1-D7ED82B10B94@cisco.com> <20131211193239.GK3245@audi.shelbyville.oz> <558F8D49-4024-4DF1-9A9E-AF422F1292C2@iii.ca> <20131212011550.GM3245@audi.shelbyville.oz> <E8882BCE-4795-4CF5-B785-18C2141A5DE2@iii.ca> <20131212183852.GN3245@audi.shelbyville.oz> <9B19C671-4356-4918-B271-D95B7AA84BBA@iii.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9B19C671-4356-4918-B271-D95B7AA84BBA@iii.ca>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
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: Thu, 12 Dec 2013 21:32:48 -0000

On Thu, Dec 12, 2013 at 11:59:31AM -0700, Cullen Jennings wrote:
> 
> Great - glad that worked and let me know if that helps clarify the situation. 

So none of what was talked about there was something that I was previously
confused about, it never really seemed that complicated to me or poorly
explained what you had in mind, my main concern was (and still is) that it
doesn't actually solve the numerous problems - and in fact creates a whole
bunch of new ones to only partly solve one problem with one H.264 patent
holding group out of several known ones.

But I couldn't know that for sure until I'd actually seen it :)


It does however raise a brand new problem (one which is actually quite
technically interesting!), and I am interested to know if that was just
a misunderstanding on your part in explaining it, or if you actually do
plan to really solve this. [1]

You talk about Mozilla fingerprinting the *source* that they verified,
and then being able to confirm that fingerprint in the binary blob they
download from the Cisco build farm.

I had previously assumed people were only planning to take a hash of
the binaries already up there, merely to ensure the blob that a user
actually downloaded wasn't some totally foreign trojan, but was what
was expected to come from the Cisco site.


There is considerable work presently being done on fully reproducible
binaries, since obviously this is of interest on many fronts, but it's
currently far from being a universally (or easily) Solved Problem.

Is Cisco actually planning to invest work into solving this (for all
architectures!) as part of this project?  Or was that just you assuming
something which probably isn't how it will actually work in practice?


The former certainly would be a cool contribution and a real and
pleasant surprise to me, independently of the problems that still
plague this as a solution to the MTI codec problem.

  Cheers,
  Ron


[1] - I am also kind of curious how you plan to deal with the fact
      that there are several thousand Debian derivatives, all of
      which may or may not be binary compatible with each other
      at any given point in time.
      But I suspect I do already know the answer to that one :)