Subject: [rtcweb] Video Codec Selection Plan

From: Ted Hardie <[email-masked]>
Date: Fri, 13 Sep 2013 09:52:24 -0700

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

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 13 Sep 2013 09:59:14 -0700

1. Please explain why this decision is an IETF decision and not a W3C 
decision, given that it is a choice about what to mandate in the 
presentation layer as codec, NOT what to mandate for the on-the-wire 
transport format (which has already been selected as DTLS-SRTP with an 
appropriate IETF payload based on the application)

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?

Matthew Kaufman

On 9/13/2013 9:52 AM, Ted Hardie wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 13 Sep 2013 10:11:47 -0700

Ted --
The H.264 vs. VP8 discussion has at this point been "overtaken by events", so that the proposed plan below would be a waste of everybody's time, about as relevant as debating the fashion merits of bell bottoms versus nehru jackets.  
With Google having announced plans to implement VP9 (potentially with SVC), and with the recent ratification of H.265, the industry has moved on, and so should RTCWEB. 
Date: Fri, 13 Sep 2013 09:52:24 -0700
From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]
Subject: [rtcweb] Video Codec Selection Plan

WG,

consensus.

over the other.

regards,

Magnus,  Cullen, and Ted

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 13 Sep 2013 19:21:39 +0200

Do not take me wrong, but IMHO this decision should be taken by the W3C
WebRTC group.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Ralph Giles <[email-masked]>
Date: Fri, 13 Sep 2013 10:41:28 -0700

> appropriate IETF payload based on the application)

This working group selected OPUS and G711 as MTI audio codecs to avoid
session negotiation failure. Session negotiation being part of the
WebRTC protocol suite being specified within the IETF.

The same arguments apply to a video codec. If we can find rough
consensus to specify one it is useful to do so.

 -r

---

From: Ted Hardie <[email-masked]>
Date: Fri, 13 Sep 2013 10:47:51 -0700

On Fri, Sep 13, 2013 at 10:11 AM, Bernard Aboba
<[email-masked]>wrote:

> Ted --
>
> The H.264 vs. VP8 discussion has at this point been "overtaken by events",
> so that the proposed plan below would be a waste of everybody's time, about
> as relevant as debating the fashion merits of bell bottoms versus nehru
> jackets.
>
> With Google having announced plans to implement VP9 (potentially with
> SVC), and with the recent ratification of H.265, the industry has moved on,
> and so should RTCWEB.
>
>
Hi Bernard,

The agreement to specify a mandatory-to-implement video codec to avoid
negotiation failure is a very long standing one.  If you believe the MTI
should be VP9 or H.265, you are welcome to propose either; please do so,
however, in the form of a draft by October 6th so we can move forward
knowing that it is your proposal.

regards,

Ted Hardie

> ------------------------------
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 13 Sep 2013 20:00:05 +0200

> consensus to specify one it is useful to do so.

One error does not justify another one.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 13 Sep 2013 11:06:40 -0700

Ted said:
"If you believe the MTI should be VP9 or H.265, you are welcome to propose either; please do so"
[BA] I am not prepared to argue for (or against) either VP9 or H.265 at this time, and I believe that many industry colleagues would say the same.  In a way, that is the point -- minds have not yet been made up, as in (many cases) they have been on the topic of VP8 vs. H.264.  
"It's not only generals who fight the last war" -- Dan Gardner

---

From: Adam Roach <[email-masked]>
Date: Fri, 13 Sep 2013 13:07:01 -0500

On 9/13/13 12:11, Bernard Aboba wrote:
> SVC), and with the recent ratification of H.265, the industry has 
> moved on...

At which point we need to ask whether we're trying to pick "the best 
possible codec" or "a suitable codec." If the former, then your point is 
relevant. But I don't think there's consensus (rough or otherwise) 
around "best possible codec" being the goal.

/a

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 13 Sep 2013 19:03:24 +0000

That topic was discussed between W3C and IETF when forming the two WG and very clear decisions was made that the W3C would not make that decision. Part of the reasons had to do with the history of a very similar argument at W3C around the video tag. 

On Sep 13, 2013, at 11:21 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> Do not take me wrong, but IMHO this decision should be taken by the W3C WebRTC group.
> 
>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 13 Sep 2013 19:42:44 +0000

The W3C was the right venue for the video tag codec discussion, just like it is for this video codec discussion.

I'll note that the chairs have repeatedly pointed out that the scope is explicitly "browsers"

