Re: [rtcweb] Video Codec Selection Plan

[Lorenzo Miniero <[e-mail]>]

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.

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