Subject: [rtcweb] Straw Poll on Video Codec Alternatives

From: Ted Hardie <[email-masked]>
Date: Mon, 9 Dec 2013 09:24:35 -0800

Dear WG,

This is the email announcing the straw poll across the video codec
alternatives proposed to the WG. If you haven’t read the “Next Steps in
Video Codec Selection Process” (
http://www.ietf.org/mail-archive/web/rtcweb/current/msg10448.html )then
please do that before you continue to read.

The straw poll’s purpose is to make it clear to the WG which of the
alternatives that are favored or disfavored and what objections you have,
if any, against a particular alternative. The WG chairs will use the
information from this straw poll to identify an alternative to put as a
single consensus question to the group. Thus, everyone that has an opinion
on at least one alternative should answer this poll. Provide your poll
input by replying to this email to the WG mailing list. The poll will run
until the end of the 12th of January 2014.

As can be seen below, the poll lists the alternative that have proposed to
the WG. For each alternative two questions are listed.

The first question is “Are you in favor of this option
[Yes/No/Acceptable]:”. These three levels allow you to indicate that you:
Yes= I would be fine with the WG choosing this option. No = I really don’t
favor this, and it should not be picked. Acceptable = I can live with this
option but I prefer something else to be picked.

The second question is “Do you have any objections to this option, if so
please explain it:” If you have any objection at a minimum indicate it with
a “Yes”.   Please also add a short (1-sentence) summary of each of the
objections you believe applies.  (If you wish to provide a longer
explanation, please do so in a separate thread).  If you have no objection,
leave that question blank.

Please provide input on as many of the alternatives as you like and feel
comfortable to do. The more inputs, the more well informed decision the WG
chairs can take when identifying the option to be brought forward for
consensus. Any alternative that you chose to leave blank, will simply be
considered as one without any input from you.

WG participants, please do not comment on anyone’s input in this thread! If
you want to comment, then create a separate thread and change the subject
line to something else. Otherwise you are making life for the chairs very
difficult to track the results of this straw poll.

If discussion causes you to update your position, please feel free to send
an update via email on the straw poll thread prior to the closing date.

   1.

   All entities MUST support H.264
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      2.

   All entities MUST support VP8
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      3.

   All entities MUST support both H.264 and VP8
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      4.

   Browsers MUST support both H.264 and VP8, other entities MUST support at
   least one of H.264 and VP8
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      5.

   All entities MUST support at least one of H.264 and VP8
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      6.

   All entities MUST support H.261
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      7.

   There is no MTI video codec
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      8.

   All entities MUST support H.261 and all entities MUST support at least
   one of H.264 and VP8
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      9.

   All entities MUST support Theora
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      10.

   All entities MUST implement at least two of {VP8, H.264, H.261}
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      11.

   All entities MUST implement at least two of {VP8, H.264, H.263}
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      12.

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

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      13.

   All entities MUST support H.263
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      14.

   All entities MUST implement at least two of {VP8, H.264, Theora}
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      15.

   All entities MUST support decoding using Theora.
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:
      16.

   All entities MUST support Motion JPEG
   1.

      Are you in favor of this option [Yes/No/Acceptable]:
      2.

      Do you have any objections to this option, if so please summarize
      them:

H.264 is a reference to the proposal in
https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/<https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/>

VP8 is a reference to the proposal in
https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/<https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/>

Theora is a reference to Xiph.org Theora Specification from March 16, 2011 (
http://www.xiph.org/theora/doc/Theora_I_spec.pdf)

H.263 is a reference to profile 0 level 70 defined in annex X of ITU-T rec
H.263 (http://www.itu.int/rec/T-REC-H.263/)

H.261 is a reference to http://tools.ietf.org/html/rfc4587

Motion JPEG is a reference to http://tools.ietf.org/html/rfc2435

Thanks,

The Chairs

---

From: John Leslie <[email-masked]>
Date: Mon, 9 Dec 2013 12:51:34 -0500

Ted Hardie <[email-masked]> wrote:
>... 
> Provide your poll input by replying to this email to the WG mailing list.
>...

   I don't see a Reply-To header; and plain reply sends only to Ted.

   Ted's statement is not clear whether he wants the reply to go to
the list, alas...

   I really think that should be made clear.

   (BTW, "reply-to-all" comes up with a rather long list...)

--
John Leslie <[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 09 Dec 2013 09:54:00 -0800

On 12/9/2013 9:24 AM, Ted Hardie wrote:
> [Yes/No/Acceptable]:”. These three levels allow you to indicate that
> you: Yes= I would be fine with the WG choosing this option. No = I
> really don’t favor this, and it should not be picked. Acceptable = I can
> live with this option but I prefer something else to be picked

Survey methodology remains trickier than anyone would like:  The set of 
choices is unbalanced.

In effect, two of the three choices say that a choice is ok and only one 
says it isn't.  You also need a 'don't care' choice.

Given the intent of 'acceptable', what you need is something like:

    Yes
    Prefer yes
    Don't care
    Prefer no
    No

The first and last indicate simple, direct views, without indicating 
feelings about alternatives.  They might imply "yes means only this is 
acceptable" and no means can't live with this choice", but that probably 
doesn't have to be made explicit.

The second and fourth add those preferences for and against alternatives.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 9 Dec 2013 18:00:58 +0000

I don't think the chairs feel like we need that level of detail in trying to figure out what consensus call we might make. 

On Dec 9, 2013, at 10:54 AM, Dave Crocker <[email-masked]>
 wrote:

> Survey methodology remains trickier than anyone would like:  The set of choices is unbalanced.
> 
> In effect, two of the three choices say that a choice is ok and only one says it isn't.  You also need a 'don't care' choice.
> 
> The first and last indicate simple, direct views, without indicating feelings about alternatives.  They might imply "yes means only this is acceptable" and no means can't live with this choice", but that probably doesn't have to be made explicit.
>

---

From: John Leslie <[email-masked]>
Date: Mon, 9 Dec 2013 13:02:40 -0500

Dave Crocker <[email-masked]> wrote:
>> The first question is ?Are you in favor of this option
>> [Yes/No/Acceptable]:?. These three levels allow you to indicate that
>> really don?t favor this, and it should not be picked. Acceptable = I can
> says it isn't.

   I must agree with Dave that the difference between "Acceptable" and
"Yes" is a bit ambiguous. I would have recommended a simple Yes/No/blank.
But I don't believe Dave raises an issue we need to address.

> You also need a 'don't care' choice.

   Blank is clearly a legal choice.

> Given the intent of 'acceptable', what you need is something like:

   Again, I don't think we need to follow Dave's advice (even if I would
be more comfortable with those choices).

---

From: Adam Roach <[email-masked]>
Date: Mon, 09 Dec 2013 12:13:18 -0600

> 1.  All entities MUST support H.264
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

Yes

 >         b. Do you have any objections to this option, if so please
 >            summarize them:
 >
 > 2.  All entities MUST support VP8
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

Yes

 >         b. Do you have any objections to this option, if so please
 >            summarize them:
 >
 > 3.  All entities MUST support both H.264 and VP8
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

No

 >         b. Do you have any objections to this option, if so please
 >            summarize them:

Yes; two major objections.

First, the specification of these specific two codecs as MTI creates a union
of the problems raised regarding each codec: given a choice between a 
rock and
a hard place, only a fool would select both. (There is nuance here: the 
folly
is in requiring everyone to implement both, not in implementing both.)

Second, forcing all implementations to source and maintain two codecs 
just to
remain compliant creates additional, unnecessary barriers to entry.

 > 4.  Browsers MUST support both H.264 and VP8, other entities MUST 
support at
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

No

 >         b. Do you have any objections to this option, if so please
 >            summarize them:

Yes; see my "first" objection to 3b above.

 > 5.  All entities MUST support at least one of H.264 and VP8
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

No

 >         b. Do you have any objections to this option, if so please
 >            summarize them:

Yes. Assuming this is the only statement made on video codecs, this would
represent a failure of the working group to define an interoperable
communications protocol. If the specifications produced by standards bodies
result in compliant implementations that can't interoperate with each other,
then we're better off with proprietary, unstandardized implementations. 
If we
go this way, we may as well shut down the WG and send everyone off to do
useful things, since the WG's reason for existing will have been nullified.

 > 6.  All entities MUST support H.261
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

 >         b. Do you have any objections to this option, if so please
 >            summarize them:
 >
 > 7.  There is no MTI video codec
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

No

 >         b. Do you have any objections to this option, if so please
 >            summarize them:

Yes; see 5b, above.

 > 8.  All entities MUST support H.261 and all entities MUST support at 
least one
 >     of H.264 and VP8
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

 >         b. Do you have any objections to this option, if so please
 >            summarize them:

Yes. Forcing all implementations to source and maintain two codecs just to
remain compliant creates additional, unnecessary barriers to entry.

 > 9.  All entities MUST support Theora
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

 >         b. Do you have any objections to this option, if so please
 >            summarize them:
 >
 > 10. All entities MUST implement at least two of {VP8, H.264, H.261}
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

 >         b. Do you have any objections to this option, if so please
 >            summarize them:

Yes. Forcing all implementations to source and maintain two codecs just to
remain compliant creates additional, unnecessary barriers to entry.

 > 11. All entities MUST implement at least two of {VP8, H.264, H.263}
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

 >         b. Do you have any objections to this option, if so please
 >            summarize them:

Yes. Forcing all implementations to source and maintain two codecs just to
remain compliant creates additional, unnecessary barriers to entry.

 > 12. All entities MUST support decoding using both H.264 and VP8, and MUST
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

No.

 >         b. Do you have any objections to this option, if so please
 >            summarize them:

Yes. See both objections to 3b, above.

 > 13. All entities MUST support H.263
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

 >         b. Do you have any objections to this option, if so please
 >            summarize them:
 >
 > 14. All entities MUST implement at least two of {VP8, H.264, Theora}
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

 >         b. Do you have any objections to this option, if so please
 >            summarize them:

Yes. Forcing all implementations to source and maintain two codecs just to
remain compliant creates additional, unnecessary barriers to entry.

 > 15. All entities MUST support decoding using Theora.
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

 >         b. Do you have any objections to this option, if so please
 >            summarize them:
 >
 > 16. All entities MUST support Motion JPEG
 >         a. Are you in favor of this option [Yes/No/Acceptable]:

No

 >         b. Do you have any objections to this option, if so please
 >            summarize them:

Yes. As far as I can tell, this is the only codec proposed so far that
actually cannot transmit usable video streams over average consumer 
broadband
connections in real-time.

/a

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 9 Dec 2013 18:22:18 +0000

Clarification: Just in case there was any confusion, we want the responses to the straw poll to go to the rtcweb@ietf list so everyone can see them. Thanks, Cullen 

On Dec 9, 2013, at 10:24 AM, Ted Hardie <[email-masked]>
 wrote:

> Dear WG,
> 
> This is the email announcing the straw poll across the video codec alternatives proposed to the WG. If you haven’t read the “Next Steps in Video Codec Selection Process” (http://www.ietf.org/mail-archive/web/rtcweb/current/msg10448.html )then please do that before you continue to read.
> 
> The straw poll’s purpose is to make it clear to the WG which of the alternatives that are favored or disfavored and what objections you have, if any, against a particular alternative. The WG chairs will use the information from this straw poll to identify an alternative to put as a single consensus question to the group. Thus, everyone that has an opinion on at least one alternative should answer this poll. Provide your poll input by replying to this email to the WG mailing list. The poll will run until the end of the 12th of January 2014.
> 
> As can be seen below, the poll lists the alternative that have proposed to the WG. For each alternative two questions are listed.
> 
> The first question is “Are you in favor of this option [Yes/No/Acceptable]:”. These three levels allow you to indicate that you: Yes= I would be fine with the WG choosing this option. No = I really don’t favor this, and it should not be picked. Acceptable = I can live with this option but I prefer something else to be picked.  
> 
> The second question is “Do you have any objections to this option, if so please explain it:” If you have any objection at a minimum indicate it with a “Yes”.   Please also add a short (1-sentence) summary of each of the objections you believe applies.  (If you wish to provide a longer explanation, please do so in a separate thread).  If you have no objection, leave that question blank.
> 
> Please provide input on as many of the alternatives as you like and feel comfortable to do. The more inputs, the more well informed decision the WG chairs can take when identifying the option to be brought forward for consensus. Any alternative that you chose to leave blank, will simply be considered as one without any input from you.  
> 
> WG participants, please do not comment on anyone’s input in this thread! If you want to comment, then create a separate thread and change the subject line to something else. Otherwise you are making life for the chairs very difficult to track the results of this straw poll.  
> 
> If discussion causes you to update your position, please feel free to send an update via email on the straw poll thread prior to the closing date.
> 
> 
> 	• All entities MUST support H.264
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST support VP8
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST support both H.264 and VP8
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST support at least one of H.264 and VP8
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST support H.261
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• There is no MTI video codec
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST support Theora
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST implement at least two of {VP8, H.264, H.261}
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST implement at least two of {VP8, H.264, H.263}
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST support H.263
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST implement at least two of {VP8, H.264, Theora}
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST support decoding using Theora.
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 	• All entities MUST support Motion JPEG
> 		• Are you in favor of this option [Yes/No/Acceptable]:
> 		• Do you have any objections to this option, if so please summarize them:
> 
> 
> H.264 is a reference to the proposal in https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/
> 
> VP8 is a reference to the proposal in https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/
> 
> Theora is a reference to Xiph.org Theora Specification from March 16, 2011 (http://www.xiph.org/theora/doc/Theora_I_spec.pdf)
> 
> H.263 is a reference to profile 0 level 70 defined in annex X of ITU-T rec H.263 (http://www.itu.int/rec/T-REC-H.263/)
>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 09 Dec 2013 10:37:38 -0800

> I don't think the chairs feel like we need that level of detail in trying to figure out what consensus call we might make.

You misunderstood my note, apparently at the level of confusing data 
with information:  The concern I'm raising is not about "level" of 
detail but that unbalanced response choice are known to bias responses 
and evaluation.  So while you'll presumably get lots of responses, their 
meaning might not be as obvious as one would expect.

It's clear that the new questionnaire is trying to be diligently 
thorough.  However the choice of responses create an extremely 
well-known methodology problem.

For example:

http://help.surveymonkey.com/articles/en_US/kb/Design-Tips-How-to-create-and-administer-effective-surveys

http://help.surveymonkey.com/articles/en_US/kb/SurveyMonkey-Audience-Tips-Question-Design-Tips#fully-inclusive-answer-options

and especially:

      Basics of Survey and Question Design
 
http://www.howto.gov/customer-experience/collecting-feedback/basics-of-survey-and-question-design

Take a look at the sections on:

      Leaving out choices
 
http://www.howto.gov/customer-experience/collecting-feedback/basics-of-survey-and-question-design#leavingout

      Leading questions
 
http://www.howto.gov/customer-experience/collecting-feedback/basics-of-survey-and-question-design#leading

      Built-in assumptions
 
http://www.howto.gov/customer-experience/collecting-feedback/basics-of-survey-and-question-design#assumptions

 >     Blank is clearly a legal choice.

An empty answer vs. an explicit "don't care" have entirely different 
semantics.  Empty answer, for example, might mean "I care but I can't 
decide"; it might mean other things, too.

d/

---

From: cowwoc <[email-masked]>
Date: Mon, 09 Dec 2013 14:05:37 -0500

What about this?

Yes: I am in favor of this option, and would implement it.
Acceptable: I am neutral on this option, but would implement it if it is 
chosen as MTI.
No: I am against this option, and would not implement it even if it is 
chosen as MTI.

Gili

On 09/12/2013 1:37 PM, Dave Crocker wrote:
>> I don't think the chairs feel like we need that level of detail in 
>> trying to figure out what consensus call we might make.
>
> and evaluation.  So while you'll presumably get lots of responses, 
> their meaning might not be as obvious as one would expect.
>

---

From: John Leslie <[email-masked]>
Date: Mon, 9 Dec 2013 14:25:04 -0500

(This is a different clarification: thanks for clarifying my first question.)

   I notice Adam Roach has provided an answer on-list which is both
reasonable and easy to read.

   When I tried a reply from my mail-reader, I became confused by the
numbering; and I eventually gave up because I wasn't sure how automatic
software might interpret my answers.

   (Ted's original had confusing numbers following each question, e.g.:
] 
]    All entities MUST support both H.264 and VP8
]    1.
] 
]       Are you in favor of this option [Yes/No/Acceptable]:
]       2.
] 
]       Do you have any objections to this option, if so please summarize   
]       them:
]       4.

   Adam left out the "2" following each "in favor" question, and attached
the question-number, e.g. "4" to the next question.

   Should we be trying to emulate Adam's format -- or is there some
automated way to answer the questions in an unambiguous manner?

---

From: Ted Hardie <[email-masked]>
Date: Mon, 9 Dec 2013 12:03:00 -0800

> software might interpret my answers.
We're not planning on using automated software to interpret your answers,
so as long as you answer the questions in a way that unambiguously
associates
the answer to the question, you should be okay.

If you, or others, would like to emulate Adam's format, you are welcome to
do so.

Ted

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Mon, 09 Dec 2013 15:28:53 -0500

> No: I am against this option, and would not implement it even if it is

This is still unbalanced, I believe, for many of the same reasons.  What
about, "I am against this, but I will implement it even if it is MTI".
This conveys an entirely different idea about feelings on an issue.  The
person would have chosen differently if given an option, whereas neutral
means they actually don't care about this vs. another option, meaning
they're the same for the purpose.

-- 
Libre Video
http://librevideo.org

---

From: cowwoc <[email-masked]>
Date: Mon, 09 Dec 2013 15:30:10 -0500

> they're the same for the purpose.

I'm fine with changing the middle option to "I am against this, but will 
implement it even if it is MTI". It conveys the same feeling that I 
meant with the previous text.

Gili

---

From: cowwoc <[email-masked]>
Date: Mon, 09 Dec 2013 15:30:17 -0500

I'm fine with changing the middle option to "I am against this, but will 
implement it even if it is MTI". To me, it conveys the same feeling that 
I meant with the previous text.

Gili

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Mon, 9 Dec 2013 23:32:10 +0000

I believe we are way off the acceptable process track here.

First, there was a discussion and a call for rough consensus at the last IETF in-person meeting. That call was not continued on the list, instead a lack of consensus was declared at the meeting.

Next, there was a proposal from the chairs to vote in a particular way, and a call for options on which to vote. It was claimed at that time that after the list was compiled, the act of taking such a vote would be taken to a consensus call. That never happened.

Instead the chairs are now conducting a "straw poll" of their own design, clearly in an effort to circumvent some very specific objections to the proposed instant-runoff vote with restricted participation. But again, instead of attempting to reach WG consensus for conducting such a poll, it has simply been foisted upon us.

I have not seen ANY replies to the message "Next Steps in Video Codec Selection Process" that indicate working group consensus of ANY KIND for conducting a poll in this format at this time or to follow the subsequent steps described in that message.

I am requesting that the chairs immediately suspend the "Straw Poll" described below until such time as there is Working Group consensus to spend the Working Group's time and energy conducting the poll and/or to continue with the subsequent steps called out in "Next Steps in Video Codec Selection Process" at http://www.ietf.org/mail-archive/web/rtcweb/current/msg10448.html

Matthew Kaufman

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Monday, December 9, 2013 5:25 PM
To: [email-masked]; Gonzalo Camarillo; Richard Barnes; Magnus Westerlund; Cullen Jennings
Subject: [rtcweb] Straw Poll on Video Codec Alternatives

Dear WG,

This is the email announcing the straw poll across the video codec alternatives proposed to the WG. If you haven't read the "Next Steps in Video Codec Selection Process" (http://www.ietf.org/mail-archive/web/rtcweb/current/msg10448.html )then please do that before you continue to read.

The straw poll's purpose is to make it clear to the WG which of the alternatives that are favored or disfavored and what objections you have, if any, against a particular alternative. The WG chairs will use the information from this straw poll to identify an alternative to put as a single consensus question to the group. Thus, everyone that has an opinion on at least one alternative should answer this poll. Provide your poll input by replying to this email to the WG mailing list. The poll will run until the end of the 12th of January 2014.

The first question is "Are you in favor of this option [Yes/No/Acceptable]:". These three levels allow you to indicate that you: Yes= I would be fine with the WG choosing this option. No = I really don't favor this, and it should not be picked. Acceptable = I can live with this option but I prefer something else to be picked.

The second question is "Do you have any objections to this option, if so please explain it:" If you have any objection at a minimum indicate it with a "Yes".   Please also add a short (1-sentence) summary of each of the objections you believe applies.  (If you wish to provide a longer explanation, please do so in a separate thread).  If you have no objection, leave that question blank.

WG participants, please do not comment on anyone's input in this thread! If you want to comment, then create a separate thread and change the subject line to something else. Otherwise you are making life for the chairs very difficult to track the results of this straw poll.

b.    Do you have any objections to this option, if so please summarize them:

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

4.  Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

8.  All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

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

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

.      Are you in favor of this option [Yes/No/Acceptable]:

a.    Do you have any objections to this option, if so please summarize them:

H.264 is a reference to the proposal in https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/<https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/>

VP8 is a reference to the proposal in https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/<https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/>

Thanks,

The Chairs

---

From: David Singer <[email-masked]>
Date: Mon, 09 Dec 2013 16:29:59 -0800

OK, this is meant as a light-hearted comment.  You can stop reading now if you want serious.

It is kind of amusing to think of “no” as meaning “I would not implement this even if mandated” in response to this question:

>>        a. Are you in favor of this option [Yes/No/Acceptable]:

I am tempted to pose a few more options:

xx.  We continue to argue about MTI codec(s), essentially forever.
  a. Are you in favor of this option [Yes/No/Acceptable]:
  b. Do you have any objections to this option, if so please
         summarize them:

yy.  We continue to argue about the process for selecting MTI codec(s), essentially forever.
  a. Are you in favor of this option [Yes/No/Acceptable]:
  b. Do you have any objections to this option, if so please
         summarize them:

inevitably leading to

zz.  zzzzz zzzzzzzz zzzzz (sounds of snoring)
  a. Are you in favor of this option [Yes/No/Acceptable]:
  b. Do you have any objections to this option, if so please
         summarize them:

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Brent Kelly <[email-masked]>
Date: Tue, 10 Dec 2013 00:41:40 +0000

I agree with Matt. I thought the process was

1.       See if there is group consensus on whether or not to take a vote.

2.       If the group consensus is to take a vote, then get group consensus on *who* should be eligible to vote

3.       Do the actual voting on the alternatives

The non-binding straw poll was not part of this process.

Kind regards,
E. Brent Kelly, Ph.D.
Principal Analyst/Consultant

KelCor, Inc.
tel: +1 435 563 2532
email: [email-masked]<mailto:[email-masked]> | web: www.kelcor.com<http://www.kelcor.com/>

twitter: @ebkell | blog: www.uccinsider.blogspot.com<http://www.uccinsider.blogspot.com/>

From: Matthew Kaufman (SKYPE) [mailto:[email-masked]]
Sent: Monday, December 09, 2013 4:32 PM
To: Ted Hardie; [email-masked]; Gonzalo Camarillo; Richard Barnes; Magnus Westerlund; Cullen Jennings; [email-masked]
Subject: Re: [rtcweb] Straw Poll on Video Codec Alternatives

Matthew Kaufman

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Monday, December 9, 2013 5:25 PM
To: [email-masked]<mailto:[email-masked]>; Gonzalo Camarillo; Richard Barnes; Magnus Westerlund; Cullen Jennings
Subject: [rtcweb] Straw Poll on Video Codec Alternatives

Dear WG,

1.  All entities MUST support VP8

1.  All entities MUST support both H.264 and VP8

1.  Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8

1.  All entities MUST support at least one of H.264 and VP8

1.  All entities MUST support H.261

1.  There is no MTI video codec

1.  All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8

1.  All entities MUST support Theora

1.  All entities MUST implement at least two of {VP8, H.264, H.261}

1.  All entities MUST implement at least two of {VP8, H.264, H.263}

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

1.  All entities MUST support H.263

1.  All entities MUST implement at least two of {VP8, H.264, Theora}

1.  All entities MUST support decoding using Theora.

1.  All entities MUST support Motion JPEG

Thanks,

The Chairs

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Dec 2013 16:51:16 -0800

> 1.       See if there is group consensus on whether or not to take a vote.

One might choose to infer that there is not consensus to proceed with a
vote.  Though that might be tempered by adding "...at this moment."

---

From: Brent Kelly <[email-masked]>
Date: Tue, 10 Dec 2013 00:53:27 +0000

Maybe the poll should be to get consensus on whether to have a MTI codec vote “at this moment”. ☺

Kind regards,
E. Brent Kelly, Ph.D.

KelCor, Inc.
tel: +1 435 563 2532

From: Martin Thomson [mailto:[email-masked]]
Sent: Monday, December 09, 2013 5:51 PM
To: Brent Kelly
Cc: Matthew Kaufman (SKYPE); Ted Hardie; [email-masked]; Gonzalo Camarillo; Richard Barnes; Magnus Westerlund; Cullen Jennings; [email-masked]
Subject: Re: [rtcweb] Straw Poll on Video Codec Alternatives

On 9 December 2013 16:41, Brent Kelly <[email-masked]<mailto:[email-masked]>> wrote:
1.       See if there is group consensus on whether or not to take a vote.

One might choose to infer that there is not consensus to proceed with a vote.  Though that might be tempered by adding "...at this moment."

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Dec 2013 17:01:59 -0800

On 9 December 2013 16:53, Brent Kelly <[email-masked]> wrote:

> Maybe the poll should be to get consensus on whether to have a MTI codec
> vote “at this moment”.

Does not parse.  We have established IETF dogma that states that assessing
consensus using polls doesn't work.  I happen to have bought the dogma.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Dec 2013 09:28:02 +0100

Hi Matthew,

I hope I can answer your questions and resolve your objections.

On 2013-12-10 00:32, Matthew Kaufman (SKYPE) wrote:
> First, there was a discussion and a call for rough consensus at the last
> IETF in-person meeting. That call was not continued on the list, instead
> a lack of consensus was declared at the meeting.

No, it wasn't because the chairs did not believe there would emerge any
consensus on the mailing list based on the input provided during the
meeting.

> 
>  
> 
> Next, there was a proposal from the chairs to vote in a particular way,
> and a call for options on which to vote. It was claimed at that time
> that after the list was compiled, the act of taking such a vote would be
> taken to a consensus call. That never happened.

So this was a proposal for the a process. This proposal was heavily
debated and valid comments regarding issues was raised against it. Thus,
the chairs have selected to not proceed with the proposal. Instead we
will use this process.

> 
>  
> 
> Instead the chairs are now conducting a “straw poll” of their own
> design, clearly in an effort to circumvent some very specific objections
> to the proposed instant-runoff vote with restricted participation. But
> again, instead of attempting to reach WG consensus for conducting such a
> poll, it has simply been foisted upon us.

Yes, this process is intended to resolve all the major issues with the
previous proposal. It is designed to be open, provide more information
to all the WG participants about peoples positions and objections to the
various alternatives. It is information finding to enable us to take the
next step of identifying if there is any alternative we can make a
consensus call on.

> 
>  
> 
> I have not seen ANY replies to the message “Next Steps in Video Codec
> Selection Process” that indicate working group consensus of ANY KIND for
> conducting a poll in this format at this time or to follow the
> subsequent steps described in that message.

No, we have not requested WG consensus for this one. This is a decision
we chair have made ourselves. And the reason for this is while the
previous process proposal did require WG consensus to be used, this
information seeking is something we chairs can initiate, perform. In
this case we do believe that the time is best spent on performing this
pool rather than discussing if it is going to be done or not. The WG
will by the end of this poll have more information and a better
understanding of the positions and objections against the various
alternatives proposed.

> 
>  
> 
> I am requesting that the chairs immediately suspend the “Straw Poll”
> described below until such time as there is Working Group consensus to
> spend the Working Group’s time and energy conducting the poll and/or to
> continue with the subsequent steps called out in “Next Steps in Video
> Codec Selection Process” at
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg10448.html
> 

The WG chairs believe they have good motivations and rights to call for
this straw poll. We will not suspend it. If you like to escalate your
objection please contact our Area Director Gonzalo Camarillo.

Regards

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: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Dec 2013 09:34:07 +0100

On 2013-12-10 01:41, Brent Kelly wrote:
> 2.       If the group consensus is to take a vote, then get group
> consensus on **who** should be eligible to vote
> 

What you list above is the core of the chairs previous process proposal.
I like to stress "PROPOSAL". It got a lot of critique both in the WG and
by the larger IETF community. Thus we have abandoned it. We have
selected another path, which starts with this straw poll to better judge
the WG participants positions and objections against the various
alternatives.

cheers

Magnus Westerlund

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Tue, 10 Dec 2013 17:24:12 +0800

1.a No
  .b Feeling not comfortable with h.264 situation / license / IP.
2.a Yes
3.a No
  .b In our opinion, only one MTI is needed to have interop. More than one
would not improve interop, but would increase risks and maintenance.
4.a No
  .b browser should be treated differently. It's taking the risk of
defining several class of citizens, and have to handle a definition of
"browsers" (do application which include webkit fall under this for
example.)
5.a No
  .b This does not provide a common codec for interop. between webrtc
implementations.
6.a (Barely) acceptable
  .b We are concerned that the quality achievable, and the bandwidth
requirement are barely acceptable, however, we could live with it.
7.a No
  .b We believe we need a common codec for minimal interop.
8.a No
  .b same reason as 3.b
9.a Acceptable (neutral, would prefer 2)
10.a No
    .b Same as 3.b
11.a No
    .b Same as 3.b
12.a No
    .b Same as 3.b
13.a No
    .b same as 1.b replace 264 by 263
14.a No
    .b Same as 3.b
15.a No
    .b does not solve the problem of encoding.
16.a No
   .b Same reason as 6.b, just worse.

