Re: [rtcweb] Video Codec Selection Plan

Ted Hardie <ted.ietf@gmail.com> Fri, 13 September 2013 22:05 UTC

Return-Path: <ted.ietf@gmail.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 7C24611E80F9 for <rtcweb@ietfa.amsl.com>; Fri, 13 Sep 2013 15:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.391
X-Spam-Level:
X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 0yCmcnVW3GWA for <rtcweb@ietfa.amsl.com>; Fri, 13 Sep 2013 15:05:24 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 10DA611E80AD for <rtcweb@ietf.org>; Fri, 13 Sep 2013 15:05:22 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id ar20so3825183iec.18 for <rtcweb@ietf.org>; Fri, 13 Sep 2013 15:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P9EVpPZbtAwIKtyT91Fd0Til8WHT0tSZmUyKRvCY/lA=; b=hlLSi845oA4OENMhiyv5tKZFbAjW4KrOk1nDVygohHV0YNIfbNt18UnJqz6vaGtRYH c5UNGqMX/hyZQS+y7XsUwZfAsGGqy4Gjy9SF7DWLLMGRaMR3lU5clXamklP78D3kTzjh gN5Oazdm6FgCuqIkrg3ho7wEKaqGMspNz42kUgIipcFdaXfwChX7paAmAVi0ILBrZkzp GFfToM1ijNdsLCFCYKfUH4p5o9PNN9xtiAmtdcLD61JaLk4GBQGss9rmZjpKWBn2g6Ci Y0cAzdwDrSFEPhJKQ/IwpuGglfIg0cSRvzxPYb+fQI/Ike2eaJO/9qpWX49dAk/FFydl Bhdg==
MIME-Version: 1.0
X-Received: by 10.50.120.104 with SMTP id lb8mr2215404igb.22.1379109922536; Fri, 13 Sep 2013 15:05:22 -0700 (PDT)
Received: by 10.42.29.202 with HTTP; Fri, 13 Sep 2013 15:05:22 -0700 (PDT)
In-Reply-To: <523384F6.9010401@qti.qualcomm.com>
References: <CA+9kkMAvdtq_gufKmDNCNCL+kKcxyi0MGUoVHetd9_DzbEdEnA@mail.gmail.com> <52334462.608@matthew.at> <52335E78.2080406@qti.qualcomm.com> <CA+9kkMCuHn3TR7umXtuScWixBfOD9jfS6mu3njxaCOADfG-nvw@mail.gmail.com> <523384F6.9010401@qti.qualcomm.com>
Date: Fri, 13 Sep 2013 15:05:22 -0700
Message-ID: <CA+9kkMA_neg0oVzgYFJ+Fn+6A1cjVEV1dxs8E-xC3sPVRtdJvQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Pete Resnick <presnick@qti.qualcomm.com>
Content-Type: multipart/alternative; boundary="047d7bd76bb20a055e04e64b0daf"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Video Codec Selection Plan
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: Fri, 13 Sep 2013 22:05:27 -0000

On Fri, Sep 13, 2013 at 2:34 PM, Pete Resnick <presnick@qti.qualcomm.com>wrote:

> **
> On 9/13/13 3:45 PM, Ted Hardie wrote:
>
> I've now had lunch and nice coffee, and I take electrons in hand to answer
> your missive, sent earlier today.
>
>
> Erst kommt das Fressen, dann kommt die Standards.
>
>
Trust me, the food was too good to guzzle.


 On Fri, Sep 13, 2013 at 11:50 AM, Pete Resnick
<presnick@qti.qualcomm.com>wrote:
>
>  Asking "who wants or can live with VP8?" and "who wants or can live with
>> H.264?" might be a good start to the discussion, but at that point, I'm
>> going to want to hear *why* people *can't* live with one or the other.
>
>
>  That discussion is supposed to happen before this, not after...
>
>
> That's good to hear, but at least your present "plan" message, and none
> that I can find elsewhere, makes it apparent that you are now soliciting
> the list of outstanding issues and their purported answers, nor that a
> summary of that list and the closed issues would be available before the
> face-to-face. I'm all for that.
>
>
Um, did you miss the part where folks were supposed to have their proposals
in by the 6th of October so that objections and discussions could happen in
advance of the meeting?

"To enable the WG participants to get answers to any questions, the
proposals in draft form and any supporting material MUST be made
available by 6th of October. This is to ensure that the WG
participants can verify or object to any claims or statements in
the proposal material prior to the WG session"


