Subject: [rtcweb] Proposed Video Selection Process

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Nov 2013 17:51:00 +0100

WG,

The WebRTC ecosystem needs to avoid interoperability failure to grow
optimally.  The RTCWEB working group took on the task of establish Audio
and Video MTI codecs as part of meeting that need. We have not succeeded
in finishing that task for video using normal IETF process, but it is
still important.

We (WG chairs) are proposing that the working group consent to a method
that will establish an MTI, even if the MTI chosen does not have rough
consensus.  We would far prefer the normal IETF process, but it is not
proving workable for this selection.

We initially proposed a method from RFC 3929 (external review team), but
now believe that the working group would not consent to that method.
Instead we are proposing a method that leaves the decision in the hands
of the WG.

The method we propose is based on Instant-runoff voting,
http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
understanding that the choice will be the winner according to the
Instant-runoff voting process.

The steps in the proposed process are these (1-5):

1) Establish a final list of alternatives, based on the WG's input to
Gonzalo's email on the 13th of November that requires any additions to
provided by end of the 27th of November.

2) Establish those eligible to vote.  Any participant in the
working group process either electronically or in-person as of yesterday
(20th of November). Who has participated in the Working group process
will be anyone that can be identified from:
 - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
   an interim meeting since the WG's creation.
 - posting of at least one email to the RTCWEB mailing list

The voter must at time of voting prove their eligibility, by pointing to
the mail archive or a particular blue sheet/meeting. Please verify your
own eligibility.

3) Start the the voting period. Those eligible and willing to vote send
their ballot to a vote collector (Matt Lepinski, former Nomcom chair)
within two weeks using email. The vote collector will check when
receiving a ballot the that the voter is eligible and send a
confirmation email on receiving the ballot. During the balloting period
the vote collector will keep all ballots secret.

Balloting:
 - The voter MUST rank ALL alternatives in their ballot from the most
   preferred, marked with rank 1, the second most with 2, all the way
   to the least preferred marked with rank N.

4) When the voting period is over the ballot collector will publish the
results as well as all ballots, including the voters name to the RTCWEB
WG mailing list. This enables all voting individuals to verify that
their ballot is unmodified. And allows anyone to verify the result of
the vote.

5) The selection is recorded in the drafts.

--- End of Process Proposal ---

This message initiates the first step in the working group consensus
call process. Namely a one week comment and discussion period for the
above process.

After that week the WG chairs will update, if necessary, the proposal.
Then using the normal IETF process in which anyone is eligible to
participate, the chairs will ask for (rough) consensus to adopt this
extraordinary process to achieve the working group's stated goals.  The
end date for this consensus call is 2-weeks after the announcement of
the consensus call.

If the working group does not consent to using this extraordinary
process, we will hold a consensus call if the WG can accept
"WebRTC entities MUST support at least one of H.264 or VP8.".

If there is failure to establish consensus even for this statement, the
chairs conclude that the WG can't establish what to say about a MTI
video codec.

The WG Chairs

Magnus Westerlund
Cullen Jennings
Ted Hardie

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 21 Nov 2013 18:59:05 +0100

>--- End of Process Proposal ---

I think this needs to say how invalid ballots are handled. It seems easy
to assign the same rank twice, for instance.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 21 Nov 2013 10:09:09 -0800

On 21 November 2013 08:51, Magnus Westerlund <[email-masked]
> wrote:

> the mail archive or a particular blue sheet/meeting. Please verify your
What about those who are not on the blue sheets because we participated
(and at the last meeting voted/hummed on this issue) through Jabber?

Regards,

Peter

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 21 Nov 2013 10:11:34 -0800

> to assign the same rank twice, for instance.

Good point - would you be OK if the  vote collector notices a problem, they can email the voter and see if they want to correct it, but any invalid ballots that are not correct by the end of voting period will be discarded ?

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 21 Nov 2013 10:14:52 -0800

If there are any people in that category that wish to vote, could they email the chairs with full name and affiliation. That would make it easier to figure out how to deal with this issue. I think it will be hard to take votes from someone that will not provide the information required to be on a blue sheet due to questions about double counting. 

On Nov 21, 2013, at 10:09 AM, Peter Dunkley <[email-masked]> wrote:

> 
> On 21 November 2013 08:51, Magnus Westerlund <[email-masked]> wrote:
> 
> What about those who are not on the blue sheets because we participated (and at the last meeting voted/hummed on this issue) through Jabber?
> 
> Regards,
> 
> Peter
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Thu, 21 Nov 2013 18:17:04 +0000

If they participated in the mailing list they would be included. I can't imagine that simply logging into a chat room in order to vote qualifies you.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 21 Nov 2013 19:21:08 +0100

* Cullen Jennings wrote:
>Good point - would you be OK if the  vote collector notices a problem, 
>they can email the voter and see if they want to correct it, but any 
>invalid ballots that are not correct by the end of voting period will be 
>discarded ?

That would be acceptable.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 21 Nov 2013 10:24:20 -0800

This is a topic that is important to me (and the company I work for) that I
have been following closely, but each time I see an issue on the list I
would like to comment on it someone has already said what I would say.

There will have been many people in the room at the meetings (and
presumably on the blue sheets) who have never posted on this list and these
people get a vote.  The only difference between them and me will be that
they work for a company that has the budget (both in terms of money and
time) to send them there.

If you allow those who have been in the room and not posted to vote, but
those of us who were only able to participate online cannot vote, you are
in effect giving preference to organisations and individuals with bigger
budgets.  That would hardly seem fair.

Regards,

Peter

On 21 November 2013 10:17, Jeremy Laurenson (jlaurens)
<[email-masked]>wrote:

> If they participated in the mailing list they would be included. I can't
> imagine that simply logging into a chat room in order to vote qualifies you.
>
>

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 21 Nov 2013 11:26:31 -0700

> Instant-runoff voting process.

I have the greatest respect for the chairs, but this is an engraved
invitation for people to appeal whatever decision might be reached.

More fundamentally: Voting? At the IETF?? Really?!?

I sincerely hope we can figure out a better process...

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 21 Nov 2013 11:43:18 -0700

On 11/21/13 11:26 AM, Peter Saint-Andre wrote:
>> understanding that the choice will be the winner according to
>> the Instant-runoff voting process.
> 
> I have the greatest respect for the chairs, but this is an
> engraved invitation for people to appeal whatever decision might be
> reached.
> 

In an effort to post something more productive, I suggest that we at
least explore the idea of two MTI codecs, as we already have done for
audio. This was not an option in Vancouver because no one wrote an
Internet-Draft about it before the deadline, but I got the sense in
the room that at least some people would have preferred this approach,
if only to put an end to our long working group nightmare.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Justin Uberti <[email-masked]>
Date: Thu, 21 Nov 2013 10:56:25 -0800

Following an IETF meeting on Jabber doesn't count as participating?

The "big guy vs little guy" narrative continues...

---

From: Adam Roach <[email-masked]>
Date: Thu, 21 Nov 2013 10:58:52 -0800

On 11/21/13 08:51, Magnus Westerlund wrote:
> consensus.

Although this is phrased very carefully, I think this email 
inadvertently glosses over the fact that this is a formal call for 
consensus around the proposed approach. I also think you need to be 
crystal clear -- and I'm going to borrow RFC 3929's language here -- 
"that the working group's consensus to use [this specific] method stands 
in for the working group's consensus on the technical issue."

I wanted to point this out because it would be very easy to accidentally 
read the email as an announcement for the way the codec will be 
selected, rather than a call for consensus around a proposed approach.

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Nov 2013 20:11:51 +0100

Forking this thread, and leaving aside all consideration of whether the 
IETF should do voting, whether the electorate is the right electorate 
for the decision and so on:

I wonder if Instant Runoff is the right choice for this situation.
Instant Runoff means that when you don't get a majority for anything, 
you drop the lowest-ranked candidate and distribute the ballots that had 
this as their #1 across the other candidates.

This has the property that in a polarized situation, compromises may get 
dropped out of the running before the alternatives that they might serve 
as a compromise between.

In this case, I'd favour a Condorcet-compatible method, such as Schulze; 
it provides the guarantee that if a choice is preferred by a majority of 
the participants over every other choice, it will always be chosen.

http://en.wikipedia.org/wiki/Condorcet_method#Schulze_method

On 11/21/2013 05:51 PM, Magnus Westerlund wrote:
> google.com

---

From: Adam Roach <[email-masked]>
Date: Thu, 21 Nov 2013 11:13:11 -0800

> The "big guy vs little guy" narrative continues...

I think that's a bit specious. If someone is following the issue at such 
a distance that they haven't expressed an opinion on the mailing list, I 
can't see how taking a vote from them counts as anything other than 
simple, old-fashioned ballot stuffing.

I'll take it one step further. I find the prospect that we're allowing 
blue sheets to stand in for participation to be highly questionable: 
letting the tourists vote is weighting the opinion of demonstrably 
uninvolved (or less-involved) parties at the same level as those who 
have actually been working on the topic. I do not think that a 
blue-sheet sign in without any on-list participation should be 
sufficient to participate in the kind of process the chairs are proposing.

Or perhaps I'm missing something. Is there something about the 
capabilities of "the little guy" that makes sending an email an 
unrealistically high barrier to entry?

/a

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 21 Nov 2013 20:18:56 +0100

> If there are any people in that category that wish to vote, could they email the chairs with full name and affiliation. That would make it easier to figure out how to deal with this issue. I think…

There is an issue with the jabber logs: they only record room nicknames, 
not the full JID. So there is no way to tell who that "stpeter" or "EKR" 
guy really is.

That is certainly something that needs to be improved in the future.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Nov 2013 11:19:12 -0800

In order to forestall the inevitable voting nerd thread, allow me to
point to:

http://en.wikipedia.org/wiki/Arrow%27s_theorem

-Ekr

On Thu, Nov 21, 2013 at 11:11 AM, Harald Alvestrand <[email-masked]>wrote:

> IETF should do voting, whether the electorate is the right electorate for
> the decision and so on:
>
> Instant Runoff means that when you don't get a majority for anything, you
> drop the lowest-ranked candidate and distribute the ballots that had this
> as their #1 across the other candidates.
>
> dropped out of the running before the alternatives that they might serve as
> a compromise between.
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 21 Nov 2013 11:21:40 -0800

The intention was to discus this for a week update it as needed,  then make the formal consensus call to use the proposed process process. So I agree we need a very clear consensus call on it. 

On Nov 21, 2013, at 10:58 AM, Adam Roach <[email-masked]> wrote:

> Although this is phrased very carefully, I think this email inadvertently glosses over the fact that this is a formal call for consensus around the proposed approach. I also think you need to be crystal clear -- and I'm going to borrow RFC 3929's language here -- "that the working group's consensus to use [this specific] method stands in for the working group's consensus on the technical issue."
> 
> I wanted to point this out because it would be very easy to accidentally read the email as an announcement for the way the codec will be selected, rather than a call for consensus around a proposed approach.
> 
> /a

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 21 Nov 2013 11:21:24 -0800

Barring blue sheets signers who have not sent an email on the list as well would seem fair to me.

What I considered unfair was those that had been able to attend in person (but not really contributed) could vote when those online could not.

Regards,

Peter

--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

> On 21 Nov 2013, at 11:13, Adam Roach <[email-masked]> wrote:
> 
> I think that's a bit specious. If someone is following the issue at such a distance that they haven't expressed an opinion on the mailing list, I can't see how taking a vote from them counts as anything other than simple, old-fashioned ballot stuffing.
> 
> I'll take it one step further. I find the prospect that we're allowing blue sheets to stand in for participation to be highly questionable: letting the tourists vote is weighting the opinion of demonstrably uninvolved (or less-involved) parties at the same level as those who have actually been working on the topic. I do not think that a blue-sheet sign in without any on-list participation should be sufficient to participate in the kind of process the chairs are proposing.
> 
> Or perhaps I'm missing something. Is there something about the capabilities of "the little guy" that makes sending an email an unrealistically high barrier to entry?
> 
> /a

---

From: David Singer <[email-masked]>
Date: Thu, 21 Nov 2013 11:24:51 -0800

On Nov 21, 2013, at 10:26 , Peter Saint-Andre <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I sincerely hope we can figure out a better process…
> 

Me too.

For example, the W3C uses a Call for Objections process, where the option with the weakest technical objection is selected.  I fear that voting will result in a decision that won’t be honored by a significant part of the population.  We don’t need just a mandate, we want the effect of an effective mandate.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 21 Nov 2013 11:33:22 -0800

My primary objection was to the tourist phenomenon you point out; if we are
going to allow lurkers to vote, we should do so regardless of whether their
presence is physical or virtual.

On Thu, Nov 21, 2013 at 11:13 AM, Adam Roach <[email-masked]> wrote:

> I think that's a bit specious. If someone is following the issue at such a
> distance that they haven't expressed an opinion on the mailing list, I
> can't see how taking a vote from them counts as anything other than simple,
> old-fashioned ballot stuffing.
>
> uninvolved (or less-involved) parties at the same level as those who have
> actually been working on the topic. I do not think that a blue-sheet sign
> in without any on-list participation should be sufficient to participate in
> the kind of process the chairs are proposing.
>

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 21 Nov 2013 14:37:49 -0500

> http://en.wikipedia.org/wiki/Arrow%27s_theorem

It's only the second time it's been brought up regarding MTI codecs! :)

-- 
Libre Video
http://librevideo.org

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 21 Nov 2013 11:37:55 -0800