> Theora is a reference to Xiph.org Theora Specification from March 16, 2011
> (http://www.xiph.org/theora/doc/Theora_I_spec.pdf)
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Dec 2013 10:34:29 +0100

Hi Dave,

I agree that it is difficult to design questionnaires and will agree
that this one may have some flaws. You argue for a balanced list of
choices where there is equally positive and negative options. The goal
was that the Acceptable would be the in the middle option, between I
favor or I don't favor it. Thus I suggested Acceptable, a I can live
with this but don't favor it or disfavor it. Using a word like neutral
would also be strange in regards to the formulation of the question.

> Given the intent of 'acceptable', what you need is something like:

What does it mean to say "I Don't Care about the option: "There is no
MTI video codec". Similar it appears difficult to interpret using
"Prefer no". In such a case a 1-5 (Least favored to Most favored) rating
would be less problematic as it would allow people to think in their own
terms.

Yes, we can spend a lot of emails on discussing what the questions
should be. I don't think this would be productive unless there is a wide
belief that the question asked is so flawed that we really are missing
important information or skewing the results significantly. So far I
seen John's comment that you have your points, but not sufficient to
redo the questions. Then I have two individuals that are happy to
discuss what the question should have been, but hasn't provided opinion
on if it necessary to change the question.

Regards

Magnus

-- 

Magnus Westerlund

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 10 Dec 2013 11:13:30 +0000

I decided to skip procedural discussions and follow Adam's example and 
just answer the poll. As Ted recommended, I am repeating text instead of 
referring.

My five cents in-line.

...

Yes

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:
>
>  2.
>

No

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:

According to an IPR disclosure the IPR owner is unwilling to license its 
IPR needed to implement VP8. It seems senseless to mandate 
implementation of technology that can't be licensed on any terms.

No

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:

According to an IPR disclosure the IPR owner is unwilling to license its 
IPR needed to implement VP8. It seems senseless to mandate 
implementation of technology that can't be licensed on any terms.

>
>  4.
>
>     Browsers MUST support both H.264 and VP8, other entities MUST
>     support at least one of H.264 and VP8
>
>      1.
>

No

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:

According to an IPR disclosure the IPR owner is unwilling to license its 
IPR needed to implement VP8. It seems senseless to mandate 
implementation of technology that can't be licensed on any terms.

No

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:

Accomplishes nothing since I expect all implementations to support one
of them anyway.

No

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:

Inferior quality, implementations not widespread

Acceptable

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:
>
>  8.
>
>     All entities MUST support H.261 and all entities MUST support at

No

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:

The fallback would be h.261, meaning inferior quality; implementations
not widespread

No

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:

The licensing/IPR situation is not well understood with regards to 
Theora, nor is its performance (in terms of quality vs. bitrate)

No

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:

The fallback would be h.261, meaning inferior quality; implementations
not widespread

Acceptable

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:
>
> 12.
>
>     All entities MUST support decoding using both H.264 and VP8, and
>     MUST support encoding using at least one of H.264 or VP8
>
>      1.
>

No

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:

According to an IPR disclosure the IPR owner is unwilling to license its 
IPR needed to implement VP8. It seems senseless to mandate 
implementation of technology that can't be licensed on any terms.

Acceptable

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:
>
> 14.
>

No

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:

The fallback would be Theora, and for it the licensing/IPR situation is 
not well understood, nor is its performance (in terms of quality vs. 
bitrate).

No

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:

The licensing/IPR situation is not well understood with regards to 
Theora, nor is its performance (in terms of quality vs. bitrate)

No

>
>      2.
>
>         Do you have any objections to this option, if so please
>         summarize them:

The performance (in terms of quality vs. bitrate) is lousy.

> https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/
>
>
> https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/
>
>
> Theora is a reference to Xiph.org Theora Specification from March 16,
> 2011 (http://www.xiph.org/theora/doc/Theora_I_spec.pdf)
>
>
> H.263 is a reference to profile 0 level 70 defined in annex X of ITU-T
> rec H.263 (http://www.itu.int/rec/T-REC-H.263/)
>
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Dec 2013 06:46:32 -0800

Magnus,

> that this one may have some flaws. You argue for a balanced list of

Apparently, you misunderstood my note.  I wasn't expressing an opinion 
in the nature of a preference.  I was noting a methodological error.  In 
other words, I was citing something broken, not merely distasteful.

> was that the Acceptable would be the in the middle option, between I

I would have thought that the goal would be meaningful results.

One does not usually have a structural choice as a "goal".

As I noted, 2/3 of the choices were positive.  That biases response 
patterns.  I went to the effort of providing citations specifically so 
that you would not think I was inventing the concern or expressing an 
"opinion".

> would also be strange in regards to the formulation of the question.

There are other issues in providing such a long and undifferentiated 
list of questions to folk, including respondent fatigue.  I was merely 
trying to raise the flag with one of the more obvious and 
well-understood flaws.

> "Prefer no".

Actually, it's semantics match your use of "Acceptable".  That is, the 
respondent doesn't actively want the choice, but can tolerate it.  The 
label I'm suggesting is a more accurate semantic since it makes the 
respondents starting point of a negative assessment explicit whereas 
yours does not.

The reason to have both prefer yes and prefer no is to balance "can live 
with its being chosen" with "can live with its not being chosen".  Hence 
the range of responses gives a more accurate sense of response strengths 
and potential points of resistance.

> In such a case a 1-5 (Least favored to Most favored) rating

Except that least/most semantics don't match the nature of the question. 
  The fact that both are 5-point scales misses the potential differences 
in respondent interpretation of the label semantics.  Such a difference 
affects respondent behavior quite a bit.

> important information or skewing the results significantly.

If the text said 2+2=5 and only one person noted the error and no one 
responded, would that make it acceptable to ignore the problem?

Again, you seem to be confusing the difference between prefer and broken.

As basic as the methodology problem is to the survey instrument, it's 
actually a pretty minor concern, compared with the continuing failure to 
recruit wg participation in deciding how to proceed.  Imposing the 
survey before getting agreement from the wg to /do/ the survey and use 
the proffered questions is an example of what seems to be a pattern in 
the wg's management.

d/

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Dec 2013 09:24:24 -0600

On 12/10/13 08:46, Dave Crocker wrote:
> patterns.

I don't think we need to go around accusing the chairs of biasing 
towards success as if it's something bad.

/a

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Dec 2013 07:29:06 -0800

> towards success as if it's something bad.

Wow.  That misunderstanding of my note is even more impressive than 
thinking that I'm merely expressing an opinion, rather than citing 
methodological fact.

The term 'bias' is a term of art in research methodology.  It pertains 
to procedural problems that produce distorted results.  The fact that an 
error is present in methodology is independent of how or why it was 
introduced.

In particular, I was not making assertion about the "intent" of the folk 
creating and issuing the survey.  I frankly don't care what their intent 
is, since ad hominem factors are nearly always supposed to be out of 
scope for IETF discussions.

d/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Dec 2013 16:35:09 +0100

> other words, I was citing something broken, not merely distasteful.

I don't think I fully misunderstood it. Yes, I may not have understood
all aspects of what you wanted convey. However, my interpretation of
what you are saying is: This methodological error introduces a degree of
brokenness in your survey.

I personally have a view of how bad this brokenness is. I asked for
others to express their considerations on how bad they consider this error.

Because from my perspective it comes down to the issue. Is this so
broken that we must fix it, or can we live with it. Nothing ever is
perfect and works fully as intended.

> trying to raise the flag with one of the more obvious and

Seriously, I don't think respondent fatigue is going to be a serious
issue for this. It is 16 alternatives with 2 questions per alternative.
There is no time pressure on doing and getting it done. In fact I
recommend that people take their time to work through the options and
consider their response well.

> respondents starting point of a negative assessment explicit whereas

Okay, so "Tolerable" or some other English word that conveys a more
neutral position would address this issue?

> and potential points of resistance.

Sorry, but I don't get your labels. They doesn't make sense to me in
this context. But, I don't see it worth spending more time on the
particular labels to use if one would like to have five values in this
survey. Not, unless we really need to change it.

> affects respondent behavior quite a bit.

Isn't this the core of the issue we are discussing. Either you are using
labels that will be interpreted and you get peoples interpretation of
the individual labels. Which introduce a certain potential bias due to
the labels. Or if you use a range and only anchor the edges of the
range, you get floating interpretations of what the mid values mean.

Different types of errors.

No.

> Again, you seem to be confusing the difference between prefer and broken.

No, but I am trying to arrive at a judgment if the brokenness is so
severe that you have to stop and call a tow truck, drive immediately to
the car shop, or if you can continue to drive for the next month and
have it addressed in your planned maintenance.

For the moment my personal interpretation is that this is something I
will do my best to remember the next time I am part of design a survey.

> the proffered questions is an example of what seems to be a pattern in

I will not try to deny that we have made some errors and misjudgment.
Clear the WG hasn't caught some of them either, which was on WG review.
Looking in the rear view mirror it is easy to say how one should or
could have done it to make things better. We also have a role of running
and driving the process and do need to make decision at some points.

We chairs have discussed to put the straw poll and next steps out as a
proposal for the WG review. We felt that the information the straw poll
would give would be good independent for the whole WG. Thus we
implemented rather than have a week or two of discussion on it before
being able to implement it.

The high level process we intent to follow afterwards have been
provided. You are welcome to provide feedback on it.

Cheers

Magnus Westerlund

---

From: Richard Barnes <[email-masked]>
Date: Tue, 10 Dec 2013 10:57:11 -0500

On Tue, Dec 10, 2013 at 10:29 AM, Dave Crocker <[email-masked]> wrote:

> The term 'bias' is a term of art in research methodology.  It pertains to
> procedural problems that produce distorted results.  The fact that an error
> is present in methodology is independent of how or why it was introduced.
>
> is, since ad hominem factors are nearly always supposed to be out of scope
> for IETF discussions.

Dave, the salient question here is whether whatever biases are in the straw
poll will affect the outcome in a way that is (1) material and (2)
detrimental.  As Adam notes, the worst case is that we think there's more
support than there actually is.  I'm sure the subsequent consensus call
will control for this.  And I am far from convinced that there is any
likelihood of a material impact from the straw poll's layout.  People here
are smart enough to choose wisely.

Your observations of the empirical facts on methodology-induced bias are
noted.  Your opinion that those facts have some bearing on the process here
is, as far as I can tell, in the rough.

--Richard

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 10 Dec 2013 17:23:06 +0000

Anyone fatigued by 16 yes/no questions was lost long ago in the thousands
of mails on this topic. I see nothing unacceptable in the straw poll
process.

...respondent fatigueŠ

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Dec 2013 09:57:04 -0800

My responses below.

Yes

No.

>>        Do you have any objections to this option, if so please

VP8 has not yet completed the MPEG standardization process and additional IPR declarations are therefore possible, or even likely. Also, we have an IPR declaration with a refusal to license.

No

>>        summarize 

VP8 has not yet completed the MPEG standardization process and additional IPR declarations are therefore possible, or even likely. Also, we have an IPR declaration with a refusal to license.

No

>>        summarize 

VP8 has not yet completed the MPEG standardization process and additional IPR declarations are therefore possible, or even likely. Also, we have an IPR declaration with a refusal to license.

No

>>        Do you have any objections to this option, if so please

All implementations will do this anyway so why bother?

No

>>        Do you have any objections to this option, if so please

Poor quality; no incentive to implement.

Acceptable

No

No

No

No. 

>>        Do you have any objections to this option, if so please

H.263 quality is inferior and will require additional licensing fees.

No

>>        Do you have any objections to this option, if so please

VP8 has not yet completed the MPEG standardization process and additional IPR declarations are therefore possible, or even likely. Also, we have an IPR declaration with a refusal to license.

No

>>        Do you have any objections to this option, if so please

H.263 quality is inferior, will require licensing fees.

No.

No

No

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 10 Dec 2013 18:35:08 +0000

I guess the problem is that a direction at this stage implies that a consensus question of a particular form may result in success. So bias at this stage may result in an subsequent unsuccessful consensus call.

That is certainly something that is not desirable, given the amount of resource already used on trying to address this issue.

Keith

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 10 December 2013 15:24
> To: [email-masked]; Magnus Westerlund; Cullen Jennings (fluffy)
> Cc: [email-masked]
> Subject: Re: [rtcweb] Unacceptable - (Re: Straw Poll on Video 
> Codec Alternatives)
> 
> I don't think we need to go around accusing the chairs of 
> biasing towards success as if it's something bad.
> 
> /a

---

From: [email-masked]
Date: Tue, 10 Dec 2013 10:54:33 -0800

1.

      acceptable
      2.

      ipr concerns, prefer FOSS
      2.

      yes
      2.

      3.

      acceptable
      2.

      less compliant browser chooses de-facto MTI.  Same as no MTI, I think.
      4.

      acceptable
      2.

      (3b)
      5.

      acceptable
      2.

      prefer to not transcode
      6.

      no
      2.

      want MTI with better coding efficiency, or none
      7.

      acceptable
      2.

      may require transcoding when ms/apple implement, possibly by 2015
      8.

      acceptable
      2.

      9.

      yes
      2.

      10.

      acceptable
      2.

      11.

      acceptable
      2.

      12.

      acceptable
      2.

      13.

      acceptable
      2.

      14.

      yes
      2.

      15.

      yes
      2.

      16.

      no
      2.

      coding efficiency

On Tue, Dec 10, 2013 at 9:57 AM, Bernard Aboba <[email-masked]>wrote:

> VP8 has not yet completed the MPEG standardization process and additional
> IPR declarations are therefore possible, or even likely. Also, we have an
> IPR declaration with a refusal to license.
>
> >
> >>
> >> 3.
> >>
> VP8 has not yet completed the MPEG standardization process and additional
> IPR declarations are therefore possible, or even likely. Also, we have an
> IPR declaration with a refusal to license.
>
>
> >
> >>
> >> 4.
> >>
> VP8 has not yet completed the MPEG standardization process and additional
> IPR declarations are therefore possible, or even likely. Also, we have an
> IPR declaration with a refusal to license.
>
>
>
> >
> >>
> >> 5.
> >>
> VP8 has not yet completed the MPEG standardization process and additional
> IPR declarations are therefore possible, or even likely. Also, we have an
> IPR declaration with a refusal to license.
>
>
> >
> >>
> >> 13.
> >>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 10 Dec 2013 13:58:11 -0500

Honestly, why are we wasting our time on this? I can do a straw poll, but
there are no options acceptable to everybody present. Here is my analysis
of presented options:

H.264 -- Not acceptable to anybody who is not already using H.264 due to
its licensing schema. To license H.264 you need to make a deal with
MPEG-LA. After this you need to make a deal with Nokia and other people not
part of MPEG-LA. As a result you are going to get rights to decoder.
Encoder is not specified by the standard and there are no obligations for
MPEG members to declare anything, so you are more then likely exposed to
addition IPR risks when implementing a good encoder. You cannot afford not
to license since if you are real business (ie one generating money or
taking investor money) you cannot afford such business risk. Even if you
are planning to distribute less then 100K codec instances you will still
need a license since MPEG-LA terms are ambiguous enough that you would want
to have a contact that clarifies what exactly you can do. After you jumped
through all these licensing hoops you are still exposed to all the
potential undisclosed IPR with your only hope that patent trolls will go
after the bigger guys first (from my experience they will not).

Using Cisco binary codec is also unacceptable unless you are doing
something basic since it limits what you can do by requiring to use their
pre-built binary. I am building conferencing servers, so I expect that I
will need to optimize the codec for my needs. I will need to build custom
optimized VP8 to H.264 transcoder. I will need to build custom H.264
bitrate adaptation (ie H.264 to H.264 transcoder to adjust bitrate). All of
this is not an option with Cisco binary.

Bottom line H.264 is not acceptable to me or people like me.

VP8 -- This works for me but I see that this will not work for any company
already using H.264 or ever planning to sue Google. If you are already
using H.264, why do you want to expose yourself to additional IPR risks?
Google license is not acceptable to many larger companies (partially due to
this license being automatically revoked if you decide to sue Google for
reasons non related to VP8) . Fail for VP8.

All the other codecs -- Their quality is too low for modern communications
to be used for anything except when everything else fails. They are better
then nothing but neither one of them is widespread enough and used enough
to simply be there.  They all present additional maintenance and
development effort. They also present an additional IPR risk. H.261 and
H.263 only specify decoders. If you try to optimize the encoder to work
better you most likely run into patents that have not expired yet. So, all
the other codecs are not an option either.

My proposal -- no MTI until a new non encumbered video codec, like Daala,
is developed specifically for this purpose. Until then this discussion is
essentially discussion G.722.2 vs Vorbis vs Linear PCM for audio codec MTI.
Neither one was acceptable for WebRTC, so Opus was developed. The same
needs to be done for video.
_____________
Roman Shpount

On Mon, Dec 9, 2013 at 12:24 PM, Ted Hardie <[email-masked]> wrote:

> WG participants, please do not comment on anyone’s input in this thread!
> If you want to comment, then create a separate thread and change the
> subject line to something else. Otherwise you are making life for the
> chairs very difficult to track the results of this straw poll.
>
>    Browsers MUST support both H.264 and VP8, other entities MUST support
>    at least one of H.264 and VP8
>    1.
>

---

From: Engel Nyst <[email-masked]>
Date: Tue, 10 Dec 2013 23:51:45 +0200

> reasons non related to VP8) . Fail for VP8.

I'm not sure why you say "reasons not related to VP8". VP8 additional 
patent grant says:
"If you or your agent or exclusive licensee institute or order or agree 
to the institution of patent litigation against any entity (including a 
cross-claim or counterclaim in a lawsuit) alleging that this 
implementation of VP8 or any code incorporated within this 
implementation of VP8 constitutes direct or contributory patent 
infringement, or inducement of patent infringement, then any patent 
rights granted to you under this License for this implementation of VP8 
shall terminate as of the date such litigation is filed." [1]

Note "alleging that this implementation of VP8 or any code incorporated 
within this implementation of VP8". If the allegations are unrelated to 
VP8, they don't fall within the bounds of "this implementation of VP8" 
with what it actually contains. Am I reading this wrong?

[1] http://www.webmproject.org/license/additional/

-- 
~enyst

"Excuse me, Professor Lessig, but may I ask you to sign this CLA, so 
that we have legally your permission to distribute your CC-licensed words?"

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Tue, 10 Dec 2013 22:33:07 +0000

> From: Magnus Westerlund [mailto:[email-masked]]
> 
> No, we have not requested WG consensus for this one. This is a decision we
> chair have made ourselves. And the reason for this is while the previous
> process proposal did require WG consensus to be used, this information
> seeking is something we chairs can initiate, perform. In this case we do
> believe that the time is best spent on performing this pool rather than
> discussing if it is going to be done or not. The WG will by the end of this poll
> have more information and a better understanding of the positions and
> objections against the various alternatives proposed.

Spending the Working Group's time on picking an MTI video codec at this point is just as disruptive to the vital work the WG needs to complete as it would be for me to stand in the corner of the next WG meeting continuously blowing a vuvuzela.

Since taking up valuable meeting time on this topic and considerable mailing list thread with this topic, we are no closer to a decision, and much more importantly, it appears that zero progress has been made on nothing else that the WG has signed up to deliver.

> > I am requesting that the chairs immediately suspend the "Straw Poll"
> > spend the Working Group's time and energy conducting the poll and/or
> > to continue with the subsequent steps called out in "Next Steps in
> > Video Codec Selection Process" at
> The WG chairs believe they have good motivations and rights to call for this
> straw poll. We will not suspend it. If you like to escalate your objection please
> contact our Area Director Gonzalo Camarillo.

I believe that the "straw poll" is both a thinly veiled recasting of the original "vote" proposal *and* that the Working Group is having its time and energy wasted on this progress. 

As a result, I am not confident at this time that the chairs are directing the Working Group in a way that will produce its chartered output in a timely manner.

The Area Director is already copied and I would like this message considered as escalation of my previous objection and request to suspend the poll.

Matthew Kaufman

---

From: cowwoc <[email-masked]>
Date: Tue, 10 Dec 2013 17:36:52 -0500

Hi,

Caveat: I am answering based on the information available to me as of 
today. For example, if Cisco releases a decent H.264 software codec with 
a commercially-friendly license, I would likely revise my answer 1a from 
"No" to "Acceptable". The same is true for other answers as more 
information becomes available.

 1.

     1.

        No

     2.

        Concerned about IPR and software licensing of H.264 codec, and
        royalty fees.

 2.

     1.

        Yes

     2.

 3.

     1.

        Acceptable

     2.

        Same as 1b

 4.

     1.

        Acceptable

     2.

        Non-browser interoperability is no less important than browser
        interoperability. This might not seem like a big deal today, but
        once mobile deployments increase we're likely to end up with
        federated networks.

 5.

     1.

        No

     2.

        This does not guarantee interoperability. Basic P2P chat should
        not require transcoding.

 6.

     1.

        Acceptable

     2. Better than requiring transcoding
 7.

     1.

        No

     2.

        Same as 5b

 8.

     1.

        Acceptable

     2.

        I prefer option 10

 9.

     1.

        Acceptable

     2.

        Same as 6b

10.

     1.

        Yes

     2.

11.

     1.

        Acceptable

     2.

        Concerned about IPR status of H.263

12.

     1.

        Yes

     2.

13.

     1.

        Acceptable

     2.

        Same as 11b

14.

     1.

        Yes

     2.

15.

     1.

        Acceptable

     2.

        Same as 6b

16.

     1.

        Acceptable

     2.

        Same as 6b

Thank you,
Gili

On 09/12/2013 12:24 PM, Ted Hardie wrote:
> alternatives proposed to the WG. If you haven't read the "Next Steps 
> in Video Codec Selection Process" 
> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg10448.html)then please 
> do that before you continue to read.
>
>
> The straw poll's purpose is to make it clear to the WG which of the 
> alternatives that are favored or disfavored and what objections you 
> have, if any, against a particular alternative. The WG chairs will use 
> the information from this straw poll to identify an alternative to put 
> as a single consensus question to the group. Thus, everyone that has 
> an opinion on at least one alternative should answer this poll. 
> Provide your poll input by replying to this email to the WG mailing 
> list. The poll will run until the end of the 12th of January 2014.
>
>
> As can be seen below, the poll lists the alternative that have 
> proposed to the WG. For each alternative two questions are listed.
>
>
> The first question is "Are you in favor of this option 
> [Yes/No/Acceptable]:". These three levels allow you to indicate that 
> really don't favor this, and it should not be picked. Acceptable = I 
> can live with this option but I prefer something else to be picked.
>
>
> The second question is "Do you have any objections to this option, if 
> so please explain it:" If you have any objection at a minimum indicate 
> it with a "Yes".   Please also add a short (1-sentence) summary of 
> each of the objections you believe applies.  (If you wish to provide a 
> longer explanation, please do so in a separate thread).  If you have 
> no objection, leave that question blank.
>
>
> Please provide input on as many of the alternatives as you like and 
> feel comfortable to do. The more inputs, the more well informed 
> decision the WG chairs can take when identifying the option to be 
> brought forward for consensus. Any alternative that you chose to leave 
> blank, will simply be considered as one without any input from you.
>
>
> WG participants, please do not comment on anyone's input in this 
> thread! If you want to comment, then create a separate thread and 
> change the subject line to something else. Otherwise you are making 
> life for the chairs very difficult to track the results of this straw 
> poll.
>
>
> If discussion causes you to update your position, please feel free to 
> send an update via email on the straw poll thread prior to the closing 
> date.
>
>
>
> 1.
>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Tue, 10 Dec 2013 22:48:02 +0000

Also please note that I am objecting to the lack of WG consensus on following the *entire list* of "next steps" called out in the introductory mail http://www.ietf.org/mail-archive/web/rtcweb/current/msg10448.html and not simply the act of the chairs calling for a straw poll.

If not simply a veiled version of the "vote" - which it is, given that the next step is that the chairs will identify "an option" based on the results of said straw poll and issue a consensus call on that single option - I do agree that a straw poll is something that does not *necessarily* require Working Group consensus to conduct. However, both the particular and detailed form of this straw poll, and that continuing this discussion has caused a major disruption to the Working Group progress on any other issues are both highly concerning, and that is what forms the basis for my objection and subsequent escalation.

For reference, the above-mentioned list is quoted here:

  -- Conduct a straw poll to gather information on which option might achieve consensus
  -- Chairs identify an option based on the results of the straw poll and issue a consensus call
  -- If there is consensus (as judged by Richard Barnes), the selected option is reflected in a WG document
  -- The WG document is confirmed via the normal process of WGLC and IETF LC

Matthew Kaufman

> From: ietf [mailto:[email-masked]] On Behalf Of Matthew Kaufman
> (SKYPE)
> Sent: Tuesday, December 10, 2013 10:33 PM
> To: Magnus Westerlund; Ted Hardie; [email-masked]; Gonzalo Camarillo;
> Richard Barnes; Cullen Jennings; [email-masked]
> Subject: RE: Matthew's Objections: was Re: [rtcweb] Straw Poll on Video
> Codec Alternatives
> 
> > No, we have not requested WG consensus for this one. This is a
> > decision we chair have made ourselves. And the reason for this is
> > while the previous process proposal did require WG consensus to be
> > used, this information seeking is something we chairs can initiate,
> > perform. In this case we do believe that the time is best spent on
> > performing this pool rather than discussing if it is going to be done
> > or not. The WG will by the end of this poll have more information and
> > a better understanding of the positions and objections against the various
> alternatives proposed.
> 
> Spending the Working Group's time on picking an MTI video codec at this
> point is just as disruptive to the vital work the WG needs to complete as it
> would be for me to stand in the corner of the next WG meeting continuously
> blowing a vuvuzela.
> 
> Since taking up valuable meeting time on this topic and considerable mailing
> list thread with this topic, we are no closer to a decision, and much more
> importantly, it appears that zero progress has been made on nothing else
> that the WG has signed up to deliver.
> 
> > > described below until such time as there is Working Group consensus
> > > to spend the Working Group's time and energy conducting the poll
> > > and/or to continue with the subsequent steps called out in "Next
> > > Steps in Video Codec Selection Process" at
> > The WG chairs believe they have good motivations and rights to call
> > for this straw poll. We will not suspend it. If you like to escalate
> > your objection please contact our Area Director Gonzalo Camarillo.
> 
> I believe that the "straw poll" is both a thinly veiled recasting of the original
> "vote" proposal *and* that the Working Group is having its time and energy
> wasted on this progress.
> 
> As a result, I am not confident at this time that the chairs are directing the
> Working Group in a way that will produce its chartered output in a timely
> manner.
> 
> The Area Director is already copied and I would like this message considered
> as escalation of my previous objection and request to suspend the poll.
> 
> Matthew Kaufman

---

From: cowwoc <[email-masked]>
Date: Tue, 10 Dec 2013 17:55:11 -0500

Matthew,

Part of the difficulty of reaching consensus is knowing what options 
people consider acceptable. I don't think that this straw poll is about 
counting which option gets more support. Rather, it's a way for us to 
narrow the list down to (say) 3 options and bring *those* to a follow-up 
consensus call. We can't proceed to a consensus call with 16 options.

Do you have an alternative proposal for reaching consensus on this 
matter? Or are you simply advocating we declare "No MTI"?

Thank you,
Gili

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Dec 2013 17:23:01 -0600

> Spending the Working Group's time on picking an MTI video codec at this point is just as disruptive to the vital work the WG needs to complete as it would be for me to stand in the corner of the ne…

Then light a candle.

The working group is made of its participants, of which you are 
presumably one. Start a conversation about something else. I agree that 
there are other deliverables, and there's no reason we can't discuss and 
progress them in parallel with any codec-related discussions.

Start here; dive in anywhere:

http://tools.ietf.org/wg/rtcweb/

/a

____
P.S. FWIW, I think the chairs are doing a perfectly reasonable job under 
some of the most difficult circumstances I've seen in 16 years of IETF 
work. For the past couple of meeting cycles, the problem hasn't even 
been the codec discussions; it's been the hyperaggressive 
meta-conversations talking *about* the codec conversations. From that 
perspective, you *are* standing in the corner playing a vuvuzela as a 
member of a highly disruptive vuvuzela chorus. We formally have three 
chairs, which is already large for a working group. We really don't need 
the hundred or so participants to be back-seat chairs as well.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2013 16:01:30 -0800

> Then light a candle.

I continue to do this, but still find myself agreeing with Matthew.

---

From: <[email-masked]>
Date: Tue, 10 Dec 2013 23:55:42 +0000

On 12/10/13 16:33, Matthew Kaufman (SKYPE) wrote:
>> Spending the Working Group's time on picking an MTI video codec at this point
>> is just as disruptive to the vital work the WG needs to complete as it would be for
>> me to stand in the corner of the next WG meeting continuously blowing a vuvuzela.
>
> Then light a candle.

...and curse the dorks.

---

From: cowwoc <[email-masked]>
Date: Tue, 10 Dec 2013 20:00:47 -0500

> I continue to do this, but still find myself agreeing with Matthew.

Methinks we are going to end up with two competing WebRTC specifications...

We have hundreds of participants on this list and everyone thinks they 
know better. The only way we're going to reach any sort of consensus is 
if people start compromising. I mention this because I noticed that some 
people have responded to the straw poll with one "Yes", a bunch of "No"s 
and not a single "Acceptable".

Anyway, I'll ask you the same question as I've asked Matthew: what is 
your counter-proposal?

Gili

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2013 19:48:58 -0800

On 10 December 2013 17:00, cowwoc <[email-masked]> wrote:
> Anyway, I'll ask you the same question as I've asked Matthew: what is your
> counter-proposal?

What part of "waste of time" are you having trouble understanding?

---

From: cowwoc <[email-masked]>
Date: Tue, 10 Dec 2013 22:50:45 -0500

> What part of "waste of time" are you having trouble understanding?

So you're advocating settling on "No MTI"?

Gili

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 11 Dec 2013 06:31:15 +0000

Methinks you take that statement too far.

Or are you saying video is a mandatory component of all webrtc sessions?

And even if video was, then in 10 years, either of the particular codec specifications will be an irrelevance, but webrtc might live on - assuming it ever gets enough specification off the starting blocks.

In other words lets get a sense of perspective here, lets see less of the cycles on this discussion and lets see the focus back on progressing the documents.

Which document do the chairs want to place most emphasis on progressing first?

Regards

Keith 

> From: rtcweb [mailto:[email-masked]] On Behalf Of cowwoc
> Sent: 11 December 2013 01:01
> To: [email-masked]
> Subject: Re: [rtcweb] Matthew's Objections: was Re: Straw 
> Poll on Video Codec Alternatives
> 
> We have hundreds of participants on this list and everyone 
> thinks they know better. The only way we're going to reach 
> any sort of consensus is if people start compromising. I 
> mention this because I noticed that some people have 
> responded to the straw poll with one "Yes", a bunch of "No"s 
> Anyway, I'll ask you the same question as I've asked Matthew: 
> what is your counter-proposal?
> 
> Gili

---

From: cowwoc <[email-masked]>
Date: Wed, 11 Dec 2013 01:52:58 -0500

Hi Keith,

> Or are you saying video is a mandatory component of all webrtc sessions?

It doesn't matter what happens on a per-session basis. If video is a 
mandatory feature of all WebRTC implementations then it is our duty to 
ensure that all such implementation can inter-operate with each other.

> And even if video was, then in 10 years, either of the particular codec specifications will be an irrelevance, but webrtc might live on - assuming it ever gets enough specification off the starting…

If the IBMs and Microsofts of the world can drop features over time, so 
can we. We'll use a deprecation mechanism to transition from one codec 
to another.

> In other words lets get a sense of perspective here, lets see less of the cycles on this discussion and lets see the focus back on progressing the documents.

To what end? The entire point of a specification is to ensure 
interoperability. Producing documents for their own sake is kind of useless.

> Which document do the chairs want to place most emphasis on progressing first?

Do you plan to ship WebRTC 1.0 without video support? If not, why does 
it matter whether we tackle video first or last?

Gili

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Wed, 11 Dec 2013 07:45:32 +0000

> From: Adam Roach [mailto:[email-masked]]
> 
> The working group is made of its participants, of which you are presumably
> one. Start a conversation about something else. I agree that there are other
> deliverables, and there's no reason we can't discuss and progress them in
> parallel with any codec-related discussions.

At the in-person meetings, discussing the MTI video codec is agenda-exclusive of progressing any other document.

On the mailing list, discussing the MTI video codec is drowning out any other discussion (as many are simply ignoring the list entirely) and slowing the work on any other document (as many are time-limited as to their participation, and are using their limited time to figure out how to strategically respond to ranked-choice voting alternatives instead of how to progress other documents)

> P.S. FWIW, I think the chairs are doing a perfectly reasonable job under some
> of the most difficult circumstances I've seen in 16 years of IETF work. For the
> past couple of meeting cycles, the problem hasn't even been the codec
> discussions; it's been the hyperaggressive meta-conversations talking
> *about* the codec conversations. From that perspective, you *are* standing
> in the corner playing a vuvuzela as a member of a highly disruptive vuvuzela
> chorus. We formally have three chairs, which is already large for a working
> group. We really don't need the hundred or so participants to be back-seat
> chairs as well.

There are chairs for a reason, both at the in-person meetings and on the mailing list. The chairs *could* have shut down the conversation about the codecs and they *could* have shut down the meta-conversations about the codec discussion, but they have not. Instead they have consumed several hours of several meetings and on an issue that appears to be diverging, not converging (and consuming an ever greater percentage of the mailing list traffic), despite much other unfinished work... much of it requiring cooperation with other working groups in order to close. I believe that objecting to the actions of the chairs is a bigger lever towards real progress than trying to be the one tiny voice in the corner trying to progress something else unilaterally during this storm.

Matthew Kaufman

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Wed, 11 Dec 2013 07:53:46 +0000

> Matthew,
> 
> Part of the difficulty of reaching consensus is knowing what options people
> consider acceptable. I don't think that this straw poll is about counting which
> option gets more support. Rather, it's a way for us to narrow the list down to
> (say) 3 options and bring *those* to a follow-up consensus call. We can't
> proceed to a consensus call with 16 options.
> 
> Do you have an alternative proposal for reaching consensus on this matter?

Sure. Drop this entirely, go finish the other work, and then see if the situation has changed. Given how long it will likely take to finish the items that require cooperation with MMUSIC (as just one example), it is possible that one of these codec choices will have a change in its IPR status (e.g., MPEG standardization, royalty-free licensing) or that a new codec that is not currently proposed will become a viable or even preferred choice.

We've certainly spent enough time so far to know that simple consensus on the current choices at the current time isn't going to happen... and that it isn't happening for reasons that are *not* technical in nature, and so not resolvable by the stakeholders in the room. (As an example, my employer is not represented in the working group by any of its legal and corporate affairs staff)

> Or are you simply advocating we declare "No MTI"?

If the situation is unchanged at that time, I believe that "No MTI" is the only possible outcome. Plus, given the current IPR situation, that's exactly how the browser vendors will act anyway... and we are chartered to care primarily about the browser use cases. (Whether or not you think that's appropriate, that's how it is). But anything could happen between now and finishing the other work... if only we could get back to doing it.

Matthew Kaufman

---

From: <[email-masked]>
Date: Wed, 11 Dec 2013 08:34:13 +0000

I believe this MTI codec discussion in rtcweb is actually a foretaste of what MTI security discussions will be like after draft-farrell-perpass-attack. Mandatory To Implement and discussion around that will basically stall everything.

Having three chairs in a group is a sign of dysfunction. DTNRG has three chairs... there security was pretty much MTI and promoted by the chairs. in rtcweb, the codec is MTI and promoted by the chairs. This is more than a coincidence or an analogy.

I've seen the future of the IETF. It lacks accord and progress - though it won't want for MTI and process.

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: ietf [[email-masked]] On Behalf Of Matthew Kaufman (SKYPE) [[email-masked]]
Sent: 11 December 2013 07:45
To: Adam Roach; Magnus Westerlund; Ted Hardie; [email-masked]; Gonzalo Camarillo; Richard Barnes; Cullen Jennings; [email-masked]
Subject: RE: [rtcweb] Matthew's Objections: was Re: Straw Poll on Video Codec Alternatives

Matthew Kaufman

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Wed, 11 Dec 2013 09:06:51 +0000

+1 for the other discussion has been influenced. I remembered there were some draft comments in the mailing list after IETF88. But I could not find them now, and I remember there is no reply on these valuable comments. 

First, let's finish the Poll to give the WG and the chairs a reference to stop this chaos . There are too few feedbacks by now comparing to the hot discussion before.....

Second, At least, we could move the codec discussion to a separate mailing list like PNTAW. I need say sorry to Harald about it. I objected his same suggestion before because I believe we could get a result in plan. But now I find he was so wise. 

Third, I still hope there will be more discussions on the other draft and direction. Otherwise the milestone will be far far... from us. 

Best Regards,
     Xin 

>From: rtcweb [mailto:[email-masked]] On Behalf Of Matthew
>Kaufman (SKYPE)
>Sent: Wednesday, December 11, 2013 3:54 PM
>To: cowwoc; [email-masked]
>Subject: Re: [rtcweb] Matthew's Objections: was Re: Straw Poll on Video Codec
>Alternatives
>
>Sure. Drop this entirely, go finish the other work, and then see if the situation
>has changed. Given how long it will likely take to finish the items that require
>cooperation with MMUSIC (as just one example), it is possible that one of these
>codec choices will have a change in its IPR status (e.g., MPEG standardization,
>royalty-free licensing) or that a new codec that is not currently proposed will
>become a viable or even preferred choice.
>
>We've certainly spent enough time so far to know that simple consensus on the
>current choices at the current time isn't going to happen... and that it isn't
>happening for reasons that are *not* technical in nature, and so not resolvable
>by the stakeholders in the room. (As an example, my employer is not
>represented in the working group by any of its legal and corporate affairs staff)
>
>If the situation is unchanged at that time, I believe that "No MTI" is the only
>possible outcome. Plus, given the current IPR situation, that's exactly how the
>browser vendors will act anyway... and we are chartered to care primarily about
>the browser use cases. (Whether or not you think that's appropriate, that's how
>it is). But anything could happen between now and finishing the other work... if
>only we could get back to doing it.
>
>Matthew Kaufman
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 11 Dec 2013 12:25:18 +0100

Il giorno Wed, 11 Dec 2013 09:06:51 +0000
"Chenxin (Xin)" <[email-masked]> ha scritto:

<snip>

> 
> Second, At least, we could move the codec discussion to a separate
> mailing list like PNTAW. I need say sorry to Harald about it. I
> objected his same suggestion before because I believe we could get a
> result in plan. But now I find he was so wise. 

+1, that's what I was going to propose too. It is probably the only way
to be able to work on the other important RTCWEB stuff in here, while
keeping the video discussion going on.

Lorenzo

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 11 Dec 2013 12:42:15 +0100

No.

>       Do you have any objections to this option, if so please

I have serious concerns on the licensing burdens that come with H.264.
Anyone that does not already have a license and can't get one would be
unable to support video. The Cisco module would not solve the issue, as
it would still require a separate license for parts of the
specification that are not covered, and cannot be safely depended on in
the long run. Besides, it couldn't be just linked to, but one would
need to download it on the fly for every installation.

>       Are you in favor of this option [Yes/No/Acceptable]:

Yes.

No.

>       Do you have any objections to this option, if so please

I have serious concerns on the licensing burdens that come with H.264.
Anyone that does not already have a license and can't get one would be
unable to support video. The Cisco module would not solve the issue, as
it would still require a separate license for parts of the
specification that are not covered, and cannot be safely depended on in
the long run. Besides, it couldn't be just linked to, but one would
need to download it on the fly for every installation.

>       Are you in favor of this option [Yes/No/Acceptable]:

Acceptable.

>       Do you have any objections to this option, if so please

While it may be acceptable for me, as it would allow me NOT to
implement H.264, I must say it's closer to a NO than to an ACCEPTABLE
if I start thinking about browser makers outside of the "Fantastic
Fours". I have serious concerns on the licensing burdens that come with
H.264. Anyone that does not already have a license and can't get one
would be unable to support video, and this would include most of the
open source browsers, especially those in Fedora and Debian. The Cisco
module would not solve the issue, as it would still require a separate
license for parts of the specification that are not covered, and cannot
be safely depended on in the long run. Besides, it couldn't be just
linked to, but one would need to download it on the fly for every
installation.

No.

>       Do you have any objections to this option, if so please

Implementations wouldn't be interoperable.

>       Are you in favor of this option [Yes/No/Acceptable]:

Acceptable.

>       Do you have any objections to this option, if so please

Quality wouldn't be great, but it's not a dealbreaker: some video is
better than no video.

No.

>       Do you have any objections to this option, if so please

We do need a MTI video. I'd only be okay with such a consensus if it
meant that we're giving up now, until we manage to find a suitable
candidate later on.

>       Are you in favor of this option [Yes/No/Acceptable]:

Acceptable.

>       Do you have any objections to this option, if so please

Considering how divided the group is on those two codecs, we'd still be
stuck with low quality video for most of the calls.

>       Are you in favor of this option [Yes/No/Acceptable]:

Yes.

>       Are you in favor of this option [Yes/No/Acceptable]:

Acceptable.

>       Do you have any objections to this option, if so please

Considering how divided the group is on H.264 and VP8, we'd still be
stuck with low quality video for most of the calls.

>       Are you in favor of this option [Yes/No/Acceptable]:

Acceptable.

>       Do you have any objections to this option, if so please

H.263 is much better than H.261, which means decent quality, but
apparently there still are licensing burdens to it, which makes it
better than H.264 but not that much.

Considering how divided the group is on H.264 and VP8, we'd still be
stuck with lower quality video for most of the calls.

No.

>       Do you have any objections to this option, if so please

I have serious concerns on the licensing burdens that come with H.264.
Anyone that does not already have a license and can't get one would be
unable to support video. The Cisco module would not solve the issue, as
it would still require a separate license for parts of the
specification that are not covered, and cannot be safely depended on in
the long run. Besides, it couldn't be just linked to, but one would
need to download it on the fly for every installation.

>       Are you in favor of this option [Yes/No/Acceptable]:

Acceptable.

>       Do you have any objections to this option, if so please

H.263 is much better than H.261, which means decent quality, but
apparently there still are licensing burdens to it, which makes it
better than H.264 but not that much.

>       Are you in favor of this option [Yes/No/Acceptable]:

Yes.

No.

>       Do you have any objections to this option, if so please

I said YES to Theora as the MTI, but this option makes no sense, since
it doesn't mandate anything on the encoder side.

No.

>       Do you have any objections to this option, if so please

It's bandwidth consumption for reasonable resolutions/framerates is so
overkill I really can't see it working anywhere out of a LAN.

Lorenzo

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Wed, 11 Dec 2013 22:34:50 +0800

+1 on a separate mailing list for the video Codec.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Dec 2013 15:38:53 +0100

Hi Roman,

Please change the subject line if you are commenting and not providing a
straw poll.

On 2013-12-10 19:58, Roman Shpount wrote:
> Honestly, why are we wasting our time on this?

Because we are getting mixed signals from people in the WG. Some say,
stop this now and have no MTI. Some say MTI is very important. Others
say lets get on with some voting selection etc. As WG chair based on
that we did collect the list of alternatives, I need a better
understanding what the WG participants positions are. Then I hope we can
attempt to conclude this is some way. Either you are right and we have
no option that is sufficiently acceptable to have a chance to reach
consensus, or we can find one (preferable) or a small set that makes
other next steps meaningful.

 I can do a straw poll,
> but there are no options acceptable to everybody present. Here is my
> analysis of presented options:

I would appreciate if you do. I think there is value in getting the
response from as many as possible.

Cheers

Magnus

> MPEG-LA. After this you need to make a deal with Nokia and other people
> not part of MPEG-LA. As a result you are going to get rights to decoder.
> Encoder is not specified by the standard and there are no obligations
> for MPEG members to declare anything, so you are more then likely
> exposed to addition IPR risks when implementing a good encoder. You
> cannot afford not to license since if you are real business (ie one
> generating money or taking investor money) you cannot afford such
> business risk. Even if you are planning to distribute less then 100K
> codec instances you will still need a license since MPEG-LA terms are
> ambiguous enough that you would want to have a contact that clarifies
> what exactly you can do. After you jumped through all these licensing
> hoops you are still exposed to all the potential undisclosed IPR with
> your only hope that patent trolls will go after the bigger guys first
> (from my experience they will not).
> 
> something basic since it limits what you can do by requiring to use
> their pre-built binary. I am building conferencing servers, so I expect
> that I will need to optimize the codec for my needs. I will need to
> build custom optimized VP8 to H.264 transcoder. I will need to build
> custom H.264 bitrate adaptation (ie H.264 to H.264 transcoder to adjust
> bitrate). All of this is not an option with Cisco binary. 
> 
> VP8 -- This works for me but I see that this will not work for any
> company already using H.264 or ever planning to sue Google. If you are
> already using H.264, why do you want to expose yourself to additional
> IPR risks? Google license is not acceptable to many larger companies
> (partially due to this license being automatically revoked if you decide
> to sue Google for reasons non related to VP8) . Fail for VP8.
> 
> All the other codecs -- Their quality is too low for modern
> communications to be used for anything except when everything else
> fails. They are better then nothing but neither one of them is
> widespread enough and used enough to simply be there.  They all present
> additional maintenance and development effort. They also present an
> additional IPR risk. H.261 and H.263 only specify decoders. If you try
> to optimize the encoder to work better you most likely run into patents
> that have not expired yet. So, all the other codecs are not an option
> either.
> 
> My proposal -- no MTI until a new non encumbered video codec, like
> Daala, is developed specifically for this purpose. Until then this
> discussion is essentially discussion G.722.2 vs Vorbis vs Linear PCM for
> audio codec MTI. Neither one was acceptable for WebRTC, so Opus was
> developed. The same needs to be done for video.
> _____________
> Roman Shpount
> 
> 
> On Mon, Dec 9, 2013 at 12:24 PM, Ted Hardie <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Dear WG,
> 
> 
>     alternatives proposed to the WG. If you haven’t read the “Next Steps
>     in Video Codec Selection Process”
>     (http://www.ietf.org/mail-archive/web/rtcweb/current/msg10448.html)then
>     have, if any, against a particular alternative. The WG chairs will
>     use the information from this straw poll to identify an alternative
>     to put as a single consensus question to the group. Thus, everyone
>     that has an opinion on at least one alternative should answer this
>     poll. Provide your poll input by replying to this email to the WG
>     mailing list. The poll will run until the end of the 12th of January
>     2014.
> 
> 
>     really don’t favor this, and it should not be picked. Acceptable = I
>     The second question is “Do you have any objections to this option,
>     if so please explain it:” If you have any objection at a minimum
>     indicate it with a “Yes”.   Please also add a short (1-sentence)
>     summary of each of the objections you believe applies.  (If you wish
>     to provide a longer explanation, please do so in a separate thread).
>      If you have no objection, leave that question blank.
> 
> 
>     brought forward for consensus. Any alternative that you chose to
>     leave blank, will simply be considered as one without any input from
>     you.  
> 
> 
>     WG participants, please do not comment on anyone’s input in this
>     life for the chairs very difficult to track the results of this
>     straw poll.  
> 
> 
>     If discussion causes you to update your position, please feel free
>     to send an update via email on the straw poll thread prior to the
>     closing date.
> 
> 
> 
>      1.
> 
>     Theora is a reference to Xiph.org Theora Specification from March
>     16, 2011 (http://www.xiph.org/theora/doc/Theora_I_spec.pdf)
> 
> 
>     H.263 is a reference to profile 0 level 70 defined in annex X of
>     ITU-T rec H.263 (http://www.itu.int/rec/T-REC-H.263/)
> 
> 
>     [email-masked] <mailto:[email-masked]>

-- 

Magnus Westerlund

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 11 Dec 2013 15:40:16 +0000

1.
     *

Yes

     *
     *
Do you have any objections to this option, if so please summarize them:

  1.
     *

No

     *
     *
Do you have any objections to this option, if so please summarize them:

my concerns are related to the fact that one IPR owner has declared
to be unwilling to license its IPRs needed to implement VP8

     *
  1.
     *

No

     *
     *
Do you have any objections to this option, if so please summarize them:

It does not make sense to me to have two similar codecs

     *
  1.
Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8
     *
Are you in favor of this option [Yes/No/Acceptable]:

No

     *
     *
Do you have any objections to this option, if so please summarize them:

I don't like the distinction between browsers and other entities, as it can create
interop problem in the webrtc world

     *
  1.
     *

No

     *
     *
Do you have any objections to this option, if so please summarize them:

this solution doesn't seem to solve the interop problem, that is the reason behind MTI

     *
  1.
     *

No

     *
     *
Do you have any objections to this option, if so please summarize them:

     *
  1.
     *

Acceptable

     *
     *
Do you have any objections to this option, if so please summarize them:
  1.
All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8
     *
Are you in favor of this option [Yes/No/Acceptable]:

No

     *
     *
Do you have any objections to this option, if so please summarize them:
  1.
All entities MUST support Theora
     *
Are you in favor of this option [Yes/No/Acceptable]:

No

     *
     *
Do you have any objections to this option, if so please summarize them:
  1.
All entities MUST implement at least two of {VP8, H.264, H.261}
     *
Are you in favor of this option [Yes/No/Acceptable]:

No

     *
     *
Do you have any objections to this option, if so please summarize them:
  1.
All entities MUST implement at least two of {VP8, H.264, H.263}
     *
Are you in favor of this option [Yes/No/Acceptable]:

No

     *
     *
Do you have any objections to this option, if so please summarize them:
  1.
All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8
     *
Are you in favor of this option [Yes/No/Acceptable]:

No

     *
     *
Do you have any objections to this option, if so please summarize them:
  1.
All entities MUST support H.263
     *
Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

     *
     *
Do you have any objections to this option, if so please summarize them:
  1.
All entities MUST implement at least two of {VP8, H.264, Theora}
     *
Are you in favor of this option [Yes/No/Acceptable]:

No

     *
     *
Do you have any objections to this option, if so please summarize them:
  1.
All entities MUST support decoding using Theora.
     *
Are you in favor of this option [Yes/No/Acceptable]:

No

     *
     *
Do you have any objections to this option, if so please summarize them:
  1.
All entities MUST support Motion JPEG
     *
Are you in favor of this option [Yes/No/Acceptable]:

No

     *
     *
Do you have any objections to this option, if so please summarize them:

Theora is a reference to Xiph.org<http://Xiph.org> Theora Specification from March 16, 2011 (http://www.xiph.org/theora/doc/Theora_I_spec.pdf)

Thanks,

The Chairs

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 11 Dec 2013 08:56:08 -0800

Matthew,

Since you have escalated this to the area directors after Magnus's replay,
I will leave them to respond to your main request, but I have two
corrections to factual mis-statements:

On Tue, Dec 10, 2013 at 11:45 PM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

> At the in-person meetings, discussing the MTI video codec is
> agenda-exclusive of progressing any other document.
>
>
As attending the actual meetings would have told (or even reading their
minutes), this is simply not true.  We have had sessions related to
resolving this issue, but in every case there have also been other topics
discussed during the same IETF meeting, albeit in sometimes in other
sessions.

> I believe that objecting to the actions of the chairs is a bigger lever
> towards real progress than trying to be the one tiny voice in the corner
> trying to progress something else unilaterally during this storm.
>
>
The chairs have gratefully received and pushed action on reviews received
on a variety of documents during this period, and there has been movement
on data channel and the security documents driven by those who have chosen
to continue to work on those issues.   If you choose to ignore that work to
focus on this issue, that's your choice of how to use your time, not an
imposition by the chairs.  Self-fulfilling prophecies tend to be, well,
self-fulling, but they need not be universal.

I invite you to submit a review of any document currently before the
working group, and I pledge to you that it will get attention from the
chairs, no matter what else is going on.

regards,

Ted Hardie

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Dec 2013 09:39:22 -0800

> On Dec 11, 2013, at 1:36 AM, "cowwoc" <[email-masked]> wrote:
> 
> Methinks we are going to end up with two competing WebRTC specifications.

[BA] I would argue that if we don't get back on track we will end up with no specs in a useful timeframe. As Matthew said, the MTI issue is likely to be resolved in the marketplace in the fullness of time without the IETF. The same is not true of the RTCWEB documents - we need to accelerate progress.

---

From: Maik Merten <[email-masked]>
Date: Wed, 11 Dec 2013 18:40:18 +0100

No

>         Do you have any objections to this option, if so please

H.264 licensing.

In the event of the H.264 baseline profile actually becoming 
royalty-free, which has been discussed for years without results: "Yes"

Yes

No

>         Do you have any objections to this option, if so please

H.264 licensing.

No

>         Do you have any objections to this option, if so please

Does not guarantee interoperability for anything but browsers. My 
understanding is that there may be clients that are not browsers.

No

>         Do you have any objections to this option, if so please

Does not guarantee interoperability.

Acceptable.

This will guarantee (very) basic video interoperability. H.261 should be 
the codec with the lowest possible IPR risk.

No

>         Do you have any objections to this option, if so please

Will guarantee spurious interoperability failures in P2P scenarios.

Acceptable

Yes

Yes

No

>         Do you have any objections to this option, if so please

Licensing situation for H.263 is unclear.

If it turns out that the proposed H.263 baseline is deployable without 
licensing, my "No" will transform into a "Yes" in a spectacular fashion.

No

>         Do you have any objections to this option, if so please

Licensing for H.264 decoders is incompatible with free software.

No

>         Do you have any objections to this option, if so please

Licensing situation for H.263 is unclear.

If it turns out that the proposed H.263 baseline is deployable without 
licensing, my "No" will transform into a "Yes".

Yes

No

>         Do you have any objections to this option, if so please

Does not guarantee interoperability.

Acceptable

>         Do you have any objections to this option, if so please

Coding efficiency is by far the lowest of all proposed codecs. Still 
better than "no MTI", as this at least allows for visual content with 
low update frequency.

---

From: Erik Lagerway <[email-masked]>
Date: Wed, 11 Dec 2013 09:54:06 -0800

+1

We may want to consider getting back to it later (if need be) once VP8 has
had a chance to get a bit further into the MPEG LA process. This might
address the concerns of some around IPR etc. but it will take some time.
Either way, battling around MTI it doesn't seem to be doing us much good.

*Erik Lagerway <http://ca.linkedin.com/in/lagerway> |
*Hookflash<http://hookflash.com/>* |
1 (855) Hookflash ext. 2 | Twitter
<http://twitter.com/elagerway> | WebRTC.is Blog <http://webrtc.is/> *

On Wed, Dec 11, 2013 at 9:39 AM, Bernard Aboba <[email-masked]>wrote:

> [BA] I would argue that if we don't get back on track we will end up with
> no specs in a useful timeframe. As Matthew said, the MTI issue is likely to
> be resolved in the marketplace in the fullness of time without the IETF.
> The same is not true of the RTCWEB documents - we need to accelerate
> progress.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 11 Dec 2013 13:15:06 -0500

1.

 No

   1.

 Not acceptable to anybody who is not already using H.264 due to its
licensing schema. To license H.264 you need to make a deal with MPEG-LA.
After this you need to make a deal with Nokia and other people not part of
MPEG-LA. As a result you are going to get rights to decoder. Encoder is not
specified by the standard and there are no obligations for MPEG members to
declare anything, so you are more then likely exposed to addition IPR risks
when implementing a good encoder. You cannot afford not to license since if
you are real business (ie one generating money or taking investor money)
you cannot afford such business risk. Even if you are planning to
distribute less then 100K codec instances you will still need a license
since MPEG-LA terms are ambiguous enough that you would want to have a
contact that clarifies what exactly you can do. After you jumped through
all these licensing hoops you are still exposed to all the potential
undisclosed IPR with your only hope that patent trolls will go after the
bigger guys first (from my experience they will not).

   1.

 Acceptable

   1.

 It is acceptable since implementation is provided by Google under
reasonable license terms. It is not a strong yes since VP8 is not formally
defined by any standard's body.

   1.

 No

   1.

 Not acceptable due to H.264 licensing. Creates additional burden on
development and support

   1.

 No

   1.

 Not acceptable due to H.264 licensing. Creates additional burden on
development and support

   1.

 No

   1.

 Does not result in MTI.

   1.

 No

   1.

 Quality is not acceptable for modern video communications

   1.

 No

   1.

 Video is essential to WebRTC

   1.

 No

   1.

 Essentially makes H.261 an MTI, but its quality is not acceptable for
modern video communications

   1.

 No

   1.

 No better then VP8 since it never went through a standard body, but much
worse quality wise.

   1.

 No

   1.

 Additional burden on implementation and support with a strong option of
using H.261 for call which is not acceptable due to quality.

   1.

 No

   1.

 Additional burden on implementation and support with a strong option of
using H.263 for call which is not acceptable due to quality and additional
IPR licensing requirements

   1.

 No

   1.

 Decoding H.264 has exactly the same licensing issues as encoding it, so it
is as unacceptable for me as simple H.264 support

   1.

 No

   1.

 Quality is much worse then H.264 and VP8. Still requires IPR licensing

   1.

 No

   1.

 Additional support burden. Theora can be used for communications but its
quality is much worse then VP8 or H.264

   1.

 No

   1.

 Does not create an MTI

   1.

 No

   1.

 Resulting quality would be so bad it would be almost unusable.

______________

Roman Shpount

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 11 Dec 2013 19:44:46 +0000

I was of the understanding that the statement:

"Encoder is not specified by the standard and there are no obligations for MPEG members to declare anything, so you are more then likely exposed to addition IPR risks when implementing a good encoder. "

applied to pretty much every videocodec under the sum, and was not specific to H.264.

The general method of specifying videocodecs is to specify the decoder only. I'd certainly thought seen a statement of that sort previously on the list; have I understood it wrong?

Essentially if you do anything innovative that is not covered by the standard, you stand a chance of contravening IPR of someone who thought of it before you did and then patented it.

Keith Drage

________________________________
From: rtcweb [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 11 December 2013 18:15
To: Ted Hardie
Cc: [email-masked]; Cullen Jennings
Subject: Re: [rtcweb] Straw Poll on Video Codec Alternatives

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Not acceptable to anybody who is not already using H.264 due to its licensing schema. To license H.264 you need to make a deal with MPEG-LA. After this you need to make a deal with Nokia and other people not part of MPEG-LA. As a result you are going to get rights to decoder. Encoder is not specified by the standard and there are no obligations for MPEG members to declare anything, so you are more then likely exposed to addition IPR risks when implementing a good encoder. You cannot afford not to license since if you are real business (ie one generating money or taking investor money) you cannot afford such business risk. Even if you are planning to distribute less then 100K codec instances you will still need a license since MPEG-LA terms are ambiguous enough that you would want to have a contact that clarifies what exactly you can do. After you jumped through all these licensing hoops you are still exposed to all the potential undisclosed IPR with your only hope that patent trolls will go after the bigger guys first (from my experience they will not).

Using Cisco binary codec is also unacceptable unless you are doing something basic since it limits what you can do by requiring to use their pre-built binary. I am building conferencing servers, so I expect that I will need to optimize the codec for my needs. I will need to build custom optimized VP8 to H.264 transcoder. I will need to build custom H.264 bitrate adaptation (ie H.264 to H.264 transcoder to adjust bitrate). All of this is not an option with Cisco binary.

     *   Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

     *   Do you have any objections to this option, if so please summarize them:

It is acceptable since implementation is provided by Google under reasonable license terms. It is not a strong yes since VP8 is not formally defined by any standard's body.

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Not acceptable due to H.264 licensing. Creates additional burden on development and support

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Not acceptable due to H.264 licensing. Creates additional burden on development and support

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Does not result in MTI.

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Essentially makes H.261 an MTI, but its quality is not acceptable for modern video communications

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

No better then VP8 since it never went through a standard body, but much worse quality wise.

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Additional burden on implementation and support with a strong option of using H.261 for call which is not acceptable due to quality.

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Additional burden on implementation and support with a strong option of using H.263 for call which is not acceptable due to quality and additional IPR licensing requirements

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Decoding H.264 has exactly the same licensing issues as encoding it, so it is as unacceptable for me as simple H.264 support

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Additional support burden. Theora can be used for communications but its quality is much worse then VP8 or H.264

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Does not create an MTI

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

______________

Roman Shpount

---

From: Engel Nyst <[email-masked]>
Date: Wed, 11 Dec 2013 23:30:34 +0200

No.

>        Do you have any objections to this option, if so please summarize

MPEG-LA owns patents /and/ uses them aggressively to stifle development 
of open standards. I do not see this as remotely appropriate for 
*Mandatory*-to-Implement.
I am concerned about the fake appearances Cisco is giving. The code 
"appears" to be BSD-licensed, and github repository gives no indication 
to well intended people that in reality it's not. Forking the repository 
and building a derivative release *already runs afoul* of MPEG-LA 
restrictions and exposes people to uncertainty and being chased for 
fees, when it's a natural thing to do.
Misleading people that an implementation is open source when it's not is 
an unacceptable action in my book, under any shape or form; and I will 
keep short here as to other practical scenarios and issues that it brings.

Yes.

Practical results achieve interoperability. Quality. On the right path 
towards open standards.

No.

>        Do you have any objections to this option, if so please summarize

MPEG-LA owns patents /and/ uses them aggressively to stifle development 
of open standards. I do not see this as remotely appropriate for 
*Mandatory*-to-Implement.
Misleading innocent actors that it's open sourced when it's not, is an 
unacceptable action in my book.

Acceptable.

>        Do you have any objections to this option, if so please summarize

MPEG-LA owns patents /and/ uses them aggressively to stifle development 
of open standards. I do not see this as remotely appropriate for 
*Mandatory*-to-Implement.
Misleading innocent actors that it's open sourced when it's not, exposes 
them even more to uncertainty and doubt.
Interoperability issues.
However, at least I see in this option a narrow and difficult path to 
many, not all, compliant setups, at the price of ignoring the codec one 
doesn't implement or use in practice.

Acceptable.

>        Do you have any objections to this option, if so please summarize

Interoperability issues. However, at least the islands that will result 
are feasible setups taken in isolation. Not optimal, but I could live 
with it considering all the context of this decision.

>        Are you in favor of this option [Yes/No/Acceptable]:

Yes.
Path to an open standard of better quality next time.

>        Are you in favor of this option [Yes/No/Acceptable]:

Yes.
The result in practice is "islands" in other options, so might as well 
not choose a mandatory-but-not-used-in-practice solution.

>        Do you have any objections to this option, if so please summarize

Interoperability not achieved for the next years before an open standard 
is ready at the quality of the day. However the objection should be read 
as softened by the above.

>        Are you in favor of this option [Yes/No/Acceptable]:

Yes.
Interoperability achieved. Choice between preferred and fallback.

Acceptable.

Acceptable.

>        Do you have any objections to this option, if so please summarize

MPEG-LA owns patents /and/ uses them aggressively to stifle development 
of open standards.
Misleading innocent actors that it's open sourced like any other when 
it's not, exposes them even more to uncertainty and doubt.
But another practical result of this option is interoperability.

No.

>        Do you have any objections to this option, if so please summarize

Too risky still. Patent aggressivity and bad faith.

No.

>        Do you have any objections to this option, if so please summarize

MPEG-LA owns patents /and/ uses them aggressively to stifle development 
of open standards. I do not see this as remotely appropriate for 
*Mandatory*-to-Implement.
Misleading innocent actors that it's open sourced like any other when 
it's not, exposes them even more to uncertainty and doubt.

No.

>        Do you have any objections to this option, if so please summarize

Too risky still. Patent aggressivity and bad faith.

Acceptable.

Acceptable.

Acceptable.

>        Do you have any objections to this option, if so please summarize

Quality issues.

-- 
~enyst

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 12 Dec 2013 01:09:39 +0000

Let me try and answer what I think is your central issue here which is: why are we spending any time on this topic. 

We have heard from a significant number of people that they think it is important for WebRTC devices and applicaitons to be able to know that video will work between devices. It was the number one requested item when speaking to the various developers with products demonstrated at WebRTC Expo and a significant issue on this email list. It is one of the several topics the chairs are driving forward. We plan to continue to do try to drive it to resolution. Note resolution includes consensus for no MTI. 

However, we perfectly well understand that you, or others, may not want to spend time on the video MTI issue. Feel free to ignore the email threads if you believe the outcome is inevitable and put your time into some of the other things we are also driving forward. 

Cullen in my co-chair role (and I'm not speaking for my co-chairs but I am pretty sure they also want to drive this issue to resolution) 

On Dec 9, 2013, at 4:32 PM, Matthew Kaufman (SKYPE) <[email-masked]> wrote:

> Instead the chairs are now conducting a “straw poll” of their own design, clearly in an effort to circumvent some very specific objections to the proposed instant-runoff vote with restricted participation. But again, instead of attempting to reach WG consensus for conducting such a poll, it has simply been foisted upon us.
>  
> I have not seen ANY replies to the message “Next Steps in Video Codec Selection Process” that indicate working group consensus of ANY KIND for conducting a poll in this format at this time or to follow the subsequent steps described in that message.
>  
> I am requesting that the chairs immediately suspend the “Straw Poll” described below until such time as there is Working Group consensus to spend the Working Group’s time and energy conducting the poll and/or to continue with the subsequent steps called out in “Next Steps in Video Codec Selection Process” at http://www.ietf.org/mail-archive/web/rtcweb/current/msg10448.html

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 12 Dec 2013 02:27:05 +0100

* Cullen Jennings (fluffy) wrote:
>Let me try and answer what I think is your central issue here which is:
>why are we spending any time on this topic. 
>
>We have heard from a significant number of people that they think it is 
>important for WebRTC devices and applicaitons to be able to know that 
>video will work between devices. It was the number one requested item 
>when speaking to the various developers with products demonstrated at 
>WebRTC Expo and a significant issue on this email list. It is one of the 
>several topics the chairs are driving forward. We plan to continue to do 
>try to drive it to resolution. Note resolution includes consensus for no 
>MTI. 

To me, an important point is that some people are now investigating some
alternative options that have not been given much consideration before,
like the data points and samples regarding H.261 that have been sent to
the group's mailing list recently, which may open up new ways to find a
consensus. I think a straw poll is much more useful in this situation
than a vote or giving up.
-- 
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: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Dec 2013 10:44:57 +0100

Hi Matthew,

> The Area Director is already copied and I would like this message
> considered as escalation of my previous objection and request to
> suspend the poll.

there have been many emails around this topic. I assume you refer to the
fact that the WG should stop spending time on discussing video codecs
shortly and spend all its time on other chartered items instead.

Actually, I agree with that and I told the chairs so after our last
meeting in Vancouver. That is why the chairs are driving this issue to
its conclusion. The idea is to get consensus on whatever the WG can get
consensus on at this point (e.g., a particular codec as MTI, to
implement at least one of two codecs, no MTI at all, or any of the other
options being considered) and move on.

Cheers,

Gonzalo

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 12 Dec 2013 12:40:34 +0000

I also think it is important that we should be able to work between devices.

However the devices I want to work between are webRTC devices and SIP devices, and other devices that are currently using video codecs.

Unfortunately we seem to have got the mandatory to implement video codec stated in the charter (without any thought or real discussion in my view of the implications), but every suggestion that we need requirements to interwork with existing infrastructure has been shouted down by certain groups. However that does not mean that there is consensus not to do this, just that there is no position.

Yes one can deploy infrastructure to do transcoding, but inherently that costs (and why should one force the cost to be on someone wanting to interwork with existing infrastructure), and potentially loses video quality (and should therefore be reserved for where one wants to conference different codecs together rather than on end to end sessions).

So fundamentally we are trying to address the wrong set of documented requirements.

Regards

Keith

P.S. And I did ask a few messages back which documents the chairs want to work on with higher priority, and I have had no response. So obviously they only want the WG to work on video codec MTI.

> From: rtcweb [mailto:[email-masked]] On Behalf Of 
> Cullen Jennings (fluffy)
> Sent: 12 December 2013 01:10
> To: Matthew Kaufman (SKYPE)
> Cc: [email-masked]; [email-masked]
> Subject: [rtcweb] Why the Straw Poll
> 
> 
> Let me try and answer what I think is your central issue here 
> which is: why are we spending any time on this topic. 
> 
> We have heard from a significant number of people that they 
> think it is important for WebRTC devices and applicaitons to 
> be able to know that video will work between devices. It was 
> the number one requested item when speaking to the various 
> developers with products demonstrated at WebRTC Expo and a 
> significant issue on this email list. It is one of the 
> several topics the chairs are driving forward. We plan to 
> continue to do try to drive it to resolution. Note resolution 
> includes consensus for no MTI. 
> 
> However, we perfectly well understand that you, or others, 
> may not want to spend time on the video MTI issue. Feel free 
> to ignore the email threads if you believe the outcome is 
> inevitable and put your time into some of the other things we 
> are also driving forward. 
> 
> Cullen in my co-chair role (and I'm not speaking for my 
> co-chairs but I am pretty sure they also want to drive this 
> issue to resolution) 
> 
> 
> > First, there was a discussion and a call for rough 
> consensus at the last IETF in-person meeting. That call was 
> not continued on the list, instead a lack of consensus was 
> declared at the meeting.
> >  
> > Next, there was a proposal from the chairs to vote in a 
> particular way, and a call for options on which to vote. It 
> was claimed at that time that after the list was compiled, 
> the act of taking such a vote would be taken to a consensus 
> call. That never happened.
> >  
> > Instead the chairs are now conducting a "straw poll" of 
> their own design, clearly in an effort to circumvent some 
> very specific objections to the proposed instant-runoff vote 
> with restricted participation. But again, instead of 
> attempting to reach WG consensus for conducting such a poll, 
> it has simply been foisted upon us.
> >  
> > I have not seen ANY replies to the message "Next Steps in 
> Video Codec Selection Process" that indicate working group 
> consensus of ANY KIND for conducting a poll in this format at 
> this time or to follow the subsequent steps described in that message.
> >

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Dec 2013 16:30:32 +0100

Hi Keith,

Dropping other lists than WG list.

On 2013-12-12 13:40, DRAGE, Keith (Keith) wrote:

> P.S. And I did ask a few messages back which documents the chairs
> want to work on with higher priority, and I have had no response. So
> obviously they only want the WG to work on video codec MTI.
> 

Sorry,

I missed that in my reading of your previous message.

First of all we need to progress basically all of the current WG
documents to finish up to have a working solution:
https://datatracker.ietf.org/wg/rtcweb/

However, I think JSEP and the Data Channel + Protocol drafts are two
sets of documents I would recommend to focus on currently. JSEP because
I think it has quite a lot of work left to be done. Data channel +
protocol because these are getting into the finishing up phase.

The security, security architecture and RTP usage there will be updates
hopefully soon. So those will need reviews as soon as the updates become
available.

We have three smaller documents that all can benefit from review by a
larger community. These are:
draft-ietf-rtcweb-transports-01
draft-ietf-rtcweb-stun-consent-freshness-00
draft-ietf-rtcweb-audio-03

So please review the document or documents you fell most comfortable
with contributing and send your comments to the authors and the list. If
you have text proposals for improvements, even better.

cheers

Magnus Westerlund

---

From: Mary Barnes <[email-masked]>
Date: Thu, 12 Dec 2013 10:24:46 -0600

It's also very important (and IMHO more important) to consider the
documents in other WGs upon which RTCWEB WG deliverables are dependent. For
example, JSEP has some major dependencies in MMUSIC:
http://www.fenron.net/~fenner/ietf/deps/index.cgi?dep=draft-ietf-rtcweb-jsep

While the entirety of the WG focus has been on lack of interoperability if
there is no MTI codec, without the docs in MMUSIC being completed, you have
even more basic interop problems.

Regards,
Mary

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 12 Dec 2013 17:29:31 +0000

Just as FYI for you, you are wrong about several things below. If you would like to have a phone call to discuss them, glad to help get you the information that is correct. 

On Dec 11, 2013, at 2:30 PM, Engel Nyst <[email-masked]> wrote:

> 
> MPEG-LA owns patents /and/ uses them aggressively to stifle development of open standards. I do not see this as remotely appropriate for *Mandatory*-to-Implement.
> I am concerned about the fake appearances Cisco is giving. The code "appears" to be BSD-licensed, and github repository gives no indication to well intended people that in reality it's not. Forking the repository and building a derivative release *already runs afoul* of MPEG-LA restrictions and exposes people to uncertainty and being chased for fees, when it's a natural thing to do.
> Misleading people that an implementation is open source when it's not is an unacceptable action in my book, under any shape or form; and I will keep short here as to other practical scenarios and issues that it brings.

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 12 Dec 2013 18:48:19 +0100

Il giorno Thu, 12 Dec 2013 17:29:31 +0000
"Cullen Jennings (fluffy)" <[email-masked]> ha scritto:

> 
> Just as FYI for you, you are wrong about several things below. If you
> would like to have a phone call to discuss them, glad to help get you
> the information that is correct. 
> 

Engel, I have to agree with Cullen that you're misinterpreting some
points here. The code is definitely BSD, and you're free to fork it (as
many have already done).

The problem with the licensing you're probably mentioning is related to
the distribution of the compiled code. You're on your own and "chased
for fees" as soon as you compile your own version and have your app
link to it directly, instead of downloading the compiled module from
Cisco. But this would happen whether or not you fork the code in the
first place: that is, you're not covered by the Cisco license even if
you compile the original github code yourself and distribute it with
your app.

If that's what you meant, then on this we definitely agree, as it is
one of the points I'm not a big fan of (to say the very least), but
saying that Cisco's code is not really open source just isn't true.
After all, the same happens for x264: that code is open source as well,
but you can't use it without a license either. We can only hope this
situation changes in the future, but I wouldn't hold my breath! :-)

Lorenzo

> > MPEG-LA owns patents /and/ uses them aggressively to stifle
> > development of open standards. I do not see this as remotely
> > appropriate for *Mandatory*-to-Implement. I am concerned about the
> > fake appearances Cisco is giving. The code "appears" to be
> > BSD-licensed, and github repository gives no indication to well
> > intended people that in reality it's not. Forking the repository
> > fees, when it's a natural thing to do. Misleading people that an
> > implementation is open source when it's not is an unacceptable
> > action in my book, under any shape or form; and I will keep short
> > here as to other practical scenarios and issues that it brings.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Dec 2013 14:38:29 +0100

On 2013-12-12 17:24, Mary Barnes wrote:
> documents in other WGs upon which RTCWEB WG deliverables are dependent.
> For example, JSEP has some major dependencies in MMUSIC:

I would note that this particular dependency graph looks broken, most
likely to wrongly classified information in JSEP.

However, I do agree with your note, our normative dependencies also
needs review, feedback and contribution to resolve issues.

> 
> While the entirety of the WG focus has been on lack of interoperability
> if there is no MTI codec, without the docs in MMUSIC being completed,
> you have even more basic interop problems.

There are also documents in AVTCORE and TSVWG that are needed to provide
a interoperable solution.

So please select a document or two and review them and send your
feedback and suggestions

Cheers

Magnus Westerlund
(As WG chair)

---

From: Steve McFarlin <[email-masked]>
Date: Mon, 16 Dec 2013 12:10:11 -0800

Weighted opinions are purely mine, and not that of my employer. I am not taking Cisco's gift into consideration. While it is generous and useful for some, the license 'hack' forces the installation of the library on the end user machine/device. This is not feasible on some platforms. 

No.

> Do you have any objections to this option, if so please summarize them:

Not all platforms expose access to a hardware or software encoder. If every feasible platform exposed H.264 API's then my reply would be "Acceptable 0.4". I also feel the IPR burden is too much on smaller players implementing MCU's.

Yes.

> Do you have any objections to this option, if so please summarize them:

While I don't like putting my faith with other companies when it comes to IPR, I truly believe that Google will in good faith deal with any IPR issues that arise in the future. I think the gamble is an acceptable risk.

> Are you in favor of this option [Yes/No/Acceptable]:

Acceptable (0.3)

> Do you have any objections to this option, if so please summarize them:

While I still think the IPR on 264 is a burden, I think this is acceptable with respect to the browser space. My only concern is this option might just fragment/split the webrtc space with conforming and non conforming implementations. If selected I full expect FOSS implementations to be mostly VP8. With this said as long as the major players (browsers) implement both, then any custom non conforming RTC stack will still work in most cases.

There is still 264 IPR issues on conforming MCU's that do any coding tasks with the 264 data. There are also IPR issues related to broadcasting and the sale of H.264 content, but those are obviously outside the scope of this discussion.

> Are you in favor of this option [Yes/No/Acceptable]:

Acceptable (0.8)

> Do you have any objections to this option, if so please summarize them:

There is still 264 IPR issues on MCU's that do any coding tasks with the 264 data. There are also IPR issues related to broadcasting and the sale of H.264 content, but those are obviously outside the scope of this discussion.

No

> Do you have any objections to this option, if so please summarize them:

This only makes sense if we want to 'see who wins'. Given the division amongst many people I suspect we would see more 244 xor VP8 implementations then ones with both.

No

> Do you have any objections to this option, if so please summarize them:

While the video is usable, it just can't compete in the modern video communications space.

> Are you in favor of this option [Yes/No/Acceptable]:

Acceptable (0.1)

> Do you have any objections to this option, if so please summarize them:

If no consensus is made on any other option then I see no other choice. This group needs to move forward at some point.

> Are you in favor of this option [Yes/No/Acceptable]:

Acceptable (0.3)

> Do you have any objections to this option, if so please summarize them:

I really don't like the fallback to 261. It is just not a good codec.

> Are you in favor of this option [Yes/No/Acceptable]:

Acceptable (0.2)

> Do you have any objections to this option, if so please summarize them:

While better than 261, I feel having at least one modern codec as a MUST is better than this.

> Are you in favor of this option [Yes/No/Acceptable]:

Acceptable (0.4)

> Do you have any objections to this option, if so please summarize them:

I really don't like 261. It is not a good codec for modern video communications.

No.

> Do you have any objections to this option, if so please summarize them:

As far as I am aware 263 still has IPR issues. This just forces compliant stacks into a possible IPR violation issue.

No.

> Do you have any objections to this option, if so please summarize them:

While I think the risk of an IPR suite for disturbing a H.264 decoder is small, I would not put it past some NPE popping up and forcing you to visit that lovely court in Texas. The visit alone would put any small player instantly out of business assuming they did not 'pay the fee'. This option in a IETF spec just makes it that much easier for a NPE or IPR holder to select targets.

No

> Do you have any objections to this option, if so please summarize them:

Possible IPR issues. Not a modern codec. (I understand VP8 and 264 are not modern codecs per say, but at least they are 'more' modern than 263).

> Are you in favor of this option [Yes/No/Acceptable]:

Acceptable (0.6)

> Do you have any objections to this option, if so please summarize them:

Theora is a better quality codec than 261, and does not have any possible IPR issues that 263 has. I am not sure of the IPR status of Theora, and I don't ever recall seeing someone sued for it. Then again maybe there has never been a big enough target for anyone who thinks they have IPR on Theora from coming forward. I would personally be willing to take a risk on the much more than 263 or distributing a 264 decoder.

No

> Do you have any objections to this option, if so please summarize them:

Maybe I have not had enough or had too much coffee today, but I don't see the logic in this option at the moment.

> Are you in favor of this option [Yes/No/Acceptable]:

No No No.

> Do you have any objections to this option, if so please summarize them:

I understand the need to enumerate all options, but this just has so much FAIL attached to it. Do we really need interop with old Canon network cams (lol)? On the positive side I think Firefox still supports motion JEPG streaming as a relic from the Netscape implementation back in 96 (or earlier). Kidding aside, this will be way too bandwidth intensive to achieve good quality video.

---

From: cowwoc <[email-masked]>
Date: Mon, 16 Dec 2013 15:16:51 -0500

I know we're not supposed to reply directly to authors but I don't 
understand how to interpret Steve's answers...

Steve, can you please clarify what "Acceptable (X)" means? What is the 
significance of X? Is the higher the number, the better? Does it imply 
that one Acceptable answer is more acceptable than another?

Thanks,
Gili

On 16/12/2013 3:10 PM, Steve McFarlin wrote:
> Weighted opinions are purely mine, and not that of my employer. I am 
> not taking Cisco's gift into consideration. While it is generous and 
> useful for some, the license 'hack' forces the installation of the 
> library on the end user machine/device. This is not feasible on some 
> platforms.
>
>> 1.
> Not all platforms expose access to a hardware or software encoder. If 
> every feasible platform exposed H.264 API's then my reply would be 
> "Acceptable 0.4". I also feel the IPR burden is too much on smaller 
> players implementing MCU's.
>
>> 2.
> While I don't like putting my faith with other companies when it comes 
> to IPR, I truly believe that Google will in good faith deal with any 
> IPR issues that arise in the future. I think the gamble is an 
> acceptable risk.
>
>> 3.
> While I still think the IPR on 264 is a burden, I think this is 
> acceptable with respect to the browser space. My only concern is this 
> option might just fragment/split the webrtc space with conforming and 
> non conforming implementations. If selected I full expect FOSS 
> implementations to be mostly VP8. With this said as long as the major 
> players (browsers) implement both, then any custom non conforming RTC 
> stack will still work in most cases.
>
> There is still 264 IPR issues on conforming MCU's that do any coding 
> tasks with the 264 data. There are also IPR issues related to 
> broadcasting and the sale of H.264 content, but those are obviously 
> outside the scope of this discussion.
>
>> 4.
> There is still 264 IPR issues on MCU's that do any coding tasks with 
> the 264 data. There are also IPR issues related to broadcasting and 
> the sale of H.264 content, but those are obviously outside the scope 
> of this discussion.
>
>> 5.
> This only makes sense if we want to 'see who wins'. Given the division 
> amongst many people I suspect we would see more 244 xor VP8 
> implementations then ones with both.
>
>> 6.
> If no consensus is made on any other option then I see no other 
> choice. This group needs to move forward at some point.
>
>> 8.
> As far as I am aware 263 still has IPR issues. This just forces 
> compliant stacks into a possible IPR violation issue.
>
>>12.
> While I think the risk of an IPR suite for disturbing a H.264 decoder 
> is small, I would not put it past some NPE popping up and forcing you 
> to visit that lovely court in Texas. The visit alone would put any 
> small player instantly out of business assuming they did not 'pay the 
> fee'. This option in a IETF spec just makes it that much easier for a 
> NPE or IPR holder to select targets.
>
>>13.
> Possible IPR issues. Not a modern codec. (I understand VP8 and 264 are 
> not modern codecs per say, but at least they are 'more' modern than 263).
>
>>14.
> Theora is a better quality codec than 261, and does not have any 
> possible IPR issues that 263 has. I am not sure of the IPR status of 
> Theora, and I don't ever recall seeing someone sued for it. Then again 
> maybe there has never been a big enough target for anyone who thinks 
> they have IPR on Theora from coming forward. I would personally be 
> willing to take a risk on the much more than 263 or distributing a 264 
> decoder.
>
>>15.
> Maybe I have not had enough or had too much coffee today, but I don't 
> see the logic in this option at the moment.
>
>>16.
> I understand the need to enumerate all options, but this just has so 
> much FAIL attached to it. Do we really need interop with old Canon 
> network cams (lol)? On the positive side I think Firefox still 
> supports motion JEPG streaming as a relic from the Netscape 
> implementation back in 96 (or earlier). Kidding aside, this will be 
> way too bandwidth intensive to achieve good quality video.
>
>
>
>

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 17 Dec 2013 07:57:48 +1100

Percentage of agreement is what is call it. Higher is better.
Silvia.
 On 17 Dec 2013 07:17, "cowwoc" <[email-masked]> wrote:

> significance of X? Is the higher the number, the better? Does it imply that
> one Acceptable answer is more acceptable than another?
>
> Thanks,
> Gili
>
> Weighted opinions are purely mine, and not that of my employer. I am not
> taking Cisco's gift into consideration. While it is generous and useful for
> some, the license 'hack' forces the installation of the library on the end
> user machine/device. This is not feasible on some platforms.
>
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  No.
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
> "Acceptable 0.4". I also feel the IPR burden is too much on smaller players
> implementing MCU's.
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  Yes.
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
> to IPR, I truly believe that Google will in good faith deal with any IPR
> issues that arise in the future. I think the gamble is an acceptable risk.
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  Acceptable (0.3)
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
> option might just fragment/split the webrtc space with conforming and non
> conforming implementations. If selected I full expect FOSS implementations
> to be mostly VP8. With this said as long as the major players (browsers)
> implement both, then any custom non conforming RTC stack will still work in
> most cases.
>
> tasks with the 264 data. There are also IPR issues related to broadcasting
> and the sale of H.264 content, but those are obviously outside the scope of
> this discussion.
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  Acceptable (0.8)
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
>  There is still 264 IPR issues on MCU's that do any coding tasks with the
> 264 data. There are also IPR issues related to broadcasting and the sale of
> H.264 content, but those are obviously outside the scope of this discussion.
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  No
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
> amongst many people I suspect we would see more 244 xor VP8 implementations
> then ones with both.
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  No
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  Acceptable (0.1)
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
>  If no consensus is made on any other option then I see no other choice.
> This group needs to move forward at some point.
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  Acceptable (0.3)
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  Acceptable (0.2)
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  Acceptable (0.4)
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  No.
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
>    1. All entities MUST support decoding using both H.264 and VP8, and
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  No.
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
>  While I think the risk of an IPR suite for disturbing a H.264 decoder is
> small, I would not put it past some NPE popping up and forcing you to visit
> that lovely court in Texas. The visit alone would put any small player
> instantly out of business assuming they did not 'pay the fee'. This option
> in a IETF spec just makes it that much easier for a NPE or IPR holder to
> select targets.
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  No
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  Acceptable (0.6)
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
> maybe there has never been a big enough target for anyone who thinks they
> have IPR on Theora from coming forward. I would personally be willing to
> take a risk on the much more than 263 or distributing a 264 decoder.
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  No
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
>     1. Are you in favor of this option [Yes/No/Acceptable]:
>
>
>  No No No.
>
>
>     1.
>        2. Do you have any objections to this option, if so please
>       summarize them:
>
>
> much FAIL attached to it. Do we really need interop with old Canon network
> cams (lol)? On the positive side I think Firefox still supports motion JEPG
> streaming as a relic from the Netscape implementation back in 96 (or
> earlier). Kidding aside, this will be way too bandwidth intensive to
> achieve good quality video.
>
>
>
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: Steve McFarlin <[email-masked]>
Date: Mon, 16 Dec 2013 13:20:12 -0800

I am sorry. I was not sure if I should weight my Acceptable answers or not. Basically Yes = 1.0 and No = 0. Higher weight is 'better'. I should probably just have included my objections and not added any extra info as this seems to have added noise to the process. My apologies. Chairs please disregard my weights.

steve

On Dec 16, 2013, at 12:16 PM, cowwoc <[email-masked]> wrote:

> I know we're not supposed to reply directly to authors but I don't understand how to interpret Steve's answers...
> 
> Steve, can you please clarify what "Acceptable (X)" means? What is the significance of X? Is the higher the number, the better? Does it imply that one Acceptable answer is more acceptable than another?
> 
> Thanks,
> Gili
>

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 17 Dec 2013 08:22:21 +1100

I quite liked them. Gave me a feeling for how much you object. I
thought it would have been good for everyone to do it this way
actually. It would be easier to summarize in the end, too. But alas,
that boat has sailed. :-)
Silvia.

On Tue, Dec 17, 2013 at 8:20 AM, Steve McFarlin <[email-masked]> wrote:
> I am sorry. I was not sure if I should weight my Acceptable answers or not.
> Basically Yes = 1.0 and No = 0. Higher weight is 'better'. I should probably
> just have included my objections and not added any extra info as this seems
> to have added noise to the process. My apologies. Chairs please disregard my
> weights.
>
> steve
>
>
> Not all platforms expose access to a hardware or software encoder. If every
> feasible platform exposed H.264 API's then my reply would be "Acceptable
> 0.4". I also feel the IPR burden is too much on smaller players implementing
> MCU's.
>
> While I don't like putting my faith with other companies when it comes to
> IPR, I truly believe that Google will in good faith deal with any IPR issues
> that arise in the future. I think the gamble is an acceptable risk.
>
> While I still think the IPR on 264 is a burden, I think this is acceptable
> with respect to the browser space. My only concern is this option might just
> fragment/split the webrtc space with conforming and non conforming
> implementations. If selected I full expect FOSS implementations to be mostly
> VP8. With this said as long as the major players (browsers) implement both,
> then any custom non conforming RTC stack will still work in most cases.
>
> There is still 264 IPR issues on conforming MCU's that do any coding tasks
> with the 264 data. There are also IPR issues related to broadcasting and the
> sale of H.264 content, but those are obviously outside the scope of this
> discussion.
>
> There is still 264 IPR issues on MCU's that do any coding tasks with the 264
> data. There are also IPR issues related to broadcasting and the sale of
> If no consensus is made on any other option then I see no other choice. This
> group needs to move forward at some point.
>
> As far as I am aware 263 still has IPR issues. This just forces compliant
> stacks into a possible IPR violation issue.
>
> Possible IPR issues. Not a modern codec. (I understand VP8 and 264 are not
> modern codecs per say, but at least they are 'more' modern than 263).
>
> Theora is a better quality codec than 261, and does not have any possible
> IPR issues that 263 has. I am not sure of the IPR status of Theora, and I
> don't ever recall seeing someone sued for it. Then again maybe there has
> never been a big enough target for anyone who thinks they have IPR on Theora
> from coming forward. I would personally be willing to take a risk on the
> much more than 263 or distributing a 264 decoder.
>
> I understand the need to enumerate all options, but this just has so much
> FAIL attached to it. Do we really need interop with old Canon network cams
> (lol)? On the positive side I think Firefox still supports motion JEPG
> earlier). Kidding aside, this will be way too bandwidth intensive to achieve
> good quality video.
>
>
>
>

---

From: Gustavo Garcia <[email-masked]>
Date: Mon, 16 Dec 2013 13:22:59 -0800

No

Yes

No

> 4.  Browsers MUST support both H.264 and VP8, other entities MUST support
at

No

>         b. Do you have any objections to this option, if so please

3.b.

No

Acceptable

No

least one

Acceptable

Acceptable

Acceptable

Acceptable

No.

Yes

Acceptable

No

No

---

From: cowwoc <[email-masked]>
Date: Mon, 16 Dec 2013 16:24:44 -0500

Gustavo,

Did you forget to answer part "b" for all "No" answers? I noticed one 
answer referenced "3.b." but there is no such answer.

Gili

---

From: Gustavo Garcia <[email-masked]>
Date: Mon, 16 Dec 2013 14:24:38 -0800

I initially answered the b part of some of the alternatives but then I
realized that I was basically repeating the same things that other people
had said and I decided to just leave the straight answers to make it
simpler to read and to summarize.

---

From: cowwoc <[email-masked]>
Date: Mon, 16 Dec 2013 17:35:05 -0500

(Changing the subject line per Björn's request)

Gustavo,

For the same of completeness, can you please elaborate on why you voted 
"No" or "Acceptable" for options, even if it repeats points that others 
have brought up? It would help the rest of us understand your reasoning.

Thanks,
Gili

On 16/12/2013 5:24 PM, Gustavo Garcia wrote:
> realized that I was basically repeating the same things that other 
> people had said and I decided to just leave the straight answers to 
> make it simpler to read and to summarize.
>
>
>
> On Mon, Dec 16, 2013 at 1:24 PM, cowwoc <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Gustavo,
>
>     Did you forget to answer part "b" for all "No" answers? I noticed
>     one answer referenced "3.b." but there is no such answer.
>
>     Gili
>
>
>>     > 4.  Browsers MUST support both H.264 and VP8, other entities
>>     MUST support at
>>
>>     > 8.  All entities MUST support H.261 and all entities MUST
>>     support at least one
>>     >     of H.264 and VP8

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Dec 2013 00:26:19 +0100

On 12/16/2013 10:20 PM, Steve McFarlin wrote:
> I am sorry. I was not sure if I should weight my Acceptable answers or 
> not. Basically Yes = 1.0 and No = 0. Higher weight is 'better'. I 
> should probably just have included my objections and not added any 
> extra info as this seems to have added noise to the process. My 
> apologies. Chairs please disregard my weights.

I actually liked the weights. They give ranking information, which is 
important. I think I'll add some to my reply to the poll (in preparation).

What I don't like is having followups to poll answers without changing 
the subject - this makes the actual poll answers harder to find.

Sorry to be a PITA about this.

>
> steve
>
> On Dec 16, 2013, at 12:16 PM, cowwoc <[email-masked] 
>> Steve, can you please clarify what "Acceptable (X)" means? What is 
>> the significance of X? Is the higher the number, the better? Does it 
>> imply that one Acceptable answer is more acceptable than another?
>>
>> Thanks,
>> Gili
>>
>>> Not all platforms expose access to a hardware or software encoder. 
>>> If every feasible platform exposed H.264 API's then my reply would 
>>> be "Acceptable 0.4". I also feel the IPR burden is too much on 
>>> smaller players implementing MCU's.
>>>
>>>> 2.
>>> While I don't like putting my faith with other companies when it 
>>> comes to IPR, I truly believe that Google will in good faith deal 
>>> with any IPR issues that arise in the future. I think the gamble is 
>>> an acceptable risk.
>>>
>>>> 3.
>>> acceptable with respect to the browser space. My only concern is 
>>> this option might just fragment/split the webrtc space with 
>>> conforming and non conforming implementations. If selected I full 
>>> expect FOSS implementations to be mostly VP8. With this said as long 
>>> as the major players (browsers) implement both, then any custom non 
>>> conforming RTC stack will still work in most cases.
>>>
>>> This only makes sense if we want to 'see who wins'. Given the 
>>> division amongst many people I suspect we would see more 244 xor VP8 
>>>>     All entities MUST support decoding using both H.264 and VP8,
>>>>     and MUST support encoding using at least one of H.264 or VP8
>>>>     1.
>>> While I think the risk of an IPR suite for disturbing a H.264 
>>> decoder is small, I would not put it past some NPE popping up and 
>>> forcing you to visit that lovely court in Texas. The visit alone 
>>> would put any small player instantly out of business assuming they 
>>> did not 'pay the fee'. This option in a IETF spec just makes it that 
>>> much easier for a NPE or IPR holder to select targets.
>>>
>>>>13.
>>> Possible IPR issues. Not a modern codec. (I understand VP8 and 264 
>>> are not modern codecs per say, but at least they are 'more' modern 
>>> than 263).
>>>
>>>>14.
>>> Theora, and I don't ever recall seeing someone sued for it. Then 
>>> again maybe there has never been a big enough target for anyone who 
>>> thinks they have IPR on Theora from coming forward. I would 
>>> personally be willing to take a risk on the much more than 263 or 
>>> distributing a 264 decoder.
>>>
>>>>15.
>>> Maybe I have not had enough or had too much coffee today, but I 
>>> don't see the logic in this option at the moment.
>>>
>>>>16.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Dec 2013 09:26:25 +0100

On 2013-12-16 23:24, Gustavo Garcia wrote:
> people had said and I decided to just leave the straight answers to make
> it simpler to read and to summarize.

Although it makes it easier to enter, as a Chair I do request that if
you are comfortable with it include the objections that you have. That
way we can potentially identify if any alternative has a much greater
chance to reach consensus based on your objections.

Thanks

Magnus

-- 

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Dec 2013 12:17:28 +0100

*

Some introduction:

*

I think this is a difficult poll to answer, and even harder to analyze
responses for. There are multiple considerations here, and different
evaluations of those considerations.

My primary consideration is that we want a vibrant WebRTC ecosystem.

To reach that state, I think it is important that entities without the
ability to do licensing deals can become first class citizens of the
ecosystem - that's why a royalty free video codec is important.

I also think that having a good quality video experience in all cases is
important. A bad quality video will in many (most?) cases be better than
no video. Having a consistently good video quality is even better - but
I don't think that's as vital.

In many cases, there's doubt. Especially about IPR risk. That's hard to
quantify.

I've chosen to adopt Steve McFarlin's "weight" number on my "acceptable"
alternatives - ranging from 0.1 to 0.9 - 1.0 would be "Yes", 0.0 would
be "No".

This message is sent in HTML mail - apologies to those who see it as
broken formatting. A PDF version is attached "just in case".

*

**

 1.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: NO

     2.

         1.

            This option locks the entire ecosystem into the MPEG-LA
            licensing scheme. This is harmful for the development of the
            ecosystem.

 2.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: YES

     2.

 3.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: ACCEPTABLE

     2.

         1.

            0.7. This option locks the ecosystem into the MPEG-LA
            licensing scheme, but the inclusion of a royalty-free
            alternative means that entities that do not claim
            conformance can leave out H.264, and still be members of the
            ecosystem; therefore, the harm to the ecosystem is less than
            a pure H.264 MTI.

 4.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: ACCEPTABLE

     2.

         1.

            0.5 This locks the browser part of the ecosystem into the
            MPEG-LA licensing scheme. The current large browser vendors
            (Apple, Microsoft, Google, Mozilla) all have current or
            planned strategies for H.264 licensing agreements - H.264
            licensing fees are not an issue for them (including the
            Cisco/Mozilla alliance). This option allows other entities
            to claim conformance while still communicating with the
            browser ecosystem; it is therefore less objectionable than
            3, but still gets a lower score because the inconsistent
            requirements allow some cases of interoperability failure.
             It does require new browsers to find a way to live with
            H.264 licensing in order to claim conformance.

 5.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: NO

     2.

         1.

            This option does not give interoperability.

 6.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: NO

     2.

         1.

            While H.261 is presumably royalty free, the quality impact
            is high enough to isolate baseline codec users from the
            ecosystem.

 7.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: NO

     2.

         1.

            This fails to achieve interoperability.

 8.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: ACCEPTABLE

     2.

         1.

            0.3 This achieves very limited interoperability between high
            quality islands, but will allow a high quality ecosystem to
            evolve, even if islanded, and is therefore less
            objectionable than the pure "H.261 as MTI" alternative.

 9.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: NO

     2.

         1.

            The IPR and quality properties of this codec are not
            different enough from those of VP8 to make it an
            "alternative that makes a difference"; the IPR status is
            approximately equal, and the quality is definitely worse.

10.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: ACCEPTABLE

     2.

         1.

            0.4 This achieves very limited interoperability between high
            quality islands, but will allow a high quality ecosystem to
            evolve. In contrast to 8, this allows entities without H.261
            to claim conformance.

11.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: ACCEPTABLE

     2.

         1.

            0.2 This achieves limited interoperability at a slightly
            higher quality level than with H.261, but at the cost of
            some IPR risk. It allows a high quality ecosystem to evolve.

12.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: ACCEPTABLE

     2.

         1.

            0.4 It is not clear what the implication of this alternative is.

13.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: NO

     2.

         1.

            0.2 H.263 raises some IPR risk, but gives better quality
            interoperation than H.261.

14.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: ACCEPTABLE

     2.

         1.

            0.3 This achieves limited interoperability at a reasonable
            quality, but the advantage of including Theora in the mix
            seems limited in terms of reassuring people with IPR worries.

15.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: NO

     2.

         1.

            This alternative does not give interoperability, since it
            doesn't have an MTI encoder.

16.

     1.

        Are you in favor of this option [Yes/No/Acceptable]: NO

     2.

         1.

            The same logic as for 6 applies. In addition, the bitrate
            shown for MJPEG is appallingly high for any reasonable quality.

*

---

From: David Singer <[email-masked]>
Date: Wed, 18 Dec 2013 08:51:27 -0800

> 
> 1..        All entities MUST support H.264

Yes

> 2..        All entities MUST support VP8

No

>         b.         Do you have any objections to this option, if so please summarize them:

VP8 has a formal declaration of unlicensable IPR, https://ietf.org/ipr/2035/  .

No

>         b.         Do you have any objections to this option, if so please summarize them:

VP8 has a formal declaration of unlicensable IPR, https://ietf.org/ipr/2035/  .

No

>         b.         Do you have any objections to this option, if so please summarize them:

VP8 has a formal declaration of unlicensable IPR, https://ietf.org/ipr/2035/  .
Also, ‘browser’ is ill-defined, and it is not correct to try to divide the world in this way.

Yes

No

>         b.         Do you have any objections to this option, if so please summarize them:

Few have H.261 implemented any more, and those that don’t, will not implement to comply with this requirement.

Acceptable.

No

>         b.         Do you have any objections to this option, if so please summarize them:

Few have H.261 implemented any more, and those that don’t, will not implement to comply with this requirement.

No

>         b.         Do you have any objections to this option, if so please summarize them:

Theora is not ‘current’, it has an unclear license situation, is poorly supported in hardware.

No

>         b.         Do you have any objections to this option, if so please summarize them:

Few have H.261 implemented any more, and those that don’t, will not implement to comply with this requirement.
VP8 has a formal declaration of unlicensable IPR, https://ietf.org/ipr/2035/  .

Yes

No

>         b.         Do you have any objections to this option, if so please summarize them:

VP8 has a formal declaration of unlicensable IPR, https://ietf.org/ipr/2035/  .

Yes

No

>         b.         Do you have any objections to this option, if so please summarize them:

Theora is not ‘current’, it has an unclear license situation, is poorly supported in hardware.
VP8 has a formal declaration of unlicensable IPR, https://ietf.org/ipr/2035/  .

No

>         b.         Do you have any objections to this option, if so please summarize them:

Theora is not ‘current’, it has an unclear license situation, is poorly supported in hardware.

Acceptable

David Singer

---

From: David Singer <[email-masked]>
Date: Wed, 18 Dec 2013 11:31:32 -0800

I should say I only put in the ‘negative’ statements here, not reasons to say ‘yes’, since only objections were requested.

For example, why is Motion JPEG OK but 261 not?  Because MJPEG is I-frame only, one can send reasonable visual quality at low frame rates, and the user is aware of the other end and that the system works, and systems all have JPEG implemented today, and the RTP format is not complex to add.

David Singer

---

From: Adam Roach <[email-masked]>
Date: Wed, 18 Dec 2013 13:47:13 -0600

> For example, why is Motion JPEG OK but 261 not?  Because MJPEG is I-frame only, one can send reasonable visual quality at low frame rates, and the user is aware of the other end and that the system…

Thanks for the clarification. I was really scratching my head over that 
one. I think you and I differ in what we consider "usable," but at least 
your reasoning makes sense to me now.

/a

---

From: Mohammed Raad <[email-masked]>
Date: Thu, 19 Dec 2013 07:56:16 +1100

David,

Is it your understanding that Nokia is unwilling to license the patents
they have listed in the declaration that you refer to and so you repeatedly
say that VP8 has unlicensable IPR?

My understanding is that they are not willing to license under the options
provided on the form, not that they are unwilling to license.

Mohammed
On Dec 19, 2013 6:31 AM, "David Singer" <[email-masked]> wrote:

> I should say I only put in the ‘negative’ statements here, not reasons to
> say ‘yes’, since only objections were requested.
>
> For example, why is Motion JPEG OK but 261 not?  Because MJPEG is I-frame
> only, one can send reasonable visual quality at low frame rates, and the
> user is aware of the other end and that the system works, and systems all
> have JPEG implemented today, and the RTP format is not complex to add.
>
> MUST support at least one of H.264 and VP8
> > Few have H.261 implemented any more, and those that don’t, will not
> implement to comply with this requirement.
> >
> > Few have H.261 implemented any more, and those that don’t, will not
> implement to comply with this requirement.
> >
> > Few have H.261 implemented any more, and those that don’t, will not
> implement to comply with this requirement.
> >> 12.       All entities MUST support decoding using both H.264 and VP8,

---

From: David Singer <[email-masked]>
Date: Wed, 18 Dec 2013 13:01:09 -0800

I guess you may be formally right;  I was being terse.  But looking at the options:

	• a) No License Required for Implementers.
	•  b) Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers.
	•  c) Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee.
	•  d) Licensing Declaration to be Provided Later (implies a willingness to commit to the provisions of a), b), or c) above to all implementers; otherwise, the next option "Unwilling to Commit to the Provisions of a), b), or c) Above". - must be selected).
	•  e) Unwilling to Commit to the Provisions of a), b), or c) Above.
	•  f) See Text Below for Licensing Declaration.