> I call "horse-pucky". And this is exactly why looking at
> skyward-pointing-appendages is a lousy tool in this particular case. You
> don't know that if they state "they cannot live with this" that they are
> not going to deploy. You would only know that if you knew their reasons.
> Because my friend mentioned below who is raising his arm because his Aunt
> Gertrude told him to do so is not affecting deployment one little bit.
>

We disagree. A set of working group participants will not use a codec
because they have financial reasons, technical reasons, or a personal
promise to their aunts comes down to the same thing:  they will not
implement or deploy.  The impact to the network effect is the same if the
reasoning is philosophical, financial, or personal.


> At some point, you have to trust people to be honest
>

Exactly.  Or, perhaps more to the point, if you cannot trust their
statements on their future course of action, why would you trust their
statement on their reasons?

but you need to ask the right question. In this case, if I say, "I can't
> implement this in my little open source release (that my employer would
> never sanction) if you use the FOOBAR codec for such-and-so reasons", it's
> reasonable to ask, "Who's in the same boat with Pete?", perhaps even
> following up with "Is the WG really OK with the idea the that folks in
> Pete's circumstances (open-source developers, 1-coder shops, holdover
> Macintosh developers, coders for devices with less than 1K of available
> memory, etc.) are not going to be able to implement this?" Maybe the WG
> will say, "Poor Pete. He's in the rough. We're chartered to make this work
> on a wide-scale, and Pete's sort of implementation is just not
> realistically a part of what we're doing."
>

Actually, what we're doing is set out elsewhere, in the charter and the use
case document.  As you consulted the archives on this topic, perhaps you
saw the WGLC on the latter.


> But then you're asking about whether the WG is willing to punt a
> particular kind of deployment, not counting heads (hands, souls, auras, or
> otherwise).
>
>
>    The actual system we are trying to build will suffer.  Judging
> consensus is not here an end in itself, it's a way of working out whether
> or not the system we're building does or does not have a way to avoid the
> negotiation failure.
>
>
> We agree on the goal. We disagree on the methodology.
>
>
>    We would not have spent the amount of time we have unless that were
> important, and we would not be considering using RFC 3929 unless we thought
> it was worth getting to a resolution.  I implore you to stop treating this
> as an academic exercise in consensus theory, and remind yourself that we're
> trying to do some engineering here.
>
>
> Let's avoid questioning each others' motives, shall we? No good down that
> road.
>
>
Let me implore you, then, to look at the engineering aspects rather than
the process aspects.


>
>    But asking for a show of hands in the room for people who "can live
>> with" one or the other and deciding whether or not consensus exists based
>> on that show of hands is simply taking a vote, it's not judging consensus.
>
>
>  That rather presumes you know the count.
>
>
> Not at all.
>
>
>    In several of our recent calls, we have had unanimity, which is
> generally held to be a strong indicator of consensus.
>
>
> Unanimity is, I concede. Other counts have more or less interesting
> indications.
>
>
>    The last time we had a straw poll which used similar language, we also
> had absolutely no question that we had not achieved consensus.
>
>
> You certainly had the appearance of non-consensus. But I'm not convinced
> the work was done to determine what the showstoppers were for the people
> who "couldn't live with" one choice or the other.
>

Had that been the first time we had visited the topic, I would agree with
you.  But it was not even the first handful.



> (I will put aside the fact that some chap -- with a blue dot on his badge,
> no less -- sitting down the row from me during that straw poll, exclaimed
> upon conclusion of it, "Well, it's pretty obvious we have consensus for
> 'A'". I was.....disappointed.)
>
>
The chairs have recused themselves from calling consensus, but had the most
recent straw poll resulted in an assertion of consensus, I would have been
mightily surprised.


>    Sometimes signals are strong.
>
>
> Strong signal of something. I'm not always totally sure what.
>
>
Well, starting from the assumption that people are answering the question
they were asked seems reasonable to me.


>
>
> If you re-read RFC 3929, you will discover that it requires that you make
> an explicit call for its use; the consensus to use it standing in for the
> consent on the technical matter.  The working group chairs have no
> intention of skipping that step, should RFC 3929 be used.
>
>
> As above, I worry about how the determination is made. Once made, all is
> well.
>
>
Should it become necessary, I'm sure that any suggestion you have on
wording such a question to the working group will be given all due
consideration,

Ted


>    fondly,
>
>
> Right back at ya'.
>
> pr
>
> --
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>
>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>
>