Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them)

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Thu, 06 November 2014 21:56 UTC

Return-Path: <sergio.garcia.murillo@gmail.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 B99291A90EF for <rtcweb@ietfa.amsl.com>; Thu, 6 Nov 2014 13:56:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, 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 nvGDwTq6GJaD for <rtcweb@ietfa.amsl.com>; Thu, 6 Nov 2014 13:56:16 -0800 (PST)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B121A90EA for <rtcweb@ietf.org>; Thu, 6 Nov 2014 13:56:15 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id d1so2850984wiv.13 for <rtcweb@ietf.org>; Thu, 06 Nov 2014 13:56:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=zOZk9P+I2KzmUFhn9JxBT00Wv/WhB62bv0KhOR5iniU=; b=RgqHYfKSFBFTNfgj6ZtdgAAb7Lam7Y4wKHk4G2pPaUaRIt9bUl2DvWaMdvezyqazcQ RTf1CbkYF4D63JitjVFlija/Q0j6ZHwYsgNsF+teUrbppPwmhGoPcxnosNyCbm/0b5Bw nCuWIgfN/RyR/fESm8T7PZ36CDNaGXgzKeENVGWW+0Y4IBnFg8p5ZgDCO2tmItFtGW2L qJMKhE9h3XxGGSD9TxBVHaqaBxpvYKJMapCIi13M6P4ddvulmbIuh/UQ0aIcD3cQ47ej yAj6XpFH/wg3AzUhL0WzqB08GACy646yW1Y5CfQSCiuZt26Shhg8rZ+CWbKqEjr2rIoa PErA==
X-Received: by 10.180.104.105 with SMTP id gd9mr44616429wib.65.1415310974266; Thu, 06 Nov 2014 13:56:14 -0800 (PST)
Received: from [192.168.0.195] ([95.61.111.78]) by mx.google.com with ESMTPSA id ud9sm9383113wjc.20.2014.11.06.13.56.12 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Nov 2014 13:56:13 -0800 (PST)
Message-ID: <545BEE7E.1020501@gmail.com>
Date: Thu, 06 Nov 2014 22:56:14 +0100
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <E78E8017-A08F-4061-B2BA-FB3900B1C681@phonefromhere.com> <CAGTXFp-9AtQakpLt+O_eNRNr71uyh26igLb-_56LDUTQ+g5iJg@mail.gmail.com> <545A6281.4050601@gmail.com> <EC89515C-4FD9-4C08-A80A-42B36004A516@phonefromhere.com> <545A7E0B.4070505@gmail.com> <C17546AB-1419-49C2-A634-49296C122347@phonefromhere.com> <CABcZeBOWyy3hagGpjMzmbPJjCaBdUjUUs5zat-t7h75Xa+Fzkg@mail.gmail.com> <20141106182937.GH8092@hex.shelbyville.oz> <D0812C0A.3DDD9%mzanaty@cisco.com> <20141106210038.GI8092@hex.shelbyville.oz> <CAHp8n2nY_R5Tskj4J3=iOMPbumY=g4Om1=umUMmZkUj3KqJMDg@mail.gmail.com>
In-Reply-To: <CAHp8n2nY_R5Tskj4J3=iOMPbumY=g4Om1=umUMmZkUj3KqJMDg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------040501060404060707040401"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0qtXiMcPVwMsRFImFMws_-N9QIE
Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them)
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, 06 Nov 2014 21:56:21 -0000

+1, agree on all statements, especially:

"It does also still leave the problem of people needing custom and/or urgent
fixes, whether for security reasons or simply because of some show
stopper bug that might be specific to some narrow use case."

Been there too many times to not worry about it.

BR
Sergio