They did not offer (d) or (f), either of which would suggest that some other license was available or forthcoming.  So, we’re left with the possibility that there is a future license which is not RF, not RAND. I suppose that’s logically possible, but whether a hypothetical future license that is unreasonable, or discriminatory, or both, is useful to this discussion I am less sure.

I am not a lawyer, and I agree I was being terse.

On Dec 18, 2013, at 12:56 , Mohammed Raad <[email-masked]> wrote:

> David,
> 
> Is it your understanding that Nokia is unwilling to license the patents they have listed in the declaration that you refer to and so you repeatedly say that VP8 has unlicensable IPR?
> 
> My understanding is that they are not willing to license under the options provided on the form, not that they are unwilling to license.
> 
> Mohammed
> 

David Singer

---

From: Mohammed Raad <[email-masked]>
Date: Thu, 19 Dec 2013 08:48:51 +1100

I think that there is a relevant, although subtle, point here.

This declaration has been used repeatedly as "evidence" that VP8 has a
problematic IPR situation. But has the question of whether or not Nokia is
willing to license under terms it considers suitable been asked and/or
answered?

Afterall, unlike AVC/h264, VP8 has an active sponsoring entity that has put
in the effort and resources to secure a licensing agreement from multiple
other parties that offers the relevant technology under royalty free terms.