On Thu, Nov 21, 2013 at 11:13 AM, Adam Roach <[email-masked]> wrote:
> distance that they haven't expressed an opinion on the mailing list, I can't
> see how taking a vote from them counts as anything other than simple,

They might have just been active on the W3C webrtc list and watched
here to see what is happening with codecs, but haven't expressed their
position.

> I'll take it one step further. I find the prospect that we're allowing blue
> sheets to stand in for participation to be highly questionable: letting the
> tourists vote is weighting the opinion of demonstrably uninvolved (or
> less-involved) parties at the same level as those who have actually been
> working on the topic. I do not think that a blue-sheet sign in without any
> on-list participation should be sufficient to participate in the kind of
> process the chairs are proposing.

We could add that participation on the W3C webrtc list also qualifies.

> Or perhaps I'm missing something. Is there something about the capabilities
> of "the little guy" that makes sending an email an unrealistically high
> barrier to entry?

To address the little guys even more, we could also add that
participation on the discuss-webrtc list also qualifies.

Just my 2c worth.

Cheers,
Silvia.

---

From: Stefan Slivinski <[email-masked]>
Date: Thu, 21 Nov 2013 13:31:05 -0600

I'm a new comer, so just a brief intro: I have a background developing real time video codecs for embedded devices so I'm in a position to comment at a technical level within this group

For clarity purposes the proposed alternatives in Magnus' email on nov 18th; are we strictly speaking about decoders?  Historically mandatory requirements are they relate to video compatibility define just the decoders.  Obviously if there is only a single mandatory video decoder this implies a mandatory encoder, however in the case where there are 2 mandatory decoders only a single encoder is technically required.

Clarifying this is fairly important because in the case of both h264 and vp8 (and in the future vp9 and h265) the decoder complexity is fairly low and hardware acceleration is not critical but in the case of the encoders where the complexity can be 3x or worse, hardware acceleration becomes increasingly important

Stefan

----- Original Message -----
From: Adam Roach [mailto:[email-masked]]
Sent: Thursday, November 21, 2013 12:58 PM
To: Magnus Westerlund <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Proposed Video Selection Process

/a

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 21 Nov 2013 11:46:46 -0800

Hello,

I am sure there are many people on the blue sheets who have never
participated on any of the mailing lists.  My point is that to be fair (and
as this is controversial it must be fair) if they get a vote because they
showed up in person those of us who showed up online should get a vote too.

I am based in the UK, so the late in the day meetings at Vancouver were at
incredibly anti-social times for me.  Still, it was important and I made
the effort to stay up and participate in the only way I could.

There is also a consistency issue here.  Those of us on Jabber were able to
(and encouraged to) participate in the consensus process, but it has been
proposed that we be excluded from the vote.  Really, you should either be
able to participate through Jabber or not in a consistent way.

Regards,

Peter

On 21 November 2013 11:37, Silvia Pfeiffer <[email-masked]>wrote:

> a
> can't
> blue
> capabilities

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 21 Nov 2013 14:56:31 -0500

> Clarifying this is fairly important because in the case of both h264 and vp8 (and in the future vp9 and h265) the decoder complexity is fairly low and hardware acceleration is not critical but in t…

What is being specified as MTI is a format, and not a specific
implementation.  So, MTI will not take the form of "OpenH264" or
"libvpx", but rather, "H.264 Constrainted Baseline Profile" or "VP8".

The same was done for the MTI audio codec, which is Opus, not *libopus*,
which is one specific implementation of the codec.

There was a suggestion that the WG also offer a reference implementation
of the MTI codec choice, but that seems like it won't happen, nor is it
really the purpose of the WG to do so.  We are picking from
already-existing and implemented formats in the first place.

-- 
Libre Video
http://librevideo.org

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 21 Nov 2013 21:02:05 +0100

On Thu, 21 Nov 2013 11:46:46 -0800

> showed up in person those of us who showed up online should get a vote too.

Considering that a considerable part of the attendance at the last RTCWEB meeting session was made of people who didn't even know what RTCWEB was, I can't but agree with you.

Lorenzo

-- 
Lorenzo Miniero, COB

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

---

From: Stefan Slivinski <[email-masked]>
Date: Thu, 21 Nov 2013 14:02:37 -0600

I in no way intended to suggest  a specific implementation of a video codec.  My question was around whether we are voting on requiring decoders (my assumption) or both encoders and decoders

---

From: John Leslie <[email-masked]>
Date: Thu, 21 Nov 2013 15:11:19 -0500

> I sincerely hope we can figure out a better process...

   +1

====

   Additionally, if we are to follow a voting process, we must publish
a list of voters and invent some process to challenge who is included
and who is omitted. This is NOT trivial.

--
John Leslie <[email-masked]>

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 21 Nov 2013 15:15:30 -0500

> I in no way intended to suggest  a specific implementation of a video codec.  My question was around whether we are voting on requiring decoders (my assumption) or both encoders and decoders

The discussions, up to this point, have been about choosing an MTI video
format so that rtcweb endpoints can communicate with one-another.  I am
not sure how this goal can be achieved without having an encoder and a
decoder on both ends, sharing at least one common format, whether it is
H.261, Theora, H.264, VP8, or something else.

-- 
Libre Video
http://librevideo.org

---

From: Matt Fredrickson <[email-masked]>
Date: Thu, 21 Nov 2013 14:18:28 -0600

I agree.  I too attempt to participate remotely and would not like to
be excluded from any decision making vote on this process.

Matthew Fredrickson

On Thu, Nov 21, 2013 at 1:46 PM, Peter Dunkley
<[email-masked]> wrote:
> incredibly anti-social times for me.  Still, it was important and I made the
> effort to stay up and participate in the only way I could.
>

---

From: Stefan Slivinski <[email-masked]>
Date: Thu, 21 Nov 2013 14:28:36 -0600

So this is my concern.  On iOS for example it's pretty easy do decode large resolutions in software only using either h.264 or vp8 (and for that matter vp9 and h.265).  So making both h264 and vp8 decoders mandatory isn't a big technical problem.  The encoder however is a bigger issue.  A reasonably good implementation requires roughly 3x the compute to do this in software.  iOS however supports hardware encoding using H264 so there is an obvious advantage to using that specific codec on that device.  The same might be true for VP8 on other architectures.

So requiring all webrtc implementations to support H264 and VP8 gives the flexibility to pick the most appropriate encoder for a given architecture.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 21 Nov 2013 12:36:29 -0800

iOS doesn't expose APIs for said hardware decoding, so you're doing
software no matter what, and VP8 and H.264 are therefore on level ground.

That said, I think the general understanding here is that this is no longer
a technical decision.

On Thu, Nov 21, 2013 at 12:28 PM, Stefan Slivinski
<[email-masked]>wrote:

> So this is my concern.  On iOS for example it's pretty easy do decode
> large resolutions in software only using either h.264 or vp8 (and for that
> matter vp9 and h.265).  So making both h264 and vp8 decoders mandatory
> isn't a big technical problem.  The encoder however is a bigger issue.  A
> reasonably good implementation requires roughly 3x the compute to do this
> in software.  iOS however supports hardware encoding using H264 so there is
> an obvious advantage to using that specific codec on that device.  The same
> might be true for VP8 on other architectures.
>
> So requiring all webrtc implementations to support H264 and VP8 gives the
> flexibility to pick the most appropriate encoder for a given architecture.
>
>
> > I in no way intended to suggest  a specific implementation of a video
> codec.  My question was around whether we are voting on requiring decoders
> (my assumption) or both encoders and decoders
>

---

From: Randell Jesup <[email-masked]>
Date: Thu, 21 Nov 2013 15:35:43 -0500

> If there are any people in that category that wish to vote, could they email the chairs with full name and affiliation. That would make it easier to figure out how to deal with this issue. I think…

I think anyone who certifies they participated in one or more of the 
IETF rtcweb meetings via jabber should be allowed to vote, so long as 
they give their name and affiliation, and which meeting they 
participated in.  The list of people who vote in this manner should 
perhaps be made public, but I'm not sure that's needed barring any 
belief by the chairs someone is trying to game the system.

It does point out a weakness in the IETF jabber participation 
mechanisms; we should have a "virtual bluesheet" for jabber attendees.

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Ron <[email-masked]>
Date: Fri, 22 Nov 2013 07:11:47 +1030

On Thu, Nov 21, 2013 at 11:13:11AM -0800, Adam Roach wrote:
> I think that's a bit specious. If someone is following the issue at
> such a distance that they haven't expressed an opinion on the
> mailing list, I can't see how taking a vote from them counts as
> anything other than simple, old-fashioned ballot stuffing.
> 
> I'll take it one step further. I find the prospect that we're
> allowing blue sheets to stand in for participation to be highly
> questionable: letting the tourists vote is weighting the opinion of
> demonstrably uninvolved (or less-involved) parties at the same level
> as those who have actually been working on the topic. I do not think
> that a blue-sheet sign in without any on-list participation should
> be sufficient to participate in the kind of process the chairs are
> proposing.
> 
> Or perhaps I'm missing something.

I'd assumed that Justin was referring to the fact that people were
objecting to jabber participants but not the blue sheet tourists
who packed the room for the session with a hum.

So I'm glad you've made that (IMO obvious and important) extra detail
quite specific.

But that said, I think I'm firmly with Peter Saint-Andre here.
Taking this straight to (another) vote seems like a questionable
choice, with a very high chance of an even more questionable and
protested outcome (and precedent). [1]

My understanding of the current situation is:

 - We established consensus long ago that MTI codecs are a very
   important part of this specification.

 - We've had 2 seriously proposed codecs prior to the last meeting.

 - We have people expressing objections to both of them, that the
   chairs consider sufficient to declare there is no workable
   consensus for either at present.

 - The sustainable objections to both all boil down to people claiming
   there are insurmountable IPR difficulties.  Whether that be mythical
   risk, or clear impossibilities of obtaining a licence.

 - We've now had people resign themselves to the fact that this is the
   blocking issue for consensus that needs to be resolved, and propose
   solutions that directly address that issue, through the use of a
   codec that is broadly agreed does not have this problem.

So to me the obvious next step would be to probe for consensus about
the codec options that _do_ remain on the table - and see if anybody
has an actually sustainable objection that would prevent achieving a
rough consensus that the concerns surrounding our original preferred
choices are indeed satisfied by taking this path.

The strong objections that people have had to H.264 and VP8 aren't
going to go away, however a vote might decide - so unless those people
are going to retract their objections now (or the chairs are going to
declare them vexatious and irrelevant), then 'voting' for either of
those as MTI seems utterly pointless.

By my understanding we so far have 2 possible candidates for a MTI
codec that may satisfy the IPR and licencing concerns that have
blocked us from a decision to date:

 - H.261, for which everyone seems to agree the IPR is exhausted.

 - MPEG1, which Stephan raised some oblique concerns about, that
   might still prove unfounded with a little more investigation.

Theora I'm assuming will attract the same FUD that it did with W3C
(since people have already quoted the farce that occurred there)
and that VP8 has attracted.  All the other H.xxx codecs are still
within the lifetime of live patents.  So if we can rule out H.264
and VP8, then we can immediately rule these out too without going
through the motions of repeating all the same arguments again,
with a just some search and replace for the codec names.

So wouldn't a better first step be to:

 - See if MPEG1 can actually be ruled out with plausible indications
   of real remaining IPR trouble.

 - If it is, we only have one codec left for people to try to raise
   objections about that might be sustained.

 - If it isn't, we really still only have one codec left for people
   to raise objections about, since there's obvious agreement that
   it would be superior to H.261 in every other way.

Given the agreement we've previously seen on what a MTI codec is
supposed to achieve, I'm having a hard time seeing how consensus
couldn't be established for at the worst H.261.  We'll all agree
that it sucks -- but I'm yet to see any reasonable objection about
why it _can't_ satisfy the requirements for being the MTI fallback,
in the absence of working agreement for a better alternative.

So why don't we just skip straight to seeking consensus on this?

Instead of having a vote stacked with multiple options that will remain
just as unacceptable as they are today, for all the same reasons, where
people won't have to actually _justify_ why they consider some option
or another to be unacceptable.

  Ron

[1] - though I'm not at all questioning the good faith of the chairs
      in trying to find an adequate way to resolve this (or envious
      of their predicament here).

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Thu, 21 Nov 2013 21:42:27 +0100

> For example, the W3C uses a Call for Objections process, where the option with the weakest technical objection is selected.  I fear that voting will result in a decision that won’t be honored by a…
Same opinion here.

IMO, it's very unlikely that only such voting will have proper 
effectiveness and, more important, fairness. No matter 
jabber/blue-sheets persons are allowed to vote or not, there was a lot 
of activity on the mailing lists only from lobbyists. That said, it is 
going to be a lot of influence from companies that bet on 'send many and 
speak loud'. But there were many entities that preferred to speak with a 
single and clear voice so far, not involving an army of email bots.

Just dismissing everyone (people/companies/projects) that simply relied 
on the usual 'consensus' policy, which doesn't require to step in front 
unless the decision is likely to be what one doesn't want, does not look 
fair at all. Many spent lot of time in actually doing work/implementing 
webrtc specs so far.

As highlighted before, the issue now is about selecting the voters. For 
example, I see no reason not to allow anyone that was subscribed to any 
webrtc mailing lists hosted by IETF and W3C - it is an indication of 
interest more that many people that go at IEFT for touristic reasons. 
Those that didn't actively participated in discussions so far on mailing 
lists, they should eventually prove their involvement in other related 
activities, with public references, such as:

- implemented webrtc releated specs in an application or product
- they participated to webrtc interop events
- they presented on webrtc topic at some conferences out there
- they wrote related IETF drafts

