Subject: [rtcweb] Alternative consensus and MTI video codecs

From: Gregory Maxwell <[email-masked]>
Date: Thu, 7 Nov 2013 16:41:42 -0800

I've always thought the RFC 3929 procedures were more of a threat to
encourage a consensus— if an uncomfortable one— than something that
ought to be used... but its not much of a threat if its never used,
and sometimes it's really important to have a decision.

I think we had previously agreed here that an MTI codec is important.
That it would break marketplace symmetry and create compatibility. It
may be that after the OpenH264 announcement some people believe MTI is
less important.

I think the question to ask is "Is and MTI video codec important
here".  Not do I support this codec or that. But is MTI video
something important the group should deliver.  If not, why not and why
wasn't it before?

"MTI is hard" isn't a valid answer to that question. "My favorite
option didn't win" isn't an answer either.

If we still believe from an engineering perspective that WebRTC ought
to have one MTI video codec it still can, even though the counts were
split:   We can invoke RFC 3929 4.4 and _flip a coin_.

A coinflip is a simple process which is guaranteed to make a section.
(If we don't trust a chair member to perform an actual coinflip, I can
suggest a trivial cryptographic protocol we can do in the list with
nothing more than the sha256sum tool)

I don't see how anyone can argue that for the goal of selecting an MTI
that a coinflip between options in a largely split room cannot achieve
that goal.

Alternatively, — considering market realities if MUST one of {vp8,h264
constrained baseline} is really the closest to MTI-in-practice  we
could expect full deployment of— is that preferable? Does it achieve
the goal of having MTI video in the first place? Does it partially
achieve it?

I don't think the argument that one-of-either is better than
none-at-all is sufficient: We can coinflip so none at all is not a
necessary option.  I think an argument for one-of-either must argue
that market realities make a single MTI (selected via coinflip) a dead
letter.  And arguments that either single codec as MTI were dead
letters have failed to convince the working group already.

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Nov 2013 17:06:07 -0800

On 11/7/13 16:41, Gregory Maxwell wrote:
> split:   We can invoke RFC 3929 4.4 and_flip a coin_.

I do not believe the decision under consideration qualifies for the 
process in section 4.4. As that section itself notes, random selection 
is only appropriate for something like deciding a numerical codepoint or 
a DNS prefix.

Our situation is radically different: there are a number of actual 
arguments to be made for both options.

I think an external review team (section 4.1) is a reasonable way 
forward, as it lets the decision rest on the merits that proponents of 
each approach have themselves put forth, without allowing partisan or 
emotional considerations to get in the way of facts.

I'll make an even stronger statement: I would contend that any strong 
push against the use of an external review team amounts to a tacit 
admission by an individual that the arguments for their preferred 
position are insufficiently compelling.

If anyone believes that their position logically follows from the known 
facts, then they would necessarily believe that a randomly-selected 
panel of neutral third parties will agree with them. If such a person 
thinks that the panel won't, perhaps they should reevaluate whether 
their arguments are grounded in facts and logic, or their own emotional 
investment in this decision.

/a

---

From: Gregory Maxwell <[email-masked]>
Date: Thu, 7 Nov 2013 18:22:57 -0800

On Thu, Nov 7, 2013 at 5:06 PM, Adam Roach <[email-masked]> wrote:
> Our situation is radically different: there are a number of actual arguments
> to be made for both options.

We've heard these arguments, at long length, and have, apparently, not
found them sufficiently decisive or we wouldn't be at this juncture.

I must have failed to make the point I was attempting to make
sufficiently clear.  Let me retry: If we believe that an MTI video
codec, regardless of what it is, was an independently important thing
to have then "no MTI" shouldn't be the result of failing to achieve an
MTI in discussion, because there exist _an option_, any option, to
achieve a MTI video codec.  So I was hoping to see any support for "no
MTI" (which sounded very popular in the room) to come with arguments
for why an MTI doesn't actually matter.