Of course such an approach would not be suitable if Nokia is unwilling to
license under any terms. If that is the case though, it is important for
this WG to be aware of that situation, to make sure an informed decision is
being made.

Mohammed
On Dec 19, 2013 8:01 AM, "David Singer" <[email-masked]> wrote:

>         •  d) Licensing Declaration to be Provided Later (implies a
> willingness to commit to the provisions of a), b), or c) above to all
> implementers; otherwise, the next option "Unwilling to Commit to the
> Provisions of a), b), or c) Above". - must be selected).
> They did not offer (d) or (f), either of which would suggest that some
> other license was available or forthcoming.  So, we’re left with the
> possibility that there is a future license which is not RF, not RAND. I
> suppose that’s logically possible, but whether a hypothetical future
> license that is unreasonable, or discriminatory, or both, is useful to this
> discussion I am less sure.
>
> > My understanding is that they are not willing to license under the
> options provided on the form, not that they are unwilling to license.
> >
> > Mohammed
> >
> > I should say I only put in the ‘negative’ statements here, not reasons
> to say ‘yes’, since only objections were requested.
> >
> > For example, why is Motion JPEG OK but 261 not?  Because MJPEG is
> I-frame only, one can send reasonable visual quality at low frame rates,
> and the user is aware of the other end and that the system works, and
> systems all have JPEG implemented today, and the RTP format is not complex
> to add.
> >
> > >> 12.       All entities MUST support decoding using both H.264 and
> VP8, and MUST support encoding using at least one of H.264 or VP8

---

From: David Singer <[email-masked]>
Date: Wed, 18 Dec 2013 14:14:23 -0800

I just go by what is formally declared.  If you think Nokia can or will make a clearer, or more nuanced, or different, declaration, then of course you may encourage them to do so.

As it stands, I am reading what is written.

>         •  b) Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers.

And it’s clear we don’t have them in this case.  Or do you imagine something other than (a) or (b) that would formally satisfy the MTI need?

On Dec 18, 2013, at 13:48 , Mohammed Raad <[email-masked]> wrote:

> This declaration has been used repeatedly as "evidence" that VP8 has a problematic IPR situation. But has the question of whether or not Nokia is willing to license under terms it considers suitable been asked and/or answered?
> 
> Afterall, unlike AVC/h264, VP8 has an active sponsoring entity that has put in the effort and resources to secure a licensing agreement from multiple other parties that offers the relevant technology under royalty free terms.
> 
> Of course such an approach would not be suitable if Nokia is unwilling to license under any terms. If that is the case though, it is important for this WG to be aware of that situation, to make sure an informed decision is being made.
> 
> Mohammed
> 

David Singer

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 18 Dec 2013 17:19:04 -0500

RS>  YES 

b.     Do you have any objections to this option, if so please summarize
them:

RS> Acceptable

b.     Do you have any objections to this option, if so please summarize
them:

RS> Acceptable

b.     Do you have any objections to this option, if so please summarize
them:

1.     Browsers MUST support both H.264 and VP8, other entities MUST support
at least one of H.264 and VP8

RS> Acceptable leaning strongly to YES. 

b.     Do you have any objections to this option, if so please summarize
them:

RS> Yes - At the very least one or the other preferably both. 

b.     Do you have any objections to this option, if so please summarize
them:

RS> NO

b.     Do you have any objections to this option, if so please summarize
them:

RS> Not efficient on the wire by any reasonable operational standard. 

RS> NO

b.     Do you have any objections to this option, if so please summarize
them:

RS> A decision of no MTI codec impedes interoperability and ultimately IMHO
dooms the entire project.  

1.     All entities MUST support H.261 and all entities MUST support at
least one of H.264 and VP8

RS> NO 

b.     Do you have any objections to this option, if so please summarize
them:

RS> leave H.261 out of this. 

RS> NO

b.     Do you have any objections to this option, if so please summarize
them:

RS> NO

b.     Do you have any objections to this option, if so please summarize
them:

Either VP8 or 264 but not one of 3.  I object to the inclusion of H 261 as
unacceptable. 

RS> YES but not if 261 is included. 

b.     Do you have any objections to this option, if so please summarize
them:

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

RS> YES

b.     Do you have any objections to this option, if so please summarize
them:

RS> NO <sigh> 

b.     Do you have any objections to this option, if so please summarize
them:

RS> NO 

b.     Do you have any objections to this option, if so please summarize
them:

No more than 2. 

RS> NO

b.     Do you have any objections to this option, if so please summarize
them:

RS> NO as in NEVER. 

b.     Do you have any objections to this option, if so please summarize
them:

Thanks,

The Chairs

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 18 Dec 2013 23:47:14 +0000

My gosh.  Nokia has people at the IETF, and they made statements and have not minced words.  Nor did they in MPEG.  Come on, leave these meta arguments for the lawyers.
Stephan

From: Mohammed Raad <[email-masked]<mailto:[email-masked]>>
Date: Thu, 19 Dec 2013 08:48:51 +1100
To: Dave Singer <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Richard Barnes <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Straw Poll on Video Codec Alternatives

Mohammed

On Dec 19, 2013 8:01 AM, "David Singer" <[email-masked]<mailto:[email-masked]>> wrote:
I guess you may be formally right;  I was being terse.  But looking at the options:

On Dec 18, 2013, at 12:56 , Mohammed Raad <[email-masked]<mailto:[email-masked]>> wrote:

> On Dec 19, 2013 6:31 AM, "David Singer" <[email-masked]<mailto:[email-masked]>> wrote:
> On Dec 18, 2013, at 8:51 , David Singer <[email-masked]<mailto:[email-masked]>> wrote:
>
> >>

David Singer

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

---

From: Ron <[email-masked]>
Date: Thu, 19 Dec 2013 14:00:01 +1030

Please people, changing the subject for side discussions like the Chairs
requested isn't rocket science ...

On Wed, Dec 18, 2013 at 11:47:14PM +0000, Stephan Wenger wrote:
> My gosh.  Nokia has people at the IETF, and they made statements
> and have not minced words.

They also have people making statements in the courts, where they
seem to be getting, well, thoroughly minced!

The interesting question isn't Nokia's intention here, I don't think
anyone seriously doubts what it is.  The interesting questions are
twofold:

 a) Do they even have the slimmest leg to stand on with their claims
    against VP8?  There's so far no supporting evidence to say that
    they do, and plenty stacking up against them.

 b) Given their stubborn refusal to make any declaration about their
    intentions or IPR for H.264 here, does anybody have even the
    slightest idea what their terms are for licencing the Cisco blob?

Meritorious or meretricious, the devil is in such little details.

  Ron

---

From: Mohammed Raad <[email-masked]>
Date: Thu, 19 Dec 2013 17:44:51 +1100

Correct on changing the subject line, this really started as a
clarification question and then grew, sorry.

What is relevant to the straw poll thread is that we should have a correct
summary of where the IPR situation really is.

It has been pointed out that the MTI should satisfy options a) or b) on the
ietf declaration form. As matters stand AVC/h264 does not satisfy that,
this has been made very clear through the ISO process. On the other hand,
VP8 has so far withstood court challenges, as you point out - something
which AVC could not BTW - and the technology owning entities willing to
license VP8 relevant technology under the required royalty free terms has
grown significantly during the past year.

It would seem very clear that the codec that is closer to the royalty free
ideal situation is VP8.

As such, it is surprising to see AVC proponents opposing the adoption of
VP8, even as one of two MTI codecs - something that VP8 proponents appear
to be saying is acceptable - based on IPR arguments.

If members of this WG wish to move towards a compromise that allows webrtc
to fulfill the potential that it has then this is their opportunity. I
certainly encourage them to take this opportunity.

Mohammed

  Ron

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 19 Dec 2013 17:50:00 +1100

I think the biggest problem is that people only want to maintain code
for one codec. If you already have H.264 support implemented, you will
oppose every other codec, no matter how big the advantages.
Therefore, a compromise is not possible with such a position.

Silvia.

On Thu, Dec 19, 2013 at 5:44 PM, Mohammed Raad
<[email-masked]> wrote:
> Correct on changing the subject line, this really started as a clarification
> question and then grew, sorry.
>
> ietf declaration form. As matters stand AVC/h264 does not satisfy that, this
> has been made very clear through the ISO process. On the other hand, VP8 has
> so far withstood court challenges, as you point out - something which AVC
> could not BTW - and the technology owning entities willing to license VP8
> relevant technology under the required royalty free terms has grown
> significantly during the past year.
>
> VP8, even as one of two MTI codecs - something that VP8 proponents appear to
> be saying is acceptable - based on IPR arguments.
>

---

From: Mohammed Raad <[email-masked]>
Date: Thu, 19 Dec 2013 18:32:02 +1100

Well, many of those same people saying that they only want to maintain one
codec have been more than willing to keep on developing new standardized
codecs and to pile on profiles, which, in many practical situations means
different code bases.

A compromise, by definition, is taking what one can get, which simply has
to be acceptable and may not match what one was aiming for.

What members of this WG have been saying, and writing, is that they want
interoperability. OK, so that can be achieved with at least one of the
options in the straw poll that VP8 proponents have indicated is acceptable.
It would seem logical and reasonable to expect AVC proponents to take up
that option also. I started commenting when I noticed that was not
happening, which raised the question in my mind as to whether or not there
is an intention to achieve interoperability, or whether there were still
genuine misunderstandings wrt the IPR situation.

Best Regards,
Mohammed

On Thu, Dec 19, 2013 at 5:50 PM, Silvia Pfeiffer
<[email-masked]>wrote:

> this

-- 
Mohammed Raad, PhD.
Partner
RAADTECH CONSULTING
P.O. Box 113
Warrawong
NSW 2502 Australia
Phone: +61 414451478
Email: [email-masked]

---

From: Maik Merten <[email-masked]>
Date: Thu, 19 Dec 2013 08:59:35 +0100

>      they do, and plenty stacking up against them.

Also IMO it's quite clear that Nokia, having willfully voided their VP8 
license, would presumably file anything to block VP8 from becoming part 
of any standard they are interested in.  These "will not license" 
declarations are mandatory byproducts of tactics employed by some 
parties in the mobile platform wars (and I'm not merely looking at Nokia 
here).

This, of course, changes nothing regarding the fact that these 
declarations exist. However, for me, this impacts the credibility of 
said claims.

Maik

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 19 Dec 2013 10:48:53 +0100

> Therefore, a compromise is not possible with such a position.

Actually very few people are going to maintain code for only one codec.

This might have been seen as a possibility when we started this effort, 
but at the moment, it's clear that people will want to ship their 
favourite out of {H.265, VP9} in addition to whatever is agreed as MTI.

So at worst we're looking at increasing the support burden from 2 to 3. 
In many cases, I suspect that the delta is even less, because a lot of 
the people with "legacy" equipment are already supporting other "legacy" 
codecs.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 19 Dec 2013 12:37:30 +0000

FWIW - here is my input:

a.            Are you in favor of this option [Yes/No/Acceptable]:  Yes

a.            Are you in favor of this option [Yes/No/Acceptable]:  Acceptable

b.            Do you have any objections to this option, if so please summarize them: There are still unresolved IPR claims. Availability of a binary distribution would alleviate these concerns.

3.All entities MUST support both H.264 and VP8

a.            Are you in favor of this option [Yes/No/Acceptable]: Acceptable

b.            Do you have any objections to this option, if so please summarize them: There are still unresolved IPR claims on VP8. Availability of a binary distribution would alleviate these concerns

a.            Are you in favor of this option [Yes/No/Acceptable]: Acceptable

b.            Do you have any objections to this option, if so please summarize them: are still unresolved IPR claims on VP8. Availability of a binary distribution would alleviate these concerns

a.            Are you in favor of this option [Yes/No/Acceptable]: No

b.            Do you have any objections to this option, if so please summarize them: No interoperability

a.            Are you in favor of this option [Yes/No/Acceptable]: No

b.            Do you have any objections to this option, if so please summarize them: Unacceptable RT quality

a.            Are you in favor of this option [Yes/No/Acceptable]: No

b.            Do you have any objections to this option, if so please summarize them: No interoperability. This would change in 'Acceptable' if a videocodec WG is chartered immediately to develop an IPR-clean video codec specification, on the lines of the work done for the audio codec which resulted in OPUS, and the RTCWEB commits to adopt it as MTI codec

a.            Are you in favor of this option [Yes/No/Acceptable]: Acceptable

b.            Do you have any objections to this option, if so please summarize them: RT quality is not guaranteed

a.            Are you in favor of this option [Yes/No/Acceptable]: No

b.            Do you have any objections to this option, if so please summarize them: uncertain IPR status for Theora

a.            Are you in favor of this option [Yes/No/Acceptable]:  Acceptable

b.            Do you have any objections to this option, if so please summarize them: RT quality is not guaranteed

a.            Are you in favor of this option [Yes/No/Acceptable]: Acceptable

b.            Do you have any objections to this option, if so please summarize them: RT quality is not guaranteed

a.            Are you in favor of this option [Yes/No/Acceptable]: Acceptable

b.            Do you have any objections to this option, if so please summarize them: are still unresolved IPR claims on VP8.

a.            Are you in favor of this option [Yes/No/Acceptable]: No

b.            Do you have any objections to this option, if so please summarize them:  unacceptable RT quality

a.            Are you in favor of this option [Yes/No/Acceptable]:  Acceptable

b.            Do you have any objections to this option, if so please summarize them:  uncertain IPR status on Theora, there are still unresolved IPR claims on VP8.

a.            Are you in favor of this option [Yes/No/Acceptable]:  No

b.            Do you have any objections to this option, if so please summarize them:  uncertain IPR status on Theora

a.            Are you in favor of this option [Yes/No/Acceptable]: No

b.            Do you have any objections to this option, if so please summarize them: inefficient codec, high BW requirements, IPR issues

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Monday, December 09, 2013 7:25 PM
To: [email-masked]; Gonzalo Camarillo; Richard Barnes; Magnus Westerlund; Cullen Jennings
Subject: [rtcweb] Straw Poll on Video Codec Alternatives

Dear WG,

Thanks,

The Chairs

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Dec 2013 13:25:58 +0000

My input.

a.    Are you in favor of this option [Yes/No/Acceptable]: YES

.      Are you in favor of this option [Yes/No/Acceptable]: NO

a.    Do you have any objections to this option, if so please summarize them: Unclear IPR situation

.      Are you in favor of this option [Yes/No/Acceptable]: NO

a.    Do you have any objections to this option, if so please summarize them: One MTI codec is enough

.      Are you in favor of this option [Yes/No/Acceptable]: NO

a.    Do you have any objections to this option, if so please summarize them: I have seen no justification for distinguishing between browsers and non-browsers.

.      Are you in favor of this option [Yes/No/Acceptable]: YES

.      Are you in favor of this option [Yes/No/Acceptable]: NO

a.    Do you have any objections to this option, if so please summarize them: We shall look forward, not backward.

.      Are you in favor of this option [Yes/No/Acceptable]: YES

.      Are you in favor of this option [Yes/No/Acceptable]: NO

a.    Do you have any objections to this option, if so please summarize them: One MTI codec is enough