Probably the list can continue with other activities ... but is clear 
that the range of people interested in the topic is way larger. The 
process of deciding who can vote might create a bigger issue than 
deciding for vp8 or h264 (or other codec) with a flipping coin.

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 21 Nov 2013 15:48:44 -0500

>       of their predicament here).

I think that what Ron is presenting here is likely the only sensible
action that's left for us.  I am not sure if there's a possibility to
just condense all the options down into this one.

Has anyone actually objected to H.261 being the one MTI codec, while
leaving VP8 and H.264 as shoulds, as a whole and complete resolution to
our situation?

-- 
Libre Video
http://librevideo.org

---

From: Maik Merten <[email-masked]>
Date: Thu, 21 Nov 2013 21:51:49 +0100

This is IMO a very nice summary of issues and options.

Maik

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Nov 2013 12:52:15 -0800

On 21 November 2013 12:48, Basil Mohamed Gohar
<[email-masked]> wrote:
> Has anyone actually objected to H.261 being the one MTI codec [...] ?

More than one person has already.

And I find the argument raised quite compelling.  It's hard to justify
spending valuable time and resources on implementing something that
crappy.

---

From: Leon Geyser <[email-masked]>
Date: Thu, 21 Nov 2013 23:01:40 +0200

+1

---

From: Stefan Slivinski <[email-masked]>
Date: Thu, 21 Nov 2013 14:52:20 -0600

I think this has deviated from my original question but...that's not to suggest apple wouldn't expose a webrtc api in the future given adequate support for codecs they do support in hardware

Back to my original point, are we voting on both encoders and decoders or just the decoder for the mandatory supported codecs.

From: Justin Uberti [mailto:[email-masked]]
Sent: Thursday, November 21, 2013 02:36 PM
To: Stefan Slivinski
Cc: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Proposed Video Selection Process

iOS doesn't expose APIs for said hardware decoding, so you're doing software no matter what, and VP8 and H.264 are therefore on level ground.

That said, I think the general understanding here is that this is no longer a technical decision.

On Thu, Nov 21, 2013 at 12:28 PM, Stefan Slivinski <[email-masked]<mailto:[email-masked]>> wrote:
So this is my concern.  On iOS for example it's pretty easy do decode large resolutions in software only using either h.264 or vp8 (and for that matter vp9 and h.265).  So making both h264 and vp8 decoders mandatory isn't a big technical problem.  The encoder however is a bigger issue.  A reasonably good implementation requires roughly 3x the compute to do this in software.  iOS however supports hardware encoding using H264 so there is an obvious advantage to using that specific codec on that device.  The same might be true for VP8 on other architectures.

----- Original Message -----
From: Basil Mohamed Gohar [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 21, 2013 02:15 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Proposed Video Selection Process

--
Libre Video
http://librevideo.org
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Maik Merten <[email-masked]>
Date: Thu, 21 Nov 2013 22:07:06 +0100

> spending valuable time and resources on implementing something that

The justification would be "to enable P2P video interoperability, at 
least on a basic level". Interoperability apparently sometimes (often? 
always?) comes at a price.

However, I'm completely with you: It *is* (very!) unfortunate that IPR 
concerns seem to block anything but technologically vastly outdated formats.

Maik

---

From: Stefan Slivinski <[email-masked]>
Date: Thu, 21 Nov 2013 15:04:40 -0600

I think arguing in favor of a legacy codec is completely counter productive to the proliferation of webrtc.  This working group is attempting to avoid dealing with the obvious IPR issues with vp8 and h.264 that any and every webrtc vendor is going to have to deal with.  We are basically saying 'we don't know how to deal with this problem so you're on your own' which is completely the wrong message to send as an organization.

Can you imagine if the bluray groups said we don't want to deal with h.264 IPR issues so we'll just mandate h.261?

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Nov 2013 13:14:23 -0800

Agreed.

To take a not-so-random example, given that Firefox will soon
support both H.264 and VP8, what additional implementations
will it be able to talk to if it does H.261?

-Ekr

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 21 Nov 2013 22:19:37 +0100

Just want to +1 this sub-thread of the discussion.

The RFC series turned to success >40y ago by documenting running code 
and best practices. If the specs produced by this WG today end up 
documenting the preference of a restricted group of mailing list posters 
rather than the reality of real world deployments, that will have the 
only effect of undermining the relevance of the IETF.

No MTI is certainly better than a random MTI. For everyone.

Enrico

On 11/21/13 7:26 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSjlBXAAoJEOoGpJErxa2pxmoP/2cCm8UEteJlhNkpV+kTrgYc
> epj1s0LHlQYS/XBWvTpa6d/DeBS0N/mWUAHg+QDj1J5kXiCol3PVpZB7yp2YP4p+
> OcsF/y4KTJCZz+Qs/SBj6o68eX4Cuk68FZ5nrSK6/jSuRFLH6LYTbXW7jvF/Y4pX
> ER5kUg14c+s+NFo575ru3PjYJy2NoSUHVJfB/pLtmlFSH+WKZXw7RFR+Sivlyw3p
> RSJ2fsGldRRa/5aLFajDXxVmViwOtDbuoIFpKKfSSw76a3Q4IbPPX+gezQi7p0ky
> cJCED5/U6IR4wtyWxsfQTV7XDvebYtWTXk2smzKPmQCdRnUiHmT5fmtR6bxDVbSu
> h7xrLCTJeW8qx4IN9zvXCg6QUKUzPdtJuhRF/HouCiZQs9v+d0jmSaR/ZUiZ0Ho9
> 1uXHkiUezkksDKjxB9hsJDmMj24BMzu8TmkndZd3Q4lSg0PI+R1ALd6MgXupBCif
> L8lwYm+JG4cT548O1AfFrBmYcqKnNuTilAA7ZwwJtk6eLcpzpwbLFvRq0LVhsmJC
> dDiNKGSFmgj8wTgT7Z3SQ+km++gecDILGvnJU5hXo6RmnErcjzkis7YMootreSUi
> qCA1fJm7s1TZMn18X79XzHRF6run0C9UaYZORSPwlpmTzAdjRKN5WimstXO2yIQJ
> IZFFqvSNutklVl36Limg
> =G59C
> -----END PGP SIGNATURE-----

---

From: Emil Ivov <[email-masked]>
Date: Thu, 21 Nov 2013 22:20:51 +0100

The IETF does not vote!

This is not a democracy!

We reach consensus based on technical arguments or we declare lack thereof.

The fact that I could afford a plane ticket to this meeting, had the time
to post on that mailing list or sent a +1 message on an XMPP MUC does not
make me more or less qualified to cast a vote on this topic than anyone
else.

The criteria that is being suggested for picking a voter's base here is so
desperately arbitrary that it makes a coin flip pale in comparison. It also
shows how ill suited the IETF is for such things.

In other words, +1 to what Peter said and let's stick to what we actually
can do.

--sent from my mobile

---

From: Leon Geyser <[email-masked]>
Date: Thu, 21 Nov 2013 23:21:23 +0200

That is a completely different situation. We are talking about the open
web. Not some propriety disc format controlled by big companies.
They can deal with IPR easily. Average people who want to work out of their
garage do want other options even if it isn't the best.
Besides this has been pointed out millions of times: Nothing stops anyone
to implement VP8 or H.264 if H.261 is made MTI.

On 21 November 2013 23:04, Stefan Slivinski <[email-masked]> wrote:

> I think arguing in favor of a legacy codec is completely counter
> productive to the proliferation of webrtc.  This working group is
> attempting to avoid dealing with the obvious IPR issues with vp8 and h.264
> that any and every webrtc vendor is going to have to deal with.  We are
> basically saying 'we don't know how to deal with this problem so you're on
> your own' which is completely the wrong message to send as an organization.
>

---

From: Ron <[email-masked]>
Date: Fri, 22 Nov 2013 07:57:31 +1030

> spending valuable time and resources on implementing something that

That argument is only 'compelling' if it can overcome the implicit
assumption it carries - that we should revert the existing consensus
that there should be a MTI codec.

If we all agree the preferred codecs have impossible IPR problems,
then the race to the bottom has been run.

There is no further distance to fall, aside from abandoning the
requirement for guaranteed interoperability.  And I'll be interested
to see what compelling argument can be made for that which doesn't
look like simply trying to completely hijack the chartered goals of
this WG and mandate the failure of this specification.

If you don't want something crappy, well, last chance to recant the
FUD about VP8 ...

  Going, going,
  Ron

---

From: Maik Merten <[email-masked]>
Date: Thu, 21 Nov 2013 22:33:26 +0100

My understanding is that WebRTC is not a browser-only thing. Also: Just 
because Mozilla may have found a way to sidestep the H.264 licensing 
issues with the help of Cisco, this doesn't mean this "fix" applies 
everywhere. For example, is the blob acceptable for Iceweasel? And what 
do the limited distribution rights of OpenH264 mean regarding system 
administration (e.g., replicating machines with disk images)?

Maik

Am 21.11.2013 22:14, schrieb Eric Rescorla:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     [email-masked] <mailto:[email-masked]>

---

From: Stefan Slivinski <[email-masked]>
Date: Thu, 21 Nov 2013 15:31:28 -0600

While I will readily admit this isn't the best analogy I think taking this to extremes and suggesting that someone working in their garage is at risk of being sued for IP infringement and then using that as justification for just requiring H.261 is a bit of a stretch.

From: Leon Geyser [mailto:[email-masked]]
Sent: Thursday, November 21, 2013 03:21 PM
To: Stefan Slivinski
Cc: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Proposed Video Selection Process

That is a completely different situation. We are talking about the open web. Not some propriety disc format controlled by big companies.
They can deal with IPR easily. Average people who want to work out of their garage do want other options even if it isn't the best.
Besides this has been pointed out millions of times: Nothing stops anyone to implement VP8 or H.264 if H.261 is made MTI.

On 21 November 2013 23:04, Stefan Slivinski <[email-masked]<mailto:[email-masked]>> wrote:
I think arguing in favor of a legacy codec is completely counter productive to the proliferation of webrtc.  This working group is attempting to avoid dealing with the obvious IPR issues with vp8 and h.264 that any and every webrtc vendor is going to have to deal with.  We are basically saying 'we don't know how to deal with this problem so you're on your own' which is completely the wrong message to send as an organization.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Nov 2013 13:35:52 -0800

On 21 November 2013 13:27, Ron <[email-masked]> wrote:
> If you don't want something crappy, [...]

You're making some big assumptions here about what I want.

But we're well beyond "want" at this point.  We need to figure out
what people would settle for.  I don't think that the proposed process
does that.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 21 Nov 2013 22:40:27 +0100

* Ron wrote:
>and that VP8 has attracted.

The mailing list archive holds 10 000 messages. Up until the thread
"Video Codec Selection Plan" two months ago, there have been only 23
mails that mention "Theora" in any way. Ignoring two mails where it's
mentioned only in HTML code, the last mention was over a year ago,
<http://www.ietf.org/mail-archive/web/rtcweb/current/msg05583.html>.

I think it would be fair to say the Working Group has given no con-
sideration to making Theora a mandatory-to-implement codec. I went
through those few messages again just now and do not really see any
argument against it. So unless my mail client is failing me, I would
not make such an assumption.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Nov 2013 13:40:43 -0800

On Thu, Nov 21, 2013 at 1:33 PM, Maik Merten <[email-masked]>wrote:

> My understanding is that WebRTC is not a browser-only thing.

I don't recall anyone saying that it was, and that's missing the point.
Rather, given that H.261 is really lame and that most everyone is
going to deploy *either* VP8 or H.264, I'm trying to figure out why
mandating H.261 is useful

 Also: Just because Mozilla may have found a way to sidestep the H.264
> licensing issues with the help of Cisco, this doesn't mean this "fix"
> applies everywhere. For example, is the blob acceptable for Iceweasel? And
> what do the limited distribution rights of OpenH264 mean regarding system

These may be relevant questions in some other thread, but not here.

However, with that said, Cisco's blob should be usable for IceWeasel.
Whether the IceWeasel people opt to use it is of course up to them.
WRT the second question, 100k images is a lot of images.

-Ekr

Maik

---

From: <[email-masked]>
Date: Thu, 21 Nov 2013 21:33:47 +0000

Would the implement any two of {VP8, H.264 CBP, H.261} option solve your problem?

+1 for Ron's reasoning.

Markus

Sent from my iPad

On Nov 21, 2013, at 23:15, "ext Eric Rescorla" <[email-masked]<mailto:[email-masked]>> wrote:

Agreed.

-Ekr

On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
On 21 November 2013 12:48, Basil Mohamed Gohar

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Nov 2013 13:46:23 -0800

>  Would the implement any two of {VP8, H.264 CBP, H.261} option solve your

Well, for my specific problem, essentially anything that mandates
either VP8 or H.264 or both or the user's choice would. H.261
doesn't bring anything to the party. I'm trying to figure out who it
does benefit and coming up a bit short.

-Ekr

 +1 for Ron's reasoning.
>
>  Markus
>
> Sent from my iPad
>
> On Nov 21, 2013, at 23:15, "ext Eric Rescorla" <[email-masked]> wrote:
>
>   Agreed.
>
> On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson <[email-masked]
> > wrote:
>

---

From: Leon Geyser <[email-masked]>
Date: Thu, 21 Nov 2013 23:47:39 +0200

>>mandating H.261 is useful

No interoperability if nothing is between the two clients to transcode the
video. *either* doesn't always mean both H.264 and VP8. So H.261 will be
useful if transcoding can't be done.

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 21 Nov 2013 16:54:03 -0500