Without intending any "push", strong or otherwise, I'll point out that
the apparent difficulty in responding to my message without
allegations of irrational arguments and emotional investments
increases my estimation that locating a set of "randomly selected
neutral parties" which is sufficiently non-partisan to not cloud the
process is not obviously possible.  Without that kind of doubt in mind
it's not clear to me if that alternative process could be successful,
which is why I attempted to illustrate my point with the 4.4 coinflip.
Coinflip will produce a result, and the result it will produce will
achieve the goal of selecting an MTI codec (especially in
consideration of substantial support for either option, both on the list
and in the room), and it doesn't require selecting non-partisan
parties.  I wasn't trying to say it was _good_ though, only that it
was enough to say failure to pick an MTI alone isn't enough to justify
removing MTI for the sake of MTI from the goals.

(There are plenty of other arguments that can be made about the
non-optimality of the 3929 panel process— e.g. the requirement to meet
nomcom requirements with physical meeting attendance would generally
make it easy for large corporate contributors, especially ones with
diverse participation, to be over represented. But, to be frank, your
response has made me feel uncomfortable pointing that much out... I
didn't start this thread with an intention to argue against it, but I
wonder after your message if anyone else would dare.)

---

From: cowwoc <[email-masked]>
Date: Fri, 08 Nov 2013 00:56:14 -0500

I'll bring up a related point that I brought up a few days ago (I 
changed to subject to avoid hijacking the thread).

Say we can't agree on whether to use VP8 or H.264 as MTI. We can then 
simply settle on a codec with expired IPR such as H.261. H.261 is the 
codec everyone loves to hate but allow me to point out the following:

  * If H.261 is MTI, you can still upgrade to VP8
  * If H.261 is MTI, you can still upgrade to H.264
  * If H.261 is MTI, you can still use transcoding to connect VP8 to H.264

Using H.261 as MTI is a big win over no MTI because "no MTI" means we're 
forced to do transcoding, whereas H.261 as MTI means we can still do 
transcoding if we want, but we don't have to.

And yes, I agree that a more ideal solution is to choose VP8 or H.264 as 
MTI (or both) than H.261... but if worse comes to worse, I don't see a 
benefit to choosing "no MTI" over H.261.

Does anyone have a counter-point?

Gili

On 07/11/2013 9:22 PM, Gregory Maxwell wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Ron <[email-masked]>
Date: Fri, 8 Nov 2013 23:01:09 +1030

On Thu, Nov 07, 2013 at 05:06:07PM -0800, Adam Roach wrote:
> process in section 4.4. As that section itself notes, random
> selection is only appropriate for something like deciding a
> numerical codepoint or a DNS prefix.

I agree that there are still too many unanswered objections to declare
that both options have equal merit and a random selection of either
will therefore suffice.

Though I do also agree with Greg's analysis that if this group is going
to punt that decision to an outside actor, we will be faced with some
difficulty in finding a more unbiased selector.

> arguments to be made for both options.

Yes, there certainly are.  And I think our next step needs to be to
distill those to the ones that are actually still contentious, and
strive to achieve rough consensus on each of those remaining arguments.

We already have violent agreement occurring on quite a number of the
original selection points.  I think we can safely say there is rough
consensus on things like "the performance and quality difference is
negligible enough that it isn't a deciding factor".

Which means we only need to decide on the actually relevant problems
that remain outside of that to see if a clear best choice remains.
And I really do think that if we take each of those individually and
in isolation, that each of them individually and in isolation does
have an answer that we can achieve rough consensus on.

And that when we then sum the result of those consensus decisions,
a clear advantage will remain for just one choice.

A large part of the confusion at present appears to be that whenever
the Hard Questions are raised, someone then buries achieving any
conclusion to them under "what about this other idea that we discussed
and dismissed two years ago!!" ...   lather, rinse, repeat.

It's been said here many times that the IETF does not vote.  Yet
people are still talking about voting, and what we had today was
essentially "just a vote".  If it had been conclusive, that would
have been great, but it wasn't, and since nobody was required to
justify the reasoning for their preference vote, I think it's
premature to declare "we have failed to reach rough consensus".