.      Are you in favor of this option [Yes/No/Acceptable]: NO

a.    Do you have any objections to this option, if so please summarize them: One MTI codec is enough

.      Are you in favor of this option [Yes/No/Acceptable]: NO

a.    Do you have any objections to this option, if so please summarize them: One MTI codec is enough

.      Are you in favor of this option [Yes/No/Acceptable]: NO

a.    Do you have any objections to this option, if so please summarize them: One MTI codec is enough

.      Are you in favor of this option [Yes/No/Acceptable]: Acceptable

a.    Do you have any objections to this option, if so please summarize them: Acceptable, even though I still think one MTI codec is enough

 .      Are you in favor of this option [Yes/No/Acceptable]: Acceptable

a.    Do you have any objections to this option, if so please summarize them: We can look a little backward, if really needed.

.      Are you in favor of this option [Yes/No/Acceptable]: NO

a.    Do you have any objections to this option, if so please summarize them: One MTI codec is enough

15.  All entities MUST support decoding using Theora

 .      Are you in favor of this option [Yes/No/Acceptable]: NO

a.    Do you have any objections to this option, if so please summarize them: Strange criteria (decoding only).

.      Are you in favor of this option [Yes/No/Acceptable]: Acceptable

a.    Do you have any objections to this option, if so please summarize them: May not work in resource restricted scenarios.

Regards,
Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Dec 2013 15:05:29 +0000

Just a small correction on question 9:

a.    Are you in favor of this option [Yes/No/Acceptable]: NO

b.    Do you have any objections to this option, if so please summarize them: Unclear IPR situation

From: rtcweb [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 19. joulukuuta 2013 15:26
To: Ted Hardie; [email-masked]; Gonzalo Camarillo; Richard Barnes; Magnus Westerlund; Cullen Jennings
Subject: Re: [rtcweb] Straw Poll on Video Codec Alternatives

My input.

a.    Are you in favor of this option [Yes/No/Acceptable]: NO

b.    Do you have any objections to this option, if so please summarize them: Unclear IPR situation

a.    Are you in favor of this option [Yes/No/Acceptable]: NO

b.    Do you have any objections to this option, if so please summarize them: One MTI codec is enough

a.    Are you in favor of this option [Yes/No/Acceptable]: NO

b.    Do you have any objections to this option, if so please summarize them: I have seen no justification for distinguishing between browsers and non-browsers.

a.    Are you in favor of this option [Yes/No/Acceptable]: NO

b.    Do you have any objections to this option, if so please summarize them: We shall look forward, not backward.

1.    Are you in favor of this option [Yes/No/Acceptable]: NO

2.    Do you have any objections to this option, if so please summarize them: One MTI codec is enough

2.    All entities MUST support Theora

1.    Are you in favor of this option [Yes/No/Acceptable]: NO

2.    Do you have any objections to this option, if so please summarize them: One MTI codec is enough

2.    All entities MUST implement at least two of {VP8, H.264, H.261}

a.    Are you in favor of this option [Yes/No/Acceptable]: NO

b.    Do you have any objections to this option, if so please summarize them: One MTI codec is enough

a.    Are you in favor of this option [Yes/No/Acceptable]: NO

b.    Do you have any objections to this option, if so please summarize them: One MTI codec is enough

b.    Do you have any objections to this option, if so please summarize them: Acceptable, even though I still think one MTI codec is enough

b.    Do you have any objections to this option, if so please summarize them: We can look a little backward, if really needed.

a.    Are you in favor of this option [Yes/No/Acceptable]: NO

b.    Do you have any objections to this option, if so please summarize them: One MTI codec is enough

1.    All entities MUST support decoding using Theora

a.    Are you in favor of this option [Yes/No/Acceptable]: NO

b.    Do you have any objections to this option, if so please summarize them: Strange criteria (decoding only).

b.    Do you have any objections to this option, if so please summarize them: May not work in resource restricted scenarios.

Regards,
Christer

---

From: cowwoc <[email-masked]>
Date: Thu, 19 Dec 2013 19:24:30 -0500

+1.

Every time I see someone voting YES for one option and NO for everything 
else (a pattern that keeps on repeating) I question whether they are 
genuinely looking for a compromise.

Gili

On 19/12/2013 2:32 AM, Mohammed Raad wrote:
> Well, many of those same people saying that they only want to maintain 
> one codec have been more than willing to keep on developing new 
> standardized codecs and to pile on profiles, which, in many practical 
> situations means different code bases.
>
> A compromise, by definition, is taking what one can get, which simply 
> has to be acceptable and may not match what one was aiming for.
>
> What members of this WG have been saying, and writing, is that they 
> want interoperability. OK, so that can be achieved with at least one 
> of the options in the straw poll that VP8 proponents have indicated is 
> acceptable. It would seem logical and reasonable to expect AVC 
> proponents to take up that option also. I started commenting when I 
> noticed that was not happening, which raised the question in my mind 
> as to whether or not there is an intention to achieve 
> interoperability, or whether there were still genuine 
> misunderstandings wrt the IPR situation.
>
> Best Regards,
> Mohammed
>
>
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
> Email: [email-masked] <mailto:[email-masked]>
>
>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 20 Dec 2013 03:34:43 +0000

I am answering this straw poll under protest based on my earlier objections to the poll.

In addition, I believe the poll is flawed due to the lack of direct participation by the legal departments that are actually driving this decision.

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: There are entities that are unable to comply with the license terms around H.264

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: There are entities that are unable to accept the legal risk of shipping VP8

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: There are entities that are unable to comply with the license terms around H.264 and there are entities that are unable to accept the legal risk of shipping VP8

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: There are entities that are unable to comply with the license terms around H.264 and there are entities that are unable to accept the legal risk of shipping VP8. Additionally I am not comfortable trying to define "browsers"

     *   Are you in favor of this option [Yes/No/Acceptable]: Barely acceptable

     *   Do you have any objections to this option, if so please summarize them: There appear to be no entities that are prevented from shipping one of these at this time based on the responses I have seen, however we may find at a future time that this is not true. It also will be meaningless at a future time when a new codec comes along that is in all ways superior. I also believe that it will be reasonable to have "audio-only WebRTC devices", and those obviously won't want to ship either codec.

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: Old inefficient codec. No reason to be forced to carry the cost of having this code.

     *   Are you in favor of this option [Yes/No/Acceptable]: YES

     *   Do you have any objections to this option, if so please summarize them: All of my other objections are remedied by this option. Additionally, this entire straw poll is flawed in that the technical community is answering on behalf of their respective legal departments, who are not present for the discussion.

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: Old inefficient codec. No reason to be forced to carry the cost of having this code

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: Old inefficient codec. No reason to be forced to carry the cost of having this code. Also unclear IPR issues around this codec.

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: H.261 is an Old inefficient codec. No reason to be forced to carry the cost of having this code.

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: H.263 is an older, less efficient codec but still has IPR issues that some entities will not be able to meet. There are few entities that can meet this by shipping VP8 and H.264.

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: At this time I am not convinced that there is a way for all entities to comply with the decoding requirement.

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: Older less-efficient codec, IPR issues.

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: Code cost and IPR risk of carrying Theora, impossibility of complying by shipping VP8 and H.264 for almost all entities.

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: Code cost and IPR risk of carrying Theora. Also my understanding of Theora is that there is no separate smaller decoder-only codebase.

     *   Are you in favor of this option [Yes/No/Acceptable]: NO

     *   Do you have any objections to this option, if so please summarize them: Codec does not provide sufficient quality at reasonable bandwidth for any use case.

---

From: cowwoc <[email-masked]>
Date: Fri, 20 Dec 2013 01:17:06 -0500

Hi,

You bring up a good point: at least 50% of this decision is legal in 
nature, yet no one bothered consulting a lawyer. Personally I think that 
people care more about the politics than legality, but still...

Is there any precedence in IETF or W3C for consulting with lawyers in 
order to make a more informed decision?

Gili

On 19/12/2013 10:34 PM, Matthew Kaufman (SKYPE) wrote:
> In addition, I believe the poll is flawed due to the lack of direct 
> participation by the legal departments that are actually driving this 
> decision.
>
>
> 1.
>
>         summarize them: There are entities that are unable to comply
>         with the license terms around H.264
>
> 2.
>
>         summarize them: There are entities that are unable to accept
>         the legal risk of shipping VP8
>
> 3.
>
>         summarize them: There are entities that are unable to comply
>         with the license terms around H.264 and there are entities
>         that are unable to accept the legal risk of shipping VP8
>
> 4.
>
>         summarize them: There are entities that are unable to comply
>         with the license terms around H.264 and there are entities
>         that are unable to accept the legal risk of shipping VP8.
>         Additionally I am not comfortable trying to define "browsers"
>
> 5.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Barely
>         acceptable
>
>     2.
>
>         summarize them: There appear to be no entities that are
>         prevented from shipping one of these at this time based on the
>         responses I have seen, however we may find at a future time
>         that this is not true. It also will be meaningless at a future
>         time when a new codec comes along that is in all ways
>         superior. I also believe that it will be reasonable to have
>         "audio-only WebRTC devices", and those obviously won't want to
>         ship either codec.
>
> 6.
>
>         summarize them: Old inefficient codec. No reason to be forced
>         to carry the cost of having this code.
>
> 7.
>
>         summarize them: All of my other objections are remedied by
>         this option. Additionally, this entire straw poll is flawed in
>         that the technical community is answering on behalf of their
>         respective legal departments, who are not present for the
>         discussion.
>
> 8.
>
>         summarize them: Old inefficient codec. No reason to be forced
>         to carry the cost of having this code
>
> 9.
>
>         summarize them: Old inefficient codec. No reason to be forced
>         to carry the cost of having this code. Also unclear IPR issues
>         around this codec.
>
>10.
>
>         summarize them: H.261 is an Old inefficient codec. No reason
>         to be forced to carry the cost of having this code.
>
>11.
>
>         summarize them: H.263 is an older, less efficient codec but
>         still has IPR issues that some entities will not be able to
>         meet. There are few entities that can meet this by shipping
>         VP8 and H.264.
>
>12.
>
>         summarize them: At this time I am not convinced that there is
>         a way for all entities to comply with the decoding requirement.
>
>13.
>
>         summarize them: Older less-efficient codec, IPR issues.
>
>14.
>
>         summarize them: Code cost and IPR risk of carrying Theora,
>         impossibility of complying by shipping VP8 and H.264 for
>         almost all entities.
>
>15.
>
>         summarize them: Code cost and IPR risk of carrying Theora.
>         Also my understanding of Theora is that there is no separate
>         smaller decoder-only codebase.
>
>16.
>
>         summarize them: Codec does not provide sufficient quality at
>         reasonable bandwidth for any use case.
>
>
>
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Dec 2013 08:38:22 +0100

>> participation by the legal departments that are actually driving this

Matthew and Gili,

Matthew, there are no restrictions preventing anyone's legal department
to provide input directly into this straw poll, it is open to anyone.
Will you encourage Skype's legal department to provide an input to the poll?

I would also hope that the WG participants have consulted with their
respective legal counsel in regards to the licensing and other questions
of legal nature they may have when determining how to answer this straw
poll.

Gili, can you be more precise in your question regarding IETF consulting
lawyers? I know IETF has legal counsel, but that is used to avoid that
IETF as an organization does not create illegal working process etc. The
legal counsel is to my knowledge not available for IETF participants to
answer their questions in regards to standardization questions of
technical nature. One reason for this is clearly economical. I can also
see that there would be many other reasons, for example the client role,
the question of what jurisdictions that are of interest. Thus each
participant would need its own legal counsel if needed.

Cheers

Magnus Westerlund
(As one of the WG chairs)

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Dec 2013 09:30:45 +0100

On 12/20/2013 01:24 AM, cowwoc wrote:
> +1.
>
> Every time I see someone voting YES for one option and NO for 
> everything else (a pattern that keeps on repeating) I question whether 
> they are genuinely looking for a compromise.

Just as a matter of truth-in-advertising:

So far (19 positions that I've noticed) there have been no opinion 
statements (I don't want to use the word "vote", since the chairs have 
called for an opinion poll) with 15 NO positions. There have been (by my 
count) 8 opinion statements with a single YES position, and 7 opinion 
statements with 10 or more NO positions, but there isn't a single 
statement with YES for one option and NO for everything else.

(Roman comes close with one ACCEPTABLE and everything else NO ... well 
played!)

The division is pretty clear, and pretty sharp, but it's not 
*completely* black and white.

>> Well, many of those same people saying that they only want to 
>> maintain one codec have been more than willing to keep on developing 
>> new standardized codecs and to pile on profiles, which, in many 
>> practical situations means different code bases.
>>
>> of the options in the straw poll that VP8 proponents have indicated 
>> is acceptable. It would seem logical and reasonable to expect AVC

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Dec 2013 09:40:01 +0100

On 12/20/2013 07:17 AM, cowwoc wrote:
> nature, yet no one bothered consulting a lawyer. Personally I think 
> that people care more about the politics than legality, but still...

I believe that lawyers have been consulted. But I'd be surprised to see 
anyone quoting their lawyer's advice verbatim in public, for multiple 
reasons.

The tradition of the IETF is that participants speak for themselves; it 
is not the tradition of the IETF to bring in those who you consult in 
order to have them speak on your behalf (except when filing IPR statements).

---

From: Peter Dunkley <[email-masked]>
Date: Fri, 20 Dec 2013 14:35:09 +0000

Acceptable
> b. Do you have any objections to this option, if so please summarize them:
Yes, I am concerned about the difficulty (in terms of licensing) of using
H.264 on iOS, Windows Mobile, and similar platforms as the Cisco binary
will not be usable in all cases.

Yes
No

Acceptable
> b. Do you have any objections to this option, if so please summarize them:
Yes, I am concerned about the difficulty (in terms of licensing) of using
H.264 on iOS, Windows Mobile, and similar platforms as the Cisco binary
will not be usable in all cases.

Yes
No

No
> b. Do you have any objections to this option, if so please summarize them:
Yes, this will not ensure interoperability which is the whole point of an
MTI codec.

No
> b. Do you have any objections to this option, if so please summarize them:
Yes, as time goes on people will move away from H.264 and VP8 for better
performing codecs. It would seem pointless to start off with such an old
one.

No
> b. Do you have any objections to this option, if so please summarize them:
Yes, interoperability is important and an MTI video codec will be needed
for this.

Acceptable
> b. Do you have any objections to this option, if so please summarize them:
Yes, I don't like the idea of falling back to H.261 but this at least means
there a good chance of a better codec being selected.

No
> b. Do you have any objections to this option, if so please summarize them:
Yes, as time goes on people will move away from H.264 and VP8 for better
performing codecs. It would seem pointless to start off with such an old
one.

Acceptable
> b. Do you have any objections to this option, if so please summarize them:
Yes, I don't like the idea of falling back to H.261 but this at least means
there a good chance of a better codec being selected.

No
> b. Do you have any objections to this option, if so please summarize them:
Yes, there are licensing requirements for H.263 and unlike H.264 there is
no Cisco (or other) binary to at least help with this on some platforms.

Yes

No
> b. Do you have any objections to this option, if so please summarize them:
Yes, there are licensing requirements for H.263 and unlike H.264 there is
no Cisco (or other) binary to at least help with this on some platforms.

Acceptable
> b. Do you have any objections to this option, if so please summarize them:
Yes, I don't like the idea of falling back to Theora but this at least
means there a good chance of a better codec being selected.

No
> b. Do you have any objections to this option, if so please summarize them:
Yes, as time goes on people will move away from H.264 and VP8 for better
performing codecs. It would seem pointless to start off with such an old
one.

No
> b. Do you have any objections to this option, if so please summarize them:
Yes, as time goes on people will move away from H.264 and VP8 for better
performing codecs. It would seem pointless to start off with such an old
one.

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: "cb.list6" <[email-masked]>
Date: Fri, 20 Dec 2013 06:43:24 -0800

> The tradition of the IETF is that participants speak for themselves; it
is not the tradition of the IETF to bring in those who you consult in order
to have them speak on your behalf (except when filing IPR statements).

+1 for the tradition. And, lawyers have been consulted, that is why it is a
legal issue and big name positions fall where they do.

Very dangerous territiry. Skype's lawyer is not your lawyer and does not
represent your interests in your relevant jurisdiction.

The ietf always punts on legal issues, and it is best that way. It stinks
because anyone can introduce FUD.

The ietf is not a patent cartel like 3gpp and mpeg.

CB

---

From: cowwoc <[email-masked]>
Date: Fri, 20 Dec 2013 11:36:12 -0500

Peter,

I assume 4b should be the same as 1b (since you'd still have to 
implement H.264).

Gili

On 20/12/2013 9:35 AM, Peter Dunkley wrote:
> Yes, I am concerned about the difficulty (in terms of licensing) of 
> using H.264 on iOS, Windows Mobile, and similar platforms as the Cisco 
> binary will not be usable in all cases.
>
> > 2.All entities MUST support VP8
> Yes, I am concerned about the difficulty (in terms of licensing) of 
> using H.264 on iOS, Windows Mobile, and similar platforms as the Cisco 
> binary will not be usable in all cases.
>
> Yes, this will not ensure interoperability which is the whole point of 
> an MTI codec.
>
> Yes, as time goes on people will move away from H.264 and VP8 for 
> better performing codecs. It would seem pointless to start off with 
> such an old one.
>
> Yes, interoperability is important and an MTI video codec will be 
> needed for this.
>
> Yes, I don't like the idea of falling back to H.261 but this at least 
> Yes, as time goes on people will move away from H.264 and VP8 for 
> better performing codecs. It would seem pointless to start off with 
> such an old one.
>
> Yes, I don't like the idea of falling back to H.261 but this at least 
> Yes, there are licensing requirements for H.263 and unlike H.264 there 
> is no Cisco (or other) binary to at least help with this on some 
> platforms.
>
> > 12. All entities MUST support decoding using both H.264 and VP8, and 
> Yes, there are licensing requirements for H.263 and unlike H.264 there 
> is no Cisco (or other) binary to at least help with this on some 
> platforms.
>
> Yes, as time goes on people will move away from H.264 and VP8 for 
> better performing codecs. It would seem pointless to start off with 
> such an old one.
>
> Yes, as time goes on people will move away from H.264 and VP8 for 
> better performing codecs. It would seem pointless to start off with 
> such an old one.
>
>
> On 9 December 2013 17:24, Ted Hardie <[email-masked] 
>     alternatives proposed to the WG. If you haven't read the "Next
>     Steps in Video Codec Selection Process"
>     The straw poll's purpose is to make it clear to the WG which of
>     the alternatives that are favored or disfavored and what
>     objections you have, if any, against a particular alternative. The
>     WG chairs will use the information from this straw poll to
>     identify an alternative to put as a single consensus question to
>     the group. Thus, everyone that has an opinion on at least one
>     alternative should answer this poll. Provide your poll input by
>     replying to this email to the WG mailing list. The poll will run
>     [Yes/No/Acceptable]:". These three levels allow you to indicate
>     that you: Yes= I would be fine with the WG choosing this option.
>     No = I really don't favor this, and it should not be picked.
>     Acceptable = I can live with this option but I prefer something
>     else to be picked.
>
>
>     The second question is "Do you have any objections to this option,
>     if so please explain it:" If you have any objection at a minimum
>     indicate it with a "Yes".   Please also add a short (1-sentence)
>     summary of each of the objections you believe applies.  (If you
>     wish to provide a longer explanation, please do so in a separate
>     thread).  If you have no objection, leave that question blank.
>
>
>     Please provide input on as many of the alternatives as you like
>     and feel comfortable to do. The more inputs, the more well
>     informed decision the WG chairs can take when identifying the
>     option to be brought forward for consensus. Any alternative that
>     you chose to leave blank, will simply be considered as one without
>     any input from you.
>
>
>     change the subject line to something else. Otherwise you are
>     making life for the chairs very difficult to track the results of
>     this straw poll.
>
>

---

From: Peter Dunkley <[email-masked]>
Date: Fri, 20 Dec 2013 16:44:30 +0000

I am an implementer of "other entities".  From my personal point-of-view it
is perfectly OK if browsers must do both as long as I don't have to.

Browsers doing both and my not having to still allows my applications and
servers to interoperate with browsers - which is the key thing for me.

I am fully aware that this might not match other peoples requirements.

Regards,

Peter

On 20 December 2013 16:36, cowwoc <[email-masked]> wrote:

>  Peter,
>
> I assume 4b should be the same as 1b (since you'd still have to implement
> H.264).
>
> Gili
>
>>  As can be seen below, the poll lists the alternative that have proposed
>> to the WG. For each alternative two questions are listed.
>>
>>  The second question is “Do you have any objections to this option, if
>> so please explain it:” If you have any objection at a minimum indicate it
>> with a “Yes”.   Please also add a short (1-sentence) summary of each of the
>> feel comfortable to do. The more inputs, the more well informed decision
>> the WG chairs can take when identifying the option to be brought forward
>> for consensus. Any alternative that you chose to leave blank, will simply
>> be considered as one without any input from you.
>>
>> thread! If you want to comment, then create a separate thread and change
>> the subject line to something else. Otherwise you are making life for the
>> send an update via email on the straw poll thread prior to the closing date.
>>
>>
>>
>>    1.
>>

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: cowwoc <[email-masked]>
Date: Fri, 20 Dec 2013 11:50:00 -0500

> participant would need its own legal counsel if needed.

Hi Magnus,

One idea I was toying with is having everyone chip into a legal pool. We 
would then use this money to contract the services of an odd number of 
legal firms (1 or 3) picked at random that would share their legal 
opinion on the IPR situation of VP8 and H.264, followed by H.263, H.261, 
Theora if there is enough money.

Another approach on this is having VP8-proponents chip into a pool that 
would investigate VP8 IPR, and H.264-proponents pay into a pool that 
would investigate H.264 IPR. Each party must be use an independent legal 
firm (not in-house lawyers) and those firms must publish their legal 
opinion in writing for all to see. We then give the firms an opportunity 
to comment on each other's statements. This is approach open to FUD, but 
hopefully less so since: (a) the firms are not going to be keen on 
tarnishing their name in public (b) the lawyers get to challenge each 
other's positions.

The IETF is not the only organization to run into this kind of 
situation. The first approach I've mentioned is inspired by a real-life 
organization that I'm familiar with.

Gili

---

From: cowwoc <[email-masked]>
Date: Fri, 20 Dec 2013 11:50:36 -0500

Got it :) Thanks for the clarification.

Gili

On 20/12/2013 11:44 AM, Peter Dunkley wrote:
> I am an implementer of "other entities".  From my personal 
> point-of-view it is perfectly OK if browsers must do both as long as I 
> don't have to.
>
> Browsers doing both and my not having to still allows my applications 
> and servers to interoperate with browsers - which is the key thing for me.
>
> On 20 December 2013 16:36, cowwoc <[email-masked] 
>>     Yes, I am concerned about the difficulty (in terms of licensing)
>>     of using H.264 on iOS, Windows Mobile, and similar platforms as
>>     the Cisco binary will not be usable in all cases.
>>
>>     Yes, I am concerned about the difficulty (in terms of licensing)
>>     of using H.264 on iOS, Windows Mobile, and similar platforms as
>>     the Cisco binary will not be usable in all cases.
>>
>>     Yes, this will not ensure interoperability which is the whole
>>     point of an MTI codec.
>>
>>     better performing codecs. It would seem pointless to start off
>>     with such an old one.
>>
>>     Yes, I don't like the idea of falling back to H.261 but this at
>>     least means there a good chance of a better codec being selected.
>>
>>     better performing codecs. It would seem pointless to start off
>>     with such an old one.
>>
>>     Yes, I don't like the idea of falling back to H.261 but this at
>>     least means there a good chance of a better codec being selected.
>>
>>     Yes, there are licensing requirements for H.263 and unlike H.264
>>     there is no Cisco (or other) binary to at least help with this on
>>     some platforms.
>>
>>     Yes, there are licensing requirements for H.263 and unlike H.264
>>     there is no Cisco (or other) binary to at least help with this on
>>     some platforms.
>>
>>     Yes, I don't like the idea of falling back to Theora but this at
>>     least means there a good chance of a better codec being selected.
>>
>>     better performing codecs. It would seem pointless to start off
>>     with such an old one.
>>
>>     better performing codecs. It would seem pointless to start off
>>     with such an old one.
>>
>>
>>         This is the email announcing the straw poll across the video
>>         codec alternatives proposed to the WG. If you haven’t read
>>         the “Next Steps in Video Codec Selection Process”
>>         The straw poll’s purpose is to make it clear to the WG which
>>         of the alternatives that are favored or disfavored and what
>>         objections you have, if any, against a particular
>>         alternative. The WG chairs will use the information from this
>>         straw poll to identify an alternative to put as a single
>>         consensus question to the group. Thus, everyone that has an
>>         opinion on at least one alternative should answer this poll.
>>         Provide your poll input by replying to this email to the WG
>>         mailing list. The poll will run until the end of the 12th of
>>         January 2014.
>>
>>
>>         As can be seen below, the poll lists the alternative that
>>         have proposed to the WG. For each alternative two questions
>>         are listed.
>>
>>
>>         [Yes/No/Acceptable]:”. These three levels allow you to
>>         indicate that you: Yes= I would be fine with the WG choosing
>>         this option. No = I really don’t favor this, and it should
>>         not be picked. Acceptable = I can live with this option but I
>>         prefer something else to be picked.
>>
>>
>>         The second question is “Do you have any objections to this
>>         option, if so please explain it:” If you have any objection
>>         at a minimum indicate it with a “Yes”.   Please also add a
>>         short (1-sentence) summary of each of the objections you
>>         believe applies.  (If you wish to provide a longer
>>         explanation, please do so in a separate thread).  If you have
>>         Please provide input on as many of the alternatives as you
>>         like and feel comfortable to do. The more inputs, the more
>>         well informed decision the WG chairs can take when
>>         identifying the option to be brought forward for consensus.
>>         Any alternative that you chose to leave blank, will simply be
>>         WG participants, please do not comment on anyone’s input in
>>         this thread! If you want to comment, then create a separate
>>         thread and change the subject line to something else.
>>         Otherwise you are making life for the chairs very difficult
>>         to track the results of this straw poll.
>>
>>
>>         If discussion causes you to update your position, please feel
>>         free to send an update via email on the straw poll thread
>>         prior to the closing date.
>>
>>
>>
>>         1.
>>
>>             Browsers MUST support both H.264 and VP8, other entities
>>             All entities MUST support decoding using both H.264 and
>>         H.263 is a reference to profile 0 level 70 defined in annex X
>>         of ITU-T rec H.263 (http://www.itu.int/rec/T-REC-H.263/)
>>
>>

---

From: David Singer <[email-masked]>
Date: Fri, 20 Dec 2013 09:17:10 -0800

Responding to various people

>>> What members of this WG have been saying, and writing, is that they want interoperability. OK, so that can be achieved with at least one of the options in the straw poll that VP8 proponents have indicated is acceptable. It would seem logical and reasonable to expect AVC proponents to take up that option also.

I am unclear as to which option you are talking about.

>>> I think the biggest problem is that people only want to maintain code for one codec.

I think it’s a preference, but not a total bar.  I think this is true of any organization: you want to use engineer-hours wisely.

>>>  If you already have H.264 support implemented, you will

Let’s see, I have suggested we look more closely at H.263, H.261, Motion JPEG, to name only 3.  I also have been trying to get an RF status for H.264 baseline (in several ways).  Cisco has tried to soften the practical position as well.  I don’t think it’s fair to describe this as a dog-in-manger attitude.

Regrettably, there is an (unconditional) type-2 (royalty-bearing) declarations for H.264 baseline from a company purporting to support RF coding, as well. How helpful is that? It hardly swings the tide in a helpful direction.

>>> > has been made very clear through the ISO process. 

But at least it satisfies (c).

>>> On the other hand, VP8 has
>>> > so far withstood court challenges, as you point out

I am unaware of a result from Germany still (it was expected in JUNE, wasn’t it?). And I believe that we have been told that those cases only involve a subset of what what was declared.
And the formal declaration stands, something which H.264 at least does not have (in any body). Generally standards bodies — and especially the engineering sides — have to go by the declarations.  Occasionally (e.g. at the W3C) a formal process is run to analyze and handle them.

Oblig IANAL.

>>> - something which AVC
>>> > could not BTW

You’re saying you are aware of IPR declarations against H.264 that are unlicensable and would stand up in court?  Pray tell.

>>> > It would seem very clear that the codec that is closer to the royalty free

VP8 is formally *unlicensable* at the IETF.  Ignoring this does not increase credibility of your arguments.

David Singer

---

From: David Singer <[email-masked]>
Date: Fri, 20 Dec 2013 09:28:15 -0800

> The ietf is not a patent cartel like 3gpp and mpeg. 

Please stay civil.  These are both standards bodies.  Patents are handled outside both of them. And both have plenty of specs that can be implemented without payment.

David Singer

---

From: SM <[email-masked]>
Date: Fri, 20 Dec 2013 09:32:21 -0800

Hi Gili,
At 08:50 20-12-2013, cowwoc wrote:
>One idea I was toying with is having everyone chip into a legal 
>pool. We would then use this money to contract the services of an 
>odd number of legal firms (1 or 3) picked at random that would share 
>their legal opinion on the IPR situation of VP8 and H.264, followed 
>by H.263, H.261, Theora if there is enough money.

[snip]

>situation. The first approach I've mentioned is inspired by a 
>real-life organization that I'm familiar with.

The situation is not an IETF problem.  It is a problem for the RTCWEB 
working group.  I don't think that it would be appropriate for the 
working group as a whole to contract the services of one or more 
legal firms as that might cause other problems.

Regards,
-sm

---

From: cowwoc <[email-masked]>
Date: Fri, 20 Dec 2013 12:52:03 -0500

On 20/12/2013 12:32 PM, SM wrote:
>> One idea I was toying with is having everyone chip into a legal pool. 
>> We would then use this money to contract the services of an odd 
>> number of legal firms (1 or 3) picked at random that would share 
> working group as a whole to contract the services of one or more legal 
> firms as that might cause other problems.

What problems are you referring to? If money is the problem then it 
seems to me that it would be a lot cheaper to contract this once across 
RTCWEB than have every single organization contract their own lawyer.

Gili

---

From: SM <[email-masked]>
Date: Fri, 20 Dec 2013 10:22:52 -0800

Hi Gili,
At 09:52 20-12-2013, cowwoc wrote:
>seems to me that it would be a lot cheaper to contract this once 
>across RTCWEB than have every single organization contract their own lawyer.

   "The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed
    to pertain to the implementation or use of the technology
    described in this document or the extent to which any license
    under such rights might or might not be available; nor does it
    represent that it has made any independent effort to identify any
    such rights."

Contracting a lawyer as a WG activity is problematic.  It might run 
afoul of current process rules.  It's not about money; there are 
other aspects to standards-making.

Regards,
-sm

---

From: Ron <[email-masked]>
Date: Sat, 21 Dec 2013 05:26:59 +1030

> But at least it satisfies (c).

Does it?  Can you point me to the IETF declaration which indicates this?

> I am unaware of a result from Germany still (it was expected in JUNE, wasn’t
> it?). And I believe that we have been told that those cases only involve a
> subset of what what was declared.

But you'd assume it's the _strongest_ subset that they think they might be
able to prove to the court.

Unless you're suggesting they're cunningly setting themselves up for an
appeal on the grounds that their lawyers used a pair of dice to select the
patents they would petition the court with ;?

> VP8 is formally *unlicensable* at the IETF.

I don't believe that is true.  The IETF *formally* takes no position or
makes no claims about the validity or applicability of any declaration.

  The results of this procedure shall not, in themselves, block
  publication of an IETF Document or advancement of an IETF
  Document along the standards track.  A working group may take
  into consideration the results of this procedure in evaluating
  the technology,  ...

This wouldn't be the first working group that has had to laugh off a
patently ridiculous claim in a disclosure in order to achieve a sensible
result that was in the best interest of its charter.

> You’re saying you are aware of IPR declarations against H.264

I'm still waiting for us to be informed of the reasons why IETF sanctions
shouldn't be sought against the contributors who have failed to meet their
obligations to make them.

  Ron

---

From: David Singer <[email-masked]>
Date: Fri, 20 Dec 2013 11:29:56 -0800

> Does it?  Can you point me to the IETF declaration which indicates this?

If there an IETF specification for H.264/AVC?

Seriously, you need to look at the ISO, IEC, and ITU databases, because that’s where it is published.  The declarations are all there. There are no ‘unwilling to license’ declarations.

Perhaps you didn’t realize that declarations are in the same place as the standard?

> able to prove to the court.

In legal matters, I have long learned that assumptions are dangerous.

> makes no claims about the validity or applicability of any declaration.

There is a formal declaration registered at the IETF of unlicensable IPR.  

> result that was in the best interest of its charter.

If someone makes to analyze these patents and VP8, and stand behind their analysis, go ahead.

If you want to mandate people to ignore declarations, I think you need a much stronger case.

> obligations to make them.

Against what IETF document?

If we insist on a recursive closure of all normatively referenced documents, the database would be so overloaded as to be unreadable and a mess.  As far as I know, no body has gone down that (insane, IMHO) route, expecting that people can work out for themselves that if a document is published by body A, it may well be in body A that you’ll find the declarations.

Let’s at least try to deal with the as it is.

David Singer

---

From: Ted Hardie <[email-masked]>
Date: Fri, 20 Dec 2013 11:54:56 -0800

> There is a formal declaration registered at the IETF of unlicensable IPR.
I'm not sure what "formal" means here, so let me restate this:

There is an IPR declaration related to one of the technologies under
consideration by the working group.  That IPR declaration asserts a set of
patents covers the technology.  That IPR declaration also states that no
license will be provided by that patent holder for that technology.

In the IETF, the validity of the assertion is not assessed by the
IETF-as-an-organization; it is assessed by the individuals who make up the
working group, as part of their analysis of how to build the standard.

For cases where the rights are freely available, the assessment might be
short or absent, because the result is a no-op.  For cases where it is not,
the individuals making up the working group conduct whatever analysis they
believe best.  The individuals making up the working group are not required
to accept assertions at face value, though that certainly could be their
choice of analytical method.

We then try, as a working group made up of individuals, to come to
consensus on what to do.

I hope this clarifies both the state and the process, but, as always,
reference to the relevant BCPs will give a fuller picture.

regards,

Ted Hardie

---

From: David Singer <[email-masked]>
Date: Fri, 20 Dec 2013 12:00:26 -0800

On Dec 20, 2013, at 11:54 , Ted Hardie <[email-masked]> wrote:

> I'm not sure what "formal" means here,

It’s not hearsay, or an email on a list, or a verbal statement.  It’s a submission using the ‘formal’ means provided by the IETF to make IPR statements.  That’s what I mean by ‘formal’ — it uses the formal channel and formats for making such statements.

> so let me restate this:
> 
> There is an IPR declaration related to one of the technologies under consideration by the working group.  That IPR declaration asserts a set of patents covers the technology.  That IPR declaration also states that no license will be provided by that patent holder for that technology.
> 
> In the IETF, the validity of the assertion is not assessed by the IETF-as-an-organization; it is assessed by the individuals who make up the working group, as part of their analysis of how to build the standard.  
> 
> For cases where the rights are freely available, the assessment might be short or absent, because the result is a no-op.  For cases where it is not, the individuals making up the working group conduct whatever analysis they believe best.  The individuals making up the working group are not required to accept assertions at face value, though that certainly could be their choice of analytical method.
> 
> We then try, as a working group made up of individuals, to come to consensus on what to do.
> 
> I hope this clarifies both the state and the process, but, as always, reference to the relevant BCPs will give a fuller picture.

Thank you.

I still see a significant problem with person A deciding that they don’t {like | believe | recognize | something} an IPR declaration, and can ask to make the underlying technology mandatory to implement for persons B, C, D, who might not see things the same way.

The point of ‘formal’ is that none of A thru D here can pretend that there was no information.

David Singer

---

From: Ron <[email-masked]>
Date: Sat, 21 Dec 2013 06:49:06 +1030

On Fri, Dec 20, 2013 at 11:29:56AM -0800, David Singer wrote:
> Seriously, you need to look at the ISO, IEC, and ITU databases, because
> that’s where it is published.  The declarations are all there. There are no
> ‘unwilling to license’ declarations.
> 

I'm not suggesting they be ignored.  But since they don't reference any part
of the specification that they claim to apply to, and since nobody has been
able to subsequently point to one, their applicability to this working group
in its capacity to "revise the work to attempt to avoid the IPR claim" would
appear to be negligible.

If nobody can identify any affected part of VP8, then there doesn't seem to
be any work required by the group to avoid these claims.  The burden of proof
would seem to have fallen on the people claiming this is a blocker.

If they haven't analysed this either, they don't have much of a case to refute.
If they have, please point for the rest of us to see also.

> If we insist on a recursive closure of all normatively referenced documents,
> the database would be so overloaded as to be unreadable and a mess.  As far
> as I know, no body has gone down that (insane, IMHO) route, expecting that
> people can work out for themselves that if a document is published by body A,
> it may well be in body A that you’ll find the declarations.

Do you have a reference to another technology that the IETF has *mandated*
as essential to implement (effectively making it an IETF standard), without:

 a) The IETF having change control over that technology (even if just by
    reprinting a reference from some other source and making it an RFC).

 b) Following all of the other relevant IETF process requirements, such as
    timely IPR disclosure.

As noted previously, there's a very big difference between something like
an optional RTP profile and a mandatory appendage to some other standard.

It seems out of scope for this working group to unilaterally break new
ground in violation of the above requirements, and I'm not aware of any
precedent that we'd be following in the footsteps of.  Is there one?

  Ron

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Dec 2013 15:27:55 -0500