Matthew Kaufman

(Sent from my iPhone)

---

From: Pete Resnick <[email-masked]>
Date: Fri, 13 Sep 2013 13:50:32 -0500

Big caveat as I post this: I am speaking strictly as an IETF 
participant. In particular:

- I am not speaking as an AD. I am not the responsible AD for this WG, 
and the chairs can go ahead with their proposed path forward consulting 
with the WG's responsible AD, whatever they think of what I say below. 
No implication of any authority should be taken here.

- Though my comments here are clearly informed by the draft some of you 
know that I'm working on regarding consensus, that draft does not 
represent accepted theory in the IETF, so I'm not appealing to it as 
some sort of "given truth" on this.

I'm just another participant in the room.

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):

> 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. 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; 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. 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. 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.

Put me down as one voice who objects to the proposed procedure.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Ted Hardie <[email-masked]>
Date: Fri, 13 Sep 2013 13:45:36 -0700

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 <[email-masked]>wrote:

> Big caveat as I post this: I am speaking strictly as an IETF participant.
> In particular:
>
>
<SNIP>

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

> 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

> Pete Resnick<http://www.qualcomm.**com/~presnick/<http://www.qualcomm.com/~presnick/>
> >
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Pete Resnick <[email-masked]>
Date: Fri, 13 Sep 2013 16:34:46 -0500

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 
> <[email-masked] <mailto:[email-masked]>> 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.

> 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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 13 Sep 2013 15:05:22 -0700

On Fri, Sep 13, 2013 at 2:34 PM, Pete Resnick <[email-masked]>wrote:

> **
Trust me, the food was too good to guzzle.

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

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

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

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

> As above, I worry about how the determination is made. Once made, all is
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/>
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Sat, 14 Sep 2013 00:26:35 +0200

On Fri, 13 Sep 2013 13:45:36 -0700

> and doesn't do anything to move things forward.

Open source implementations are not the issue (we have x264 for that), licensing is.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: "Roni Even" <[email-masked]>
Date: Sat, 14 Sep 2013 01:35:27 +0300

Ted,

What is the difference between the proposed questions and the ones that were
asked in Orlando, we had documents and presentations and could not reach a
decision in Orlando. 

If nothing changed we can start with the proposal to use alternative
decision process.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ted Hardie
Sent: 13 September, 2013 7:52 PM
To: [email-masked]; Cullen Jennings; Magnus Westerlund
Subject: [rtcweb] Video Codec Selection Plan

WG,

regards,

Magnus,  Cullen, and Ted

---

From: Bossiel <[email-masked]>
Date: Sat, 14 Sep 2013 01:19:48 +0200

Sent from my iPhone

> 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,

---

From: Simon Perreault <[email-masked]>
Date: Sat, 14 Sep 2013 12:01:36 +0200

Le 2013-09-14 01:19, Bossiel a écrit :
>>> Cisco, for example, graciously agreed to provide an open
>>> objections that none were available
>>

I understand that the issue is the licensing of the IPR, not of the code.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Bossiel <[email-masked]>
Date: Sat, 14 Sep 2013 13:00:43 +0200

Sent from my iPhone

> I understand that the issue is the licensing of the IPR, not of the code.
Both

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Sep 2013 08:05:27 +0200

On 2013-09-14 00:35, Roni Even wrote:
> Ted,
> 
> What is the difference between the proposed questions and the ones that
> were asked in Orlando, we had documents and presentations and could not
> reach a decision in Orlando.
> 

Roni,

In Orlando we took only a straw poll as it was clear to the chairs that
people would have objected against a consensus call. Reasons for that
include the lack of licensing terms related to the IPR that Google from
other IPR right holders.

We like to avoid be in the same situation and be unable to hold a formal
consensus call. Thus, we have set an early dead line for any proposals
to enable all WG participants to review the proposals and raise any
issues on the mailing list. Thus enabling such issues to be responded to
and possibly resolved.

Cheers

Magnus Westerlund
WG chair

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Chris Wendt <[email-masked]>
Date: Mon, 16 Sep 2013 09:20:10 -0400

I would argue that because we have selected Opus and G.711, we have already satisfied the charter requirements.

  6.  Define a set of media formats that must or should be supported by
        a client to improve interoperability.

Can we move on and focus time on more relevant issues?

-Chris

On Sep 13, 2013, at 1:11 PM, Bernard Aboba <[email-masked]> wrote:

> _______________________________________________ rtcweb mailing list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "cb.list6" <[email-masked]>
Date: Mon, 16 Sep 2013 10:37:58 -0700

On Sep 16, 2013 6:22 AM, "Chris Wendt" <[email-masked]> wrote:
>
>
> I would argue that because we have selected Opus and G.711, we have
already satisfied the charter requirements.
> Can we move on and focus time on more relevant issues?

+1, the mti video is the already agreed audio-only.

If your video does not work, you and the calling/called party can discuss
about the ipr issues and politics that limit your communications

CB
>> The H.264 vs. VP8 discussion has at this point been "overtaken by
events", so that the proposed plan below would be a waste of everybody's
time, about as relevant as debating the fashion merits of bell bottoms
versus nehru jackets.
>>
>> ________________________________

---

From: cowwoc <[email-masked]>
Date: Tue, 17 Sep 2013 14:54:28 -0400

Hi Ted,

     Seeing as this discussion stems from licensing concerns, I like to 
propose the following alternative:

 1. Mandate a video codec whose IPR has expired. I agree that video
    quality will degrade, which brings me to the next point.
 2. Provide a negotiation mechanism which would allow peers to "upgrade"
    to a superior (optionally-implemented) video codec.

     This will allow us to support VP8, VP9, H264, H265 or whatever 
other codec people like without the fear of transcoding or IPR. I 
believe that in most cases negotiation will succeed in upgrading to a 
superior codec. It will also encourage (as opposed to force) vendors to 
support each other's codecs, which is the right way to go in light of 
the political nature of this decision.

Gili

Gili

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Sep 2013 19:36:25 +0000

Hi,

SDP Offer/Answer is used to negotiate codecs etc, so the API (JSEP) already provides such negotiation mechanism.

(Obviously the peers also need to negotiate with each other, but whatever protocol is used for that is outside the scope.)

Regards,

Christer

Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta cowwoc
Lähetetty: 17. syyskuuta 2013 21:54
Vastaanottaja: [email-masked]
Aihe: Re: [rtcweb] Video Codec Selection Plan

Hi Ted,

    Seeing as this discussion stems from licensing concerns, I like to propose the following alternative:

  1.  Mandate a video codec whose IPR has expired. I agree that video quality will degrade, which brings me to the next point.
  2.  Provide a negotiation mechanism which would allow peers to "upgrade" to a superior (optionally-implemented) video codec.

    This will allow us to support VP8, VP9, H264, H265 or whatever other codec people like without the fear of transcoding or IPR. I believe that in most cases negotiation will succeed in upgrading to a superior codec. It will also encourage (as opposed to force) vendors to support each other's codecs, which is the right way to go in light of the political nature of this decision.

Gili

Gili

rtcweb mailing list

[email-masked]<mailto:[email-masked]>

---

From: cowwoc <[email-masked]>
Date: Tue, 17 Sep 2013 15:47:58 -0400

So then the only question is: is there a reasonable video codec 
whose IPR has expired that we can agree on?

     My goal is to displease everyone equally. By picking a neutral 
codec, acknowledging that it displeases all parties in some way, we 
should be able to defuse most of the politics surrounding the decision.

Gili

On 17/09/2013 3:36 PM, Christer Holmberg wrote:
>
> Hi,
>
> SDP Offer/Answer is used to negotiate codecs etc, so the API (JSEP) 
> already provides such negotiation mechanism.
>
> (Obviously the peers also need to negotiate with each other, but 
> whatever protocol is used for that is outside the scope.)
>
> Regards,
>
> Christer
>
> *Lähettäjä:[email-masked] [mailto:[email-masked]] 
> *Puolesta *cowwoc
> *Lähetetty:* 17. syyskuuta 2013 21:54
> *Vastaanottaja:* [email-masked]
> *Aihe:* Re: [rtcweb] Video Codec Selection Plan
>
> Hi Ted,
>
>  2. Provide a negotiation mechanism which would allow peers to
>     "upgrade" to a superior (optionally-implemented) video codec.
>
> superior codec. It will also encourage (as opposed to force) vendors 
> to support each other's codecs, which is the right way to go in light 
> of the political nature of this decision.
>
> Gili
>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: John Leslie <[email-masked]>
Date: Tue, 17 Sep 2013 15:53:26 -0400

>    quality will degrade, which brings me to the next point.

   This is what I support. It won't be that long before whatever we
mandate will be obsolete anyway...

   But the chairs have determined we shall do one more round of duking