The clear disparity between the the majority of the jabber room
and the majority of the attendees is a significant piece of
information in its own right, and relevant to any decision process
that we might employ to establish a working rough consensus.

Especially given the principle that IETF decisions are supposed
to be made by consensus calls on the working group list.

> forward, as it lets the decision rest on the merits that proponents
> of each approach have themselves put forth, without allowing
> partisan or emotional considerations to get in the way of facts.
> 
> I'll make an even stronger statement: I would contend that any
> strong push against the use of an external review team amounts to a
> tacit admission by an individual that the arguments for their
> preferred position are insufficiently compelling.

Superficially, and taken in isolation, that would ordinarily be a
fairly compelling argument.

But taken in the context of what we saw happen today, I would say
that the onus is first on you to demonstrate that we _can_ select
a properly neutral and unbiased review team to weigh the arguments
on their actual merit.

We know FOR A FACT, that there are major problems with the selection
of a heavily encumbered, and restrictively licenced MTI codec.

The people pushing for choosing that option have acknowledged this
and tried to mitigate it by throwing several million dollars at
Freebies For Some.

Many people replied on the list that "this is wonderful, and we
thank you a lot, but it doesn't actually solve the core problem".
There was effectively no direct rebuttal to this there.

And so far the only answer to those remaining problems was along
the lines of "pfft, you're all just little fish, you don't matter".

If the candidates for an external review team are going to inherently
be biased along the same lines as the physical meeting room was, then
a monte-carlo sampling of them isn't going to get us a neutral panel.

And if an argument of "but the licence doesn't allow this at all",
can be dismissed with "pfft, that doesn't matter", then that would
seem to be a tacit admission that no argument could ever be
sufficiently compelling to a group espousing that belief.

> If anyone believes that their position logically follows from the
> known facts, then they would necessarily believe that a
> randomly-selected panel of neutral third parties will agree with
> them. If such a person thinks that the panel won't, perhaps they
> should reevaluate whether their arguments are grounded in facts and
> logic, or their own emotional investment in this decision.

My belief is that this working group hasn't actually given sufficient
and complete consideration to the already known facts to set about
abdicating the decision to an external group.

There are serious questions raised on the list that are unanswered
in any even remotely satisfactory way.

Maybe people thought the show of hands today would be decisive and
they would not have to answer them.  But it wasn't, and so the
necessity to either answer them, or admit they are the fundamental
blockers that people assert they are, still remains.

I think it would be impossible for this group to present this to
a group of people that haven't followed the discussion to date,
and expect that group to arrive at a well reasoned answer if even
we don't yet have reasonable answers to questions of grave concern.

We had two presentations today.  One was a short and sweet "my argument
remains unchanged and stands on its own merit".  The other was a great
modern adaptation of The Story Of The Reason.  If anyone who heard it
can remember what the reason actually was, I would invite them to
relay it for posterity via answers to the still unanswered questions
on the mailing list.

Let's break this down into what the showstoppers for either choice
really still are today.  If we focus on that, I don't think we're
actually very many steps from having a sensible decision be quite
obvious and undeniable.  And from having it broken down into simple
things that we can achieve consensus over, step by step -- making
the final step seem far less of an insurmountable leap of faith.

Attempts to change things that previously had consensus is not a
way forward, and we do have consensus that MTI is necessary and
crap ancient codecs are not a viable option.  Let's worry about
what the Real problems with the two choices we have actually are
and decide what needs to occur in order to resolve them if they
do stand up to scrutiny as actual problems.

I don't think we've actually failed at that, we've just had the
argument become deeply muddled in sophistry.  Having external
adjudication on a final consensus may still be necessary, but
that's quite different from totally punting on the work needed
to establish it.

Some time back Adam posted some very interesting thoughts on
the mechanisms of rough consensus.  I believe that if we follow
those, a clear best decision will emerge.

  Ron

---

From: Adam Roach <[email-masked]>
Date: Fri, 08 Nov 2013 07:19:14 -0800