>     reprinting a reference from some other source and making it an RFC).

This applies to plenty of technologies. One example would be AES. The citations
for that are to the AES FIPS.

-Ekr

---

From: Ron <[email-masked]>
Date: Sat, 21 Dec 2013 08:09:22 +1030

> for that are to the AES FIPS.

Ah, thanks!  Though even that one seems somewhat closer to the RTP profile
case than what we have proposed before us here - but it is a thinner slice
of the salami.

Maybe I'm still missing other cases but in RFC 5246 it's only mandatory
"In the absence of an application profile standard specifying otherwise"
which doesn't seem to be further defined in either that document, or in
RFC 6919 :)

And it would also seem to be subject to the IETF requirement that security
technologies MUST be strictly RF.  Which leaves the door open that the IETF
_could_ always assume change control of it if the need ever arose.  Which
seems reasonably pragmatic, even absent the "mandatory unless" language,
and the IETF does make sensible exceptions for strictly RF technologies.

We don't appear to have that option in the case of H.264 though, in the
light of declarations and statements that insist there would never be a
licence granted for an alternative but similar technology, by at least
one major IPR holder.

I know we're edging out of the scope of things that this group is chartered
to decide on, but I don't see any document that explicitly gives us the
option to ignore these requirements either, and it does seem relevant to
the decision that we need to make.

Even after we decide on something (assuming that we do), it's still going
to need to run the gauntlet of the broader IETF, and we seem to be somewhat
perilously close to a loophole whereby I could reference something which
I hold IPR on, that was published in the newsletter of my mother's knitting
group, and then assert with a Straight Face, that I have no obligation to
disclose, since it was Published Elsewhere.  And point to the discussion
here as precedent for that.

The IETF requirements as published would seem to be very clear.  Where does
our leeway come from to blur those lines here?

  Cheers,
  Ron

---

From: Mohammed Raad <[email-masked]>
Date: Sat, 21 Dec 2013 08:45:20 +1100

> Responding to various people
[MR] OK, very convenient.

> want interoperability. OK, so that can be achieved with at least one of the
> that option also.
[MR] I was mostly thinking of option 3. (entities must implement both H.264
and VP8).

> for one codec.
> I think it’s a preference, but not a total bar.  I think this is true of
> any organization: you want to use engineer-hours wisely.
>
> Let’s see, I have suggested we look more closely at H.263, H.261, Motion
> JPEG, to name only 3.  I also have been trying to get an RF status for
> H.264 baseline (in several ways).  Cisco has tried to soften the practical
> position as well.  I don’t think it’s fair to describe this as a
> dog-in-manger attitude.
>
> Regrettably, there is an (unconditional) type-2 (royalty-bearing)
> declarations for H.264 baseline from a company purporting to support RF
> coding, as well. How helpful is that? It hardly swings the tide in a
> helpful direction.
>

[MR] you had written in a previous post that the WG is looking for options
(a) and (b), and thus the reference to that comment here - very unsporting
to simply shift the goal posts.

> I am unaware of a result from Germany still (it was expected in JUNE,
> wasn’t it?). And I believe that we have been told that those cases only
> involve a subset of what what was declared.
> And the formal declaration stands, something which H.264 at least does not
> have (in any body). Generally standards bodies — and especially the
> engineering sides — have to go by the declarations.  Occasionally (e.g. at
> the W3C) a formal process is run to analyze and handle them.
>
[MR] H.264 has this type of thing
http://news.priorsmart.com/fastvdo-v-apple-l4q2/  , which is not the same
as formal patent declarations, I agree.

> Oblig IANAL.
[MR] We know.

>
> >>> - something which AVC
> >>> > could not BTW
>
> You’re saying you are aware of IPR declarations against H.264 that are
> unlicensable and would stand up in court?  Pray tell.
>
[MR] not sure how the previously linked case has concluded, but the judges
comments (available at
http://www.plainsite.org/flashlight/case.html?id=1724130  along with other
details) seem to indicate a number of agreements with what was being
claimed. I am also not a lawyer, but I would conclude that this is an
example of one case where there are still question marks about how easy it
is to get a license that covers all of the different parts of AVC/h.264. I
suspect this was concluded by some kind of license agreement, although I
have not been able to find any publicly available information on this.

> increase credibility of your arguments.
[MR] You see, that nice long list of patents you so avidly keep on going
back to is yet to be shown to be relevant to anything related to VP8 (you
mention that a few lines before this). The "formal declaration" argument
would hold some weight if the company making that declaration was not in
court getting negative results in its attempt to enforce what is in that
declaration. Copying and pasting patent numbers into an online form does
not mean those patents are relevant. But I do believe that I have found a
public statement from Nokia saying that they will not license patents that
read on VP8 at
http://www.fosspatents.com/2013/03/nokia-comments-on-vp8-patent.html which
is interesting given that they have just confirmed the licensing of their
patents to MS, so you would expect to have at least one case where the
claimed to be relevant patents are licensed.

[MR] going back to my "convenient" comment at the top - cutting different
points from different posts by different people really does build an easier
argument to deal with. Since you are concerned about credible arguments, I
would suggest not to do that.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 20 Dec 2013 23:12:02 +0100

>license will be provided by that patent holder for that technology.

A more proper phrasing would be "The holder does not commit to provide
reasonable licenses to all implementers". It might do just that, it is
just that when the holder does not, nobody can say "but you promised!"

I think the distinction is important because some might find the tech-
nology in question is available under (for their individual situation)
better license terms than other options before the Working Group. They
might be discouraged from exploring that possibility if they think the
technology is non-licensable.

I would not encourage that, but as there are non-royality-free options
under consideration, people should pick their poison carefully, if any.
-- 
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: Stephan Wenger <[email-masked]>
Date: Fri, 20 Dec 2013 22:46:24 +0000

Ron,

On 12/20/13, 1:39 PM, "Ron" <[email-masked]> wrote:

>[Š]
>technologies MUST be strictly RF.

There is no such requirement.  The only requirement that I recall related
to security technologies is that, whenever security is mandated, that
there MUST be at least one RF security technology be mandated.  Optional
other security technologies can be royalty bearing or otherwise encumbered.

Also please note that security is the one single exception we currently
have in the IETF where there exists an actual licensing requirement.  I
would argue very strongly against creating another such precedence.

>Which leaves the door open that the IETF

---

From: Ron <[email-masked]>
Date: Sat, 21 Dec 2013 10:12:54 +1030

Hi Stephan,

> other security technologies can be royalty bearing or otherwise encumbered.

Sorry, I thought the context there was clear, but I was indeed only referring
to mandatory requirements.  Optional things do seem to be in a different boat
there for several reasons that I don't think are in dispute.

It is indeed *all* mandatory technologies though, not just "at least one".

  An IETF consensus has developed that no mandatory-to-implement security
  technology can be specified in an IETF specification unless it has no
  known IPR claims against it or a royalty-free license is available ...

You're correct if they are optional, and I didn't mean to imply otherwise.

> would argue very strongly against creating another such precedence.

It's ok, I'm not arguing here for the expansion of this (or any other
requirement) -- I'm trying to get to the bottom of the rationale for
dodging the other already existing requirements, for which there seem
to be no such exceptions granted at all, and for the disclosures at
least, rather explicit "no excuses" requirements.

In the case of AES, I would assume that any existing IPR, should there
have been any, would have been required to be reported against the draft
that proposed mandating it, even by citation alone, and would have then
required the WG to pick some other option that wasn't so encumbered.
Even if there was no contributor in that case with an obligation to
disclose, the WG still had an extra obligation to ensure it was RF
(which obviously then makes a whole range of things much simpler, and
adds some practical liberties to pragmatically 'cut some corners', since
they could always be easily remedied after the fact if needed).

Here we have something that is proposed to be even more mandatory than
AES was, by people who haven't shown which IETF requirement gives them
an excuse not to disclose, and which clearly doesn't get the benefit of
any of the relaxations the IETF offers for RF technology.

I don't see how making some technology a strictly required IETF standard
by the back door path of deferring to a citation can exempt it from all
of the other normal requirements -- without driving a bulldozer through
both the spirit and the letter of those requirements.

Unless somebody can explain that, it's hard to see how this group could
do anything but reject that technology as mandatory, or face the shame
of having the broader IETF do that for us when it goes up for review.
And I'd like to not be in the shamed bunch when I decide how to answer
the survey questions that the chairs have posed :)  So I'm trying hard
to find out if there really is something I'm missing here.

  Cheers,
  Ron

---

From: SM <[email-masked]>
Date: Fri, 20 Dec 2013 16:17:03 -0800

Hi Ron,
>here as precedent for that.

I doubt that a mother would fall for that trick.  Here's some humor 
from the East:

   "This afternoon when I went to the kindergarten to pick my son up after
    school, he kept mumbling to me about how tired he was.  I said: What did
    you do today?  That little brat said something that made me almost spit
    blood, "After I finished arguing with the teacher, I had to then argue with
    the children, so how could I not be tired!"

    Should I give him a beating or should I give him a beating?"

Please note that there are two alternatives in the above. :-)

>precedent that we'd be following in the footsteps of.  Is there one?

I'll step back a little.  VP8 is not a standards-track 
specification.  H.264 is not a standards-track specification.  There 
isn't any similar specification which has been published in the IETF 
or which is currently listed as part of IETF work.  In essence, the 
IETF does not have change control over such technology.

The quoted text does not provide much information to form an opinion 
about whether there are any process requirements which have been 
violated.  I suggest an informational reading of RFC 6701 and RFC 6702.

Regards,
-sm

---

From: David Singer <[email-masked]>
Date: Fri, 20 Dec 2013 16:28:35 -0800

> [MR] you had written in a previous post that the WG is looking for options (a) and (b), and thus the reference to that comment here - very unsporting to simply shift the goal posts. 

I am not moving them, just pointing out how much further outside them one choice is.  If H.264 is problematic because it is licensable but only for fee, something that has a ‘no license’ declaration is further away still.

> [MR] not sure how the previously linked case has concluded, but the judges comments (available at http://www.plainsite.org/flashlight/case.html?id=1724130  along with other details) seem to indicate a number of agreements with what was being claimed. I am also not a lawyer, but I would conclude that this is an example of one case where there are still question marks about how easy it is to get a license that covers all of the different parts of AVC/h.264. I suspect this was concluded by some kind of license agreement, although I have not been able to find any publicly available information on this.

You’re citing FastVDO.  It only takes a moment to find that they are declared type 2 (RAND).

This is from the ITU database:

Statement Id	Recommendation	Patent number	Patent application number	Version of declaration form	License option	Received date	Statement date	Organization
H264-72		H.264 (ex. H.26L)	6 421 464	None					15 June 2002 (Common Text)	2			2003-05-15	2003-05-14		FastVDO LLC

FastVDO are MPEG and ITU members, and are therefore under a disclosure obligation, as well.

> [MR] You see, that nice long list of patents you so avidly keep on going back to is yet to be shown to be relevant to anything related to VP8 (you mention that a few lines before this). The "formal declaration" argument would hold some weight if the company making that declaration was not in court getting negative results in its attempt to enforce what is in that declaration. Copying and pasting patent numbers into an online form does not mean those patents are relevant.

I’m afraid your blithe reassurance that there is nothing to fear carries little weight.  YANAL either.  I don’t see anyone offering indemnification, either, which would indicate some confidence that the claims have no merit.

> But I do believe that I have found a public statement from Nokia saying that they will not license patents that read on VP8 at http://www.fosspatents.com/2013/03/nokia-comments-on-vp8-patent.html which is interesting given that they have just confirmed the licensing of their patents to MS, so you would expect to have at least one case where the claimed to be relevant patents are licensed.

Microsoft, IIRC, bought part of the company and rights to their entire patent portfolio.  This does not seem a route that can be generally followed.

David Singer

---

From: Ron <[email-masked]>
Date: Sat, 21 Dec 2013 12:32:01 +1030

On Fri, Dec 20, 2013 at 04:28:35PM -0800, David Singer wrote:
> I am not moving them, just pointing out how much further outside them one
> choice is.  If H.264 is problematic because it is licensable but only for
> fee, something that has a ‘no license’ declaration is further away still.

So by that logic, something with consensus of no IPR problems, that has a
tiny memory footprint, is blazingly fast on modern hardware, and will
give you better battery life than the hardest hardware acceleration on
mobile devices, should be a total no-brainer to solve the deadlock.
(If you accept this "no licence" claim actually creates one)

Right?

> Microsoft, IIRC, bought part of the company and rights to their entire
> patent portfolio.  This does not seem a route that can be generally
> followed.

You say that like there won't be another part of them for sale at an
even more heavily discounted price next year!

  Cautiously Optimistic,
  Ron

---

From: Maik Merten <[email-masked]>
Date: Sat, 21 Dec 2013 15:38:13 +0100

> VP8 is formally *unlicensable* at the IETF.  Ignoring this does not increase credibility of your arguments.

Just asking to get a better understanding of the process:

If there was a single "will not license" declaration regarding H.264, no 
matter how flimsy the claim, then H.264 would be automatically "formally 
unlicensable" as well?

This sounds like a dangerous loophole to let any party block basically 
anything and I hope there are provisions in place to mitigate such 
scenarios.

Maik

---

From: Jack Moffitt <[email-masked]>
Date: Sat, 21 Dec 2013 08:41:38 -0700

> anything and I hope there are provisions in place to mitigate such

Opus had several of these. It is still MTI for WebRTC because the
group was convinced the claims are spurious. As far as I know there is
no formal way to respond to such claims or get them removed. Each
member must decide for themselves whether the claim is valid or not.

jack.

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 21 Dec 2013 17:49:13 +0000

>> anything and I hope there are provisions in place to mitigate such

In the IETF, there is no automatic blocking of a standard proposal due to
a ³not willing to license² declaration.  In fact, the IETF does not
require any form of licensing, and there exists RFCs which had at some
time in their history ³not willing to license² declarations against them.
This is in contrast to organizations like W3C, ISO, or ITU, where there is
a minimum requirement for licensing terms.

>
>Opus had several of these.

Nonsense.  Really, people, try to do a minimum of homework before
commenting.

Opus has against it a number of declarations indicating RAND terms (in
addition to a few with other royalty free terms).  That¹s a whole world
different from ³unwilling to license².

> It is still MTI for WebRTC because the
>group was convinced the claims are spurious.

The group, as a whole made the decision to include Opus as MTI.  The
reasons for that decision is that there was rough consensus in the group.
That¹s it.  The group did not determine that claims are ³spurious².  The
IETF and its working groups do not take position on validity or
infringement, nor should they.  I, for one, accepted Opus as MTI not
because I think those claims are ³spurious², but because I knew there is a
fallback, namely G.711.  Others may have other motivations.

>As far as I know there is

 That much is true, except that the IETF does not have a membership
concept.

---

From: Monty Montgomery <[email-masked]>
Date: Sat, 21 Dec 2013 12:58:04 -0500

> Nonsense.  Really, people, try to do a minimum of homework before

Opus had a number of IPR declarations against it determined by
consensus to be completely spurious.  I read nothing incorrect in
Jack's comment.

Too much of this discussion has become willfully obtuse.

Monty

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sun, 22 Dec 2013 05:00:32 +1100

> fallback, namely G.711.  Others may have other motivations.

How did this work?
I thought the MTI is the fallback codec.
Are you saying that Opus & G.711 are both MTI?

/confused

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 21 Dec 2013 18:00:52 +0000

Please point me to that consensus call.
Thanks,
Stephan

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Dec 2013 13:00:21 -0500

> consensus to be completely spurious.  I read nothing incorrect in

Can you please point to the meeting minutes or mailing list archives
where the chairs declared consensus on this point?

-Ekr

---

From: Monty Montgomery <[email-masked]>
Date: Sat, 21 Dec 2013 13:03:07 -0500

The IETF neither legislates nor monopolizes consensus.

Monty

---

From: Monty Montgomery <[email-masked]>
Date: Sat, 21 Dec 2013 13:18:28 -0500

I never said there was a consensus call. The industry is deploying
Opus where they are loathe to deploy VP8.  There is obviously wide
belief it is safe to do so.  That's what consensus means.

The IETF didn't invent rough consensus. Nor it has stamped out the
idea elsewhere.  I'm not playing silly gotcha word games, and neither
was Jack.

If I (we) are right or wrong, it's on the merit of the arguments, not
use of punctuation, mispelingz, or brainos, or intentional misreadings
of others' points.  Honest misunderstanding is one thing.  Not caring
if you understand [and feigning outrage] is quite another.

We're all acting like a bunch of bloody engineers when there's only
one pop-tart left.

Monty
"OH. MY. GOD.  This forest FULL of trees!"

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Dec 2013 13:25:23 -0500

> The IETF neither legislates nor monopolizes consensus.

In the context of an IETF WG, "determined by consensus" generally means that
the WG made a determination. If the WG didn't make such a determination
but some other group did, it would probably be appropriate to qualify the group
that made the determination. For instance:

"Opus had a number of IPR declarations against it determined by
the consensus of those who thought they were completely spurious to
be completely spurious."

> idea elsewhere.  I'm not playing silly gotcha word games, and neither

Actually, I think that's pretty much what the above bit about the
IETF not legislating consensus consists of.

> if you understand [and feigning outrage] is quite another.

What an interesting passive aggressive way of accusing me of
acting in bad faith (seeing as you're responding to me, I'm assuming
that's who this is directed at).

Let's recap the history.

 Jack wrote that:
"Opus had several of these. It is still MTI for WebRTC because the
group was convinced the claims are spurious. "

In support of this, you wrote:

You wrote that "Opus had a number of IPR declarations against it determined by
consensus to be completely spurious.  I read nothing incorrect in
Jack's comment."

How shocking that someone would read your message as having to do with
the IETF WG, given that Jack's statement referenced "the group"

-Ekr

---

From: Adam Roach <[email-masked]>
Date: Sat, 21 Dec 2013 12:26:12 -0600

Yes.

There are several reasons why this ended being the case, all of which 
are fairly well documented in the minutes and email archives. If you 
want me to summarize these reasons privately, contact me off-list, and 
I'll give you a high-level explanation.

/a

---

From: Monty Montgomery <[email-masked]>
Date: Sat, 21 Dec 2013 13:44:04 -0500

> that made the determination.

Then you honestly misunderstood me, and I apologize for apparently
calling you out.  The message I wrote was really a continuation of the
thoughts I'd not put in the previous message.  It was not directed at
you (though it _was_ directed, apparently badly).

Opus did indeed have several spurious IPR declarations against it,
marked willing to license FRAND.  For a codec intended from inception
to be RF, that would have been a death sentence (and abject failure in
the minds of most of the individuals who contributed) had the
declarations been believable.  Simply being 'better' was unlikely to
be sufficiently compelling.

Monty

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 21 Dec 2013 18:47:49 +0000

On 12/21/13, 10:44 AM, "Monty Montgomery" <[email-masked]> wrote:

>marked willing to license FRAND.

For the record, in my opinion, those declarations are not spurious.

>For a codec intended from inception

IMO, somewhat to my surprise, the quality argument did cut to, as I
believe you correctly stated, a growing part of the industry.  You know,
some folks are willing to run the ³risk² of paying RAND terms for good
technology.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Dec 2013 13:47:39 -0500

> you (though it _was_ directed, apparently badly).

Apology accepted. My apologies for responding sarcastically. I
know that wasn't helpful.

> be sufficiently compelling.

Obviously, I'm very excited that these IPR declaration against Opus
have not hindered its adoption!

-Ekr

---

From: Ron <[email-masked]>
Date: Sun, 22 Dec 2013 05:37:23 +1030

> different from ³unwilling to license².

If the people making those sort of spurious declarations prove to be
unwilling, or indeed unable, to enforce those terms because they have
no basis in reality, then actually no, there is no difference at all
between them, or between them and RF.

Except perhaps for the damage it does to those people's reputation,
and to the credibility of any other claims they might make.

  Ron

---

From: Ron <[email-masked]>
Date: Sun, 22 Dec 2013 05:55:34 +1030

> For the record, in my opinion, those declarations are not spurious.

You have me curious now.  Have you simply not read the detailed analysis
that shows just how laughably spurious they are, or is your faith in
Texas Juries stronger than any facts?

> some folks are willing to run the ³risk² of paying RAND terms for good

And lots of folks end up paying them for invalid patents on bad technology
too.  Just because a system is horribly broken it doesn't mean smart people
can't fix it.  Being outstandingly better on all terms still beats being
better on either one for desirability, accessibility, and putting and end
to the inviolability myth of a protection racket.

  Win, win, win,
  Ron

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 21 Dec 2013 21:08:28 +0000

>Texas Juries stronger than any facts?

Perhaps I have analyzed a few of those patent claims myself?  I could do
that just as well as you guys.  I may simply have decided not to publish
the results, knowing the associated risks (which you guys either are not
aware of, or are willing to take)  Perhaps I trust the opinion of those
lawyers, many of whom I know personally for years, who made RAND
declarations?  Perhaps I have an idea what the consequences of
over-declarations can be?

As for Texas juries, I don’t worry too much.  Once a case hits a jury, in
Texas or elsewhere, I (or any other defendant) would already have spent
millions in pre-trial costs, much of which I would never see again.
Assuming I have a RAND declaration on hand, my damages  will almost
certainly orders of magnitude less, even if my product were found
infringing and the patent was found valid.  I could deal with that,
probably.  All that assuming I’m a comparatively small company--the giants
have other considerations to cope with, but also different resources.

OTOH, if there are no RAND declarations, things can be vastly different.
If someone refuses to license, I could see my products pulled of the
shelves and run over by bulldozers.  Does that make the picture clearer?
Just because you folks view paying license fees as the end of the world,
that doesn’t mean that others view it the same way.

>to the inviolability myth of a protection racket.

Have fun with your crusade.

---

From: Monty Montgomery <[email-masked]>
Date: Sat, 21 Dec 2013 16:44:22 -0500

> Perhaps I have analyzed a few of those patent claims myself?

well... have you?

> I could do that just as well as you guys.

Well... did you?

> I may simply have decided not to publish
> aware of, or are willing to take)

We're aware.  We published.  Call, raise, or fold?

> Perhaps I trust the opinion of those
> declarations?

I believe their reasons for doing so are sound but have little to do
with the validity of the IPR claim. Consequence of the current system;
they'd be insane (or just exceptionally moral) _not_ to make the
declaration.

> Perhaps I have an idea what the consequences of

I fully expect you do, and I'm not being sarcastic.  Nevertheless,
your theoretical analysis is speculative hearsay. To paraphrase a
favorite lawyer of my own, it might as well be small talk about the
weather.

Verifiable fact: Our analysis isn't speculation. It exists. We
published it. We've formally informed the parties that made the IPR
claims that we dispute those claims, and have invited rebuttal of our
analysis and clarification of the asserted rights.  You may offer your
own rebuttal, which would actually be welcome.  The more light shed,
the more transparency, the better.

Our cards are on the table, it's a bit late to bluff.

Monty

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 21 Dec 2013 17:08:51 -0500

> Are you saying that Opus & G.711 are both MTI?
[BA] Yes. Take a look at:
http://tools.ietf.org/html/draft-ietf-rtcweb-audio

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 21 Dec 2013 17:14:31 -0500

> On Dec 21, 2013, at 4:08 PM, "Stephan Wenger" <[email-masked]> Said:

> OTOH, if there are no RAND declarations, things can be vastly different.

[BA] Indeed - and this is perhaps one of the stronger arguments for codecs that have completed a standardization process in an SDO.

---

From: Ron <[email-masked]>
Date: Sun, 22 Dec 2013 09:02:22 +1030

> Have fun with your crusade.

Ah!  See there's your next mistake.  You think this is a war?

We're just pushing the bounds of engineering best practice.
Which is indeed its own brand of satisfyingly fun and rewarding.

You can't build antique siege engines to contain that, but watching
you hoist with your own petard might still be good for a giggle.

  Ron

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 21 Dec 2013 17:52:24 -0500

On Dec 21, 2013, at 1:18 PM, "Monty Montgomery" <[email-masked]> wrote:
> 
> We're all acting like a bunch of bloody engineers when there's only one pop-tart left.

[BA] The pop tart case is relatively straight forward. Someone eats the pop-tart and then someone else complains about the scarcity of pop tarts at the mike during plenary. The complainer is then deluged with pop tarts, and the IAOC, to avoid future controversy, makes sure that the pop tart shortage dies not recur.  EKR can provide further details of how the protocol works :)

In contrast, the MTI video codec discussion is "the gift that keeps on giving" - the kind of problem that if ignored, becomes irrelevant in the fullness of time. But if given full attention, it consumes all available mind share and energy, crowding out progress on anything else.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Dec 2013 03:02:19 +0000

> If we insist on a recursive closure of all normatively 
> referenced documents, the database would be so overloaded as 
> to be unreadable and a mess.  As far as I know, no body has 
> gone down that (insane, IMHO) route, expecting that people 
> can work out for themselves that if a document is published 
> by body A, it may well be in body A that you'll find the declarations.

More to the point, you will probably find that many of the potential holders of IPR against H.264, and also possible VP8, are not represented in the IETF RTCWEG WG, or else their representatives have insufficient information on their companies IPR holdings because they work in a different area. At the end of the day, the majority of the videocodec experts, who would have such direct knowledge, are in ISO/IEC. Therefore you will get an incomplete set of declarations in IETF even if you start insisting on a declaration against every dpcument.

So you will only get a complete picture of the IPR position by going to the ISO / IEC IPR databases.

And that position applies to VP8 as well. My view is that we will only have a clear view of the IPR position of VP8 when ISO / IEC asks for declarations against that technology. At the moment we only have the statement of one company (albeit a large company) that their investigations have not revealed any IPR that either they they themselves do not own, or have negotiated some sort of arrangement with). (Ignoring for the moment the Nokia IPR declaration).

Regards

Keith Drage 

> Sent: 20 December 2013 19:30
> To: [email-masked]
> Subject: Re: [rtcweb] Counting NOs (Re: Straw Poll on Nokia mincing)
> 
> 
> >>>>>> It has been pointed out that the MTI should satisfy 
> options a) or 
> >>>>>> b) on the ietf declaration form. As matters stand 
> AVC/h264 does 
> >>>>>> not satisfy that, this has been made very clear 
> through the ISO process.
> >> 
> Seriously, you need to look at the ISO, IEC, and ITU 
> databases, because that's where it is published.  The 
> declarations are all there. There are no 'unwilling to 
> license' declarations.
> 
> Perhaps you didn't realize that declarations are in the same 
> place as the standard?
> 
> > 
> >> wasn't it?). And I believe that we have been told that those cases 
> >> only involve a subset of what what was declared.
> > 
> > But you'd assume it's the _strongest_ subset that they think they 
> > might be able to prove to the court.
> 
> > I don't believe that is true.  The IETF *formally* takes no 
> position 
> > or makes no claims about the validity or applicability of 
> any declaration.
> 
> > publication of an IETF Document or advancement of an IETF  Document 
> > along the standards track.  A working group may take  into 
> > consideration the results of this procedure in evaluating  the 
> > technology,  ...
> > 
> > patently ridiculous claim in a disclosure in order to achieve a 
> > sensible result that was in the best interest of its charter.
> 
> >> You're saying you are aware of IPR declarations against H.264
> > 
> > I'm still waiting for us to be informed of the reasons why IETF 
> > sanctions shouldn't be sought against the contributors who 
> have failed 
> > to meet their obligations to make them.
> 
> If we insist on a recursive closure of all normatively 
> referenced documents, the database would be so overloaded as 
> to be unreadable and a mess.  As far as I know, no body has 
> gone down that (insane, IMHO) route, expecting that people 
> can work out for themselves that if a document is published 
> by body A, it may well be in body A that you'll find the declarations.
> 
> Let's at least try to deal with the as it is.
> 
> David Singer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Dec 2013 03:02:19 +0000

Please do not make statements that are incorrect.

"The ietf is not a patent cartel like 3gpp and mpeg."

There is absolutely nothing in the 3GPP rules (or its constituent member bodies) or indeed in ISO/IEC that differs radically from the patent rules of IETF in terms of what gets adopted.

Essentially, holders of essential patents are asked to declare, and the members of that organisation choose whether they wish to adopt technology based on those declarations.

Like IETF, adoption of technology is normally based on there being nothing stronger than FRAND.

I assume you are not confusing mpeg with MPEG-LA which is not the same, and not an SDO.

Keith
________________________________
From: rtcweb [mailto:[email-masked]] On Behalf Of cb.list6
Sent: 20 December 2013 14:43
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] Matthew's response to straw poll

On Dec 20, 2013 3:39 AM, "Harald Alvestrand" <[email-masked]<mailto:[email-masked]>> wrote:
>> You bring up a good point: at least 50% of this decision is legal in nature, yet no one bothered consulting a lawyer. Personally I think that people care more about the politics than legality, but still...
>
>
> I believe that lawyers have been consulted. But I'd be surprised to see anyone quoting their lawyer's advice verbatim in public, for multiple reasons.
>
> The tradition of the IETF is that participants speak for themselves; it is not the tradition of the IETF to bring in those who you consult in order to have them speak on your behalf (except when filing IPR statements).
>
>
>

+1 for the tradition. And, lawyers have been consulted, that is why it is a legal issue and big name positions fall where they do.

Very dangerous territiry. Skype's lawyer is not your lawyer and does not represent your interests in your relevant jurisdiction.

The ietf always punts on legal issues, and it is best that way. It stinks because anyone can introduce FUD.

CB

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Dec 2013 03:02:20 +0000

> Do you have a reference to another technology that the IETF 
> has *mandated* as essential to implement (effectively making 
> it an IETF standard), without:
> 

The closest example to the RTCWEB working group is G.711, which the IETF does not control, and has no IPR database against it in IETF.

Yet that is mandated as MTI for the audio codec work.

But I am sure we could identify lots of work elsewhere in the IETF (if I really wanted to waste any time on a pointless exercise) where there is a fundamental normative reference to some document from another SDO, particularly areas where IETF has cooperated with other organisations.

Additionally, people still seem to be working under the misapprehension that RFC 6386 is an IETF document. It is not. It is an individual submission to the RFC editor. While the mechanisms exist to declare IPR against it in the IPR database, there is absolutely no requirement to do so in relation to any work going on in the IETF.

Keith Drage