> will it be able to talk to if it does H.261?

(I apparently replied only to Ekr, and not the whole list originally)

None, but that's not the point.  Firefox is a special case for which VP8
is not considered a legal liability (by Mozilla) and they can be
satisfied, for the most part, by Cisco's proposal with OpenH264 as a
downloadable plugin/module.

So, this doesn't open up anything for Firefox that it is not already
planning to handle.

What it does open up is for, say, a small firm that cannot afford H.264
licensing, and cannot make use of Cisco's binary plugin for legal or
technical reasons, and can only implement VP8 and H.261, and, say, a
device whose manufacturers do not wish to implement VP8 for perceived
IPR risk but already license H.264.

Both cases above have an H.261 implementation that will allow mutual
video, even though they do not share a common high-end codec implementation.

There are cases outside of browsers that are interested in rtcweb, after
all.

-- 
Libre Video
http://librevideo.org

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 21 Nov 2013 16:55:14 -0500

> spending valuable time and resources on implementing something that

(another case of replying to the person and not the list)

It's no more crappy than having G.711 as a fallback audio codec for
legacy purposes, which we've already done for rtcweb audio.  I realize
that it's not the same thing, but no other alternative codec has been
presented that satisfies the blocking issues for choosing either VP8 or
H.264 as MTI, namely, the IPR- or possibly-IPR-related issues.

-- 
Libre Video
http://librevideo.org

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Nov 2013 13:58:40 -0800

On 21 November 2013 13:55, Basil Mohamed Gohar
<[email-masked]> wrote:
> legacy purposes,

Actually, it is.  G.711 is close to free to implement.  And, despite
it actually being crappy, there's still a lot of it around.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Nov 2013 13:58:59 -0800

On Thu, Nov 21, 2013 at 1:55 PM, Basil Mohamed Gohar <
[email-masked]> wrote:

> legacy purposes, which we've already done for rtcweb audio.

And there was really significant debate about that. The argument that
ultimately carried the day was that

(a) G.711 was trivial
(b) There were major interop advantages for the PSTN.

Neither of these two considerations applies here.

-Ekr

>  I realize

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Nov 2013 13:59:40 -0800

> There are cases outside of browsers that are interested in rtcweb, after

Which of those cases are going to want to not talk to browsers?

Which browsers want to do H.261?

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Nov 2013 14:03:09 -0800

> it actually being crappy, there's still a lot of it around.

I forgot, if you want directly analogous, B&W RFC 4715 at QCIF might
be a good fit.

---

From: Matt Fredrickson <[email-masked]>
Date: Thu, 21 Nov 2013 16:04:07 -0600

I also agree with Ron's suggestion....

Implement 2 of 3 seems to be the best way to absolutely preserve interop.

Matthew Fredrickson

On Thu, Nov 21, 2013 at 3:33 PM,  <[email-masked]> wrote:
> On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson <[email-masked]>
> wrote:
>>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Nov 2013 14:06:00 -0800

> I forgot, if you want directly analogous, B&W RFC 4715 at QCIF might

Correction, B&W RFC 4175 QCIF =~ G.711.

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 21 Nov 2013 17:12:31 -0500

On 11/21/2013 04:59 PM, Eric Rescorla wrote:
> 
> 
> 
> On Thu, Nov 21, 2013 at 1:54 PM, Basil Mohamed Gohar

Of course, all of them want to talk to browsers.  But not all of them
will be guaranteed to implement BOTH VP8 or H.264 (nor are browsers, and
this is key).

So, I write myself a small little device that attaches to my camera that
implements RTCweb.  I cannot afford the license for H.264, and my
platform is not supported by OpenH264.  I do, however, write-up my own
basic VP8 implementation as well, because it is is royalty-free.  I also
implement H.261 for the same reason, it's royalty free.  I need things
to be royalty free because I plan to publish my designs under a CC
license and want others to also be able to make my device.

So, I can talk to browsers that support VP8 with VP8, and browsers that
do not support VP8, but because it's MTI, do support H.261, but with
degraded quality.  BUT I CAN STILL TALK (or SEE) them, as opposed to
being unable to if H.261 was not mandated.

This example, though perhaps somewhat contrived, is a case that would be
allowed if H.261 is permitted, and would be impossible if it were left
out, because there would be some rtcweb endpoints excluded from
interoperability.

-- 
Libre Video
http://librevideo.org

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 21 Nov 2013 14:14:03 -0800

> That said, I think the general understanding here is that this is no longer a technical decision.

I'll note that some people strongly disagree with this is not a technical decision but there are others who do think it is is no longer a technical decision.

---

From: Stefan Slivinski <[email-masked]>
Date: Thu, 21 Nov 2013 16:13:04 -0600

But how does this avoid IPR issues? 

----- Original Message -----
From: Matt Fredrickson [mailto:[email-masked]]
Sent: Thursday, November 21, 2013 04:04 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Proposed Video Selection Process

Matthew Fredrickson

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Nov 2013 14:22:20 -0800

> I'll note that some people strongly disagree with this is not a technical decision but there are others who do think it is is no longer a technical decision.

Is that a chair statement declaring lack of consensus on whether the
MTI video codec debate has a technical basis?

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 21 Nov 2013 17:25:52 -0500

It is impossible to completely avoid IPR issues altogether to everyone's
satisfaction.  But there are two camps that have emerged, that is to
say, one that says H.264 IPR issues are a no go, and those that say the
same for VP8 (mostly in light of contentment with either MPEG-LA's
licensing terms or Cisco's plugin/module).

So, both camps' concerns can be addressed by allowing each camp to still
implement their own preferences, while H.261 is presented as an option
to allow interop between those that fall strictly into one of the two
above camps, with H.261 being asserted as confidently possibly to be
implemented, albeit perhaps in a basic form, without much IPR concern
from anyone.

-- 
Libre Video
http://librevideo.org

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 21 Nov 2013 14:29:16 -0800

> MTI video codec debate has a technical basis?

Sure I will upgrade that to be one of the chairs saying that some people think the decisions involves technical issues and some people do not. It is not a statement from the chair if the debate is technical or not - just a statement that people disagree on this. 

Cullen <with my co-chair hat on>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 21 Nov 2013 14:31:58 -0800

Even the proposal that recommended H.264 as MTI indicated that the
technical merit of the currently proposed codecs is equivalent, and the
fundamental question is IPR.
http://tools.ietf.org/agenda/88/slides/slides-88-rtcweb-8.pdf

Put another way, if the alleged IPR issues associated with either H.264 or
VP8 disappeared overnight, this discussion would be instantly over.

On Thu, Nov 21, 2013 at 2:14 PM, Cullen Jennings <[email-masked]> wrote:

> I'll note that some people strongly disagree with this is not a technical
> decision but there are others who do think it is is no longer a technical
> decision.
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 21 Nov 2013 14:38:12 -0800

On Nov 21, 2013, at 2:31 PM, Justin Uberti <[email-masked]> wrote:

> Put another way, if the alleged IPR issues associated with either H.264 or VP8 disappeared overnight, this discussion would be instantly over.

Justin, I don't think everyone agrees with you on this. If VP8 was magically 100% guaranteed to be free of all patents tomorrow, there would still be a large block of people arguing for H.264.  I'm not trying to say there is consensus on this topic, one way or the other, just that not everyone agrees with that.

---

From: Stefan Slivinski <[email-masked]>
Date: Thu, 21 Nov 2013 16:37:51 -0600

Having some experience with patent trolls I have come to the realization that if you have means they will sue you for pretty much anything even if you do not actually infringe on their patents. You are then in the position of fighting them or paying them off.

I think it is naïve to believe you can ever completely avoid IPR by picking some archaic codec. I think we need to come up with a different solution to defend against infringement claims rather than trying to avoid them

From: Justin Uberti [mailto:[email-masked]]
Sent: Thursday, November 21, 2013 04:31 PM
To: Cullen Jennings <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Proposed Video Selection Process

Even the proposal that recommended H.264 as MTI indicated that the technical merit of the currently proposed codecs is equivalent, and the fundamental question is IPR.
http://tools.ietf.org/agenda/88/slides/slides-88-rtcweb-8.pdf

On Thu, Nov 21, 2013 at 2:14 PM, Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Jack Moffitt <[email-masked]>
Date: Thu, 21 Nov 2013 15:41:58 -0700

> The RFC series turned to success >40y ago by documenting running code and
> best practices.

All the running code for WebRTC is VP8.

Not claiming this is the best source, but the shipping implementations
of VP8 WebRTC represent ~60% of all desktop browsers:
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

This doesn't include mobile (where market share is still significant
but not as high), but the two shipping browsers have no problem with
VP8 even though they ship mobile browsers too.

Running code with majority market share doesn't seem to count for much.

jack.

---

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

> Neither of these two considerations applies here.

H.261 was in fact designed for use in the same 64kbs timeslots of the
same ISDN that G.711 was designed for and is still used on, and both
are still part of the same standards that define what to use there.

So if transparent interop with the PSTN is a major consideration ... :)

  Blocky turtles all the way down,
  Ron

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Nov 2013 14:47:47 -0800

> All the running code for WebRTC is VP8.

All the running code *that you have seen* ...

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 21 Nov 2013 23:52:03 +0100

On Thu, 21 Nov 2013 14:47:47 -0800

> All the running code *that you have seen* ...

I have never seen Santa either...

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Matt Fredrickson <[email-masked]>
Date: Thu, 21 Nov 2013 16:57:03 -0600

Isn't the point to pick a codec old enough that the codec standard
itself should be considered prior art on any claims made against it?

Matthew Fredrickson

On Thu, Nov 21, 2013 at 4:37 PM, Stefan Slivinski
<[email-masked]> wrote:
> Having some experience with patent trolls I have come to the realization
> that if you have means they will sue you for pretty much anything even if
> you do not actually infringe on their patents. You are then in the position
> of fighting them or paying them off.
>
> I think it is naïve to believe you can ever completely avoid IPR by picking
> some archaic codec. I think we need to come up with a different solution to
> defend against infringement claims rather than trying to avoid them
>
>
> Even the proposal that recommended H.264 as MTI indicated that the technical
> merit of the currently proposed codecs is equivalent, and the fundamental
> question is IPR.

---

From: Stefan Slivinski <[email-masked]>
Date: Thu, 21 Nov 2013 17:28:18 -0600

So not to confuse licensing fees with ip infringement litigation but...I should first point out that I am not an expert in this space but I have had a reasonable amount of experience in this area and I can say that many patents are so generic and rarely specific to a particular codec, there may simply be a rate control algorithm patent that has the potential to apply to any video encoder, past/present or future.

----- Original Message -----
From: Matt Fredrickson [mailto:[email-masked]]
Sent: Thursday, November 21, 2013 04:57 PM
To: Stefan Slivinski
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Proposed Video Selection Process

Matthew Fredrickson

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 21 Nov 2013 16:11:43 -0800

> All the running code *that you have seen* ...

Other than of course the first wbertc browser on Andoid, and many more ...

---

From: David Singer <[email-masked]>
Date: Thu, 21 Nov 2013 16:57:11 -0800

> it actually being crappy, there's still a lot of it around.

well, it’s band-limited and hardly compressed, but within those limits it’s OK.  Whereas I seem to recall having trouble getting decent quality out of H.261 no matter what I did with it (but it has been *years* since I used H.261 for  anything, and it’s only because I am an old geezer that I used it at all).

David Singer

---

From: Stefan Slivinski <[email-masked]>
Date: Thu, 21 Nov 2013 19:15:03 -0600

David your point is absolutely correct.  H.261 would be completely unusable.  The max resolution is 352x288 not to mention many other algorithm  issues that make the quality even at low qp's unacceptable especially on a mobile device where the camera is anything but steady

The fact that h.261 is getting so much attention is distressing  

----- Original Message -----
From: David Singer [mailto:[email-masked]]
Sent: Thursday, November 21, 2013 06:57 PM
To: Martin Thomson <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Proposed Video Selection Process

David Singer

---

From: David Singer <[email-masked]>
Date: Thu, 21 Nov 2013 17:23:35 -0800

> The fact that h.261 is getting so much attention is distressing  

Yes, that’s my gut.  If we ask our engineers to implement it (I mean we in the sense of members of the WebRTC group) I am fairly sure that we will get a mix of “you want me to do WHAT?”, “are you insane?”, “what century are YOU from?”, and the like.

Can someone remind me why classic H.263 (with possibly the minor tweaks for picture size limits etc.) is problematic?

David Singer

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 22 Nov 2013 02:38:53 +0100

>The fact that h.261 is getting so much attention is distressing  

It might be helpful if someone explained how H.261 compares to something
people can relate to better. Like animated GIFs, or sending a bunch of
JPEG images in a row at certain frame rates, resolutions, compression
ratios.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 21 Nov 2013 21:00:16 -0500

> Can someone remind me why classic H.263 (with possibly the minor tweaks for picture size limits etc.) is problematic?

For exactly the same reasons H.264 (for some) and VP8 (for others) - IPR
issues due to not being old enough for anything patented in the standard
to be guaranteed to have expired.

-- 
Libre Video
http://librevideo.org

---

From: David Singer <[email-masked]>
Date: Thu, 21 Nov 2013 18:05:37 -0800

Ok, even though the standard issued in early 1996, more than 17 years ago?

Sent from my iPad

> On Nov 21, 2013, at 6:00 PM, Basil Mohamed Gohar <[email-masked]> wrote:
>

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 21 Nov 2013 21:11:24 -0500

Patents can last longer than 17 years.

http://patents.stackexchange.com/questions/312/how-long-are-software-patents-valid