On 11/7/13 18:22, Gregory Maxwell wrote:
> MTI in discussion, because there exist_an option_, any option, to

Thanks for the clarification: I didn't get that out of your first 
message. For what it's worth, I agree with what you're saying here.

What I could make sense of was a suggestion that we turn to complete 
randomness for the decision at hand. And while that would actually make 
me happy[1], it struck me as patent nonsense from a process perspective.

> There are plenty of other arguments that can be made about the
> non-optimality of the 3929 panel process...

I tried really hard to make sure that any conversations about 3929 could 
begin playing out by giving what I think is a rather accessible 
description of that process back in Paris.

/a

___
[1] I just want an MTI [note: singular], and don't strongly care which 
one is selected. I *do* have a preference, but I don't think the 
arguments in favor of my preference are actually relevant to the IETF.

---

From: cowwoc <[email-masked]>
Date: Fri, 08 Nov 2013 10:56:58 -0500

Hi Tim,

On 08/11/2013 6:31 AM, Tim Panton wrote:
>> Using H.261 as MTI is a big win over no MTI because "no MTI" means 
>> we're forced to do transcoding, whereas H.261 as MTI means we can 
>> still do transcoding if we want, but we don't have to.
>>
>> And yes, I agree that a more ideal solution is to choose VP8 or H.264 
>> as MTI (or both) than H.261... but if worse comes to worse, I don't 
>> see a benefit to choosing "no MTI" over H.261.
>>
> Ok, I'll bite. (Despite having proposed H261 at the mic in Paris, I've 
> changed my mind in the meanwhile.)
>
> The H261 option makes _everyone_ equally unhappy.

That's the goal :) Really. Making everyone equally unhappy gives them 
incentive to compromise to get a better experience.

> The browser makers have to support and test 2 codecs - one of which 
> they don't want anyone to use.

It's either that or push the pain onto the application developers (no 
MTI = transcoding). Given that choice, I'd rather inconvenience a 
handful of browser developers over hundreds of thousands of application 
developers.

> The javascript folks have to do massive amounts of digging in the SDP 
> to try and work out if the remote offer of h264 is
> transcoded in a middlebox or is direct vp8 or perhaps that h261 is the 
> best option - or perhaps no video is applicable.

This problem is not specific to the choice of codec. SDP is a terrible 
choice as an API surface. The WG can improve the situation by providing 
an API call that retrieves this information on behalf of the user.

> The middlebox guys get to implement 3 different codecs, and test 
> transcode paths between all of them. The video mixer guys
> can't do video size switching well because h261 hasn't got that concept.

Transcoding is already very complex. Simplifying it is not one of my 
goals. And again, we're only talking about the minority case where 
you're forced to fallback on H.261 (think of it as having to fall back 
on TURN).

> The user gets a totally variable experience based on factors she cant 
> control. There will be lots of dissatisfied users who's
> first video call happened to be h261 and never go back to the service 
> - better to fail back to audio than connect with a poor experience.

The argument is H.261 is better than transcoding, as opposed to H.261 is 
better than VP8 or H.264. I'm *not* arguing the latter. If this turns 
out that H.261 is so terrible for their particular use-case (it should 
be fine for most), the application developer can still choose to do 
transcoding. Mandating H.261 as MTI just gives them an extra option they 
normally wouldn't have.

> Part of the problem is that O/A + SDP isn't a rich enough medium for 
> the application to make a sensible/correct decision.
> Given that we are stuck with OA+SDP for version 1.0 at least, lets not 
> make it worse by complicating the SDP and degrading the
> user experience at the same time.

I agree. My view remains that (regardless of the codec choice) WebRTC 
should provide an OO interface on top of SDP and ideally eliminate SDP 
from the API altogether. Even if we choose no MTI, people are going to 
want to dig into the SDP to find out if the connection ended up choosing 
VP8 or H.264. That's painful, whether or not H.261 is MTI.

> Sorry to be so negative.
> I'll try and come up with a more positive solution next :-)

No problem. I appreciate the feedback.

Gili

---