> From: rtcweb [mailto:[email-masked]] On Behalf Of Ron
> Sent: 20 December 2013 20:19
> To: [email-masked]
> options a) 
> > >>>>>> or b) on the ietf declaration form. As matters stand 
> AVC/h264 
> > >>>>>> does not satisfy that, this has been made very clear 
> through the ISO process.
> > >> 
> > Seriously, you need to look at the ISO, IEC, and ITU databases, 
> > because that's where it is published.  The declarations are 
> all there. 
> > There are no 'unwilling to license' declarations.
> > 
> > Perhaps you didn't realize that declarations are in the 
> same place as the standard?
> > 
> > > 
> > >> I am unaware of a result from Germany still (it was expected in 
> > >> JUNE, wasn't it?). And I believe that we have been told 
> that those 
> > >> cases only involve a subset of what what was declared.
> > > 
> > > I don't believe that is true.  The IETF *formally* takes 
> no position 
>  Document 
> I'm not suggesting they be ignored.  But since they don't 
> reference any part of the specification that they claim to 
> apply to, and since nobody has been able to subsequently 
> point to one, their applicability to this working group in 
> its capacity to "revise the work to attempt to avoid the IPR 
> claim" would appear to be negligible.
> 
> If nobody can identify any affected part of VP8, then there 
> doesn't seem to be any work required by the group to avoid 
> these claims.  The burden of proof would seem to have fallen 
> on the people claiming this is a blocker.
> 
> > > sanctions shouldn't be sought against the contributors who have 
> > > failed to meet their obligations to make them.
> > 
> > If we insist on a recursive closure of all normatively referenced 
> > documents, the database would be so overloaded as to be 
> unreadable and 
> > a mess.  As far as I know, no body has gone down that 
> (insane, IMHO) 
> > route, expecting that people can work out for themselves that if a 
> > document is published by body A, it may well be in body A 
> that you'll find the declarations.
> 
> Do you have a reference to another technology that the IETF 
> has *mandated* as essential to implement (effectively making 
> it an IETF standard), without:
> 
> As noted previously, there's a very big difference between 
> something like an optional RTP profile and a mandatory 
> appendage to some other standard.
> 
> It seems out of scope for this working group to unilaterally 
> break new ground in violation of the above requirements, and 
> I'm not aware of any precedent that we'd be following in the 
> footsteps of.  Is there one?
> 
> 
>   Ron
> 
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Dec 2013 03:02:24 +0000

I'm completely lost as to what definition of consensus you are using. It obviously is not the normal IETF one.

And how anybody can test your statements to be true. You seem to be referring to your own assumption of what everyone implementing the technology did in relation to those IPR declarations.

Just to be clear, there are a number of different ways of dealing with IPR. Many organisations have cross licensing agreenments, others may have chosen to directly licence, and so on. So assuming that everyone has ignored the declared IPR because it is not valid cannot be logically justified.

Keith Drage

> Monty Montgomery
> Sent: 21 December 2013 18:18
> To: Eric Rescorla
> Cc: [email-masked]
> I never said there was a consensus call. The industry is 
> deploying Opus where they are loathe to deploy VP8.  There is 
> obviously wide belief it is safe to do so.  That's what 
> consensus means.
> 
> The IETF didn't invent rough consensus. Nor it has stamped 
> out the idea elsewhere.  I'm not playing silly gotcha word 
> games, and neither was Jack.
> 
> If I (we) are right or wrong, it's on the merit of the 
> arguments, not use of punctuation, mispelingz, or brainos, or 
> intentional misreadings of others' points.  Honest 
> misunderstanding is one thing.  Not caring if you understand 
> [and feigning outrage] is quite another.
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 23 Dec 2013 13:59:28 +0900

On 2013/12/22 2:49, Stephan Wenger wrote:

> On 12/21/13, 7:41 AM, "Jack Moffitt"<[email-masked]>  wrote:

>   That much is true, except that the IETF does not have a membership

The IETF as a whole does not have a *formal* membership concept. Nobody 
has to register, there are no membership rosters, and so on. People just 
participate. But for WGs, membership is slightly more formal. As far as 
I understand, the membership of a WG is defined to be the people 
subscribed to the mailing list.

Regards,   Martin.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 22 Dec 2013 21:05:25 -0800

> subscribed to the mailing list.

Sorry, but simply and absolutely not.

IETF working groups do not have membership.  Period.

The concept simply does not apply to IETF work, except for formal 
management groups like Nomcom, IESG, and a few others.  But working 
groups?  No.  Not at all.

d/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 23 Dec 2013 15:42:18 +0900

> IETF working groups do not have membership. Period.

http://tools.ietf.org/html/rfc2418, which is an IETF BEST CURRENT 
PRACTICE, contains phrases such as "members of the IETF", "IETF 
members", and "working group members". Are you saying it needs to be 
revised?

It also contains the sentence "There is no formal membership in the IETF.".

> management groups like Nomcom, IESG, and a few others. But working

So my conclusion is that membership applies, formal membership doesn't.

Regards,   Martin.

---

From: Ron <[email-masked]>
Date: Mon, 23 Dec 2013 18:11:31 +1030

On Mon, Dec 23, 2013 at 03:02:20AM +0000, DRAGE, Keith (Keith) wrote:
> The closest example to the RTCWEB working group is G.711,

If that's actually true, then that would indeed confirm that there is
actually no precedent at all for any exemption to the problems that
H.264 poses with this.

> which the IETF does not control,

You're missing the key point identified in earlier discussion.
The IETF _could_ have change control over G.711 at any time, if the need
for that ever arose.  All it would take is to publish an RFC with whatever
changes it was felt necessary to make.

And we could do this, on zero notice, with no need to obtain any additional
permission to what we already have, because G.711 is an unencumbered RF
specification.  Which I believe does actually satisfy BCP 79, section 9,
both in spirit and letter.

That doesn't say it must be an IETF standard, that says the IETF must have
change control over *the technology*.  If we can make a derived standard
at any time, which for G.711 we clearly can, then we have change control.
QED.

We could likewise do the same for VP8, or H.261, given the status of their
applicable IPR.  We have the option for change control, either by explicit
grant of the IPR holder in the former case, or by its expiry in the latter,
which we could exercise at any time we might need to.

The important difference is we do NOT have that luxury for H.264 at all.
Not only is it not an IETF standard, but one of its major IPR holders has
openly threatened to sue the pants off anyone who makes a derived work.
We've been openly prohibited from having any form of change control.

The closest examples to this might actually be referenced from BCP 79
itself.  It even gives examples of possible remedies - but those aren't
applicable for H.264 either in the light of that prohibitive threat.
Oops.

> and has no IPR database against it in IETF.

are you ...  seriously suggesting you think there is unreported IPR on a
40 year old standard?  One which consists of such trivial math that it's
probably about as patentable as the two times table?

> But I am sure we could identify lots of work elsewhere in the IETF
> (if I really wanted to waste any time on a pointless exercise)

If you think facts are a waste of time, then I can't help you there.
I'm sure we could imagine all sorts of fanciful things if we refuse
to be constrained by them.

The requirements of BCP 79 are fairly simple and plainly stated.

If you can't show where the authority comes from for the exceptions
that you are claiming to them, then we can probably safely take that
as consensus that those exceptions simply don't exist.

And this is the wrong place to begin inventing them from thin air.

  Ron

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Dec 2013 07:24:11 -0800

> members", and "working group members". Are you saying it needs to be

Yes.  Worse is that the sloppy phrasing was in the original version of 
the document that I co-authored.  It leads to the sort of ambiguity 
producing this thread.

> It also contains the sentence "There is no formal membership in the IETF.".

Exactly.

d/

---

From: Alan Johnston <[email-masked]>
Date: Mon, 23 Dec 2013 12:32:46 -0800

All,

Here's my opinions on these options.

- Alan -

a.            Are you in favor of this option [Yes/No/Acceptable]:  *Yes*

*Acceptable*

b.            Do you have any objections to this option, if so please
summarize them: *A VP8 binary from Google would turn this vote into a Yes*

*Acceptable*

b.            Do you have any objections to this option, if so please
summarize them: *A VP8 binary from Google would turn this vote into a Yes*

4. Browsers MUST support both H.264 and VP8, other entities MUST support at
least one of H.264 and VP8

a.            Are you in favor of this option [Yes/No/Acceptable]: *Yes*

a.            Are you in favor of this option [Yes/No/Acceptable]: *No*

b.            Do you have any objections to this option, if so please
summarize them: *Doesn’t guarantee interop*

a.            Are you in favor of this option [Yes/No/Acceptable]: *No*

b.            Do you have any objections to this option, if so please
summarize them: *Quality of H.261 is not acceptable*

a.            Are you in favor of this option [Yes/No/Acceptable]: *No*

b.            Do you have any objections to this option, if so please
summarize them: *Doesn't guarantee interop.  This would be Acceptable if
the IETF immediately moved forward with a VIDEO Working Group to
standardize a new IPR free video codec*

8. All entities MUST support H.261 and all entities MUST support at least
one of H.264 and VP8

a.            Are you in favor of this option [Yes/No/Acceptable]: *No*

b.            Do you have any objections to this option, if so please
summarize them: *Quality of H.261 is not acceptable*

a.            Are you in favor of this option [Yes/No/Acceptable]: *No*

b.            Do you have any objections to this option, if so please
summarize them:* IPR on Theora is even more unknown than VP8*

a.            Are you in favor of this option [Yes/No/Acceptable]:  *No*

b.            Do you have any objections to this option, if so please
summarize them: *Quality of H.261 is not acceptable*

a.            Are you in favor of this option [Yes/No/Acceptable]: *Yes*

*Acceptable*

b.            Do you have any objections to this option, if so please
summarize them: *A VP8 binary from Google would turn this vote into a Yes*

a.            Are you in favor of this option [Yes/No/Acceptable]: *No*

b.            Do you have any objections to this option, if so please
summarize them:  *Quality of H.263 is not sufficient for it to be the sole
MTI video codec*

*Acceptable*

b.            Do you have any objections to this option, if so please
summarize them:  *A VP8 binary from Google would turn this into a Yes*

a.            Are you in favor of this option [Yes/No/Acceptable]: *No*

b.            Do you have any objections to this option, if so please
summarize them:  *IPR on Theora is even more unknown than VP8*

a.            Are you in favor of this option [Yes/No/Acceptable]: *No*

b.            Do you have any objections to this option, if so please
summarize them: *Most of us don’t live in South Korea or Japan and hence
don't have enough bandwidth*

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Tue, 24 Dec 2013 09:44:59 -0500

Please see responses for video codec alternatives below.

Thanks
Sanjay

o   Prefer H.264 over VP8 as MTI

o   No objection but a comment. Prefer that all entities support both H.264 and VP8

o   Do not support VP8 over H.264 as MTI

o   Lower quality video and the choice regresses given the evolution to H.264 and its wider deployment already

o   Risks interoperability

o   Do not support possible outcome of VP8 and H.261 as MTI

o   Adds deployment and Operations care as this is not known to be a wider deployment

o   Do not support possible outcome of VP8 and H.261 as MTI

o   Do not support possible outcome of VP8 and H.263 as MTI

o   Not a clean option requiring one codec in one direction and another one in a different and may present interoperability challenges

o   Not a good choice for MTI given wider deployment of H.264

o   Do not support possible outcome of VP8 and Theora as MTI

o   Adds deployment and Operations care as this codec is not known to be a wider deployment

o   Low quality video

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Monday, December 09, 2013 12:25 PM
To: [email-masked]<mailto:[email-masked]>; Gonzalo Camarillo; Richard Barnes; Magnus Westerlund; Cullen Jennings
Subject: [rtcweb] Straw Poll on Video Codec Alternatives

Dear WG,

Thanks,

The Chairs

---

From: Gunnar Hellstrom <[email-masked]>
Date: Tue, 24 Dec 2013 22:47:49 +0100

My views:
On 2013-12-09 18:24, Ted Hardie wrote:
>         Are you in favor of this option [Yes/No/Acceptable]: Yes
>
>     2.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>
>         summarize them: Will cause more interoperability problems with
>         other environmnets than H.264.
>
> 3.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>
>         summarize them: More complex than plain H.264
>
> 4.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable.
>
>     2.
>
>         summarize them: Will cause more problems with interop with
>         other environments than plain H.264.
>
> 5.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: Does not encourage interoperability sufficiently.
>
> 6.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: H.261 has no suitable formats for modern cameras.
>
> 7.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         Does not encourage interoperability sufficiently. Acceptable
>         if MTI is agreed by another powerful organization.
>
> 8.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: H.261 has no suitable formats for modern cameras.
>
> 9.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: Not sufficiently wide spread before to be of
>         interest.
>
>10.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: Complex construction. H.261 is not sufficient.
>
>11.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>
>         summarize them: Will cause risk for transcoding to achieve
>         interop with other environments.
>
>12.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: Asymmetric support have interoperability risks
>
>13.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>
>         summarize them: Quite good, but sad to not agree on latest
>         generation.
>
>14.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: Theora is too little implemented to be of
>         interest.
>
>15.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: Theora is too little implemented
>
>16.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: MJPEG is too bandwidth hungry
>
>
>
/Gunnar

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 25 Dec 2013 14:47:58 +0900

Hello Sanjay, others,

I have a clarifying question below.

[snip]

[snip]

> o   Do not support possible outcome of VP8 and H.261 as MTI

Given that you are in favor of 3, and surprised at the NO here, and even 
more surprised at your justification. What's the problem if, under this 
option, some entities (not you) decide to implement VP8 and H.261, and 
communicate among themselves using either of these two?

It looks to me like there's either a fundamental issue for you that 
nobody else has mentioned yet, or there is a misunderstanding, and it 
would be great if you could clarify.

Regards,   Martin.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 25 Dec 2013 14:13:09 +0100

>would be great if you could clarify.

The answers are insisting that H.264 encoding and decoding are supported
and there are a number of participants who have expressed this sentiment
for various reasons. One being interoperability with legacy systems that
support only H.264 without transcoding the video data. I don't think the
choices here are surprising.

(Also note that, by the looks of it, some might think that if users have
to download and install a "plugin" separate from the core product, that
is enough to satisfy a mandatory-to-implement requirement, so I would
not read too much into people choosing options to require more than one
codec with possible licensing problems.)
-- 
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: "Roni Even" <[email-masked]>
Date: Wed, 25 Dec 2013 15:50:41 +0200

Hi,

Here is my view

Roni

a.    Are you in favor of this option [Yes/No/Acceptable]:Yes

.      Are you in favor of this option [Yes/No/Acceptable]:No

a.    Do you have any objections to this option, if so please summarize
them:  Inteop issues with video conferencing

a.    Do you have any objections to this option, if so please summarize
them: Complicate the implementation but provide interoperability

a.    Do you have any objections to this option, if so please summarize
them: Complicate the implementation but provide interoperability

.      Are you in favor of this option [Yes/No/Acceptable]:No

a.    Do you have any objections to this option, if so please summarize
them:  Does not provide interoperability

.      Are you in favor of this option [Yes/No/Acceptable]:No

a.    Do you have any objections to this option, if so please summarize
them: low quality

.      Are you in favor of this option [Yes/No/Acceptable]:No 

a.    Do you have any objections to this option, if so please summarize
them:  There are better options like having more than one MTI codec

.      Are you in favor of this option [Yes/No/Acceptable]:No

a.    Do you have any objections to this option, if so please summarize
them: H.261 does not provide the quality

.      Are you in favor of this option [Yes/No/Acceptable]: No

a.    Do you have any objections to this option, if so please summarize
them: Not widespread enough for interoperability

.      Are you in favor of this option [Yes/No/Acceptable]: No

a.    Do you have any objections to this option, if so please summarize
them: H.261 is not the right codec

a.    Do you have any objections to this option, if so please summarize
them: A better solution if cannot agree on one MTI codec

a.    Do you have any objections to this option, if so please summarize
them: will have interoperability issues with video conferencing systems

.      Are you in favor of this option [Yes/No/Acceptable]: no

a.    Do you have any objections to this option, if so please summarize
them:  better have newer codecs

.      Are you in favor of this option [Yes/No/Acceptable]: No

a.    Do you have any objections to this option, if so please summarize
them:  will not address interoperability

.      Are you in favor of this option [Yes/No/Acceptable]: No

a.    Do you have any objections to this option, if so please summarize
them: No MTI codec and no interoperability

.      Are you in favor of this option [Yes/No/Acceptable]: No

a.    Do you have any objections to this option, if so please summarize
them: bandwidth and interoperability issues

H.264 is a reference to the pro
<https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/> posal
in https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/

VP8 is a reference to the pro
<https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/> posal in
https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/

Theora is a reference to Xiph.org Theora Specification from March 16, 2011 (
<http://www.xiph.org/theora/doc/Theora_I_spec.pdf>
http://www.xiph.org/theora/doc/Theora_I_spec.pdf) 

H.261 is a reference to  <http://tools.ietf.org/html/rfc4587>
http://tools.ietf.org/html/rfc4587 

Motion JPEG is a reference to  <http://tools.ietf.org/html/rfc2435>
http://tools.ietf.org/html/rfc2435 

Thanks,

The Chairs

---

From: cowwoc <[email-masked]>
Date: Wed, 25 Dec 2013 19:17:55 -0500

> codec with possible licensing problems.)

i think we need to clarify this point. As far as I know, no legacy 
system supports WebRTC natively. This means that people will be sticking 
some sort of WebRTC adapter in between native WebRTC peers and the 
legacy devices. Under this scenario, won't you need to transform the 
video in some way along the way?

Gili

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 26 Dec 2013 02:12:10 +0100

>video in some way along the way?

Yes, but that operation is more like changing the container format of a
video stream from AVI to MKV or MP4. Changing the video codec requires
much more processing. To get a feel for the numbers involved, I would
recommend using `ffmpeg` like so

  % ffmpeg -i input.avi -vcodec copy ... output.mkv

for changing the container format and whatever is suitable to change the
video codec. As an example, this is what I use to encode videos for my
smartphone regardless of input format

  % ffmpeg -n -i input -vf "scale=320:trunc(ow/a/2)*2"
      -vcodec libx264 -vb 196000 -vprofile "baseline"
      -acodec aac -ac 2 -ar 64000 -ab 64000
      -movflags faststart -strict -2 output.mp4

During transcoding, `ffmpeg` should print out how many frames per second
it is currently transcoding. Between the two commands, the difference on
my main desktop computer is a factor between 100x and 300x.
-- 
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: Silvia Pfeiffer <[email-masked]>
Date: Fri, 27 Dec 2013 13:45:41 +1100

Here are my personal thoughts on the different options put in front of
us at this point in time.

1. All entities MUST support H.264
  .a No
  .b The licensing situation of H.264, where you have to pay a license
to MPEG-LA and to companies like AT&T (see
http://www.att.com/gen/sites/ipsales?pid=19116) is not acceptable:
* not for an open Web (imagine if we all had to pay license fees for
the use of UTF-8 or ASCII - how much limited would we be to publish
content/communicate - any bureaucracy is an obstacle to innovation and
non RF-licensing is such an obstacle),
* nor for the open source community (see
http://sgallagh.wordpress.com/2013/11/06/ietf-mti-codecs-and-fedora/
for a clear discussion of why OpenH264 is not a solution),
* nor does it agree with the IETF's preference of using technologies
with no known IPR claims, or with royalty-free licenses (see rfc3979),
* nor dies it agree with the W3C's assurance that Recommendations can
be implemented on a royalty-free (RF) basis (see
http://www.w3.org/Consortium/Patent-Policy-20040205/).
Therefore, having H.264 as the one and only MTI is not acceptable.

2. All entities MUST support VP8
  .a Acceptable (0.95)
  .b VP8 satisfies the IETF's preference of royalty-free licenses more
so than H.264, because it covers both encoders and decoders, while the
H.264 IP licenses are only for decoders and because all known patents
(bar one) are available royalty-free.
The agreement between Google and MPEG-LA is reassuring for the IPR of
those 11 companies that were part of the VP8 pool at MPEG-LA
(http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachments/88/n-13-03-07.pdf).
The VP8 cross-license agreement with further companies
(http://www.webm-ccl.org/vp8/primary-licensors/) is further
reassuring.

The Nokia IPR declaration (https://datatracker.ietf.org/ipr/2035/)
without willingness to license is obviously an issue for some of us.
As much as I have a gut feeling that the Nokia claims are only patent
trolling, there is certainly FUD.
I would go to 100% "Yes" if there was an analysis of the Nokia IPR
that credibly refutes the claims.

3. All entities MUST support both H.264 and VP8
  .a No
  .b Having both codecs supported helps bring interoperability with
legacy devices into WebRTC.
However, we cannot require the implementation of H.264 for the reasons
stated in 1.b.
Also, a clean cut is likely more appropriate and makes it easier to
move into a brave new world of video connectivity.

4. Browsers MUST support both H.264 and VP8, other entities MUST
support at least one of H.264 and VP8
  .a No
  .b Browsers are just sample players. If we accepted a rule like
this, we would need to extend it to all players, including mobile
phone apps, desktop apps etc.
Such a rule would clearly split the WebRTC world in two camps, with
browsers being the link between them, which is not desirable.

5. All entities MUST support at least one of H.264 and VP8
  .a No
  .b This is just as bad as not choosing an MTI codec, see 7.b.
It also splits the world into two camps, which can only interoperate
with live transcoding services, which introduces latency and is
therefore not desirable.

6. All entities MUST support H.261
  .a Acceptable (0.40)
  .b It's as bad as going back to G.711 for audio. But since it would
only be used where devices do not speak the same higher quality codec,
it might be acceptable. This might be more future-proof than the
{H.261, H.264, VP8} combination, since H.265, VP9 and even Daala are
already on the horizon.

7. There is no MTI video codec
  .a No
  .b We might as well give up on standardisation efforts, since this
does not provide for any interoperability.
Having said this, I believe if we drag out the MTI selection a bit
longer, we may end up with better choices, such as VP9 or Daala for
which the patent situation should be cleaner.

8. All entities MUST support H.261 and all entities MUST support at
least one of H.264 and VP8
  .a Acceptable (0.40)
  .b I think we can achieve the same effect with 6. but 6. is a bit
more future-proof
Also, requiring the support of several codecs certainly increases
maintenance requirements, but a compromise is certainly required.
Maybe H.261 as the MTI and a recommendation on H.264 or VP8 as the
newer codecs to implement right now with a need to revisit every 2
years or so.

9. All entities MUST support Theora
  .a Acceptable (0.45)
  .b Theora is an older codec than VP8 - I thought the world had moved
on to VP8 by now, both from a quality and from an IPR POV.
However, if we have to pick an old codec, I would prefer Theora over
H.261 as the MTI for its better quality/bandwidth use.

10. All entities MUST implement at least two of {VP8, H.264, H.261}
   .a Acceptable (0.35)
   .b It's effectively the same as 8 and thus 8.b applies.

11. All entities MUST implement at least two of {VP8, H.264, H.263}
  .a No
  .b H.263 is as much encumbered as H.264, so why go back to an older
codec that has the same IPR issues. All issues of 1.b still apply to
this option.

12. All entities MUST support decoding using both H.264 and VP8, and
MUST support encoding using at least one of H.264 or VP8
  .a Acceptable (0.05)
  .b Same as 3.b except not every device has to do both codecs, which
is easier for creating applications that only serve part of the
market.

  .a No
  .b same as 11.b

14. All entities MUST implement at least two of {VP8, H.264, Theora}
  .a Acceptable (0.40)
  .b Same as 9.b and 6.b. Theora has less licensing issues than H.263
and is newer than H.261.

15. All entities MUST support decoding using Theora.
  .a No
  .b This is not a solution to MTI - a video conference needs both
decoding and encoding ends to interoperate.

16. All entities MUST support Motion JPEG
  .a Yes, but not as the only MTI
  .b I actually like adding Motion JPEG as a codec, because JPEG
decoding is readily available. However, M-JPEG is not a solution for
the video MTI codec because of it's high bandwidth need and poor
adaptability to available bandwidth. I'd want it, however, as a
solution to low framerate, high resolution video needs such as
document cameras and maybe even screen sharing. This should be a
separate discussion.

Some summary thoughts:

If it wasn't for royalty-free codecs such as Theora, VP8, VP9 and
Daala, we would be completely at the mercy of the MPEG-LA and the
other patent holders of H.264 for video-based Web technology. The
MPEG-LA monopoly thus far had quite a hold on the corporate video
market. Only the recent introduction of better licensing terms allowed
the introduction of new players into this market and created new
competition and cloud-based solutions. WebRTC should further improve
on this situation and not close down the market again by reinforcing
the monopoly. The only sensible solution is to have a royalty-free MTI
codec - a RAND codec can be an optional addition only.

Regards and hope you all had a Merry Christmas,
Silvia.

---

From: cowwoc <[email-masked]>
Date: Fri, 27 Dec 2013 00:43:58 -0500

> my main desktop computer is a factor between 100x and 300x.

I should have been more specific.

I understand that swapping container formats is a lot cheaper, but most 
legacy systems I've seen (e.g. video broadcast systems, conference 
bridges) transcode in order to expose a video stream at multiple 
resolutions. This is a far more expensive operation, and one which they 
already do even though H.264 is available on both ends. Is this a common 
occurrence?

Would anyone care to guess as to what percentage of legacy systems would 
actually use H.264 end-to-end without transcoding if H.264 were selected 
as MTI?

Thanks,
Gili

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Fri, 27 Dec 2013 13:20:23 -0500

Martin -- We are ok to have VP8 in addition to H.264 which is what option 3 is, but are not supportive of eliminating H.264 as a MTI which is a possible outcome of choices under option 10. H.261 is not a reasonable alternative to H.264; it is an inherently low resolution (CIF) and used for video conferencing over the ISDN lines and is a big step backwards.  

Thanks
Sanjay

-----Original Message-----
From: "Martin J. Dürst" [mailto:[email-masked]] 
Sent: Wednesday, December 25, 2013 12:48 AM
To: Mishra, Sanjay
Cc: [email-masked]
Subject: Sanjay Mishra's choices (was: Re: [rtcweb] Straw Poll on Video Codec Alternatives)

Hello Sanjay, others,

[snip]

[snip]

> o   Do not support possible outcome of VP8 and H.261 as MTI

Given that you are in favor of 3, and surprised at the NO here, and even more surprised at your justification. What's the problem if, under this option, some entities (not you) decide to implement VP8 and H.261, and communicate among themselves using either of these two?

It looks to me like there's either a fundamental issue for you that nobody else has mentioned yet, or there is a misunderstanding, and it would be great if you could clarify.

Regards,   Martin.

---

From: cowwoc <[email-masked]>
Date: Fri, 27 Dec 2013 15:06:19 -0500

So you are saying that if H.264 is not selected as MTI you would rather 
drop down to audio-only (or do transcoding) than support any other codec?

I know H.264 is your ideal choice, but what option do you favor if that 
falls through?

Gili

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 27 Dec 2013 20:13:23 +0000

I’m in the camp that questions the value of this straw poll, but it doesn’t take much time for me, and I’m a good little nerd, so I comply with the esteemed chairs’ request.
Please find below my input.
Stephan

     *   Are you in favor of this option [Yes/No/Acceptable]: Acceptable

     *   Do you have any objections to this option, if so please summarize them: Preference for SVC, H.265, modern codecs with scalability in general

     *   Are you in favor of this option [Yes/No/Acceptable]: Acceptable

     *   Do you have any objections to this option, if so please summarize them: Preference for SVC, H.265, modern codecs with scalability in general

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: High cost (licensing, risk allowance) for no gain

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: PC software centric view (Browser!=other entities) is not future proof—doesn’t hold up well even today.

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: No interop point

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: misapplying yesterdays’ technology just for compliance with “requirements” of a business model that is not mine does not make sense to me.

     *   Are you in favor of this option [Yes/No/Acceptable]: Yes.

     *   Do you have any objections to this option, if so please summarize them: Running code (W3C/WhatWG no MTI decision worked out well enough for the web).  There is at least a chance that the world decides on a modern codec, against ideologists and niche folk noisy demands.

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: misapplying yesterdays’ technology just for compliance with “requirements” of a business model that is not mine does not make sense to me.  In addition: High cost (licensing, risk allowance) for no gain

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: Hi risk for no gain.  W3C/WhatWG looked into this, carefully, and decided against it.

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: misapplying yesterdays’ technology just for compliance with “requirements” of a business model that is not mine does not make sense to me. In addition: High cost (licensing, risk allowance) for no gain

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: misapplying yesterdays’ technology just for compliance with “requirements” of a business model that is not mine does not make sense to me. In addition: High cost (licensing, risk allowance) for no gain

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: High cost (licensing, risk allowance) for almost no gain.  Does not mitigate encoder patent risk in any meaningful way.

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: misapplying yesterdays’ technology just for compliance with “requirements” of a business model that is not mine does not make sense to me—especially when many the folks subscribing to the business model don’t want this alternative themselves.

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: Potentially very high cost (licensing, risk allowance) for no gain

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: Hi risk for no gain.  W3C/WhatWG looked into this, carefully, and decided against it.

     *   Are you in favor of this option [Yes/No/Acceptable]: No

     *   Do you have any objections to this option, if so please summarize them: technically inferior beyond reason.

Thanks,

The Chairs

---

From: Brent Kelly <[email-masked]>
Date: Fri, 27 Dec 2013 22:08:58 +0000

My input on the video codec straw poll:

b.    Do you have any objections to this option, if so please summarize them: May kill video WebRTC innovation given liability risk

.      Are you in favor of this option [Yes/No/Acceptable]: Yes

a.    Do you have any objections to this option, if so please summarize them: More work for implementing the standard, but it could allow the different camps to optimize their own preferred codec. More risk too.

a.    Do you have any objections to this option, if so please summarize them: Make the standard "standard" everywhere.

a.    Do you have any objections to this option, if so please summarize them: Enables WebRTC silos and interoperability issues

a.    Do you have any objections to this option, if so please summarize them: I'd hate this option to win the day, but at least the rest of the standard would not be held hostage by the video issue

a.    Do you have any objections to this option, if so please summarize them: Don't like H.261

a.    Do you have any objections to this option, if so please summarize them: H.263 is not the best solution, but it could be used as a default codec if one of the others is not supported. This may be a practical option to break the deadlock.

Thanks,

The Chairs

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Fri, 27 Dec 2013 22:36:57 -0500

Gili -- There are and can be many possibilities based on the specific use cases that a service provider like my employer may need to support that may not exclude transcoding or possibly dropping to audio only. 

It is a bit early for me to conjecture on choices the working group may end up with to then take the consensus call on but I for one hope the group & chairs pay more credence to a decision that is forward looking and not one where an MTI codec is selected but at the cost of needing plug-ins.

Thanks
Sanjay

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of cowwoc
Sent: Friday, December 27, 2013 3:06 PM
To: [email-masked]
Subject: Re: [rtcweb] Sanjay Mishra's choices

So you are saying that if H.264 is not selected as MTI you would rather drop down to audio-only (or do transcoding) than support any other codec?

I know H.264 is your ideal choice, but what option do you favor if that falls through?

Gili

---

From: Tim Panton <[email-masked]>
Date: Sat, 28 Dec 2013 16:08:13 +0000

My straw on the camel's back....

All entities MUST support H.264
Are you in favor of this option [Yes/No/Acceptable]: No
Do you have any objections to this option, if so please summarize them:
The license(s) of H.264 imposes too many unquantified financial/legal restrictions on its use to support 
the level and kinds of innovative use that webRTC may see if it is successful. As such it risks damaging 
innovative players and entrenching the world view of the existing players.
The cisco plugin marginally mitigates this, but does not address mobile apps,
or future business models that don't fit in the current license grant.

All entities MUST support both H.264 and VP8
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
Same objection as 1) - It exposes all webRTC use to the full range of legal risk for both 
codecs.

Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8
Are you in favor of this option [Yes/No/Acceptable]: Acceptable
Do you have any objections to this option, if so please summarize them:
The existing webRTC browser makers already have VP8 and H264 solutions, 
other entities (door bells, baby monitors) can pick the codec their hardware/usecase best
supports, with the certainty that there will not be an interop failure with any webRTC browser.
This proposal does make the launch of a wholly new browser more difficult.

All entities MUST support at least one of H.264 and VP8
Are you in favor of this option [Yes/No/Acceptable]: Acceptable
Do you have any objections to this option, if so please summarize them:
In theory this risks a significant level of interop failure, but in practice it will probably
end up as a 'the market will decide' option, with the huge majority of users ending up 
using a single codec.

All entities MUST support H.261
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
The codec will be unacceptable for a large number of (mobile) use cases requiring dynamic bandwidth adjustment.

There is no MTI video codec
Are you in favor of this option [Yes/No/Acceptable]:Acceptable
Do you have any objections to this option, if so please summarize them:
In theory this risks a significant level of interop failure, but in practice it will probably
end up as a 'the market will decide' option, with the huge majority of users ending up 
using a single codec.

All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8
Are you in favor of this option [Yes/No/Acceptable]: No
Do you have any objections to this option, if so please summarize them:
The H261 codec will be unacceptable for a large number of (mobile) use cases.
This option is worse than 5) since it reduces the pressure on the browser makers 
to avert interop failure.

All entities MUST support Theora
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:

All entities MUST implement at least two of {VP8, H.264, H.261}
Are you in favor of this option [Yes/No/Acceptable]:No 
Do you have any objections to this option, if so please summarize them:
Along with the objections to 5) and 6) This also brings added complexity in implementation,
api, user interface and signalling - for a minimal (or zero) benefit.

All entities MUST implement at least two of {VP8, H.264, H.263}
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
Along with the objections to 10) this adds a new unquantified legal risk over h263.

All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
SDP is really bad at specifying asymmetrical connections - with the current API's this would
ensure that _every_ javascript programer would need to become an SDP expert.

All entities MUST support H.263
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
H263 is unlikely to be acceptable for a large number of (mobile) use cases requiring dynamic bandwidth adjustment.

All entities MUST implement at least two of {VP8, H.264, Theora}
Are you in favor of this option [Yes/No/Acceptable]:No 
Do you have any objections to this option, if so please summarize them:
See 10)

All entities MUST support decoding using Theora.
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
unlikely to be acceptable for a large number of (mobile) use cases.

All entities MUST support Motion JPEG
Are you in favor of this option [Yes/No/Acceptable]:No
Do you have any objections to this option, if so please summarize them:
unlikely to be acceptable for a large number of (mobile) use cases requiring dynamic bandwidth adjustment.

---

From: Maik Merten <[email-masked]>
Date: Sat, 28 Dec 2013 17:46:49 +0100

<snip>

>     .b It's effectively the same as 8 and thus 8.b applies.

Actually, IMO option 10 is quite different from option 8. Note that with 
option 10 anyone who implements VP8 and H.264 (e.g., Mozilla) will not 
have to implement H.261, while still guaranteeing a non-empty 
intersection of codecs (i.e., no negotiation failure).

Option 10 encourages parties to implement two high-performance codecs to 
avoid old codec baggage, which overall will increase real-life 
performance. Option 8 does not have the "baggage drop" option and 
encourages choosing between the two high-performance codecs if one does 
not want to implement three codecs.

Maik

---

From: Maik Merten <[email-masked]>
Date: Sat, 28 Dec 2013 17:59:41 +0100

Am 27.12.2013 21:13, schrieb Stephan Wenger:
>         Are you in favor of this option [Yes/No/Acceptable]: *No*
>
>      2.
>
>         summarize them: *misapplying yesterdays’ technology just for
>         compliance with *“requirements” of a *business model that is not
>         mine does not make sense to me.*

This on the surface looks like you changed your mind a bit on H.261 over 
your position regarding H.261 in the <video> tag ( 
http://www.w3.org/2007/08/video/positions/Nokia.pdf ). Clearly, time has 
passed and H.261 hasn't become any less old and crusty, but I wonder how 
H.261 in a video-communication context is a "misapplication", while it 
apparently qualified as fallback codec for <video>.

Is there something regarding WebRTC that is especially troublesome for 
H.261?

Best regards,

Maik

---

From: Maik Merten <[email-masked]>
Date: Sat, 28 Dec 2013 18:19:56 +0100

Am 28.12.2013 17:08, schrieb Tim Panton:
>         The codec will be unacceptable for a large number of (mobile)
>         use cases requiring dynamic bandwidth adjustment.
>

Can you elaborate on that argument, which you also apply to H.263 and 
Theora?

H.261/H.263/Theora have no fixed increments regarding bitrate and any 
encoder can scale bandwidth basically at will. IMO bandwidth management 
is completely within the encoder realm, and implementations can choose 
to accept new bitrate targets at runtime.

Is there a specific technology you have in mind regarding the term 
"dynmaic bandwidth adjustment"?

>         api, user interface and signalling - for a minimal (or zero)

Apart from the complexity of having to implement two codecs, what 
additional overhead regarding api, user interface (?) and signalling do 
you refer to, given that codec negotiation will be part of establishing 
a WebRTC call anyway?

(The benefit is having no negotiation failure by ensuring non-empty 
codec intersections)

Best regards,

Maik

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 28 Dec 2013 17:22:29 +0000

Maik,
Please don¹t forget that in the IETF process statements like this are my
own, whereas in W3C, I clearly and expressly was representing my then
employer and was bound by in-house guidance (and so were most people
presenting opinions).  W3C is a membership organization and the IETF is
not--different rules apply.
Clearer?
Stephan

On 12/28/13, 8:59 AM, "Maik Merten" <[email-masked]> wrote:

>>         summarize them: *misapplying yesterdays¹ technology just for
>>         compliance with *³requirements² of a *business model that is not

---

From: Maik Merten <[email-masked]>
Date: Sat, 28 Dec 2013 18:26:23 +0100

Stephan,

thanks for elaborating, this indeed paints a clearer picture on how the 
statements seem to diverge on the surface.

Best regards,

Maik

---

From: Ron <[email-masked]>
Date: Sun, 29 Dec 2013 05:01:48 +1030

> not--different rules apply.

With that in mind, the statement in that paper that it was your personal
experience that the quality of H.261 was acceptably sufficient does still
seem like a notable data point.  And seems to accord with what anyone who
has actually looked at it seems to have found too.

I'm not sure what some of the people who have claimed it is unacceptable
even as a fallback on quality grounds are basing that assertion on if it
is something more than glossolalia.  It would be nice to know what their
objective standard for acceptable quality is pinned to.  Especially since
some (or all?) of their employers ship or shipped commercial products
that use it.

> >>    mine does not make sense to me.*

This however seems like an objection that, while I don't doubt its complete
sincerity, is much less relevant to making a technically sound decision.

I could equally say:

 "misapplying today's technology just for compliance with requirements of
  a business model that is not mine does not make sense to me."

Since my business model doesn't revolve around collecting royalties for
a video codec I hold still current patents on, or ensuring I retain a
monopoly lock in for the video application space.

But the IETF isn't concerned with business models, so I'd be a lot more
interested in any technical objections you have, since those are things
that people here who think there are genuine technical benefits to having
a low-complexity, tiny-footprint, unquestionably available codec as the
guaranteed fallback of last resort, could try to address if there indeed
is merit in them that warrants concern and attention.

We're faced with mobile devices that despite ostensibly being able to
do video, would be completely unable to do either H.264 or VP8.  They
could however perfectly do H.261.  Why rule them out of the game right
from the very start?

  Ron

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 28 Dec 2013 11:20:28 -0800

On Sat, Dec 28, 2013 at 10:31 AM, Ron <[email-masked]> wrote:
> do video, would be completely unable to do either H.264 or VP8.

[snip]

"ostensibly" and "do video" are doing a lot of work here.

What we have is a set of mobile devices that support the video
tag but do not (yet) do WebRTC. As far as I know, the manufacturers
haven't made any generic claims that they "do video", it's just that
they currently play videos. Now, the owner of such a device might
make the inference from that the device in question will be able
to do videoconferencing, but that's a naive assumption because
the technical requirements for videoconferencing aren't the
same as those for playing videos. Even if we mandate H.261, there
is a reasonable chance of their expectations being thwarted, since
they might well expect that the quality of video would be comparable,
yet it will not.

-Ekr

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 28 Dec 2013 20:58:54 +0100

>some (or all?) of their employers ship or shipped commercial products

The position statement claims:

  A second alternative would be the reference, as a baseline, of older 
  media compression standards, of which one can be reasonably sure that 
  related patents are expired (or are close to expiration). One example 
  for these codecs is ITU-T Rec. H.261, which (in its first version) was
ratified in November 1988. While not competitive with today’s state of
the art codecs, it’s in the author’s personal experience not that far 
  in its performance from Ogg Theora (this technology is what the 
  current HTML5 draft suggests for the same purpose).

The comparison to Theora seemed fairly crazy to me, so I finally made a
few experiments with ffmpeg's H.261 implementation. It is much better
than `1988` suggests. I am not a fan, but answering the straw poll with
"no" to H.261 requires more evidence than I have seen so far.
-- 
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: Ron <[email-masked]>
Date: Sun, 29 Dec 2013 07:54:23 +1030

On Sat, Dec 28, 2013 at 11:20:28AM -0800, Eric Rescorla wrote:
> 
> Even if we mandate H.261, there is a reasonable chance of their
> expectations being thwarted, since they might well expect that
> the quality of video would be comparable, yet it will not.

You don't get much more thwarted than "no video for you", the only
direction from there is up.  Given a device with a ~4 inch screen,
viewed from a foot or two away, possibly in open daylight, maybe
even while bouncing around on a bus or train or while walking,
maybe with a bunch of scratches on the screen or a plastic cover,
there's a fair bet that a significant percentage of viewers wouldn't
be able to pick the difference between it and a perfectly lossless
image stream anyway.

Is it going to be worse than NTSC television?  How many people were
happy enough to keep buying and watching those?  How many still
would if it was all that they could get?

Sure it might not look optimal on your studio monitor, or your floor
to ceiling boardroom conference screen, or to eyes that have spent
years picking out visual artifacts from lossy codecs.  But we're not
ruling out those people being able to use state of the art codecs
that have no hope at all of running on minimal devices.  We're looking
for a baseline that poses the minimal challenge to everything being
able to support it, for the broadest scope of interoperability.

Things that can will always negotiate up from that.  What is the
technical reason for setting the lowest bar so high that many of the
supposed target devices will never be able to reach it?  There would
seem to be few real barriers to making a more inclusive choice here,
so why don't we just do that and move on?

  Ron

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 28 Dec 2013 13:49:30 -0800

On Sat, Dec 28, 2013 at 1:24 PM, Ron <[email-masked]> wrote:
> direction from there is up.

In that case, I trust you will support having an MTI ASCII art
codec, since some users might only have VT100s?

-Ekr

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 28 Dec 2013 22:50:55 +0100

> would if it was all that they could get?
H.261 has only CIF and QCIF formats defined. Modern cameras tend to not 
support these formats anymore, more often delivering formats like QVGA , 
VGA and various wide screen formats. And applications adapt to these 
modern cameras.
Using H.261 sometimes and modern codec sometimes will create situations 
when you will get unpleasant compromises in video formats, such as 
cropped pictures, or pictures with unused margins, or processing-costly 
remapping that also reduces quality.

That together with the low quality makes it not desirable.

Gunnar

---

From: Maik Merten <[email-masked]>
Date: Sat, 28 Dec 2013 23:45:17 +0100

> remapping that also reduces quality.

I agree that CIF and QCIF are not a perfect match for whatever modern 
cameras deliver. I do think, however, that, e.g., downsampling VGA to 
CIF as part of the H.261 encoding procedure is still more lightweight 
than, e.g., implementing VP8 or H.264 in software. (Downsampling from a 
higher quality source also has some desirable properties regarding 
quality of the final encoding, depending on how it is done.)

In worst case: QVGA fits perfectly into the macroblock structure of H.261...

Not saying this isn't a kludge, it certainly is.

> That together with the low quality makes it not desirable.

It sure is not desirable, but it is available.

What would be *desirable*: A somewhat modern generally accepted royalty 
free video codec, be it, e.g., a free H.264 baseline or a conciliation 
regarding VP8's alleged IPR woes. Now is the time of the year for 
surreal dreams ;-)

Maik

---

From: Ron <[email-masked]>
Date: Sun, 29 Dec 2013 09:33:33 +1030

> codec, since some users might only have VT100s?

It must be your lucky day (and theirs), since you easily could completely
disthrust me and yet still have that!  Rolled Gold Money Back Guaranteed.

Though I am a little surprised that you'd confuse encoding with rendering. ;p
Those people would be perfectly capable of receiving H.261 and displaying
it with whatever coloured dots that they might have available.

Even vlc supports ASCII art rendering if you make the mistake of running
it without DISPLAY set appropriately.  libcaca is readily available and
licenced under the infinitely permissive (if slightly NSFW) WTFPL.

So even people with only line printers and a 20 year old CPU could use
H.261, and print themselves out a flip book that they could fast forward,
slow motion, and even watch in reverse if that really tickled their fancy.
And when they are done, they can snail mail it to their friends to share
and enjoy.

