Re: [rtcweb] Video Codec Selection Plan

[Pete Resnick <[e-mail]>]

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.

> On Fri, Sep 13, 2013 at 11:50 AM, Pete Resnick 
> <[e-mail] <mailto:[e-mail]>> 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.

> ...so that if there are issues which might be resolved, they can be.

Or, for that matter, if there are issues which are showstoppers that 
can't possibly be resolved, they are noted, because that might leave us 
with only 1 solution anyway.

> If there are issues which cannot be resolved, having a second 
> discussion on what they are amounts to re-hashing and doesn't do 
> anything to move things forward.

Absolutely agree, no second discussion is desirable. Having the list of 
unresolvable issues with the chair's calls on those, would be handy.
>
>     What I would *not* be interested in is yet another presentation
>     from the proponents of either of these to tell me why one is better;
>
>
> One might surmise that this is because you do not intend to actually 
> build, deploy, or operate a service that relates to this.  If someone 
> puts forward a codec that is better (in human assessment, lines of 
> code, or operating requirements) and meets the other criteria for 
> deployment, why wouldn't you want to hear about it?

Ah, you misunderstand my comment. I presume that the cases *for* the 
codecs have all been made quite well already. No doubt, if there is 
something that proponents believe has not been said or understood yet, 
out on the table with it.
>
>     I want to hear from *opponents* of the proposal to hear why the
>     proposal would fail.  Only then would I want to hear from
>     proponents responding to those objections. And then I'd like to
>     see a summary of those objections and those responses by the chairs 
>
>
> Pete, my dear mangel-wurzel and apple of my eye, that's the most 
> process wonky thing you've said in a long while, which is saying 
> something.

Exchange of hugs, kisses, and root vegetables deferred until Vancouver.

> The working group is trying to identify a common codec that can be 
> used to avoid negotiation failure.  If there is no common video codec, 
> the network effect of this system is much less.

Of course.

> If there are people who have stated *they cannot live with this*, they 
> are not going to build, deploy, or operate services which use the 
> common codec.

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. At some point, you have to trust people to be honest, 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." 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.

>     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. (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.)

> Sometimes signals are strong.

Strong signal of something. I'm not always totally sure what.
>
>     You cannot know from that result whether the reason that some
>     people could not "live with" a proposal was simply because "my
>     Aunt Gertrude told me that I should say that I can't live with
>     it." To ask for the show of hands and then not find out what it
>     means is not calling the consensus. And I think moving to a 3929
>     alternative on the basis of that show of hands would be improper.
>
>
> 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.

> fondly,

Right back at ya'.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]