From: Adam Roach <[email-masked]>
Date: Fri, 08 Nov 2013 08:01:08 -0800

On 11/8/13 04:31, Ron wrote:
> ...what we had today was essentially "just a vote".  If it had been conclusive, that would have been great, but it wasn't...

Well, to be fair, it did involve a rather long discussion of the various 
factors impacting the decision. The show of hands was ostensibly an 
attempt to suss out whether the arguments had proven compelling enough 
to push forward with one codec over the other.

Sadly, the form of the question, when combined with the method of 
measurement, precluded doing so.

I'm not claiming that there was consensus in the room. I'm claiming that 
its presence would not have been detected by the methodology employed. 
Consider: if everyone in the room raised their hand for both options, 
Richard would have been compelled to call it "no consensus" even though 
that result would logically mean that no one objects to either option.

Clearly, that didn't happen.

On the other hand, what *did* happen was that we had roughly 50% of the 
room say that they were willing to live with H.264, and roughly 30% of 
the room say they were willing to live with VP8. This, after the chairs 
*strongly* *encouraged* people who could live with either option to 
raise their hands for both options. We didn't explicitly ask for who was 
in both camps (and those people at the front of the room facing the 
participants did nothing to gauge overlap), nor did we try to suss out 
who was abstaining by not raising their hand.

As a result, the numbers are meaningless. On one extreme: If those sets 
of people were completely disjoint, then we're nowhere near consensus. 
At the other extreme: if the set of people who could accept VP8 were a 
strict subset of the set of people who could accept H.264, then we would 
have obvious consensus and could move forward. I know that neither of 
these scenarios are true, but measuring where the participants fell in 
that continuum would have been the true measure of the sense of the room.

So, sadly, we learned nothing.

For the record, and I'm hoping others will follow suit (since, as you 
pointed out, consensus is measured on the list): I'm of the opinion that 
either of the two options on the table are acceptable[1][2].

/a

___
[1] I recognize that approaches other than H.264 and VP8 have been 
casually mentioned on-list; but, if an approach is so unpopular that it 
hasn't yet found a proponent willing to spend the meager amount of time 
necessary to type up and submit an internet draft advocating it, then I 
have to assume that its chances of reaching critical mass are 
approximately zero. I will not waste my time or yours favoring or 
rebutting them until someone gets serious about them.

[2] Ironically, I'm somewhat regretting that I indicated this in the 
room: I was trying to be accommodating to both positions, and I know 
several other people who did the same. Had the indications of support 
been more partisan, it's possible that one of the two camps would have 
been revealed to be in the rough.

---

From: Leon Geyser <[email-masked]>
Date: Fri, 8 Nov 2013 18:32:43 +0200

Does a draft need to be created to propose H.261 as MTI?
MPEG-1 Part 2 might also be an option.

On 8 November 2013 17:56, cowwoc <[email-masked]> wrote:

>    - If H.261 is MTI, you can still upgrade to VP8
>    - If H.261 is MTI, you can still upgrade to H.264
>    - If H.261 is MTI, you can still use transcoding to connect VP8 to
>    H.264
>
> simply settle on a codec with expired IPR such as H.261. H.261 is the codec
> everyone loves to hate but allow me to point out the following:
>
>
>  The browser makers have to support and test 2 codecs - one of which they
> don't want anyone to use.
>
>
> It's either that or push the pain onto the application developers (no MTI
> = transcoding). Given that choice, I'd rather inconvenience a handful of
> browser developers over hundreds of thousands of application developers.
>
>  The javascript folks have to do massive amounts of digging in the SDP to
> try and work out if the remote offer of h264 is
> choice as an API surface. The WG can improve the situation by providing an
> API call that retrieves this information on behalf of the user.
>
> goals. And again, we're only talking about the minority case where you're
> forced to fallback on H.261 (think of it as having to fall back on TURN).
>
> first video call happened to be h261 and never go back to the service -
> better to fail back to audio than connect with a poor experience.
>
>
> better than VP8 or H.264. I'm *not* arguing the latter. If this turns out
> that H.261 is so terrible for their particular use-case (it should be fine
> for most), the application developer can still choose to do transcoding.
> Mandating H.261 as MTI just gives them an extra option they normally
> wouldn't have.
>
>  Part of the problem is that O/A + SDP isn't a rich enough medium for the
> application to make a sensible/correct decision.
> should provide an OO interface on top of SDP and ideally eliminate SDP from
> the API altogether. Even if we choose no MTI, people are going to want to
> dig into the SDP to find out if the connection ended up choosing VP8 or
> H.264. That's painful, whether or not H.261 is MTI.
>
>  Sorry to be so negative.