-- 
Libre Video
http://librevideo.org

---

From: Justin Uberti <[email-masked]>
Date: Thu, 21 Nov 2013 18:18:52 -0800

Stefan Wenger posted a fairly detailed analysis of the H.263 situation,
which I think also applies to MPEG-2.

TL;DR: no, because patents.
On Nov 21, 2013 6:11 PM, "Basil Mohamed Gohar" <[email-masked]>
wrote:

> >>> Can someone remind me why classic H.263 (with possibly the minor
> tweaks for picture size limits etc.) is problematic?
> >>

---

From: Stefan Slivinski <[email-masked]>
Date: Thu, 21 Nov 2013 23:07:27 -0600

There appears to be some confusion about codec specific patents and general video coding patents so let me try to clarify:

Both H.264 and VP8 specification describe the DECODER, specifically the format and order of the data in the bitstream.  What does that mean?  It means that for each macroblock there will be information indicating the block type, the motion vectors, the quantizer, the residual, etc.   What the specification does not say is HOW you decide what block type to use, what motion vector to use, what quantizer to use, etc.

A license from mpeg-la and presumably from google will protect you when implementing anything described in the decoder specification.  It will not protect you from the HOW.  So if you think of a really simple motion estimate engine where you search every possible location in the reference frame to find the best match using SAD as a block matching algorithm…guess what?  There’s a patent for that.  If you then decide that if there isn’t a really good match (high SAD), and you decide to do an intra search instead…guess what?  There’s a patent for that.  Your mpeg-la license (and I’m willing to bet vp8 also) won’t protect you if you happen to infringe on those.

I’m not trying to scare everyone but to argue that H.261 is somehow going to protect you from patent infringement is completely without merit.

Something else to keep in mind, many of you are aware that apple recently lost a patent infringement suit from VimetX regarding p2p calling with facetime.
What they are doing isn’t all to different than a p2p using a stun server.

My point here is we should be focusing on choosing the best technology and come up with a solution for dealing with patent trolls at some other level because it’s going to be a wide spread concern, not just a video problem.

From: rtcweb [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Thursday, November 21, 2013 6:19 PM
To: Basil Mohamed Gohar
Cc: [email-masked]
Subject: Re: [rtcweb] Proposed Video Selection Process

Stefan Wenger posted a fairly detailed analysis of the H.263 situation, which I think also applies to MPEG-2.

TL;DR: no, because patents.
On Nov 21, 2013 6:11 PM, "Basil Mohamed Gohar" <[email-masked]<mailto:[email-masked]>> wrote:
Patents can last longer than 17 years.

On 11/21/2013 09:05 PM, David Singer wrote:
>> On Nov 21, 2013, at 6:00 PM, Basil Mohamed Gohar <[email-masked]<mailto:[email-masked]>> wrote:
>>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 22 Nov 2013 06:15:16 +0000

Bluray is actually a good analogy. It mandates both H.264 and VC1. VC1 is the MPEG standard for Microsoft’s proprietary Windows Media Video (WMV). Just like VCB is the MPEG standard-in-progress for Google’s proprietary VP8. VC1 was intended to be RF, but MPEG LA formed a pool of licensors with claims on VC1, and Microsoft didn’t pay them off adequately to dissolve the pool. Fast forward to today:

s/bluray/webrtc/
s/Microsoft/Google/
s/WMV/VP8/
s/VC1/VCB/
s/and H264/xor H264/
(xor may be impeding consensus)

On 11/21/13, 4:31 PM, Stefan Slivinski <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Maik Merten <[email-masked]>
Date: Fri, 22 Nov 2013 07:57:21 +0100

There are also proposals where H.261 is only required if one cannot 
implement both VP8 and H.264.

Maik

Am 21.11.2013 22:31, schrieb Stefan Slivinski:
> While I will readily admit this isn't the best analogy I think taking
> this to extremes and suggesting that someone working in their garage is
> at risk of being sued for IP infringement and then using that as
> justification for just requiring H.261 is a bit of a stretch.
>
>
>
>
> *From*: Leon Geyser [mailto:[email-masked]]
> *Sent*: Thursday, November 21, 2013 03:21 PM
> *To*: Stefan Slivinski
> *Cc*: [email-masked] <[email-masked]>
> *Subject*: Re: [rtcweb] Proposed Video Selection Process
>
> They can deal with IPR easily. Average people who want to work out of
> their garage do want other options even if it isn't the best.
> Besides this has been pointed out millions of times: Nothing stops
> anyone to implement VP8 or H.264 if H.261 is made MTI.
>
>
>     attempting to avoid dealing with the obvious IPR issues with vp8 and
>     h.264 that any and every webrtc vendor is going to have to deal
>     with.  We are basically saying 'we don't know how to deal with this
>     problem so you're on your own' which is completely the wrong message
>     to send as an organization.
>
>     Can you imagine if the bluray groups said we don't want to deal with
>     h.264 IPR issues so we'll just mandate h.261?
>
>
>
>     Cc: [email-masked] <mailto:[email-masked]> <[email-masked]
>     <mailto:[email-masked]>>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 22 Nov 2013 19:13:30 +0900

On 2013/11/22 6:59, Eric Rescorla wrote:
> On Thu, Nov 21, 2013 at 1:54 PM, Basil Mohamed Gohar<

The Firefox example shows that making H.261 MTI is a bad idea. But it 
works out if this is changed to "two of three (of H.264, VP8, and 
H.261). Firefox will then soon be compliant. H.261 would be left for 
those who absolutely, definitely want to avoid one of VP8 or H.264 (of 
which there are many enough; otherwise we wouldn't have this whole 
discussion).

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 22 Nov 2013 19:24:01 +0900

> I in no way intended to suggest  a specific implementation of a video codec.  My question was around whether we are voting on requiring decoders (my assumption) or both encoders and decoders

My understanding is that all the proposals in each instance mean "both 
encoder and decoder". So as an example, a proposal of "MUST implement 
both VP8 and H.264" means "MUST implement both VP8 encoder and decoder, 
and H.264 encoder and decoder".

Your question brings up other choices. For example, interoperability 
would be satisfied by something like "MUST implement both VP8 and H.264 
decoders, and MUST implement at least one of VP8 and H.264 encoders".

One condition for this to work is the possibility of asymmetric 
communication, i.e. if side A implemented only a VP8 encoder, and side B 
only implemented a H.264 encoder, then traffic A->B would be VP8, 
whereas traffic B->A would be H.264. I don't know the in's and out's of 
the negotiation and protocol machinery to confirm or deny that this is 
possible.

Choices like the one above definitely open new horizons for Eric's 
selection generator. But frankly speaking, except for the specific 
choice of "MUST implement both VP8 and H.264 decoders, and MUST 
implement at least one of VP8 and H.264 encoders", which is less onerous 
than "MUST implement both VP8 and H.264", but still interoperable, I 
don't see any choices with different requirements for encoders and 
decoders that would make sense.

Regards,   Martin.

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

---

From: Steve Donovan <[email-masked]>
Date: Fri, 22 Nov 2013 08:23:08 -0600

The conversation seems to have veered into an argument about the
alternatives and not the proposed selection process.  I'll attempt to
focus on the topic in the subject line.

I am personally uncomfortable with the process as proposed.  I am one of
those referred to as a "lurker" in previous emails.  This is my first
post to this mailing list.  I have, however, read hundreds/thousands of
emails sent to this list.  I have also signed the previous three rtcWEB
blue lists.  I have not participated in meetings via Jabber.

I do think it is very important for the WEBrtc ecosystem to have at
least one MTI video codec.  I am not an expert in video codecs.  I don't
care which codec is chosen but I do consider it very important that
there be at least one MTI codec. 

I do NOT think that inventing arbitrary criteria for determining if I am
eligible to vote is a good precedent to be setting in the IETF. 

I fully understand the desire to attempt to eliminate ballot-box
stuffing in this proposed process.  Especially after the rumors of
double humming during the hum/Jabber +1'ing in Vancouver.  Personally I
think it is a fools game to try to eliminate attempts to game the
system.  It is going to happen anytime there is as much passion tied to
the outcome as in this case.  Ballot box stuffing happens.  It happens
with humming -- witness the increase in meeting attendance for sessions
with important hums.  I happens with voting -- witness the problems
established entities/governments that have extensive experience with
running elections still have keeping elections free and fair.

I don't see the IETF, who has very little experience with voting, being
successful at running a free and fair vote.  I say this with utmost
respect for the IETF.  Much of that respect coming because it is built
on consensus, not voting.

How do I think the working group should move forward?  I see three
viable options:

1) A coin flip
2) Two modern MTI codes
3) MTI of h.261 plus a modern MTI codec

I like the coin flip options as it results in a lot less email from the
lobbyists.

Regards,

Steve

---

From: John Leslie <[email-masked]>
Date: Fri, 22 Nov 2013 09:28:26 -0500

Stefan Slivinski <[email-masked]> wrote:
> 
> So if you think of a really simple motion estimate engine where you
> search every possible location in the reference frame to find the
> best match using SAD as a block matching algorithm...guess what?
> There's a patent for that. If you then decide that if there isn'?t
> a really good match (high SAD), and you decide to do an intra search
> instead...guess what? There's a patent for that.

   Yes, we know -- software patents are big-time damage...

> I'm not trying to scare everyone but to argue that H.261 is somehow
> going to protect you from patent infringement is completely without
> merit.

   There's an important point here, which many folks _do_ seem to be
missing: you _can_ run afoul of perfectly "valid" patents implementing
20-year-old technology. It is not the job of the IETF to even warn you
about this; and it's _definitely_ not our job to say how you should
deal with it.

> My point here is we should be focusing on choosing the best technology

   No.

   We're absolutely not trying to find the "best technology". We all
agree that H.265 is better than H.264 and VP9 is better than VP8,
but we're not focusing on either of them. Likewise, we all agree
that H.263, while worse than either H.264 or VP8, is better than
H.261.

   We're trying to find a "good enough" technology to be Mandatory
To Implement. We've been trying for a long time; and we may end up
failing.

   H.261 holds real promise there -- you can find an _implementation_
that's more than 20 years old and copy it bit-for-bit, and have a
rock-solid "prior art" defense. (We're not saying that's what you
should do; but it's an option available to you.)

> and come up with a solution for dealing with patent trolls at some
> other level because it's going to be a wide spread concern, not just
> a video problem.

   That's not a problem for _us_ to solve -- nor is it entirely
rational to believe we will ever see it solved. I certainly agree
the problem is quite widespread; but different companies will choose
different paths to manage the risks. (As they should!)

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 22 Nov 2013 16:28:36 +0100

>eligible to vote is a good precedent to be setting in the IETF. 

The proposed criteria boil down to that anyone who can point to public
IETF records of their past participation in the Working Group can vote.
That is the most predictable set of criteria, and not arbitrary at all.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Emil Ivov <[email-masked]>
Date: Fri, 22 Nov 2013 16:49:00 +0100

> That is the most predictable set of criteria, and not arbitrary at all.

It does however produce a voter base that is of arbitrary relevance to
the choice that we are trying to make.

Emil

--
https://jitsi.org

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 22 Nov 2013 10:54:09 -0500

> the choice that we are trying to make.

I'm not intentionally trying to be contrary here, but the ones making
the choice are exactly the ones mentioned - those that have, somehow,
participated (with some kind of documentation) in any of the venues
through which IETF operates and discusses the matter at hand.

How else should someone's relevance for voting be determined?  IETF
(historically) makes decisions via consensus at meetings and on e-mail
lists.

-- 
Libre Video
http://librevideo.org

---

From: Steve Donovan <[email-masked]>
Date: Fri, 22 Nov 2013 09:57:13 -0600

I've seen at least three criteria defined, each with its own logic and
each with its own flaws.

1) List posting by chair decided date + blue list
2) List posting by a chair decided date + blue list + Jabber participation
3) List membership + other related involvement where the burden of proof
of that involvement rests on the shoulders of the would be voter.

Labeling these "arbitrary" was maybe inappropriate.  My point, however,
is that the IETF does not have experience with running this kind of a
vote, at least not to my knowledge.  Attempting to define criteria at
this stage does strike me as a bit arbitrary and a process rife with
opportunity to actually lengthen the time it takes to make a decision.

Steve

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 10:09:49 -0600

Something else worth noting with the proposal of "MUST implement both VP8 and H.264 decoders, and MUST implement at least one of VP8 and H.264 encoders", 
It allows you to choose the appropriate codec for your architecture, especially those architectures where there is hardware acceleration for only one encoder.  It would be very undesirable for a vendor be able to send H.264 at 1080p but only 360p for VP8 because they didn’t have hardware acceleration available for it.  Decoders are less of a concern because they are far less complex.

Another point worth noting:  there are far less patents on decoders than on encoders, so it allows a vendor to mitigate their risk by choosing the encoder they feel most comfortable with.

-----Original Message-----
From: "Martin J. Dürst" [mailto:[email-masked]] 
Sent: Friday, November 22, 2013 2:24 AM
To: Stefan Slivinski
Cc: [email-masked]'
Subject: Re: [rtcweb] Proposed Video Selection Process

On 2013/11/22 5:02, Stefan Slivinski wrote:
> codec.  My question was around whether we are voting on requiring 
> decoders (my assumption) or both encoders and decoders

My understanding is that all the proposals in each instance mean "both encoder and decoder". So as an example, a proposal of "MUST implement both VP8 and H.264" means "MUST implement both VP8 encoder and decoder, and H.264 encoder and decoder".