But I'll grant you that people with only ticker tape machines might be
left out in the cold a bit still.

None of which helps people who have a device they bought in the last year
which could perfectly do multiple streams of H.261 in real time, but has
no hope at all of keeping up with even one stream of a higher complexity
codec.  Even if they have a true colour retina display available to them.

We can joke about absurdities, but I'm completely serious about the real
benefits that a low-complexity, tiny-footprint, completely accessible
codec would have as the MTI.  This is going to be the thing that will
still be there long after we've all got 4k Daala and have forgotten that
H.264 and VP8 exist and how crap they were by comparison.  That it's less
than 64k of trivial code makes the long term burden a lot easier to wear.

Actually thinking about this might be the one true gift that all the
stonewalling over the other alternatives has actually given us here.

You know this is true :)  I can't give you the shortcut to Acceptance,
but you're welcome to assail the logic until you find yourself there.
I don't discount that there may be other benefits I haven't thought of
yet either.

  Ron

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 28 Dec 2013 23:06:53 +0000

Interestingly enough, H.261 *never* had a set of picture parameters that
bear a relationship with source formats dominant in the market.
CIF has 288 lines, QCIF 144, both distinctly non NTSC world.  OTOH, the
frame rate is 1/29.97 Hz fractions thereof, definitely not PAL/SECAM.
This is the result of a standardization compromise of the worst sort.
Note that this hasn¹t hindered the adoption of H.261 much.  Perhaps
because, at the time, there were literally no alternatives.  Today there
are.
Stephan

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 28 Dec 2013 15:17:51 -0800

> codec.  Even if they have a true colour retina display available to them.

I don't see this as the tragedy you seem to. And I would note that
FirefoxOS actually runs on devices that are at least potentially in
this class, so it's not because it's a situation I don't have to deal with.

> codec would have as the MTI.

Yes, I realize you're serious. But it turns out that there is a difference
between seriously believing something and actually convincing
people.

So far you have yet to convince me, at least, that it's better
for users to have an MTI bad codec on every device than to have
an MTI good codec on most devices and no video on really low-end
devices.

-Ekr

---

From: Ron <[email-masked]>
Date: Sun, 29 Dec 2013 10:28:18 +1030

> this class, so it's not because it's a situation I don't have to deal with.

I never called this a tragedy.  I just pointed out that if people are going
to say "won't somebody think of the mobile devices!" (which have hardware
H.264 that pretty much every WebRTC app will be unable to use) -- then we
either need to actually think of those devices, and consider a codec that
has a low enough complexity that they'll actually be able to use it -- or
we need to decide they are in fact irrelevant, and any arguments based on
them are then equally irrelevant too including for H.264 or any other codec.

I'm happy to let consensus decide which it will be.  But I'm going to call
bull when people try to ride both sides of that to make blinkered claims
that strain to find any coherent connection with reality.

> between seriously believing something and actually convincing people.
> 

And that's fine, but if the limit of your technical rebuttal is reduction
to absurdity and "I'm not convinced", then you're not making a very strong
case for what is so bad that you feel it must be avoided at any cost.

How can a codec that provides perfectly legible sign language, and that a
significant portion of users probably couldn't pick for being worse than
any other alternative, and that has none of the IPR problems that everyone
is deeply concerned about regarding both the first round options, possibly
be worse than nothing at all?

I'm not rusted on to any alternative here, so I'm inviting you to convince
me if I'm not convincing you.  But you're not offering up much more than
264 legs good, 261 legs bad.  What is so terrible about the video equivalent
to G.711, that's been shipping in successful commercial products for years,
that makes it too repulsive to even consider as the fallback of last resort?

If your reasoning is strong, that shouldn't be a hard question to answer
with plain engineering facts.

  Cheers,
  Ron

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sun, 29 Dec 2013 10:59:24 +1100

> Actually, IMO option 10 is quite different from option 8. Note that with
option 10 anyone who implements VP8 and H.264 (e.g., Mozilla) will not have
to implement H.261, while still guaranteeing a non-empty intersection of
codecs (i.e., no negotiation failure).
> Option 10 encourages parties to implement two high-performance codecs to
avoid old codec baggage, which overall will increase real-life performance.
Option 8 does not have the "baggage drop" option and encourages choosing
between the two high-performance codecs if one does not want to implement
three codecs.

Right. But VP8 and h264 will become old baggage eventually too, so my
comments in 8.b still apply.

HTH,
Silvia.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 28 Dec 2013 16:34:25 -0800

On Sat, Dec 28, 2013 at 3:58 PM, Ron <[email-masked]> wrote:
> 264 legs good, 261 legs bad.

It's not an issue of H.264 versus H.261. It's an issue of modern codecs
versus H.261. VP8 quality is perfectly acceptable here. I suspect Theora
and 263 quality would be as well, but I haven't looked at enough samples
to be sure.

> with plain engineering facts.

This isn't an engineering question. It's a question of what you think is
acceptable to users. After looking at some H.261 video, I think it's
sufficiently bad that we would be better off with no MTI at all. Obviously,
your mileage may vary, but it's not a question that can be answered
with the sorts of arguments you have been offering (or that I can
offer you).

In any case, looking at the survey responses I think it's fairly clear
that there's no real consensus for H.261, so this discussion
seems particularly moot. Feel free to have the last word

-Ekr

---

From: Ron <[email-masked]>
Date: Sun, 29 Dec 2013 11:18:50 +1030

> frame rate is 1/29.97 Hz fractions thereof, definitely not PAL/SECAM.

Let's raise the curtain on the full matrix here shall we (:

 NTSC (visible) frame:  352 x 240 @ 29.97 Hz
 PAL  (visible) frame:  352 x 288 @ 25 Hz

 CIF:                   352 x 288 @ 29.97 Hz

So yes, as you point out, if you select the poorest performance parameters
from both worlds, then CIF does indeed not use those.  It instead actually
selected the highest performance constraints from each.  What a surprising
thing to do.  I'm shocked.

So you get all the resolution of PAL, with the higher frame rate of NTSC.

> This is the result of a standardization compromise of the worst sort.

... which I'd hardly consider to be the _worst_ compromise they could
have thought to make.  It's not like we're talking 44.1 audio here.

Especially given the hardware it was expected to be running on, where
dropping a few frames to get to the lower refresh rate would be trivial
even if not quite ideal - and where losing a few visible scan lines was
something that almost every CRT already did anyway, so dropping a few
extra was unlikely to be terribly noticeable.

Both format conversions lose a little, but not nearly so much as they
would have lost if they were forced to repeat the A-law/mu-law farce
for something as expensive to transcode on 20 year old hardware as
video.  Sounds like a pretty solid and well considered decision to
me, even with the benefit of hindsight to second guess them.

> because, at the time, there were literally no alternatives.

So kind of exactly like what we're faced with here today then ...  ;?

We wouldn't have even got around to thinking about this as an option
if some people didn't firmly claim that their belief about the FUD
surrounding VP8 was showstopper for them, and if the situation wrt
H.264 wasn't such a plainly obvious minefield wrapped in a pratfall
inside a volcano.

If we continue to accept the belief in the FUD about VP8, then we do
indeed have literally no alternatives.  Except perhaps for snatching
utter failure from the hands of disappointment and ignoring a perfectly
viable MTI to declare there should instead be none.

So we've come nowhere since 1988.  Sometimes that happens in engineering.
The smart engineers accept that and make do with what they actually have.

Can we start being smart engineers now?  Pretty Please?

  Ron

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 29 Dec 2013 02:44:25 +0100

>with the sorts of arguments you have been offering (or that I can

Let's say some free software hippie who avoids anything that smells like
software patents like the plague builds their own smartphone with an im-
plementation of this group's protocol. Who exactly benefits when their
smartphone cannot communicate via video with other fully conforming im-
plementations of the protocol? My smartphone has a properly licensed im-
plementation of H.264 and I am happy to receive H.264 streams on it.

But it seems I should also be happy to receive H.261 streams on it, it
does not seem to hurt my eyes much compared to H.264, does not eat all
my bandwidth or battery, and on sending does not make me look notably
worse or burdens me unacceptably in some other way. It is extremely im-
portant to me to be able to be that hippie myself, if I so choose. And
to know when that option is unavailable.

A scenario I have mentioned previously is a median German household in
2014 with two family members sending video simultaneously. If quality in
that scenario is notably worse than e.g. H.264 CBP while driving through
a tunnel, then I would probably agree that we should tell everybody we
can't have nice things. But so far I can't really look at H.261 and tell
the FOSS hippie "don't be that guy" who burdens others unreasonably.

For its age H.261 is actually so good that I am very worried I got the
encoder options wrong or forgot to disable expensive post-processing
filters in my video player during testing, at least relative to what I
had read on the list about it, and experience during Video for Windows
times. If you think H.261 is "not good enough", I think it should be
possible for you to answer Ron's request for an objective standard for
acceptable quality beyond calling it "sufficiently bad" after "looking
at some H.261 video" and claiming there can be no answers.
-- 
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: Ross Finlayson <[email-masked]>
Date: Sun, 29 Dec 2013 19:45:33 -0800

FWIW...

No
> Do you have any objections to this option, if so please summarize them:
The licensing requirements for H.264 will likely be unworkable for many people - e.g., those that produce open source software distributions, and those developers who cannot use Cisco's binary (e.g., because they're developing for platforms that permit statically-linked applications only).  (Generally speaking, licensing schemes that rely upon counting or monitoring copies of data seem anachronistic in the Internet age.)  H.264 may well end up becoming the 'de facto standard' video codec (at least for the next few years), and should, perhaps, be "highly recommended" for WebRTC, but because of the licensing requirements, it cannot be made *mandatory* to implement.

> Are you in favor of this option [Yes/No/Acceptable]:
Yes (under the assumption that the IPR claims against VP8 turn out to be FUD).

No
> Do you have any objections to this option, if so please summarize them:
See my response to question 1.

No.
> Do you have any objections to this option, if so please summarize them:
The term 'browser' isn't well-defined in this context.  An application may support the RTCWeb protocols, and render audio/video, but might not necessarily be thought of as being a general-purpose web browser.  So it doesn't seem to make sense to make such a distinction.  See also my response to question 1.

No.
> Do you have any objections to this option, if so please summarize them:
This doesn't guarantee interoperability between any two endpoints.

> Are you in favor of this option [Yes/No/Acceptable]:
Acceptable (but not as good as option 10; entities that are willing to implement both H.264 and VP8 should not also be required to implement H.261).

No.
> Do you have any objections to this option, if so please summarize them:
This will probably be what we end up with, unfortunately, but it's not something that the IETF should state definitively, because it makes it harder for us to ever change our minds about this in the future.  Saying "The IETF has not reached consensus on a MTI video codec" is better than saying "The IETF has reached consensus that there be no MTI video codec".

> Are you in favor of this option [Yes/No/Acceptable]:
Acceptable (but not as good as option 10; entities that are willing to implement both H.264 and VP8 should not also be required to implement H.261).

> Are you in favor of this option [Yes/No/Acceptable]:
Acceptable (though I imagine that the people who object to VP8 will also object to Theora).

Acceptable.

No.
> Do you have any objections to this option, if so please summarize them:
H.263 is encumbered, right?

No.
> Do you have any objections to this option, if so please summarize them:
See my response to question 1.

No.
> Do you have any objections to this option, if so please summarize them:
H.263 is encumbered, right?

> Are you in favor of this option [Yes/No/Acceptable]:
Acceptable (though I imagine that the people who object to VP8 will also object to Theora).

No.
> Do you have any objections to this option, if so please summarize them:
Unless we also specify that *encoders* support Theora, this doesn't guarantee interoperability.

No.
> Do you have any objections to this option, if so please summarize them:
JPEG is a very poor codec for video (because every frame is an 'I-frame').  It also has very high bandwidth requirements (for reasonably video quality), and is poorly suited for streaming via RTP over a WAN, because each JPEG frame will typically be fragmented over very many RTP packets, but the loss of any one of these RTP packets will typically make the entire frame un-renderable by the receiver.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 30 Dec 2013 11:00:10 +0100

On 12/28/2013 10:50 PM, Gunnar Hellstrom wrote:
> H.261 has only CIF and QCIF formats defined. Modern cameras tend to 
> not support these formats anymore, more often delivering formats like 
> QVGA , VGA and various wide screen formats. And applications adapt to 
> these modern cameras.
> Using H.261 sometimes and modern codec sometimes will create 
> situations when you will get unpleasant compromises in video formats, 
> such as cropped pictures, or pictures with unused margins, or 
> processing-costly remapping that also reduces quality.
>

FWIW, my experiments with FFMPEG's H.261 encoder seem to indicate that 
rescaling a HD picture to CIF and encoding with H.261 is quite a bit 
faster than encoding the picture in HD with VP8 or H.264.

H.261 has quality issues, but I don't think it has speed issues, even if 
you add a remapping stage.

---

From: Tim Panton <[email-masked]>
Date: Mon, 30 Dec 2013 14:05:15 +0000

On 28 Dec 2013, at 17:19, Maik Merten <[email-masked]> wrote:

> Can you elaborate on that argument, which you also apply to H.263 and Theora?
> 
> H.261/H.263/Theora have no fixed increments regarding bitrate and any encoder can scale bandwidth basically at will. IMO bandwidth management is completely within the encoder realm, and implementations can choose to accept new bitrate targets at runtime.

Has any of that been done? Is it exempt from patent attacks? Is there real world experience of how encoders/decoders 
respond to halving the available bandwidth (eg when someone walks between you and the distant wifi ap) during a call?

(I'd note that I think I was the first person to mention using antique codecs to break the logjam - that was back at the IETF in Paris.
Subsequent experiments with VP8 have convinced me that unless a codec natively supports dynamic bandwidth changing
within a call in response to rtcp-fb data then the experience is unacceptable in real world situations). 

> 
> Is there a specific technology you have in mind regarding the term "dynmaic bandwidth adjustment"?

No - just that if you disable rtcp-fb in a VP8 session, you'll have a poor experience - try it in a few wireless environments.

Any codec designed in the TDM pre-allocate-committed-bandwidth days is unlikely to be able to cope 
with the variability of modern 3/4g and wifi networks (IMHO).

I know we are all sitting comfortably on stable Gigabit wired lans doing our testing, but real world usage of webRTC
will be predominantly over unstable wireless links.

Tim.

> Apart from the complexity of having to implement two codecs, what additional overhead regarding api, user interface (?) and signalling do you refer to, given that codec negotiation will be part of establishing a WebRTC call anyway?
> 
> (The benefit is having no negotiation failure by ensuring non-empty codec intersections)
> 
> Best regards,
> 
> Maik

---

From: Tim Panton <[email-masked]>
Date: Mon, 30 Dec 2013 15:01:44 +0000

On 30 Dec 2013, at 03:45, Ross Finlayson <[email-masked]> wrote:

> The term 'browser' isn't well-defined in this context.  An application may support the RTCWeb protocols, and render audio/video, but might not necessarily be thought of as being a general-purpose web browser.  So it doesn't seem to make sense to make such a distinction.  

In my mind the distinction relates to the multi-purpose/programmable nature of a browser as opposed to the single purpose and static 
programming of an app or device. - (and I agree it isn't well defined).

So the goal of this option is to maximise the chances that user with a webRTC browser will be able to interact with the
device or app on the other end. 

Examples might be browsing to your rtcweb doorbell to see who is there, or calling in to a 'professional' video conference system.
We'd want both to work without transcoding, but we don't want to impose the requirement to implement H264 on the doorbell,
or that the whole videoconference engine has to support VP8. 
(Think about how you configure your home router for example - via http/web)

It also neatly avoids the problem that cisco's h264 licence won't help on mobile or embedded devices and allows them to use
VP8 with the certainty that the user's browser will support it. 

Tim.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 30 Dec 2013 07:28:50 -0800

> No - just that if you disable rtcp-fb in a VP8 session, you'll have a poor experience - try it in a few wireless environments.
[BA] Totally agree -- and yet the RTP usage document does not properly account for this.  
draft-ietf-payload-vp8 Section 5 refers to the RPSI and SLI feedback messages. draft-ietf-payload-rtp-h265 Section 8 refers to the RPSI and (newly defined) SPLI messages. 
And yet draft-ietf-rtcweb-rtp-usage Section 5.1.3 indicates that support for SLI is OPTIONAL while Section 5.1.4 indicates that support for RPSI is OPTIONAL.

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 30 Dec 2013 15:47:51 +0000

Tim,

I believe your questions below have been answered before, but allow me to
add more redundancy.

Stephan

On 12/30/13, 6:05 AM, "Tim Panton" <[email-masked]> wrote:

>Has any of that been done?

It¹s bread and butter for encoder developers since at least 1990.

>Is it exempt from patent attacks?

I don¹t know what ³exempt from patent attacks² means, but I will note that
rate control mechanisms are among the most heavily patented encoder
mechanisms.  For two reasons: every real-world encoder needs some form of
rate control (to adapt to application requirements that include network
condition dictated bandwidth as well as user dictated bandwidth), and
features of rate control determine to a significant extent the performance
of an overall system over variable speed networks such as the
Internet--and are, therefore, a critical product differentiator.
Note that the vast majority of rate control patents are written
independently of the codec technology in use.  The possible exception are
rate control mechanisms that cover somewhat exotic codec technologies:
scalability, SI/SP pictures, and the like.  For the purpose of the
discussion at hand, you can lump together into the same risk category any
of the codecs under discussion with the exception of MJPEG.  Note also
that many modern rate control algorithms work on older codecs, and vice
versa.  Design-around is sometimes an option once a patent has been
asserted--normally at the cost of some performance.

>Is there real world experience of how encoders/decoders
>respond to halving the available bandwidth (eg when someone walks between
>you and the distant wifi ap) during a call?

Halving the bandwidth is trivial for H.26x and VPx.  The dynamic range of
bandwidth for any of the codecs under discussion (minus MJPEG perhaps) is
several orders of magnitude.  Yes, there is such real-world experience and
has been since at least 1990 (ISDN MCU implementations, also academic
work).

>
>(I'd note that I think I was the first person to mention using antique
>codecs to break the logjam - that was back at the IETF in Paris.
>Subsequent experiments with VP8 have convinced me that unless a codec
>natively supports dynamic bandwidth changing
>No - just that if you disable rtcp-fb in a VP8 session, you'll have a
>poor experience - try it in a few wireless environments.
>
>I know we are all sitting comfortably on stable Gigabit wired lans doing
>our testing, but real world usage of webRTC

---

From: Tim Panton <[email-masked]>
Date: Mon, 30 Dec 2013 16:00:24 +0000

> I believe your questions below have been answered before, but allow me to

How apposite :-) - Must be some lossy connection between me and the discussion, or 
perhaps I temporarily didn't have the bandwidth to keep up !

> asserted--normally at the cost of some performance.

So If I understand that correctly:
1) rate control on the older codecs is possible.
2) rate control is typically separated from the codec itself
3) rate control is heavily patented
4) a modern H261 implementation would (mostly) use the same rate control techniques as H264 or VP8 

which leaves me wondering if selecting H261 wouldn't mean we retain many of the same IPR risks of newer codecs
but without a licensing authority to go to for fixes/workarounds (or a technical or legal nature). And still
have a significantly worse visual experience at a given bandwidth than for a modern codec.

Seems like the worst of all worlds to me - hopefully I misunderstood.

> has been since at least 1990 (ISDN MCU implementations, also academic

Surely with ISDN the steps were quantized at 64kbps? 

Tim.

---

From: Michael Procter <[email-masked]>
Date: Mon, 30 Dec 2013 16:35:10 +0000

> Surely with ISDN the steps were quantized at 64kbps?

You would be surprised (or maybe you wouldn't).  From recollection,
the allocated bit-rate for video in a 2B ISDN call was basically
whatever was left over once you had chosen the audio codec, and used
some bits for alignment and other signalling.  I seem to recall 68.8
kbps was a common result.  If you mix in some LSD[0], then the
bitrates can get even more obscure.  See H.221 for more details if you
really need them.

The upshot of this is that there is probably a fair amount of
knowledge around dealing with changing bitrates for H.261 from the
ISDN community.

Michael

[0] Low Speed Data!

---

From: Maik Merten <[email-masked]>
Date: Mon, 30 Dec 2013 17:45:54 +0100

I'm not Stephan, but my two cents...

Yes.

Yes.

> 3) rate control is heavily patented

I have no reason to doubt Stephan's expertise there.

> 4) a modern H261 implementation would (mostly) use the same rate control techniques as H264 or VP8

Not necessarily, given how long rate control has been studied and 
implemented.

> have a significantly worse visual experience at a given bandwidth than for a modern codec.

 From my POV: The "same IPR risks" is an overestimation. Rate control is 
one aspect of encoder technology that is not essential to the definition 
of the video format itself. VP8 and H.264 bring IPR risks that are 
inherent to the respective formats ("standard-essential patents"). In 
the area of rate control there always should be work-arounds (in worst 
case implement a rate-control scheme from the early 1990ies).

> Surely with ISDN the steps were quantized at 64kbps?

If a channel requires fixed increments, the usual way of operation is to 
encode content with a bitrate target slightly below that, and fill out 
the remaining bandwidth ("padding with zeros"). The padding is there to 
deal with the inherent bitrate variability of the video formats. So 
getting those fixed steps actually is additional work.

No codec brought up so far operates in fixed steps as normal mode of 
operation - in fact, the discussed codecs are of variable bitrate in 
nature, due to the nature of their entropy coding backends.

---

From: Ron <[email-masked]>
Date: Tue, 31 Dec 2013 03:22:03 +1030

>    rate control techniques as H264 or VP8 

Or the same rate control techniques you'd use for audio, or any
other real time stream that might suffer congestion or loss.

You have a knob that lets you tweak the bitrate.  You (hopefully!)
have information on what bitrate your link can sustain.

You insert math between them, and hope your math isn't so blatantly
obvious that someone already patented it.  Just like anything else.

> which leaves me wondering if selecting H261 wouldn't mean we retain many
> of the same IPR risks of newer codecs but without a licensing authority
> to go to for fixes/workarounds (or a technical or legal nature). And still

I think you might have ...

These are orthogonal problems.  You don't get any protection from the
licence you bought with a codec.  If the rate control method you choose
to use is encumbered then it doesn't matter what codec you chose.  What
happens next is entirely between you and who owns whatever rate control
patents you tripped over.

If the risk of codec IPR is like the risk of playing on the highway,
then the risk of other unrelated IPR is like the risk of being hit by
a meteor.

You can play on the highway, and try to dodge both trucks and meteors.
Or you can move off the highway into the open space and only have to
worry about the meteors.

What Stephan is pointing out, is that even among the people who have
reached a MAD stalemate in the codec patents they hold, there's a
completely separate competition for who can screw the other with a
monopoly on effective rate control mechanisms.  And who can scare
everyone else into not even trying.

> Surely with ISDN the steps were quantized at 64kbps? 

With ISDN, when using more than one timeslot, it's not uncommon to share
the available timeslots between all of the data that needs to be streamed,
(video, audio, control channel etc.) and they don't all have to fall on
an exact timeslot boundary.

You're wasting bandwidth if you don't use all of the available timeslot
space once all your streams are added together, but individually there
is no need for them to each be in strict 64kbs units.  And for H.261 they
quite often are not.

  Ron

---

From: cowwoc <[email-masked]>
Date: Mon, 30 Dec 2013 13:04:01 -0500

> an MTI good codec on most devices and no video on really low-end
Eric,

Here is what I don't get: On the one hand we're being told that we 
should choose H.264 as MTI because it's supported by most legacy or 
resource-constrained/mobile devices; on the other hand, the majority of 
those same devices don't support H.264 encoding in hardware (and never 
will). It just so happens that we can deploy WebRTC on legacy devices 
using an older codec, such as H.261, but that's being rejected as too old.

I'm hearing contradictory messages here. What is our top priority? 
Supporting legacy devices, or video quality? Because it doesn't seem 
like you can have both.

What am I missing here?

Gili

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Dec 2013 10:33:40 -0800

On Mon, Dec 30, 2013 at 10:04 AM, cowwoc <[email-masked]> wrote:
> Here is what I don't get: On the one hand we're being told that we should
> choose H.264 as MTI because it's supported by most legacy or
> will). It just so happens that we can deploy WebRTC on legacy devices using
> an older codec, such as H.261, but that's being rejected as too old.
>
> Supporting legacy devices, or video quality? Because it doesn't seem like
> you can have both.
>
> What am I missing here?

Well, for starters, you should be asking someone who is arguing for
H.264 as MTI, rather than against H.261, which is what I have been
doing here.

With that said, I think you're conflating two things, so I'll try to
explain the argument as I understand it:

1. Legacy non-WebRTC devices that already support H.264 (regardless of
whether or not they have hardware, though generally they do) but which
could interop with WebRTC devices if those devices used H.264.

2. Mobile devices on which we want to deploy WebRTC but which can't
afford to run a modern codec in software but could perhaps use HW
support (and perhaps could run some older codec).

Obviously, the first category of elements do support H.264 and would
benefit from the selection of H.264. They wouldn't benefit from H.261
anywhere as much if at all (depending on if they support it as some
kind of backup or not).

The second category of elements would benefit from H.264 in the
sense that they would be able to play video or have better battery
life or whatever to the extent to which hardware is available and
usable. The extent to which that's a benefit depends on how often
that will be the case; I realize that a lot of people believe that will
be rare, but the evidence I have seen so far seems pretty
equivocal. Sure, if you think you will never be able to use
HW acceleration for H.264, then this doesn't seem like a very
good argument.

I don't really see how that impacts one's view on H.261, though. It
might well be worth mandating some codec if it meant that we
got good mobile video but not bad mobile video. That doesn't
seem like a contradiction at all.

-Ekr

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 30 Dec 2013 19:42:54 +0000

A lot of this discussion seems to be predicated on the assumption that if you cannot have the video that you want, then any video is acceptable. 

Further it all seems to assume that we can have a lower order codec with more bandwidth, whereas when one gets down bandwidth constraints which mobile introduces, that does not necessarily apply.

This may be fine where one has two talking heads as a videostream, but when it is two doctors discussing my latest scan, where the video stream is a representation of that scan, it would seem to be less acceptable to the doctors, and indeed to me.

So an assumption that any video will do in the absence of a higher order codec seems to me to be a false assumption for a number of use cases. Given that this is the predicate for an MTI option that would include a lower order codec for ensuring compatibility, the argument would seem partly flawed.

I also suspect that in the two talking heads scenarios, where the bandwidth required for the video starts impacting the quality of the audio, then people will turn the video off; I know I have done this on Skype in the past.

Keith

> Sent: 28 December 2013 21:24
> To: [email-masked]
> Subject: Re: [rtcweb] Stephan Wenger's choices
> 
> > expectations being thwarted, since they might well expect that the 
> > quality of video would be comparable, yet it will not.
> 
> You don't get much more thwarted than "no video for you", the 
> only direction from there is up.  Given a device with a ~4 
> inch screen, viewed from a foot or two away, possibly in open 
> daylight, maybe even while bouncing around on a bus or train 
> or while walking, maybe with a bunch of scratches on the 
> screen or a plastic cover, there's a fair bet that a 
> significant percentage of viewers wouldn't be able to pick 
> the difference between it and a perfectly lossless image 
> stream anyway.
> 
> Is it going to be worse than NTSC television?  How many 
> people were happy enough to keep buying and watching those?  
> How many still would if it was all that they could get?
> 
> 
> Sure it might not look optimal on your studio monitor, or 
> your floor to ceiling boardroom conference screen, or to eyes 
> that have spent years picking out visual artifacts from lossy 
> codecs.  But we're not ruling out those people being able to 
> use state of the art codecs that have no hope at all of 
> running on minimal devices.  We're looking for a baseline 
> that poses the minimal challenge to everything being able to 
> support it, for the broadest scope of interoperability.
> 
> Things that can will always negotiate up from that.  What is 
> the technical reason for setting the lowest bar so high that 
> many of the supposed target devices will never be able to 
> reach it?  There would seem to be few real barriers to making 
> a more inclusive choice here, so why don't we just do that 
> and move on?
> 
>   Ron
> 
>

---

From: Tim Panton <[email-masked]>
Date: Mon, 30 Dec 2013 19:47:26 +0000

...
> HW acceleration for H.264, then this doesn't seem like a very

There is a subtle assumption there that hardware assist only applies to H264.
I notice that the raspberryPi gained experimental VP8 support using the video GPU
to accelerate it.
http://www.cnx-software.com/2013/01/26/raspberry-pi-now-has-experimental-support-for-vp6-vp8-mjpeg-and-ogg-theora-video-codecs/

What is especially interesting is that this didn't require any hardware changes,
so it may be that many existing 'H264 only' devices could follow suit if there was
a suitable motivation.

Tim.

---

From: Ron <[email-masked]>
Date: Tue, 31 Dec 2013 07:19:17 +1030

On Mon, Dec 30, 2013 at 07:42:54PM +0000, DRAGE, Keith (Keith) wrote:
> A lot of this discussion seems to be predicated on the assumption that if you
> cannot have the video that you want, then any video is acceptable. 

You say that like you think "if I can't have the Ferrari that I want,
or the ability to always use it everywhere, then I'd rather you just
chop my legs off".

> Further it all seems to assume that we can have a lower order codec with more
> bandwidth, whereas when one gets down bandwidth constraints which mobile
> introduces, that does not necessarily apply.
> 
> This may be fine where one has two talking heads as a videostream, but when
> it is two doctors discussing my latest scan, where the video stream is a
> representation of that scan, it would seem to be less acceptable to the
> doctors, and indeed to me.

If you're going to a doctor, who is going to diagnose you on a 4 inch screen
over a shitty mobile connection, then you might get your first wish regardless
of which codec is used!

What you need here is a better doctor, not a better worst case fallback codec.

> So an assumption that any video will do in the absence of a higher order
> codec seems to me to be a false assumption for a number of use cases. Given
> that this is the predicate for an MTI option that would include a lower order
> codec for ensuring compatibility, the argument would seem partly flawed.

So when you've crashed your Ferrari, and there's blood spurting out of your
neck, you'd rather the people your deaf and mute passenger has called for
help would be totally blind as to what is going on and how to help you, than
to have even some image they could show them, and be able to legibly sign
the details of where you are and what help you need?

But I'm pretty sure there's lots of far less critical cases involving far
fewer doctors, where being able to see _something_ is always going to
trump being able to see nothing at all.

> I also suspect that in the two talking heads scenarios, where the bandwidth
> required for the video starts impacting the quality of the audio, then people
> will turn the video off; I know I have done this on Skype in the past.

And nobody is talking about taking that ability away from you.

We're talking about giving people the ability to make that decision for
themselves, instead of ruling it out for no better reason than commercially
tainted artificial snobbery, which considers video to be a premium product
that only users prepared to be fleeced should enjoy.

There is absolutely no technical reason that we cannot make video available
to almost everybody.  And excellent video available to the people with the
necessary means to avail themselves of upgrading to it.

There's only people saying "oh no, we can't let people have that", it
doesn't fit with Our Current Business Model.  (despite the fact we have
shipped H.261 for years in commercial products we made lots of money on)

I quite agree with Eric, that we don't need to go any lower than we do
absolutely need to.  If I thought people might agree on Theora, I'd be
talking about it - but even though Microsoft seem to be not worried at
all about its IPR status, enough to ship Theora video on Bing, I still
fear it will suffer from the same twofaced FUD that VP8 has.

So instead we are talking about the one and only codec that has both
surprisingly acceptable quality for its age, and consensus of no IPR
showstoppers.  The relative fidelity of H.261 for video far exceeds
the relative fidelity of G.711 for speech.

And nobody seems to be able to find an objective technical reason to
rule it out.  If we remember this isn't a vote, that would seem to be
the big thing that the people opposing this really need to find if
they actually want their objections to hold any weight at all.

  Ron

---

From: cowwoc <[email-masked]>
Date: Mon, 30 Dec 2013 17:26:44 -0500

> could interop with WebRTC devices if those devices used H.264.

Just to clarify: do the majority of these devices support encoding and 
decoding H.264 @ 720p in real-time? I'm under the impression that they 
only support hardware decoding, or two-way conversations using low 
resolutions.

Thanks,
Gili

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 31 Dec 2013 00:03:59 +0000

It's well known that many SoCs (including the Broadcom chip used in Raspberry Pi and some Qualcomm chipsets) include hardware acceleration for some of the VPx codecs.  That's not really a surprise as the low level functional blocks of H.264 and VP8 (and also H.263 and some of the older Vpx codecs, so I hear) are quite similar.  It doesn't take the HW folks that much surface and engineering cycles to add support.
It's also well known that those who put the chips into system designs, in their vast majority, do not enable that acceleration for the decoding of VPx.  Your guess is as good as mine why that is so :-)
It's very hard to get your hand on data sheets etc. of the SoCs, unless you are buying hundreds of thousands of them.  Those who obtained them, cannot talk without violating NDAs.
Stephan

From: Tim Panton <[email-masked]<mailto:[email-masked]>>
Date: Mon, 30 Dec 2013 19:47:26 +0000
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Stephan Wenger's choices

On 30 Dec 2013, at 18:33, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

...

Tim.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Dec 2013 16:46:53 -0800

On Mon, Dec 30, 2013 at 2:26 PM, cowwoc <[email-masked]> wrote:
>>> using
> decoding H.264 @ 720p in real-time? I'm under the impression that they only
> support hardware decoding, or two-way conversations using low resolutions.

As I said, I am explaining the argument as I understand it, so I can't
really answer that.

Presumably the devices that JDR was talking about in his presentation in
Vancouver do two-way conversations, since that's sort of the point. I don't
know what resolutions, but maybe Mo, JDR, or Cullen can weigh in.

-Ekr

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 31 Dec 2013 05:23:55 +0000

No.

Video was one component within a frame structure defined by H.221 that also included the audio and data.

That frame structure could leave a video component with 46.4 kbit within a single B-channel. As far as I can remember the video occupies all the space not otherwise allocated to audio, etc, therefore there could be all sorts of bandwidth figures depending on the number of B-channels allocated, and the space taken by other media.

Not sure how much active changing of  bandwidth there might have been once the call was set up.

Keith

> From: rtcweb [mailto:[email-masked]] On Behalf Of Tim Panton
> Sent: 30 December 2013 16:00
> To: Stephan Wenger
> Cc: [email-masked]
> Subject: Re: [rtcweb] Tim Panton's choices
> 
> 
> > I believe your questions below have been answered before, 
> but allow me 
> > to add more redundancy.
> > 
> 
> How apposite :-) - Must be some lossy connection between me 
> and the discussion, or perhaps I temporarily didn't have the 
> bandwidth to keep up !
> 
> > Stephan
> > 
> >>> H.261/H.263/Theora have no fixed increments regarding bitrate and 
> >>> any encoder can scale bandwidth basically at will. IMO bandwidth 
> >>> management is completely within the encoder realm, and 
> >>> implementations can choose to accept new bitrate targets 
> at runtime.
> >> 
> > I don¹t know what ³exempt from patent attacks² means, but I 
> will note 
> > that rate control mechanisms are among the most heavily patented 
> > encoder mechanisms.  For two reasons: every real-world 
> encoder needs 
> > some form of rate control (to adapt to application 
> requirements that 
> > include network condition dictated bandwidth as well as 
> user dictated 
> > bandwidth), and features of rate control determine to a significant 
> > extent the performance of an overall system over variable speed 
> > networks such as the Internet--and are, therefore, a 
> critical product differentiator.
> > independently of the codec technology in use.  The possible 
> exception 
> > are rate control mechanisms that cover somewhat exotic 
> codec technologies:
> > discussion at hand, you can lump together into the same 
> risk category 
> > any of the codecs under discussion with the exception of 
> MJPEG.  Note 
> > also that many modern rate control algorithms work on older codecs, 
> > and vice versa.  Design-around is sometimes an option once a patent 
> > has been asserted--normally at the cost of some performance.
> > 
> 
> which leaves me wondering if selecting H261 wouldn't mean we 
> retain many of the same IPR risks of newer codecs but without 
> a licensing authority to go to for fixes/workarounds (or a 
> technical or legal nature). And still have a significantly 
> worse visual experience at a given bandwidth than for a modern codec.
> 
> >> Is there real world experience of how encoders/decoders respond to 
> >> halving the available bandwidth (eg when someone walks between you 
> >> and the distant wifi ap) during a call?
> > 
> > Halving the bandwidth is trivial for H.26x and VPx.  The 
> dynamic range 
> > of bandwidth for any of the codecs under discussion (minus MJPEG 
> > perhaps) is several orders of magnitude.  Yes, there is such 
> > real-world experience and has been since at least 1990 (ISDN MCU 
> > implementations, also academic work).
>

---

From: Ron <[email-masked]>
Date: Tue, 31 Dec 2013 20:20:44 +1030

On Tue, Dec 31, 2013 at 12:03:59AM +0000, Stephan Wenger wrote:
> It's also well known that those who put the chips into system designs,
> in their vast majority, do not enable that acceleration for the decoding
> of VPx.

And equally well known that the vast majority of such companies which made
such self-interested mistakes are hemorrhaging their market share like a
stuck pig :)  Not to mention losing their most talented developers to more
enlightened platforms that are "on fire" in a far more positive sense!

> It's very hard to get your hand on data sheets etc. of the SoCs, unless
> you are buying hundreds of thousands of them.

It shouldn't take more than a few minutes in google and maybe a couple of
interested email requests to show just how badly outdated this view is.
There are hundreds of potential suppliers and very few of them will turn
away an expression of interest from even very low volume purchasers.

Who would have thought there'd be people who actually want to sell the
things they make.  And who'll sell them direct to anyone on the internet
who sends them a PO.

Welcome to the year of the sub $100 development boards!

  Ron