---

From: Tim Panton <[email-masked]>
Date: Fri, 8 Nov 2013 11:31:33 +0000

On 8 Nov 2013, at 05:56, cowwoc <[email-masked]> wrote:

> 
> I'll bring up a related point that I brought up a few days ago (I changed to subject to avoid hijacking the thread).
> 
> Say we can't agree on whether to use VP8 or H.264 as MTI. We can then simply settle on a codec with expired IPR such as H.261. H.261 is the codec everyone loves to hate but allow me to point out the following:
> If H.261 is MTI, you can still upgrade to VP8
> If H.261 is MTI, you can still upgrade to H.264
> If H.261 is MTI, you can still use transcoding to connect VP8 to H.264
> Using H.261 as MTI is a big win over no MTI because "no MTI" means we're forced to do transcoding, whereas H.261 as MTI means         we can still do transcoding if we want, but we don't have to.
> And yes, I agree that a more ideal solution is to choose VP8 or H.264 as MTI (or both) than H.261... but if worse comes to worse, I don't see a benefit to choosing "no MTI" over H.261.

Ok, I'll bite. (Despite having proposed H261 at the mic in Paris, I've changed my mind in the meanwhile.)

The browser makers have to support and test 2 codecs - one of which they don't want anyone to use.

The javascript folks have to do massive amounts of digging in the SDP to try and work out if the remote offer of h264 is
transcoded in a middlebox or is direct vp8 or perhaps that h261 is the best option - or perhaps no video is applicable.

The middlebox guys get to implement 3 different codecs, and test transcode paths between all of them. The video mixer guys
can't do video size switching well because h261 hasn't got that concept.

The user gets a totally variable experience based on factors she cant control. There will be lots of dissatisfied users who's
first video call happened to be h261 and never go back to the service - better to fail back to audio than connect with a poor experience.

Part of the problem is that O/A + SDP isn't a rich enough medium for the application to make a sensible/correct decision.
Given that we are stuck with OA+SDP for version 1.0 at least, lets not make it worse by complicating the SDP and degrading the 
user experience at the same time.

Sorry to be so negative. 

T.

>> wonder after your message if anyone else would dare.)

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk

---

From: Tim Panton <[email-masked]>
Date: Fri, 8 Nov 2013 11:31:33 +0000

Sorry to be so negative. 

T.

---

From: Tim Panton <[email-masked]>
Date: Fri, 8 Nov 2013 16:08:06 +0000

On 8 Nov 2013, at 15:56, cowwoc <[email-masked]> wrote:

> The argument is H.261 is better than transcoding, as opposed to H.261 is better than VP8 or H.264. I'm *not* arguing the latter. If this turns out that H.261 is so terrible for their particular use-case (it should be fine for most), the application developer can still choose to do transcoding. Mandating H.261 as MTI just gives them an extra option they normally wouldn't have.

And that's the key difference between us, and where I changed my mind. It isn't H261 vs nothing, it is H261 vs flash. 
I do not want to be in a position where people can legitimately say of an webRTC browser "it's better if you use flash".
Also, more options == bad thing. It means more testing, more crufty code, more errors.

The final point against H261 is that it really isn't going to work well in 3g networks or 'edge of wifi' environments with 
constrained and lossy networks. That's where the growth is. 
T.

---

From: Leon Geyser <[email-masked]>
Date: Fri, 8 Nov 2013 19:05:18 +0200

Hi Tim,