Your question brings up other choices. For example, interoperability would be satisfied by something like "MUST implement both VP8 and H.264 decoders, and MUST implement at least one of VP8 and H.264 encoders".

One condition for this to work is the possibility of asymmetric communication, i.e. if side A implemented only a VP8 encoder, and side B only implemented a H.264 encoder, then traffic A->B would be VP8, whereas traffic B->A would be H.264. I don't know the in's and out's of the negotiation and protocol machinery to confirm or deny that this is possible.

Choices like the one above definitely open new horizons for Eric's selection generator. But frankly speaking, except for the specific choice of "MUST implement both VP8 and H.264 decoders, and MUST implement at least one of VP8 and H.264 encoders", which is less onerous than "MUST implement both VP8 and H.264", but still interoperable, I don't see any choices with different requirements for encoders and decoders that would make sense.

Regards,   Martin.

>> I'm a new comer, so just a brief intro: I have a background 
>> developing real time video codecs for embedded devices so I'm in a 
>> position to comment at a technical level within this group
>>
>> Clarifying this is fairly important because in the case of both h264 
>> and vp8 (and in the future vp9 and h265) the decoder complexity is 
>> fairly low and hardware acceleration is not critical but in the case 
>> of the encoders where the complexity can be 3x or worse, hardware 
>> acceleration becomes increasingly important
>>
>> Stefan
>
> The same was done for the MTI audio codec, which is Opus, not 
> *libopus*, which is one specific implementation of the codec.
>
> There was a suggestion that the WG also offer a reference 
> implementation of the MTI codec choice, but that seems like it won't 
> happen, nor is it really the purpose of the WG to do so.  We are 
> picking from already-existing and implemented formats in the first place.
>

---

From: Emil Ivov <[email-masked]>
Date: Fri, 22 Nov 2013 17:20:21 +0100

On Fri, Nov 22, 2013 at 4:54 PM, Basil Mohamed Gohar
<[email-masked]> wrote:
> participated

Exactly, and the result is that this specific group of people get to
express their preference while everyone else doesn't

Why? What does make the former group more qualified than the latter to
make a choice that would impact the Internet? Are they somehow
expected to

A) have better understanding in international patent law?
B) possess considerable knowledge on existing video related patents worldwide?
C) have better knowledge of video encoding mechanisms?
D) possess Solomonic wisdom and capability to properly balance the
WebRTC ecosystem?
E) wield Psychic skills?
F) represent 51% of the expected WebRTC population?

I haven't seen any indication to that.

What I have seen is an intention to ask frequent flyers and SMTP users
to tell us what their favourite horse in the race is.

> (with some kind of documentation)

I don't think anyone has so far mentioned participation with
documentation as part of the criteria.

> in any of the venues
> How else should someone's relevance for voting be determined?

It can't be. It shouldn't be. That's why the IETF does not vote.

> IETF

Decisions via consensus are very, very different than opinion polls on
a subject where lack of consensus has been demonstrated.

If we can't reach consensus then we are in no position to mandate.

Emil

--
https://jitsi.org

---

From: Silvia Pfeiffer <[email-masked]>
Date: Fri, 22 Nov 2013 08:24:15 -0800

I think this has value. It might bring apple and Microsoft to the table,
since decoding-only is often the less patent-affecting part.

Silvia.
On 22 Nov 2013 02:24, Martin J. Dürst <[email-masked]> wrote:

> encoder and decoder". So as an example, a proposal of "MUST implement both
> VP8 and H.264" means "MUST implement both VP8 encoder and decoder, and
> H.264 encoder and decoder".
>
> Your question brings up other choices. For example, interoperability would
> be satisfied by something like "MUST implement both VP8 and H.264 decoders,
> and MUST implement at least one of VP8 and H.264 encoders".
>
> only implemented a H.264 encoder, then traffic A->B would be VP8, whereas
> traffic B->A would be H.264. I don't know the in's and out's of the
> negotiation and protocol machinery to confirm or deny that this is possible.
>
> selection generator. But frankly speaking, except for the specific choice
> of "MUST implement both VP8 and H.264 decoders, and MUST implement at least
> one of VP8 and H.264 encoders", which is less onerous than "MUST implement
> both VP8 and H.264", but still interoperable, I don't see any choices with
> different requirements for encoders and decoders that would make sense.
>
> Regards,   Martin.
>
>
>>> I'm a new comer, so just a brief intro: I have a background developing
>>> real time video codecs for embedded devices so I'm in a position to comment
>>> at a technical level within this group
>>>
>>> For clarity purposes the proposed alternatives in Magnus' email on nov
>>> 18th; are we strictly speaking about decoders?  Historically mandatory
>>> requirements are they relate to video compatibility define just the
>>> decoders.  Obviously if there is only a single mandatory video decoder this
>>> implies a mandatory encoder, however in the case where there are 2
>>> mandatory decoders only a single encoder is technically required.
>>>
>>> Clarifying this is fairly important because in the case of both h264 and
>>> vp8 (and in the future vp9 and h265) the decoder complexity is fairly low
>>> and hardware acceleration is not critical but in the case of the encoders
>>> where the complexity can be 3x or worse, hardware acceleration becomes
>>> increasingly important
>>>
>>> Stefan
>>>
>>

---

From: tim panton <[email-masked]>
Date: Fri, 22 Nov 2013 08:40:48 -0800

Surely this flies in the face of the whole O/A model, which imposes a sort of symmetry on the endpoints ?
(Unless there is some arcane SDP FRACK at play here).

T.

On 22 Nov 2013, at 08:24, Silvia Pfeiffer <[email-masked]> wrote:

> I think this has value. It might bring apple and Microsoft to the table, since decoding-only is often the less patent-affecting part.
> 
> Silvia.
>

---

From: [email-masked]
Date: Fri, 22 Nov 2013 08:47:55 -0800

SDP can express sendonly and recvonly streams, so there is no inherent
problem with assymetry of codec choice.  But it would certainly complicate
things.

I would be in favor of a solution that allowed anyone (all browsers) to
decode both VP8 and h.264, no matter what they are capable of encoding.  In
my 1-to-many conference software, all streams are unidirectional.

On Fri, Nov 22, 2013 at 8:40 AM, tim panton <[email-masked]> wrote:

>>>> and vp8 (and in the future vp9 and h265) the decoder complexity is fairly
>>>> low and hardware acceleration is not critical but in the case of the
>>>> encoders where the complexity can be 3x or worse, hardware acceleration
>>>> becomes increasingly important
>>>>
>>>> Stefan
>>>>
>>>

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 10:47:33 -0600

The best technology is not simply which codec has the greatest compression efficiency, it is a function of complexity, performance, cost, error resiliency and many more.  

Today there exists no hardware acceleration for H.265 which means you will be hard pressed to do 720p30 encode on a high end laptop, something that even a low end, 3 year old intel can do without breaking a sweat.  On portable platforms like tablets and smartphones doing the encoder is software is going to make it impossible to do larger resolutions and it's going to kill the battery.  All of these have to be factors in deciding what is the best technology.

-----Original Message-----
From: John Leslie [mailto:[email-masked]] 
Sent: Friday, November 22, 2013 6:28 AM
To: Stefan Slivinski
Cc: [email-masked]
Subject: Re: [rtcweb] Proposed Video Selection Process

Stefan Slivinski <[email-masked]> wrote:
> search every possible location in the reference frame to find the best 
> match using SAD as a block matching algorithm...guess what?
> There's a patent for that. If you then decide that if there isn'?t a 
> really good match (high SAD), and you decide to do an intra search 

   There's an important point here, which many folks _do_ seem to be
missing: you _can_ run afoul of perfectly "valid" patents implementing 20-year-old technology. It is not the job of the IETF to even warn you about this; and it's _definitely_ not our job to say how you should deal with it.

   No.

   We're absolutely not trying to find the "best technology". We all agree that H.265 is better than H.264 and VP9 is better than VP8, but we're not focusing on either of them. Likewise, we all agree that H.263, while worse than either H.264 or VP8, is better than H.261.

   We're trying to find a "good enough" technology to be Mandatory To Implement. We've been trying for a long time; and we may end up failing.

   H.261 holds real promise there -- you can find an _implementation_ that's more than 20 years old and copy it bit-for-bit, and have a rock-solid "prior art" defense. (We're not saying that's what you should do; but it's an option available to you.)

> other level because it's going to be a wide spread concern, not just a 
> video problem.

   That's not a problem for _us_ to solve -- nor is it entirely rational to believe we will ever see it solved. I certainly agree the problem is quite widespread; but different companies will choose different paths to manage the risks. (As they should!)

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 10:54:06 -0600

Sorry, that should have read "something that even a low end, 3 year old intel can do __using H.264__ without breaking a sweat"

-----Original Message-----
From: John Leslie [mailto:[email-masked]]
Sent: Friday, November 22, 2013 6:28 AM
To: Stefan Slivinski
Cc: [email-masked]
Subject: Re: [rtcweb] Proposed Video Selection Process

   No.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 22 Nov 2013 09:03:32 -0800

In the basic case, I don't think O/A will have a problem with this, without
even needing to resort to 1-way streams.

Each side would offer both codec X and codec Y, and the remote side will
simply choose to send the one it supports (or prefers, if it supports both)

---

From: Roman Shpount <[email-masked]>
Date: Fri, 22 Nov 2013 12:19:04 -0500

Actually O/A model is asymmetric by default. All you specify in SDP are the
codecs you can receive. You are allowed to send a stream in any codec
remote side supports. So if both sides state that they support codecs X and
Y in SDP, one side can send X in one direction and another side can send Y
in opposite.

_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Nov 2013 09:33:41 -0800

On 21 November 2013 17:38, Bjoern Hoehrmann <[email-masked]> wrote:
> Like animated GIFs, or sending a bunch of

There's an RFC for that [RFC 2435] :)

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Nov 2013 09:39:39 -0800

> (Unless there is some arcane SDP FRACK at play here).

a=sendonly, a=recvonly aren't arcane.  In fact, this is already
necessary for cases where encoding is done in a camera.

---

From: Maik Merten <[email-masked]>
Date: Fri, 22 Nov 2013 18:43:21 +0100

> well, it’s band-limited and hardly compressed, but within those limits it’s OK.  Whereas I seem to recall having trouble getting decent quality out of H.261 no matter what I did with it (but it has…

I provided some samples at

https://drive.google.com/file/d/0B11N4VzriA21Z2J2ODlxTmFibmM/edit?usp=sharing

I'd say H.261 can do pretty okay-ish at around a Mbps (and is already 
useful, if not pretty, well below that), but pushing to "visually 
lossless" has unfavorable bitrate implications: I have a "normal users 
won't see the difference from the original" encoding of that testing 
sequence (complete with analog noise from the camera preserved), but it 
weighs in at 5 Mbps.

I would love to try out the QuickTime H.261 encoder, btw. Not sure it's 
still shipped, but I understand a *de*coder is still there? 
http://support.apple.com/kb/ht3775

Maik

---

From: Matt Fredrickson <[email-masked]>
Date: Fri, 22 Nov 2013 13:10:12 -0600

That is my understanding of O/A as well (at least last time I had to
deal with this in RFC3264 land).

Matthew Fredrickson

On Fri, Nov 22, 2013 at 11:19 AM, Roman Shpount <[email-masked]> wrote:
> codecs you can receive. You are allowed to send a stream in any codec remote
> side supports. So if both sides state that they support codecs X and Y in
> SDP, one side can send X in one direction and another side can send Y in
> opposite.
>
> _____________
> Roman Shpount
>
>
>>> VP8 and H.264" means "MUST implement both VP8 encoder and decoder, and H.264
>>> encoder and decoder".
>>>
>>> selection generator. But frankly speaking, except for the specific choice of
>>> "MUST implement both VP8 and H.264 decoders, and MUST implement at least one
>>> of VP8 and H.264 encoders", which is less onerous than "MUST implement both
>>> VP8 and H.264", but still interoperable, I don't see any choices with
>>>>> implies a mandatory encoder, however in the case where there are 2 mandatory
>>>>> decoders only a single encoder is technically required.
>>>>>

---

From: Paul Giralt <[email-masked]>
Date: Fri, 22 Nov 2013 14:57:01 -0500

I may be missing something but I don't know that this is entirely correct. From 3264: 

   The list of media formats for each media stream conveys two pieces of
   information, namely the set of formats (codecs and any parameters
   associated with the codec, in the case of RTP) that the offerer is
   capable of sending and/or receiving (depending on the direction
   attributes), and, in the case of RTP, the RTP payload type numbers
   used to identify those formats.

To me, this means that a capability in an offer or answer (with a direction attribute of sendrecv) means that you are capable of both sending and receiving for that particular capability. I don't see a way where you can specify (within a single m= line) that you are capable of receiving on two of the specified payload types, but only capable of sending on one of the two. In other words, if an offer or answer specifies both H.264 and VP8 with a sendrecv attribute, this implies that you are capable of both sending and receiving both. 

You could, of course, specify two separate m= lines where you specify both codecs as recvonly and the codec you support for sending as sendonly, but this is very complicated because now you have two separate m= lines for what really should be one bi-directional stream. 

Someone please correct me if I'm misunderstanding this. 

-Paul

---

From: David Singer <[email-masked]>
Date: Fri, 22 Nov 2013 12:01:37 -0800

> Stefan Wenger posted a fairly detailed analysis of the H.263 situation, which I think also applies to MPEG-2.

I’m not sure I’d call that a detailed analysis;  a detailed analysis would include, for example, opening up the 31/34 patent statements for each codec, identifying the patents, and seeing whether they had yet expired.  Stephan gave an ‘informed opinion’ that, for him, the increased performance was balanced by increased risk:

On Nov 18, 2013, at 8:35 , Stephan Wenger <[email-masked]> wrote:

> So is it worth evaluating H.263 further?  IMO, probably not.  It¹s
> doubtless technically better than H.261, but the risk is inproportionally
> higher.  And the whole idea of this substandard baseline codec has been to
> be essentially without risk.

but given the prevalence of the use of H.263 in existing systems and standards, I am not at all convinced we should give up on it so quickly.

I am not knocking his opinion, you understand, just questioning whether we should discard H.263 based on just this one opinion.

David Singer

---

From: Maik Merten <[email-masked]>
Date: Fri, 22 Nov 2013 22:19:36 +0100

> I am not knocking his opinion, you understand, just questioning whether we should discard H.263 based on just this one opinion.

The overall notion of H.261 being implementable without restrictions is 
easy to grasp: The technology is over 25 years old, which puts it into 
the "comfy zone" of patent expiration. It is hard to come up with a 
scenario where patents covering the original standard and original 
reference implementation would still be enforceable.

H.263 would be vastly preferable in terms of technology level and 
deployment, but it isn't yet old enough to *automatically* be in the 
same "comfy zone". It is quite old, but not *that* old.

This doesn't mean there actually *are* unavoidable H.263 patents. 
However, the IPR and licensing situation surrounding H.263 would need to 
be analyzed thoroughly by professionals and the findings would need to 
be shared.

Does anybody here have the resources to conduct such an analysis? If a 
credible analysis reveals that H.263 (or MPEG-1 Part 2, that one is also 
clearly superior to H.261) is actually carrying low risk this would be 
quite something.

Maik

---

From: "Ashish V. Thapliyal" <[email-masked]>
Date: Fri, 22 Nov 2013 13:54:00 -0800

Dear Chairs,
         I have participated in a face-to-face interim meeting in 2012 and
have been closely following the discussions on this list.

         I appreciate your heroic efforts to get to consensus on a
mandatory-to-implement video codec.  I am against the proposal to put this
issue to vote.  It will be hard to get it right and it will generate a lot
of complaints about who gets to vote and who does not.  In my opinion, a
fair coin toss, or allowing "either H.264 or VP8" would be preferable.
         Another interesting proposal, mentioned later in this email
thread, is the decoupling of encoder and decoder requirements.  In
particular, the idea of making both VP8 and H.264 decoders mandatory to
implement, while allowing a choice of either VP8 or H.264 encoders, is very
interesting.  It may provide a good avenue for compromise while giving us
most of the benefits of choosing one of the codecs.  It may also discourage
patent trolling because if one of the encoders gets hit by an unforeseen
intellectual property issue,  vendors could switch to the other, without
waiting for a change in the standards.

Thanks,
Ashish.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 22 Nov 2013 22:08:05 +0000

Perhaps we should also add all those that have been active in ITU or ISO/IEC on the codec discussions.

Perhaps we should also add both my grandmothers - I claim they will have insight into this issue as they are both dead.

Seriously, I don't see how any ballot process will not be open to claims (either real or imagined) that the ballot was compromised in some way. I do not think this is the way to go.

Regards

Keith 

> From: rtcweb [mailto:[email-masked]] On Behalf Of 
> Silvia Pfeiffer
> Sent: 21 November 2013 19:38
> To: Adam Roach
> Cc: [email-masked]
> > such a distance that they haven't expressed an opinion on 
> the mailing 
> > list, I can't see how taking a vote from them counts as 
> anything other 
> > than simple, old-fashioned ballot stuffing.
> 
> They might have just been active on the W3C webrtc list and 
> watched here to see what is happening with codecs, but 
> haven't expressed their position.
> 
> 
> > uninvolved (or
> > less-involved) parties at the same level as those who have actually 
> > been working on the topic. I do not think that a blue-sheet sign in 
> > without any on-list participation should be sufficient to 
> participate 
> > in the kind of process the chairs are proposing.
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 22 Nov 2013 22:08:06 +0000

No.

Some people, including myself, also want interoperability without transcoding with the existing deployed terminals for video codecs, i.e. so the gateway does not have to implement a transcoder. Those existing deployed terminals are essentially H.264.

Therefore from my viewpoint on the current proposals, any MTI decision that makes VP8 a sole MTI does nothing to support this.

That I assume is a technical viewpoint?

regards

Keith

________________________________
From: rtcweb [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 21 November 2013 22:32
To: Cullen Jennings
Cc: [email-masked]
Subject: Re: [rtcweb] Proposed Video Selection Process

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 Nov 2013 16:54:03 -0600

On 11/22/13 15:19, Maik Merten wrote:
> It is hard to come up with a scenario where patents covering the 
> original standard and original reference implementation would still be 
> enforceable. 

As a specific example of such a scenario -- one that is tantalizingly 
close to the subject at hand -- look here:

http://www.google.com/patents/US7376184

Read the first paragraph of the description. In layman's terms, it says 
"even though this patent is being issued in 2008, we claim that it was 
invented in January of 1992." And with a priority date prior to 1995, 
this means that they have protection for seventeen years from the date 
of issuance (i.e., until 2025).

Yes, this means that they have patent protection on this specific 
technique for 33 years after its invention.

In US courts, this is 100% legal and fully enforceable, since they 
started the process prior to 1995. And "prior to 1995" is exactly when 
we're talking about.

/a

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 23 Nov 2013 06:31:20 +0530

I agree with Emil & Peter that voting will not help to achieve Video codec
MTI in the industry. Let us assume that codec x is selected as per the
election result. Why should the opposite camp browser vendor or WebRTC
gateway/conference vendor *MUST* implement the specified codec x for the
sake IETF compliance? 

As the multiple codec alternative (candidate) exists and kind of implicit
coalition[1] allowed by IRV election mechanism, it is possible for less than
50% folks supported codec alternative as a first preference will be selected
as point in http://en.wikipedia.org/wiki/Instant-runoff_voting first
example. How this mechanism helps to achieve the better interop in the
internet which is our ultimate aim?

I'm worried that this election may results in situation of "the operation
was a success but the patient died."

Thanks

Partha

Note 1:  Implicit coalition - 2nd preference will become the voters choice
after the 1st preference is eliminated

From: rtcweb [mailto:[email-masked]] On Behalf Of Emil Ivov
Sent: Friday, November 22, 2013 2:51 AM
To: Peter St Andre, (stpeter)
Cc: [email-masked]
Subject: Re: [rtcweb] Proposed Video Selection Process

The IETF does not vote!

This is not a democracy!

The fact that I could afford a plane ticket to this meeting, had the time to
post on that mailing list or sent a +1 message on an XMPP MUC does not make
me more or less qualified to cast a vote on this topic than anyone else.

--sent from my mobile

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 19:38:35 -0600

Magnus Westerlund:  please add the following proposal to the list:

"must support both H.264 and VP8 decode and must support at least one of H.264 or VP8 encode" to the list of options

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Friday, November 22, 2013 2:54 PM
To: Maik Merten; [email-masked]
Subject: Re: [rtcweb] Proposed Video Selection Process

> original standard and original reference implementation would still be 

As a specific example of such a scenario -- one that is tantalizingly close to the subject at hand -- look here:

Read the first paragraph of the description. In layman's terms, it says "even though this patent is being issued in 2008, we claim that it was invented in January of 1992." And with a priority date prior to 1995, this means that they have protection for seventeen years from the date of issuance (i.e., until 2025).

Yes, this means that they have patent protection on this specific technique for 33 years after its invention.

In US courts, this is 100% legal and fully enforceable, since they started the process prior to 1995. And "prior to 1995" is exactly when we're talking about.

/a

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 Nov 2013 17:44:18 -0800

> On Nov 22, 2013, at 8:20 AM, "Emil Ivov" <[email-masked]> said:
> 

[BA] It strikes me that once we venture beyond consensus and running code into voting, we have left our home behind for someplace else whose principles should at the least be articulated.

For example, it would be helpful to understand whether we are now endorsing Kings and if so, whether the model is that of a constitutional monarchy, or more along the Absolutist line. 

we could decide to emulate Louis XIV (a defender of The Divine Right of Kings).

---

From: cowwoc <[email-masked]>
Date: Sat, 23 Nov 2013 03:33:58 -0500

Hi,

Here is a condensed response to the past 200+ posts :)

  * Instant run-off voting
      o I don't think that voting will solve all of the problems
        mentioned below, but if all other options fail (which we're
        close to) then I'm in favor of going ahead with the proposed
        process.
      o Whatever process we agree to should end with a binding decision
        at the end (as opposed to more endless debate).
  * People objecting to the very idea of voting (versus making the
    decision on a technical merit) miss the fact that this is no longer
    a technical debate.
      o We have already agreed that both VP8 and H.264 are technically
        "good enough". The only remaining differences are of a political
        and licensing in nature.
  * Voting will not solve (legitimate) licensing/IPR issues
      o For example, mandating H.264 as MTI won't help Debian because
        they cannot count license units.
      o We should brainstorm on how to remove these show-stoppers for
        all stakeholders (browsers, non-browsers, FOSS, Commercial). The
        "MUST implement 2 out of 3" approach is an example of how this
        can be done.
  * Who should participate
      o Either we should include anyone who posted on WebRTC mailing
        lists (rtcweb, public-webrtc, public-media-capture) or we should
        be try to be more inclusive by including anyone who merely
        subscribed to said lists.
      o As was suggested, publishing the full list of all voters along
        with their votes should remove any doubt of fraud. If we notice
        that 5000 voters came from the same company, we can legitimately
        question whether they are all active or whether they attempted
        to stuff the ballot.
  * Removing voting options
      o I think it is vital that we leave all options on the table
        (however silly some might think they are) and see where the
        chips drop.
      o I understand that some people object to a long list of options,
        but I'd rather err on the side of inclusivity than censorship. :)
  * Non-browsers are equally important
      o Most of the debate on this mailing list have centered around
        what the browsers will do, but if you've attended the WebRTC
        World conference over the past couple of years you will have
        noticed that a great number of demos are based on native
        applications (even more so as mobile adoption increases). There
        is a very strong interest in using WebRTC outside of the browser
        and any decision we make here should reflect that reality.
  * Endless debates aren't free
      o One thing that was evident at the conference is that many of
        companies are "moving beyond the specification".
      o The longer we debate these issues, the more likely we are to end
        up with a specification that simply documents the de-facto
        standard laid out by early adopters.
  * We need a higher-level Native API that mirrors the Javascript API
      o It's become evident that many companies in the conference are
        re-inventing the same wheel: namely, they are reimplementing
        features found in the Javascript API on top of the Native API.
      o Imagine how many developer years could be saved if the Native
        API provided some of these higher-level constructs. This ties
        into my earlier point that "non-browsers are equally important"
        to take into consideration.

     Thank you for the interesting conversation. It was nice meeting 
many of you at the conference! :)

Gili

---

From: Maik Merten <[email-masked]>
Date: Sat, 23 Nov 2013 10:20:35 +0100

> of issuance (i.e., until 2025).

As far as I can see the priority date for such filings does matter, too. 
How would such a patent apply to a set of algorithms described in a ca. 
1988 reference implementation?

I for sure see how this refiling mechanism could be trouble for MPEG-1 
Part 2 and H.263. We won't get a reliable answer on an engineering 
mailing list and I feel that actual legal resources may need to be 
employed to get a decent risk-assessment.

Maik

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 23 Nov 2013 18:37:14 +0900

On 2013/11/23 10:44, Bernard Aboba wrote:
>> On Nov 22, 2013, at 8:20 AM, "Emil Ivov"<[email-masked]>  said:
>>

Voting and kings don't necessarily go together. There's for example a 
lot of voting in Switzerland, but no kings.

But seriously, I think one consequence of the IETF trying voting in this 
case might be that in other, potentially less disputed, cases, the 
people "in the rough" might cling to their position longer and demand 
voting too. So starting voting may turn out to be a first step onto a 
slippery slope.

Regards,   Martin.

---

From: Emil Ivov <[email-masked]>
Date: Sat, 23 Nov 2013 15:40:46 +0100

On 23.11.13, 09:33, cowwoc wrote:
> # People objecting to the very idea of voting (versus making the decision
> on a technical merit) miss the fact that this is no longer a technical
> debate.
>
>   * We have already agreed that both VP8 and H.264 are technically "good
>     enough". The only remaining differences are of a political and
>     licensing in nature.

Indeed they are and the IETF is not an organisation that can resolve 
political and licensing issues *through voting*.

Imagine you have disease A and you consult a doctor. You get all 
necessary examinations then a week later you go back and she says:

"I can't tell you what the best cure for you is. There is no consensus 
on the subject. There were two candidates that could do the job but one 
requires killing a 1000 puppies and one little piggy to produce a single 
pill while the other one hasn't passed FDA approval yet and it might 
just end up killing you"

"That said," she goes on, "we took a vote with my beer buddies and every 
one who had ever sent me a mail containing the words 'disease A'. That 
vote said you MUST take the puppy/piggy slaughtering pill."

"I MUST?," you say barely believing.

"Yup," she confirms, "You MUST! Otherwise you are not getting reimbursed 
for your medical expenses and your medical insurance contract is being 
annulled."

...

This has nothing to do with exactly how important an MTI is. It's about 
what the IETF can and cannot do. If we can reach consensus on a solution 
(e.g. some combination of MTI encoders/decoders) then great. Otherwise 
someone else will have to do the choice. It could be the W3C It could be 
some WebRTC Alliance/Forum. That decision can just as easily be 
referenced in RFP requirements.