it out between H.264 and VP8. To get any other codec considered this
round, you must write a draft proposing it and stating its benefits.

   I do not choose to do so.

   Perhaps we _will_ choose one of these front-runners...

   Regardless, folks seem determined to argue the technical benefits
of these front-runners; and a number of us hold pretty strong opinions
of which of these is "better". I don't wish to complicate that
argument.

   YMMV, of course...

--
John Leslie <[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Sep 2013 13:10:26 -0700

>    quality will degrade, which brings me to the next point.
To propose a video codec, please write a draft before the deadline and put
forward the technical details you're proposing (if there are profiles, for
example, which profile).  Saying you want this on the list isn't enough
information for folks to judge the proposal.  This is why we are insisting
on drafts at a deadline that gives folks the opportunity to review the
proposal.

>    1. Provide a negotiation mechanism which would allow peers to
This is a base part of the system.

Ted

>     This will allow us to support VP8, VP9, H264, H265 or whatever other
> codec people like without the fear of transcoding or IPR. I believe that in
> most cases negotiation will succeed in upgrading to a superior codec. It
> will also encourage (as opposed to force) vendors to support each other's
> codecs, which is the right way to go in light of the political nature of
> this decision.
>
> Gili
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 17 Sep 2013 13:18:29 -0700

> mandate will be obsolete anyway...

[BA] I agree that the VP8 vs. H.264 discussion is past it's due date.  However, starting a discussion of even older, completely obsolete codecs that no browser vendor has shown an interest in doesn't seem like a better choice.

>   I do not choose to do so.

[BA] Thank you for your leadership on this. Now if everyone else would follow your lead we can recover the time for more productive pursuits :)

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Sep 2013 17:13:05 -0700

On Tue, Sep 17, 2013 at 11:54 AM, cowwoc <[email-masked]> wrote:

> Negotiation has always been part of the design. The sole question is which
codec is mandatory to implement, not which is the sole codec to be mandated.

-Ekr

---

From: Leon Geyser <[email-masked]>
Date: Wed, 18 Sep 2013 10:39:17 +0200

Anyone willing to create a draft for H.261?

---

From: Monty Montgomery <[email-masked]>
Date: Wed, 18 Sep 2013 04:49:29 -0400

I'll see your h.261 and raise one Theora.  At least it has one hell of
an encoder.

Cheers,
Monty

On Wed, Sep 18, 2013 at 4:39 AM, Leon Geyser <[email-masked]> wrote:
>>> Mandate a video codec whose IPR has expired. I agree that video quality
>>> will degrade, which brings me to the next point.
>>> Provide a negotiation mechanism which would allow peers to "upgrade" to a
>>> superior (optionally-implemented) video codec.
>>

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Wed, 18 Sep 2013 14:32:13 -0400

I was thinking if we're going to go with an older, non-IPR-encumbered
codec, Theora is the obvious choice, because it's been around about as
long as anything currently in use and has never had it's IPR seriously
challenged.

The encoder is being actively developed and has long since surpassed
pretty-much everything aside from H.264 and VP8 that are in common use
nowadays.

The fact that it takes much less CPU time to decode compared with other
modern codecs is also a plus.

Theora is also used in Elphel camera devices, so it's been used in
hardware as well (granted, those are not "burned-in-silicon" devices).

Efficiency wise, for talking-head scenarios (a common use case), I think
Theora will likely do quite well.

-- 
Libre Video
http://librevideo.org

---

From: Gili <[email-masked]>
Date: Sat, 21 Sep 2013 13:42:40 -0400

On 9/17/2013 4:10 PM, Ted Hardie wrote:
> On Tue, Sep 17, 2013 at 11:54 AM, cowwoc <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Ted,
>
>         Seeing as this discussion stems from licensing concerns, I
>     like to propose the following alternative:
>
>      1. Mandate a video codec whose IPR has expired. I agree that
>         video quality will degrade, which brings me to the next point.
>
>
> To propose a video codec, please write a draft before the deadline and 
> put forward the technical details you're proposing (if there are 
> profiles, for example, which profile).  Saying you want this on the 
> list isn't enough information for folks to judge the proposal.  This 
> is why we are insisting on drafts at a deadline that gives folks the 
> opportunity to review the proposal.

Ted,

     I understand, but unfortunately I don't have the bandwidth to 
author such a draft so I'm out. However, I will support anyone who 
decides go ahead (with H261, Theora, etc).

Gili