So the question is in the small likelihood that VP8/H.264 can't be
negotiated and there is no transcoding in-between, is it better to show no
video than some video?

>>The final point against H261 is that it really isn't going to work well
in 3g networks or 'edge of wifi' environments with
>>constrained and lossy networks. That's where the growth is.
How does dropping frames on H.264/VP8 differ from dropping frames on H.261?
Hope it isn't a dumb question.

On 8 November 2013 18:08, Tim Panton <[email-masked]> wrote:

> And that's the key difference between us, and where I changed my mind. It
> isn't H261 vs nothing, it is H261 vs flash.
> I do not want to be in a position where people can legitimately say of an
> webRTC browser "it's better if you use flash".
> The final point against H261 is that it really isn't going to work well in
> 3g networks or 'edge of wifi' environments with

---

From: "cb.list6" <[email-masked]>
Date: Fri, 8 Nov 2013 09:25:27 -0800

>>> Using H.261 as MTI is a big win over no MTI because "no MTI" means
we're forced to do transcoding, whereas H.261 as MTI means we can still do
transcoding if we want, but we don't have to.
>>> And yes, I agree that a more ideal solution is to choose VP8 or H.264
as MTI (or both) than H.261... but if worse comes to worse, I don't see a
benefit to choosing "no MTI" over H.261.

I disagree that "no MTI = transcode"

There is no scenario I would permit transcoding as normal mode of
operations.  If sdp cannot find a common codec, fall back to voice-only.
And, at the implementation discretion, offer the user advice about choosing
a browser.

CB

---

From: <[email-masked]>
Date: Fri, 8 Nov 2013 18:25:33 +0000

Adam Roach wrote:
> I'm not claiming that there was consensus in the room. I'm claiming that its
> presence would not have been detected by the methodology employed.
> Consider: if everyone in the room raised their hand for both options, Richard
> would have been compelled to call it "no consensus" even though that result
> would logically mean that no one objects to either option.
>

I agree that was the problem with how the questions were set. It was impossible to determine how many people were actually OK with either codec, and how many with just one of them. If we are to repeat the consensus call on the list, we will at least learn the distribution between "H.264 and VP8" vs. "Only H.264" vs. "Only VP8". I would suggest that if either of the "Only X" groups is relatively small, we could declare rough consensus. 
 
> room say that they were willing to live with H.264, and roughly 30% of the
> room say they were willing to live with VP8. 

Yes, so it would be useful to know what the proportion of those people raising their hands for just one vs. both options actually was. 

Markus

---

From: cowwoc <[email-masked]>
Date: Fri, 08 Nov 2013 13:53:31 -0500

On 08/11/2013 12:25 PM, cb.list6 wrote:
> operations.  If sdp cannot find a common codec, fall back to 
> voice-only. And, at the implementation discretion, offer the user 
> advice about choosing a browser.
>
> CB
>

:) That doesn't work. Dropping video is equivalent to dropping a call. 
How would you like it if the roles were reversed and we couldn't agree 
on an MTI audio? Would it be acceptable to "simply drop the audio" and 
let the participants mime their way through the call? The entire reason 
I'm starting a WebRTC video call is because I want video. Otherwise, I'd 
pick up the phone.

Also, offering users "advice" about choosing a browser is also a 
non-starter. If 3 people join a call with IE, Firefox, and Chrome 
respectively who is on the "right" browser? One is not necessarily 
better than the other, other than we need them to agree on a codec. Some 
people may not have the necessary permission to switch browsers (work). 
Others are very touchy about their browsers. Asking them to switch isn't 
going to go down well.

Gili

---

From: "cb.list6" <[email-masked]>
Date: Fri, 8 Nov 2013 12:25:13 -0800

> :) That doesn't work. Dropping video is equivalent to dropping a call.
How would you like it if the roles were reversed and we couldn't agree on
an MTI audio? Would it be acceptable to "simply drop the audio" and let the
participants mime their way through the call? The entire reason I'm
starting a WebRTC video call is because I want video. Otherwise, I'd pick
up the phone.

It works today.  Sometimes skype and hangouts offer video, sometimes only
audio.

CB
non-starter. If 3 people join a call with IE, Firefox, and Chrome
respectively who is on the "right" browser? One is not necessarily better
than the other, other than we need them to agree on a codec. Some people
may not have the necessary permission to switch browsers (work). Others are
very touchy about their browsers. Asking them to switch isn't going to go
down well.

---

From: cowwoc <[email-masked]>
Date: Fri, 08 Nov 2013 17:21:47 -0500

On 08/11/2013 3:25 PM, cb.list6 wrote:
>
> On Nov 8, 2013 10:53 AM, "cowwoc" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> > :) That doesn't work. Dropping video is equivalent to dropping a 
> call. How would you like it if the roles were reversed and we couldn't 
> agree on an MTI audio? Would it be acceptable to "simply drop the 
> audio" and let the participants mime their way through the call? The 
> entire reason I'm starting a WebRTC video call is because I want 
> video. Otherwise, I'd pick up the phone.
> >
>
> It works today.  Sometimes skype and hangouts offer video, sometimes 
> only audio.
>

     The only time I was only offered audio was when the user had no 
webcam :) In any case, I'm happy to agree with you on the following:

No Video MTI = No video or transcoding must be used

     If the community believes this is preferable to the alternatives, 
so be it.

Gili

---

From: Ron <[email-masked]>
Date: Sat, 9 Nov 2013 17:07:54 +1030

On Fri, Nov 08, 2013 at 08:01:08AM -0800, Adam Roach wrote:
> Well, to be fair, it did involve a rather long discussion of the
> various factors impacting the decision. The show of hands was
> ostensibly an attempt to suss out whether the arguments had proven
> compelling enough to push forward with one codec over the other.

Right, I didn't mean that to sound critical of the chairs, I had my
chance to suggest alternatives when they first proposed this too,
I only meant that we tried something, it didn't get us a resolution,
but that failure is not the same thing as the working group reaching
the end of its rope for establishing consensus by more normal means.

We have still unanswered objections, I don't see how invoking any
alternative method can ignore those until they are answered (and
then also seek to call the result consensus).

And since the chairs asked for suggestions on "where to go from here"
I'm suggesting we get answers to those things and continue with a more
usual approach to achieving consensus on the list.  If people can't
answer them in a satisfactory way, they obviously remain blockers to
accepting that option as having consensus.

> On the other hand, what *did* happen was that we had roughly 50% of
> the room say that they were willing to live with H.264, and roughly
> 30% of the room say they were willing to live with VP8. This, after
> the chairs *strongly* *encouraged* people who could live with either
> option to raise their hands for both options. We didn't explicitly
> ask for who was in both camps (and those people at the front of the
> room facing the participants did nothing to gauge overlap), nor did
> we try to suss out who was abstaining by not raising their hand.

The jabber room by contrast, split more like 80/20 in favour of VP8.
And unless I'm missing someone there was no overlap there at all.

(And was endcapped with the comment: "So, those that actually use the
 Internet, by all data, support option #2, VP8."  :)

I still don't think we can call anything conclusive from that, except
the two groups were clearly not representative of each other in any
statistically significant way, and "dance with the one that brung ya"
and all that ...

> As a result, the numbers are meaningless. On one extreme: If those
> sets of people were completely disjoint, then we're nowhere near
> consensus. At the other extreme: if the set of people who could
> accept VP8 were a strict subset of the set of people who could
> accept H.264, then we would have obvious consensus and could move
> forward. I know that neither of these scenarios are true, but
> measuring where the participants fell in that continuum would have
> been the true measure of the sense of the room.
> 
> For the record, and I'm hoping others will follow suit (since, as
> you pointed out, consensus is measured on the list): I'm of the
> opinion that either of the two options on the table are
> acceptable[1][2].

I'd like to reserve my final call until we've seen the answers to
the objections on the list, but a choice with definite unresolved
blockers fairly obviously can't be acceptable as consensus.

  Ron