Emil

-- 
https://jitsi.org

---

From: Marc Abrams <[email-masked]>
Date: Sat, 23 Nov 2013 08:50:43 -0800

Really great points about non-browsers and native APIs. 

As much as we want to live in our browsers, native app support on mobile devices are the best way to distribute, monetize and enable app discovery for marketing and sales. If we truly want to encourage mass adoption of WebRTC technologies, this has to be a priority. 

As to native APIs, it would be much better for non-browser development and support to not have to reinvent the wheel in likely slightly incompatible versions of homegrown APIs. A native API would minimize interoperability problems and accelerate adoption as well.

marc
________________
Marc Abrams
+1-949-873-0501
[email-masked]

On Nov 23, 2013, at 12:33 AM, cowwoc <[email-masked]> wrote:

> Instant run-off voting
> I don't think that voting will solve all of the problems mentioned below, but if all other options fail (which we're close to) then I'm in favor of going ahead with the proposed process.
> Whatever process we agree to should end with a binding decision at the end (as opposed to more endless debate).
> People objecting to the very idea of voting (versus making the decision on a technical merit) miss the fact that this is no longer a technical debate.
> We have already agreed that both VP8 and H.264 are technically "good enough". The only remaining differences are of a political and licensing in nature.
> Voting will not solve (legitimate) licensing/IPR issues
> For example, mandating H.264 as MTI won't help Debian because they cannot count license units.
> We should brainstorm on how to remove these show-stoppers for all stakeholders (browsers, non-browsers, FOSS, Commercial). The "MUST implement 2 out of 3" approach is an example of how this can be done.
> Who should participate
> Either we should include anyone who posted on WebRTC mailing lists (rtcweb, public-webrtc, public-media-capture) or we should be try to be more inclusive by including anyone who merely subscribed to said lists.
> As was suggested, publishing the full list of all voters along with their votes should remove any doubt of fraud. If we notice that 5000 voters came from the same company, we can legitimately question whether they are all active or whether they attempted to stuff the ballot.
> Removing voting options
> I think it is vital that we leave all options on the table (however silly some might think they are) and see where the chips drop.
> I understand that some people object to a long list of options, but I'd rather err on the side of inclusivity than censorship. :)
> Non-browsers are equally important
> Most of the debate on this mailing list have centered around what the browsers will do, but if you've attended the WebRTC World conference over the past couple of years you will have noticed that a great number of demos are based on native applications (even more so as mobile adoption increases). There is a very strong interest in using WebRTC outside of the browser and any decision we make here should reflect that reality.
> Endless debates aren't free
> One thing that was evident at the conference is that many of companies are "moving beyond the specification".
> The longer we debate these issues, the more likely we are to end up with a specification that simply documents the de-facto standard laid out by early adopters.
> We need a higher-level Native API that mirrors the Javascript API
> It's become evident that many companies in the conference are re-inventing the same wheel: namely, they are reimplementing features found in the Javascript API on top of the Native API.
> Imagine how many developer years could be saved if the Native API provided some of these higher-level constructs. This ties into my earlier point that "non-browsers are equally important" to take into consideration.
>     Thank you for the interesting conversation. It was nice meeting many of you at the conference! :)
> Gili

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 24 Nov 2013 17:52:35 +0100

On 11/21/2013 08:11 PM, Harald Alvestrand wrote:
> Forking this thread, and leaving aside all consideration of whether 
> the IETF should do voting, whether the electorate is the right 
> electorate for the decision and so on:
>
> you drop the lowest-ranked candidate and distribute the ballots that 
> had this as their #1 across the other candidates.
>
> This has the property that in a polarized situation, compromises may 
> get dropped out of the running before the alternatives that they might 
> serve as a compromise between.
>
> In this case, I'd favour a Condorcet-compatible method, such as 
> Schulze; it provides the guarantee that if a choice is preferred by a 
> majority of the participants over every other choice, it will always 
> be chosen.
>

I haven't seen much response to this - except pointing out that no 
voting method is perfect - but I really think the issue of Condorcet vs 
IRV matters in this case.

We have two strong camps who have a clear preferred choice, and we have 
some possible compromises. Me being the compromising type, I think we 
might be better off with a compromise than one of the strong camps' 
preferences.

Let's imagine, for a moment, that the options are:

A: Codec A
B: Codec B
C: At least one of Codec A and B

If the distribution is like this:

A proponents (40%): A C B
B proponents (40%): B C A
Compromisers group 1 (5%): C A B
Compromisers group 2 (15%): C B A

Then under IRV, the first round will go 40/40/20, alternative C will be 
eliminated, and B will be chosen.
Under Condorcet, the outcomes will be:

- A outranks B on 55%
- C outranks A on 60%
- C outranks B on 60%

Therefore, C is a Condorcet winner.

IRV is less likely to lead to a second-ranked compromise that everyone 
can live with than Condorcet.

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 25 Nov 2013 00:43:50 +0530

Hi Harald & all,

IMO, The fundamental problem with these methods (Condorcet & IRV) is that
they are designed to find the winner out of the discrete candidates (A, B,
C) in mind whereas the candidates in this voting is of combination of
discrete and set nature (A, B, (A & B), (A | B)). I like to see the proof
whether the above methods (Condorcet & IRV) are really designed to bring the
correct winner in these set of candidates as well.

I can show how your example of Condorcet fail with (A|B) is as follows: The
candidates are A,B, (A|B) 

A: Codec A
B: Codec B
A|B: At least one of Codec A and B 

A proponents (40%): A A|B 
B proponents (40%): B A|B 
Compromisers group 1 (5%): A|B A 
Compromisers group 2 (15%): A|B B 

Then under IRV, the first round will go 40/40/20, alternative A|B will be
eliminated, and B will be chosen with 55 as A has 45 only in the second
round.

- A outranks B on 55%
- B outranks A on 45%
- A|B outranks A on 60%
- A|B outranks B on 60%

Therefore, A|B is a Condorcet winner and election is successful. In reality,
the original winner is B and compromisers group 2 which is interested only
in implementing B which has 55% supporter. Also, A and Compromisers group 1
is interested only in implementing A which is 45%. So, Condorcet winner is
not required to be correct in case A|B, A&B candidates exists in the
election.

Having said that, I agree with you that IVR is also not required to yield
correct election result in case A&B, A|B candidates exists. 

As of now as I mentioned in
http://www.ietf.org/mail-archive/web/rtcweb/current/msg10113.html, the
election result may leads to the situation of "the operation was a success
but the patient died". Please let me know your opinion on the same.

Thanks
Partha

> From: rtcweb [mailto:[email-masked]] On Behalf Of Harald
> Alvestrand
> Sent: Sunday, November 24, 2013 10:23 PM
> To: [email-masked]
> Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video
> Selection Process)
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 25 Nov 2013 00:48:13 +0530

Herve,

I mailed in the another mail thread why Condorset fails for the given
candidates with detailed example. Please let me know your opinion on the
same.

Thanks
Partha

> From: Hervé W. [mailto:[email-masked]]
> Sent: Saturday, November 23, 2013 6:55 AM
> To: Parthasarathi R; 'Emil Ivov'; 'Peter St Andre, (stpeter)'
> Cc: [email-masked]
> Subject: RE: [rtcweb] IETF will fail to implement Video codec MTI after
> election? [was RE: Proposed Video Selection Process]
> 
> > From: [email-masked]
> 
> 
> > As the multiple codec alternative (candidate) exists and kind of
> > implicit coalition[1] allowed by IRV election mechanism, it is
> possible
> > for less than 50% folks supported codec alternative as a first
> > preference will be selected as point in
> > http://en.wikipedia.org/wiki/Instant-runoff_voting first example. How
> > this mechanism helps to achieve the better interop in the internet
> > which is our ultimate aim?
> 
> Would you find a Condorset method more acceptable? Harald Alvestrand
> suggested that.
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09928.html
> 
> > Note 1:  Implicit coalition – 2nd preference will become the voters
> > choice after the 1st preference is eliminated
> 
> 
> - Hervé 		 	   		  =

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 24 Nov 2013 23:02:07 +0100

> candidates are A,B, (A|B) 

Question: Why do you consider choosing A|B a fail, given that you give
exactly the same preference numbers under which I consider this position
a reasonable outcome?

The Condorcet winner will always beat each other candidate if no other
candidate is present (except in the case of a loop). With your numbers,
A|B is preferred over A, and A|B is preferred over B, so why is choosing
A|B a fail?

-- 
Surveillance is pervasive. Go Dark.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Nov 2013 13:34:36 +0100

> "must support both H.264 and VP8 decode and must support at least one of H.264 or VP8 encode" to the list of options

I have added the following to the Wiki. I hope you don't mind me
slightly changing your proposal for clear wording:

12. MUST support decoding using both H.264 and VP8, and MUST support
encoding using at least one of H.264 or VP8

Cheers

Magnus Westerlund

----------------------------------------------------------------------
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: "Parthasarathi R" <[email-masked]>
Date: Mon, 25 Nov 2013 23:22:30 +0530

Hi Harald,

The difference between your distribution and my distribution is that all
voters select all the possible combination in your distribution whereas in
my distribution, voters selected their specific choice.

In my case, A proponents and Compromisers group 1 treats A|B as A only (45%)
and which is logically correct. OTOH, B proponents and Compromisers group 2
treat A|B as B only (55%). Condorcet mechanism does not bring out the truth
that A has 45% implementation only whereas B has 55% implementation
preference. For my given distribution, IRV brings the truth perfectly as A
has 45% and B has 55% as explained in the previous mail and it reflects the
actual intention of voters. 

In current situation of Video codec MTI, my distribution looks more relevant
as most of the folks does not want the opposite camp codec.

Thanks
Partha

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Monday, November 25, 2013 3:32 AM
> To: Parthasarathi R; [email-masked]

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 25 Nov 2013 23:53:11 +0530

Please read inline.

> From: Hervé [mailto:[email-masked]]
> Sent: Monday, November 25, 2013 4:25 AM
> To: Parthasarathi R; 'Harald Alvestrand'; [email-masked]
> Subject: RE: [rtcweb] Voting method choice (Re: Proposed Video
> Selection Process)
> 
> ----------------------------------------
> I think your commentary below agrees that you swapped the numbers
> there.
> 
> 
> > - A|B outranks A on 60%
> > - A|B outranks B on 60%
> >
> What would you say is the correct winner?
> 
<Partha> In the given example, B is actual winner as it will results in 55%
implementation. As I explained in Harald mail thread, it is not coming out
by Condorcet mechanism. </Partha>

> One that avoids negotiation failure completely? A|B does not do that.
> (But might reduce the chance a little compared to no MTI.)
> 
<Partha> Agreed </Partha>

> One that the most people find acceptable? A|B is that.
<Partha> If your statement is true, there should be rough consensus for A|B
before taking voting (alternative) process. Currently, the proposed video
selection process is going for vote and then asking for regular rough
consensus mechanism for A|B if vote (alternative) fail </Partha>

> The voters in the condorcet hypothetical all get their wish and can
> comply with rtcweb without implementing the codec they do not want.
> 
> 
> From the examples I've seen, I think condorcet would be preferable to
> IRV.
> 
> There is the argument 'The IETF does not vote' to contend with. I don't
> know about that. I think VP8 as the only MTI or H.264 as the only MTI
> is unlikely to find consensus, but I also agree that the "or could live
> with" crowd might have been masked during the meeting.
<Partha> It should come out through the rough consensus </Partha>

> I think it's good to look into some alternative proposals and would be
> good to see which are least objectionable. And a vote could be just the
> tool to do that.
> Is consensus not an acceptable resolution, if not the favourite? and
> condorcet seems like a method to find it.
> 
> Another tool, a list of pros and cons,
> https://etherpad.mozilla.org/RSbHIuSOgn .
>
<Partha> Good information. I agree with the information which exists as of
now </Partha>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 27 Nov 2013 14:53:17 +0000

Adam, thought I agree with your meta point about submarine patents existed in the past, I don' think you have this quite right on the details on this one. 

For US patents applications filed prior to June 8, 1995, the term is either 17 years from date of issue or 20 years from earliest priority date, whichever is later. For applications filed after June 8, 1995, the term is 20 years from the earliest priority date.

Given this was filed after 1995, it expires 20 years after the priority date so it expired in 2012. 

On Nov 22, 2013, at 3:54 PM, Adam Roach <[email-masked]> wrote:

>> It is hard to come up with a scenario where patents covering the original standard and original reference implementation would still be enforceable. 
>

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 27 Nov 2013 15:22:27 +0000

Cullen,
You missed the patent term adjustment of 487 days in this case--a very
short adjustment period for a video coding patent (see note on over page
right below the assignees).  Note that this PTA is occasionally adjusted
upwards after printing of the cover page (quite often actually for
standards essential cases), which is recorded in the file wrapper and
usually (but not always) in a certificate of correction.
The patent in question is currently being litigated in an MPEG-2 context,
and I have heard that the question of PTA has come up (though I do not
know any details).
Stephan

On 11.27.2013, 06:53 , "Cullen Jennings (fluffy)" <[email-masked]> wrote:

>
>Adam, thought I agree with your meta point about submarine patents
>existed in the past, I don' think you have this quite right on the
>details on this one.
>
>For US patents applications filed prior to June 8, 1995, the term is
>either 17 years from date of issue or 20 years from earliest priority
>date, whichever is later. For applications filed after June 8, 1995, the
>term is 20 years from the earliest priority date.
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 27 Nov 2013 15:28:28 +0000

fair enough - I did not look at any of the file wrapper information