On 06/11/2014 22:46, Silvia Pfeiffer wrote:
>
> +1
> That's the best summary of our current state wrt MTI that I've heard.
>
> Best Regards,
> Silvia.
>
> On 7 Nov 2014 08:01, "Ron" <ron@debian.org <mailto:ron@debian.org>> wrote:
>
>     On Thu, Nov 06, 2014 at 07:11:21PM +0000, Mo Zanaty (mzanaty) wrote:
>     > We are also working with Red Hat on a potential Gstreamer plugin.
>     > We would be happy to work with Debian or anyone else on other
>     wrappers
>     > for projects that want to download some wrapper format beyond
>     the raw
>     > library.
>     >
>     > It would be ideal to have a single binary (per platform) that
>     works for
>     > all applications, without many different wrappers. That was the
>     goal of
>     > the raw library, but apparently this is not sufficient for most
>     projects.
>     > Until we reach an acceptable common wrapper (with verifiable
>     builds),
>     > we¹re happy to have folks contribute their desired wrapper for
>     hosting.
>     > Mozilla contributed the Firefox Gecko Media Plugin (GMP)
>     wrapper. They
>     > were first to contribute, so they were hosted first, not due to any
>     > special privilege.
>
>     For Debian, this gets complicated really quickly on lots of fronts,
>     not the least being the basic principle of not entering into licence
>     agreements that don't apply equally to everybody.  If someone with a
>     copy of Debian doesn't have the same rights to use/distribute/modify
>     it as Debian itself does, then it doesn't meet even the most basic
>     test of "is it Free/Open".
>
>     While the IETF does give working groups some freedom to make
>     exceptions
>     where exceptional circumstances might justify it, I do think that the
>     aspirational requirements for freedom to implement proposed standards
>     are fairly closely aligned to what Debian requires more strictly.
>
>
>     I agree that reproducible builds would go some way toward making a
>     "single binary" more viable - but that also is a Hard Problem, and
>     while people are working on it, I don't see it being universally
>     solved before H.264 has gone the same way as H.261 has.  It does
>     also still leave the problem of people needing custom and/or urgent
>     fixes, whether for security reasons or simply because of some show
>     stopper bug that might be specific to some narrow use case.
>
>     What happens when fixing that bug for your app causes somebody else's
>     app to break because of some other assumption they made in their code?
>     Who gets to decide whose app gets to stay broken?
>
>
>     I definitely appreciate the good will that Cisco has put into trying
>     to find viable answers for other groups that would allow its preferred
>     choice to actually be a viable one, but at the end of the day it is a
>     hack around the H.264 licencing, and I don't think we're really even
>     close to having charted the full extent of the thin ice that it is
>     currently floating on.  The cap announced for H.265 definitely appears
>     to have responded to this challenge already ...
>
>     So the question for me at this stage still really is:
>
>      What exceptional circumstances exist to justify this group deciding
>      to go out on such a thin and completely untested limb, to mandate a
>      technology that is so obviously, and undisputedly, encumbered?
>
>     Especially when we have an alternative choice available to us which is
>     its technical equal, and for which the equivalent encumberance is, at
>     best, still the untested assertion of a few far-from-unbiased parties.
>
>
>     I'm not ruling out that there may be *some* solution which makes H.264
>     viable without needing to resort to Clever Hacks, but so far we seem
>     to be still well short of that.  At the same time, VP8 is currently
>     under consideration to become an international standard. And there are
>     other codecs under development which may change the facts on the
>     ground
>     too before the work of this group is completed.
>
>     I do think we want an MTI video codec, but it's less clear we need to
>     rush this decision while things that may be quite pertinent to it are
>     still evolving in new and potentially game changing ways.
>
>
>     > On 11/6/14, 1:29 PM, Ron <ron@debian.org
>     <mailto:ron@debian.org>> wrote:
>     > On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote:
>     > > On Wed, Nov 5, 2014 at 2:39 PM, tim panton
>     <tim@phonefromhere.com <mailto:tim@phonefromhere.com>> wrote:
>     > > >
>     > > > Agreed, the worst aspect of any adoption of H264 is that it
>     makes it
>     > > > significantly more difficult to
>     > > > produce a custom ¹secure¹ build of firefox that has been
>     independently
>     > > > reviewed for special use-cases
>     > > > (press, humanitarian workers etc).
>     > >
>     > > Why is this true? We currently build OpenH264 and then send
>     the binary to
>     > > Cisco but keep a hash for comparison. Why is it more difficult
>     to review
>     > > this?
>     >
>     > Is Cisco offering to ship such binaries for anyone who wants to
>     build
>     > them, or is this a special privilege they offered to you to win your
>     > support for their scheme?
>     >
>     >   Ron
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb