Re: [rtcweb] Video Codec Selection Plan

[Bossiel <[e-mail]>]

Sent from my iPhone

On Sep 14, 2013, at 0:26, Lorenzo Miniero <[e-mail]> wrote:

> On Fri, 13 Sep 2013 13:45:36 -0700
> Ted Hardie <[e-mail]> wrote:
> 
>> Howdy,
>> 
>> I've now had lunch and nice coffee, and I take electrons in hand to answer
>> your missive, sent earlier today.
>> 
>> On Fri, Sep 13, 2013 at 11:50 AM, Pete Resnick <[e-mail]>wrote:
>> 
>>> Big caveat as I post this: I am speaking strictly as an IETF participant.
>>> In particular:
>> <SNIP>
>> 
>> 
>>> All that said, I am concerned about the path being proposed, and I agree
>>> with Matthew's concern (though I feel somewhat less defeatist than his
>>> assessment sounds):
>>> 
>>> 
>>> On 9/13/13 11:59 AM, Matthew Kaufman wrote:
>>> 
>>>> 2. Should I expect "room-packing" for this "show of hands" (which I don't
>>>> believe is the typical "hum" process for the IETF, either) as happened
>>>> during the SDES discussion last time, and therefore need to bring as many
>>>> people who've not participated in RTCWEB previously but who want my codec
>>>> to succeed as I can afford to fly to Vancouver?
>>> 
>>> I think this is a valid concern. 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, so that if
>> there are issues which might be resolved, they can be.  During the course
>> of the effort to find a solution here, there have been several such
>> resolutions (Cisco, for example, graciously agreed to provide an open
>> source H.264 implementation should it be selected, in order to handle
>> objections that none were available).  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.
> 
> 
> Open source implementations are not the issue (we have x264 for that), licensing is.
x264 is GPL. I guess we're talking about an open source implementation with permissive license (e.g BSD)
Mamadou,

> 
> Lorenzo
> 
> 
>> 
>>> 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?
>> 
>> 
>>> 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.  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.
>> 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.  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 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.
>> 
>> 
>>> 
>>> With that summary, the chairs can make a call of whether there is any hope
>>> of consensus. I think much of that work can and should take place on the
>>> mailing list *before* the face-to-face meeting.
>> 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.  In several of our recent calls,
>> we have had unanimity, which is generally held to be a strong indicator of
>> consensus.
>> 
>> The last time we had a straw poll which used similar language, we also had
>> absolutely no question that we had not achieved consensus.
>> 
>> Sometimes signals are strong.
>> 
>> 
>>> 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.
>> 
>> 
>>> Put me down as one voice who objects to the proposed procedure.
>> So noted.
>> 
>> fondly,
>> 
>> Ted
>> 
>> 
>> 
>>> pr
>>> 
>>> 
>>> On 9/13/2013 9:52 AM, Ted Hardie wrote:
>>>> 
>>>>> WG,
>>>>> 
>>>>> The chairs have created a plan for how to perform the Video Codec
>>>>> selection in our WG. The chairs are asking for review of our plan on
>>>>> how to undertake the mandatory-to-implement video codec selection.
>>>>> We'd much prefer to have comments on the mechanics before they begin,
>>>>> so please review now.  Proponents of a particular proposal should
>>>>> note both the actions required and the timelines proposed.
>>>>> 
>>>>> The main goal of this plan is to hold a consensus call on which of
>>>>> the proposed alternatives we as a WG should select at one of the WG
>>>>> sessions in Vancouver. Such a consensus call will of course be
>>>>> verified on the mailing list for anyone who can't participate. The
>>>>> chairs will recuse themselves from judging this particular
>>>>> consensus.
>>>>> 
>>>>> In the WG session each codec proposal will be allowed an equal amount
>>>>> of time to highlight the arguments for their proposal. After that a
>>>>> there will be a slot for discussion and clarifying questions.
>>>>> 
>>>>> 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. We chairs would really
>>>>> not like to see the proponents bring up new arguments at their
>>>>> presentation. Also the WG participants are expected to raise any
>>>>> arguments on the list ahead of time to enable the proponents to
>>>>> respond to such arguments.
>>>>> 
>>>>> The proposed consensus questions will be of the following form:
>>>>> 
>>>>> 1. If you support H.264 as the mandatory to implement codec or are
>>>>> willing to live with it as the MTI, please raise your hand now.
>>>>> 
>>>>> 2. If you support VP8 as the mandatory to implement codec or are
>>>>> willing to live with it as the MTI, please raise your hand now.
>>>>> 
>>>>> You may indicate support on both questions and we encourage you to do
>>>>> so if you can live with either, even if you have a preference for one
>>>>> over the other.
>>>>> 
>>>>> Additional proposals than the previous ones are welcome, but must be
>>>>> submitted as draft and their proponents must notify the chairs no later
>>>>> than the 6th of October that they also have a candidate proposal.
>>>>> 
>>>>> In case the WG fails to reach consensus we chairs propose that we use
>>>>> the alternative decision process as discussed in RFC3929. The method
>>>>> and its usage will be discussed on the list should the WG not
>>>>> establish consensus on a proposal for mandatory to implement video codec.
>>>>> 
>>>>> regards,
>>>>> 
>>>>> Magnus,  Cullen, and Ted
>>> --
>>> Pete Resnick<http://www.qualcomm.**com/~presnick/<http://www.qualcomm.com/~presnick/>
>>> Qualcomm Technologies, Inc. - [phone]
>>> 
>>> 
>>> ______________________________**_________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> 
> -- 
> Lorenzo Miniero, COB
> 
> Meetecho s.r.l.
> Web Conferencing and Collaboration Tools
> http://www.meetecho.com
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb