Subject: Re: [rtcweb] Straw Poll on Video Codec Alternatives

From: "Bogineni, Kalyani" <[email-masked]>
Date: Sun, 5 Jan 2014 16:42:22 -0500

Here are my responses based on use of WebRTC on 3GPP-based cellular devices with 3GPP mandatory video codec H.264,
the availability of performance enhancers in hardware, and IMS interoperability with minimum network enhancements.
Regards,
Kalyani Bogineni
Verizon

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

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

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

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

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]: Acceptable

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

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

6.    All entities MUST support H.261

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

7.    There is no MTI video 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:

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]: No

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

9.    All entities MUST support 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:

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

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

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

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

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]: No

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

13.  All entities MUST support H.263

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

14.  All entities MUST implement at least two of {VP8, H.264, 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:

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:

16.  All entities MUST support Motion JPEG

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 7 Jan 2014 09:52:08 +0100

WG,

This is a reminder that the straw poll ends on January the 12th. If you
haven't provided your position yet, please do so this week.

Please send your ballot as a response to original message sent on the
9th of December by Ted Hardie!

Cheers

Magnus Westerlund
(WG chair)

On 2013-12-09 18:24, Ted Hardie 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.
> 
> 
> 
>  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/
> 
> 
> 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/)
> 
> 
> 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
> 
> 

-- 

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: Adam Fineberg <[email-masked]>
Date: Tue, 07 Jan 2014 09:42:59 -0800

>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Yes
>
>     2.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: Shouldn't differentiate between types without
>         clearer delineation.
>
> 5.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: No interop guarantee
>
> 6.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: No interop guarantee
>
> 8.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Yes
>
>     2.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Yes
>
>     2.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>
>         Are you in favor of this option [Yes/No/Acceptable]: No
>
>     2.
>
>         summarize them: No guarantee of encoding in compatible format
>
>16.
>
>         Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
>     2.
>

-- 
Regards,
Adam

---

From: Paul Coverdale <[email-masked]>
Date: Tue, 7 Jan 2014 17:49:22 -0500

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

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 status unclear and lack of interoperability with existing video
services

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: Not ideal, but provides interoperability (albeit with IPR risk)

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]: Acceptable

b.    Do you have any objections to this option, if so please summarize
them: Not ideal, but provides 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: Doesn't provide 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: Poor quality, and doesn't provide interoperability with existing video
services

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: Basically lets the market decide

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: Poor quality of H.261, not widely deployed

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 provide interoperability with existing video services

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: Poor quality of H.261, not widely deployed

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: 

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.    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 provide full interoperability with existing video services

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: Not widely deployed

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 solve 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: Doesn't solve 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: Not a viable proposal

---

From: cowwoc <[email-masked]>
Date: Tue, 07 Jan 2014 19:14:47 -0500

Paul,

Care to elaborate on these last three responses? How do the first two 
fail to solve interoperability? And why do you feel that the 3rd option 
is "not a viable proposal"?

Thanks,
Gili

On 07/01/2014 5:49 PM, Paul Coverdale wrote:
> 14.All entities MUST implement at least two of {VP8, H.264, 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: *Doesn't solve interoperability*
>
> 15.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: *Doesn't solve interoperability*
>
> 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: *Not a viable proposa*l
>
>

---

From: John Leslie <[email-masked]>
Date: Tue, 7 Jan 2014 20:18:31 -0500

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

 1.  All entities MUST support H.264
  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:
     Too many potential implementors have IPR problems.
   
 2.  All entities MUST support 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:
     Too many potential implementors have IPR problems.

 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:
     Too many potential implementors have IPR problems. (Note, I do support both of these as SHOULD.)

 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]:
     No

  b. Do you have any objections to this option, if so please summarize them:
     Though we call it webrtc, I don't favor browsers being a mandatory middleman. (I do trust at least a few browsers to support both, regardless of our MTI wording.)

 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:
     Too many potential implementors have IPR problems.

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

 7.  There is no MTI video codec
  a. Are you in favor of this option [Yes/No/Acceptable]:
     Acceptable (0.8)

  b. Do you have any objections to this option, if so please summarize them:
     I dislike giving up; but the horse appears pretty dead. Punting to another group would be a Yes.

 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

     #10 is much better.

 9.  All entities MUST support 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:
     IPR situation is unclear.

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]:
     Yes

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]:
     No

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

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. 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:
     Too many potential implementors have IPR problems.

13.  All entities MUST support H.263
  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 situation is unclear.

14.  All entities MUST implement at least two of {VP8, H.264, 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:
     IPR situation is unclear.

15.  All entities MUST support decoding using Theora.
  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:
     Doesn't solve the issue, and IPR situation is unclear.

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:
     IPR situation is unclear (and decidedly not worth clarifying!).

--
John Leslie <[email-masked]>

---

From: Tim Panton <[email-masked]>
Date: Wed, 8 Jan 2014 11:16:56 +0000

On 7 Jan 2014, at 17:42, Adam Fineberg <[email-masked]> wrote:

> 
>> 	• 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: Shouldn't differentiate between types without clearer delineation.

I think that's entirely fair - here's a draft definition:
Browser: 
	An entity that supports multiple usages through dynamically loadable code (javascript) and can render arbitrary user interfaces
using HTML5. (e.g chrome)
Other entities:
	A non-browser entity supports a single dedicated usecase and will lack the ability to dynamically load a user interface or code
to support differing use cases. (e.g. a doorbell)

It's like blank tape vs pre-recorded cassettes (if you are old enough) .

Tim.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 08 Jan 2014 14:48:10 +0100

John,

> them: Doesn't solve the issue, and IPR situation is unclear. 
I didn't see an answer here, but from the comment, it sounds like you 
intended NO.
Is that correct?

---

From: Serge Lachapelle <[email-masked]>
Date: Wed, 8 Jan 2014 15:19:42 +0100

1.  All entities MUST support H.264
  a. Are you in favor of this option [Yes/No/Acceptable]:
     [serge] No
  b. Do you have any objections to this option, if so please summarize them:
     [serge] Licensing methods from MPEG-LA make it hard for individuals
and small companies to build services (non-commercial or commercial, in or
out of the browser, in or out various app stores) around WebRTC. The
amounts involved and accounting chores required are a serious issue for
many small companies / individuals. This will hurt the eco system.

     [serge] Yes

 3.  All entities MUST support both H.264 and VP8
  a. Are you in favor of this option [Yes/No/Acceptable]:
     [serge] Acceptable
  b. Do you have any objections to this option, if so please summarize them:
     [serge] I object to the H.264 licensing cost and chores as I wrote in
1b, but this one opens up the MTI to individuals and small companies to
build services (non-commercial or commercial, in or out of the browser, in
or out various app stores) that interop without with payments or accounting
chores.

     [serge] Yes
     [serge] Similar to 3b.

 5.  All entities MUST support at least one of H.264 and VP8
  a. Are you in favor of this option [Yes/No/Acceptable]:
     [serge] No
  b. Do you have any objections to this option, if so please summarize them:
     [serge] It opens for scenarios that fail. Goes against the reason for
an MTI.

 6.  All entities MUST support H.261
  a. Are you in favor of this option [Yes/No/Acceptable]:
      [serge] No
  b. Do you have any objections to this option, if so please summarize them:
      [serge] The 90's called. They want their codec back. This will
seriously hurt users, especially users with fixed cap mobile data plans.
They will get a subpar experience and be penalized financially for using a
MTI based solution. With everyone leaving desktops and large chunks of
population moving to mobile links for their home broadband, this is an
issue.

 7.  There is no MTI video codec
  a. Are you in favor of this option [Yes/No/Acceptable]:
     [serge] Acceptable
  b. Do you have any objections to this option, if so please summarize them:
    [serge] Not in favor, but I would hate for this workgroup, that has
proven to be capable of iteration and consensus on other topics, to spend
more time on this. We tried, we failed. There is a lot of other work to be
accomplished. Also, a lot is happening in this space with VP9, Daala and
this other codec I keep hearing about, making this conversation less and
less interesting with every month that goes by.

 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]:
     [serge] No
  b. Do you have any objections to this option, if so please summarize them:
     [serge] 261 is too old to offer acceptable performance. These high
bitrates would hurt innocent users' mobile data plans in the name of
interop.

 9.  All entities MUST support Theora
  a. Are you in favor of this option [Yes/No/Acceptable]:
    [serge] Could be acceptable, but I am not informed enough to give an
opinion.
  b. Do you have any objections to this option, if so please summarize them:
    [serge] Needs investigation. While I feel it is better than 261, I have
no clue how it performs for RTC, nor has this been discussed much in this
group.

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]:
     [serge] No
  b. Do you have any objections to this option, if so please summarize them:
      [serge] We can do better than this. This is the equivalent of 6. The
fall back will create situations that do not perform well on mobile
devices. Showing a h.261 stream on a retina screen that is acceptable must
be impossible at normal mobile bitrates. These high bitrates would hurt
innocent users' mobile data plans in the name of interop. Not acceptable.

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]:
     [serge] No.
  b. Do you have any objections to this option, if so please summarize them:
    [serge] H.263 has not been debated or analyzed enough. How does one
license it? Does one need to license it? What % of bw does it take more
than VP8 or 264?

   [serge]   No
    [serge]  Why would we do this? Unclear to me.

13.  All entities MUST support H.263
  a. Are you in favor of this option [Yes/No/Acceptable]:
   [serge]  No.
  b. Do you have any objections to this option, if so please summarize them:
 [serge] H.263 has not been debated or analyzed enough. How does one
license it? Does one need to license it?

14.  All entities MUST implement at least two of {VP8, H.264, Theora}
  a. Are you in favor of this option [Yes/No/Acceptable]:
     [serge] Cannot make an informed decision.
  b. Do you have any objections to this option, if so please summarize them:
    [serge] In all honesty, I do not know enough of Theora nor do I feel it
has been debated in this group enough to form an opinion.

15.  All entities MUST support decoding using Theora.
  a. Are you in favor of this option [Yes/No/Acceptable]:
 [serge] No.
  b. Do you have any objections to this option, if so please summarize them:
  [serge] MTI should be encode as well.

16.  All entities MUST support Motion JPEG
  a. Are you in favor of this option [Yes/No/Acceptable]:
     [serge] No
  b. Do you have any objections to this option, if so please summarize them:
    [serge] Bitrates are incredibly high. This would kill any mobile data
plan immediately and hurt end users.

---

From: cowwoc <[email-masked]>
Date: Wed, 08 Jan 2014 09:40:50 -0500

> It's like blank tape vs pre-recorded cassettes (if you are old enough) .

That is a problematic definition. Native applications running on mobile 
devices can technically do everything you mentioned in the "browser" 
definition. I thought the entire point of this option is to say that web 
browsers must implement X but native applications must implement Y.

I was expecting "browser" to be defined as an "application that enable 
users to render arbitrary web pages" whereas other entities are 
"special-purpose applications that enable users to carry out a limited 
set of operations on a limited set of (web) pages".

Gili

---

From: <[email-masked]>
Date: Wed, 8 Jan 2014 14:48:58 +0000

Please find below my answer to the straw poll on video codec alternatives as requested by the Chairs

http://www.ietf.org/mail-archive/web/rtcweb/current/msg10449.html

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: Lack of interoperability with existing video services + financial risks due to unclear IPR status

b.    Do you have any objections to this option, if so please summarize them: Since H.264 must be supported, the addition of VP8 means additional costs and risks with no value added for interop.

b.    Do you have any objections to this option, if so please summarize them: Same reasons as for 3

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

b.    Do you have any objections to this option, if so please summarize them: Low quality, Does not provide interoperability with existing video services

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

b.    Do you have any objections to this option, if so please summarize them: Same reasons as for 5 and 6

b.    Do you have any objections to this option, if so please summarize them: Does not ensure interoperability with existing video services. Increase potential future transcoding use cases

b.    Do you have any objections to this option, if so please summarize them: Same reasons as for 5 and 6

b.    Do you have any objections to this option, if so please summarize them: Same reasons as for 5 and 6

b.    Do you have any objections to this option, if so please summarize them: Does not ensure interoperability with existing video services

b.    Do you have any objections to this option, if so please summarize them: Lower quality than H.264 or VP8, Market footprint limited and decreasing

b.    Do you have any objections to this option, if so please summarize them: Same reasons as for 5 and 9

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

b.    Do you have any objections to this option, if so please summarize them: Not acceptable from bit rate/quality perspective

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Tim Panton <[email-masked]>
Date: Wed, 8 Jan 2014 15:33:15 +0000

On 8 Jan 2014, at 14:40, cowwoc <[email-masked]> wrote:

> That is a problematic definition. Native applications running on mobile devices can technically do everything you mentioned in the "browser" definition. I thought the entire point of this option is to say that web browsers must implement X but native applications must implement Y.

True, but any mobile app that allows the user to select a (possibly user defined) HTML5+javascript interface needs to support both codecs - because it can't know in advance what the other end will support. - If I point my general-purpose-home-automation-console app at the boiler I may need to render an h264 flame image, when accessing with my doorbell the same app may render a VP8 stream of the delivery driver. - So the general purpose app needs the 'browser' dual codec MTI.

Conversely the boiler will probably ship with a dedicated this-make-of-boiler-only mobile app with a prebuilt UI which only speaks h264.
The device specific app needs the ' other entity' single codec MTI.

> 
> I was expecting "browser" to be defined as an "application that enable users to render arbitrary web pages" whereas other entities are "special-purpose applications that enable users to carry out a limited set of operations on a limited set of (web) pages".

I was avoiding the words 'pages','web-server','HTTP' from my definition as I feel that the transport and encapsulation isn't the issue. It's the dynamic - user selected - unpredictability of the created-at-runtime interface required by the other peer that matters here.

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

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Wed, 8 Jan 2014 15:39:43 +0000

Dear all,

1.    All entities MUST support VP8

-          Brings a higher cost or does not allow to interoperate with existing solutions/platforms.

-          VP8 is not yet a standard and would benefit of going through the full ISO process.

-          VP8 has a declaration of un-licensable IPR, https://ietf.org/ipr/2035/  .

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

-          One MTI is enough if the codec provides “good enough” performances.

-          VP8 Brings a higher cost or does not allow to interoperate with existing solutions/platforms.

-          VP8 is not yet a standard and would benefit of going through the full ISO process.

-          VP8 has a declaration of un-licensable IPR, https://ietf.org/ipr/2035/  .

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

-          There is no reason to make a distinction between browser and non-browser.

-          One MTI is enough if the codec provides “good enough” performances.

-          VP8 Brings a higher cost or does not allow to interoperate with existing solutions/platforms.

-          VP8 is not yet a standard and would benefit of going through the full ISO process.

-          VP8 has a declaration of un-licensable IPR, https://ietf.org/ipr/2035/  .

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

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

-          Does not insure interoperability

-          This is somewhat equivalent to no MTI while slowing down the widespread adoption of a more powerful codec by RTCWeb.

1.    All entities MUST support H.261

-          In terms of “old codecs” H263 would be a better choice.

-          It took years to remove H261 from specifications and platforms, RTCWeb should not mandate it back.

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

-          In terms of “old codecs” H263 would be a better choice than H261.

-          It took years to remove normative support of H261 from specifications and platforms, RTCWeb should not mandate it back.

-          VP8 Brings a higher cost or does not allow to interoperate with existing solutions/platforms.

-          VP8 is not yet a standard and would benefit of going through the full ISO process.

-          VP8 has a declaration of un-licensable IPR, https://ietf.org/ipr/2035/  .

1.    All entities MUST support Theora

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

-          Not widely supported in hardware

-          Licensing status is not clear enough

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

-          In terms of “old codecs” H263 would be a better choice than H261.

-          It took years to remove H261 from specifications and platforms, RTCWeb should not mandate it back.

-          VP8 Brings a higher cost or does not allow to interoperate with existing solutions/platforms.

-          VP8 is not yet a standard and would benefit of going through the full ISO process.

-          VP8 has a declaration of un-licensable IPR, https://ietf.org/ipr/2035/  .

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

-          VP8 Brings a higher cost or does not allow to interoperate with existing solutions/platforms.

-          VP8 is not yet a standard and would benefit of going through the full ISO process.

-          VP8 has a declaration of un-licensable IPR, https://ietf.org/ipr/2035/  .

1.    All entities MUST support H.263

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

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

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

-          Theora is not widely supported in hardware

-          Theora’s licensing status is not clear enough

-          VP8 Brings a higher cost or does not allow to interoperate with existing solutions/platforms.

-          VP8 is not yet a standard and would benefit of going through the full ISO process.

-          VP8 has a declaration of un-licensable IPR, https://ietf.org/ipr/2035/

1.    All entities MUST support decoding using Theora.

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

-          Not widely supported in hardware

-          Licensing status is not clear enough

1.    All entities MUST support Motion JPEG

Sincerely,

Gaëlle

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "cb.list6" <[email-masked]>
Date: Wed, 8 Jan 2014 09:20:30 -0800

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: There are entities that are unable to comply with the license terms
      around H.264
      2.

      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: There are entities that are unable to accept the legal risk of
      shipping VP8
      3.

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

   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]: NO
      2.

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

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

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

      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: Old inefficient codec. No reason to be forced to carry the cost of
      having this code.
      7.

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

      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.
      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]: NO
      2.

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

      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: Old inefficient codec. No reason to be forced to carry the cost
      of having this code. Also unclear IPR issues around this codec.
      10.

      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: H.261 is an Old inefficient codec. No reason to be forced to
      carry the cost of having this code.
      11.

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

   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]: NO
      2.

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

      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: Older less-efficient codec, IPR issues.
      14.

      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: Code cost and IPR risk of carrying Theora, impossibility
of complying
      by shipping VP8 and H.264 for almost all entities.
      15.

      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: Code cost and IPR risk of carrying Theora. Also my understanding of
      Theora is that there is no separate smaller decoder-only codebase.
      16.

      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: Codec does not provide sufficient quality at reasonable
bandwidth for
      any use case.

On Wed, Jan 8, 2014 at 7:39 AM, Gaelle Martin-Cocher <
[email-masked]> wrote:

> -          This is somewhat equivalent to no MTI while slowing down the
> widespread adoption of a more powerful codec by RTCWeb.
>
> -          It took years to remove H261 from specifications and
> platforms, RTCWeb should not mandate it back.
>
> -          It took years to remove normative support of H261 from
> specifications and platforms, RTCWeb should not mandate it back.
>
> -          It took years to remove H261 from specifications and
> platforms, RTCWeb should not mandate it back.
>
> 1.    All entities MUST support decoding using both H.264 and VP8, and
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

---

From: Hervé W. <[email-masked]>
Date: Wed, 8 Jan 2014 18:47:20 +0100

No

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

Fixating on either H.264 or VP8 was not productive and don't like the
patent licensing situation. OpenH264 is generous, but far from perfect.

No

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

Fixating on either H.264 or VP8 was not productive and choosing VP8
while the Nokia claims are unresolved is not a good plan.

No

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

Twice the risk, twice the maintenance burden.

No

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

Twice the risk, twice the maintenance burden. Risk of negotiating
failure if multiple parties aren't browsers.

No

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

Risk of negotiating failure.

Yes

Quality/bitrate not as bad as MJPEG. Available bitrates go up, even in
mobile space.
Those 256kbit/s streams are just 31.25 kibibytes per second (32 kilobyte/sec).
Implementations aren't widespread now, but were.
vic, ffmpeg/libav, IVS, microsoft (M261), intel has at least one if
not more (intel's ipp library 7.0), pvrg-p64

No

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

Risk of negotiating failure. Winding up with this situation is one
thing. Choosing it is quite another.

No

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

Twice the maintenance burden. Licensing burden for h264, unresolved
claims for vp8.

Yes

IPR FUD was spread in the past without any followup claims despite
commercial products. http://wiki.xiph.org/Games_that_use_Theora
That's no guarantee, but neither is h264.
Uncertainty about its quality/bitrate is not a strong argument; tools
are freely available to encode and decode.

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

Acceptable

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

Twice the maintenance burden. Licensing burden for h264, unresolved
claims for vp8. H.261 can be avoid by those that can and wish to do so.

No

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

Twice the maintenance burden. Licensing burden for h264, licensing
burden for h263, unresolved
claims for vp8.

> 12. All entities MUST support decoding using both H.264 and VP8, and

No

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

Licensing burden for h264.

No

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

Licensing burden for h263

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

Acceptable

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

Twice the maintenance burden. Licensing burden for h264, unresolved
claims for vp8.

No

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

Could still cause negotiation failure if the implementer just wants a
rubber stamp that says 'rtcweb compliant' and does not implement
Theora encoding.

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

Acceptable

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

Worse performance than h261.

- Hervé

---

From: Steve Donovan <[email-masked]>
Date: Wed, 08 Jan 2014 13:44:20 -0600

>         summarize them: I don't see the benefit of differentiating
>         browsers and "other entities".  Interop should exist between
>         all recweb implementations.
>
> 5.
>
>         summarize them: The selection of the MTI codec(s) must ensure
>         all implementations have at least one codec in common.  This
>         option does not address that requirement.
>
> 6.
>
>         summarize them: The selection of the MTI codec(s) must ensure
>         all implementations have at least one codec in common.  This
>         option does not address that requirement.
>
> 8.
>
>         summarize them: As I understand it, this does not guarantee
>         successful negotiation of a video codec.
>
>16.
>

---

From: Xavier Marjou <[email-masked]>
Date: Thu, 9 Jan 2014 00:22:45 +0100

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: *Transcoding (ie: cost + lower quality video) needed for interworking
with existing video services + IPR uncertainties*

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

them: *c.f. 2.b for VP8*

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]: *NO*

them: *c.f 2.b for 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: *Transcoding possibly needed even for basic calls between different
types of 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: *Law quality + transcoding needed for interoperability*

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

them: *same as 5.b*

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: *Transcoding needed for interoperability if VP8 or 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: *Transcoding needed for 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:* Transcoding needed for interoperability if VP8 or 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: *Transcoding needed for interoperability if VP8 or H.263*

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

them: *Same as 5.b*

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: *Transcoding needed for 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: *Transcoding needed for 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: *Transcoding needed for 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: *Transcoding needed for interoperability + bad quality + bit rate*

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

> Video Codec Selection Process” (
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg10448.html )then
> 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.
>
> 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.
>
> 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
> 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 MUST support
> https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/<https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/>
>
> 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/)
>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 8 Jan 2014 18:20:01 -0800

1.

         This forces all conformant WebRTC implementations to have to deal
         with MPEG-LA licensing restrictions, thereby stunting the
growth of the
         ecosystem.
         2.

         No objections. Google is a strong supporter of this option and is
         willing  to provide a binary VP8 plugin, if doing so would
make life easier
         for certain WebRTC implementations.
         3.

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

         Not possible for implementations that can't deal with MPEG-LA
         restrictions to be conformant.
         4.

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

         Like #3, but non-browser endpoints can be completely conformant.
         5.

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

         This is the best of the no-guaranteed-interop outcomes; at least
         the possible cases that app developers need to handle are
known. Of the
         "acceptable", it is my least-preferred choice.
         6.

         The quality of H.261 is low enough that I don't think it is
         possible to create a competitive application that works
between apps that
         only agree on H.261.
         7.

         No interoperability, or limits on what codecs might be encountered.
         8.

         Like #10, but worse because all implementations need to incur the
         technical cost of a H.261 implementation.
         9.

         See #6.
         10.

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

         No objections; better than #8, since browsers are not forced to
         deal with H.261.
         11.

         Worse than #10.
         12.

         Not clear what the benefit is over #3.
         13.

         Worse than #1.
         14.

         Worse than #10.
         15.

         See #9.
         16.

         Worse than #6.

---

From: <[email-masked]>
Date: Thu, 9 Jan 2014 11:55:54 +0000

Hi all,

Here's my input to the poll.

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

VP8 has not been developed and is not maintained through an open and recognized standardization process. It provides no additional technical value over H.264, which is widely used in real-time video conferencing, has wide hardware support, and is included in various other video related standards. This makes it unsuitable as mandatory to implement.

> 3. All entities MUST support both H.264 and VP8  . 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:

VP8 has not been developed and is not maintained through an open and recognized standardization process. It provides no additional technical value over H.264, which is widely used in real-time video conferencing, has wide hardware support, and is included in various other video related standards.

> support at least one of H.264 and VP8  . 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:

Making browsers a special case creates confusion. 

> 5. All entities MUST support at least one of H.264 and VP8  . 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:

This is in practice no better than "There is no MTI video codec" from interoperability perspective.

VP8 has not been developed and is not maintained through an open and recognized standardization process. It provides no additional technical value over H.264, which is widely used in real-time video conferencing, has wide hardware support, and is included in various other video related standards.

>  . 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 offer high enough quality and is not widely enough supported. 

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

Does not accomplish interoperability but still better than some of the either-or or lower quality fallback options. In case none of the other options gets a clear consensus behind it, the WG should accept this option for now rather than spending more time arguing. Otherwise we risk having many more areas of interop problems for the next 2-3 years, after which all of the codecs now considered may be legacy from competitive services perspective anyway. 

> least one of H.264 and VP8  . 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 offer high enough quality and is not widely enough supported.

>  . 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 has been very little analysis on Theora in WebRTC context compared to other codecs being considered. 

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

NO.

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

VP8 has not been developed and is not maintained through an open and recognized standardization process. It provides no additional technical value over H.264, which is widely used in real-time video conferencing, has wide hardware support, and is included in various other video related standards.

H.261 does not offer high enough quality and is not widely enough supported.

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

NO.

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

This would achieve interoperability with reasonable minimum quality, but Option 13 would achieve the same in practice in a cleaner way. These two-out-of-three options should not be a preferred way for standards setting. 

VP8 has not been developed and is not maintained through an open and recognized standardization process. It provides no additional technical value over H.264, which is widely used in real-time video conferencing, has wide hardware support, and is included in various other video related standards.

> MUST support encoding using at least one of H.264 or VP8  . 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:

Making a distinction between encoding and decoding creates confusion. Benefits are not clear enough.   

VP8 has not been developed and is not maintained through an open and recognized standardization process. It provides no additional technical value over H.264, which is widely used in real-time video conferencing, has wide hardware support, and is included in various other video related standards.

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

This is not the best option, but as a fallback better than H.261 or Theora. Quality would be acceptable for some use cases. H.263 is still somewhat widely available. 

> . 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 has been very little analysis on Theora in WebRTC context compared to other codecs being considered.

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

Making a distinction between encoding and decoding creates confusion.  

> 16. All entities MUST support Motion JPEG  . 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:

MJPEG is too inefficient to be useful in most situations.

Regards,
	Markus

---

From: Leon Geyser <[email-masked]>
Date: Thu, 9 Jan 2014 16:16:04 +0200

1.

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

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

      Do you have any objections to this option, if so please summarize
      them: Won't help interoperability.
      6.

      Do you have any objections to this option, if so please summarize
      them: Won't help interoperability.
      8.

      Do you have any objections to this option, if so please summarize
      them: Won't help interoperability.
      16.

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

On 9 January 2014 13:55, <[email-masked]> wrote:

> VP8 has not been developed and is not maintained through an open and
> recognized standardization process. It provides no additional technical
> value over H.264, which is widely used in real-time video conferencing, has
> wide hardware support, and is included in various other video related
> standards. This makes it unsuitable as mandatory to implement.
>
> VP8 has not been developed and is not maintained through an open and
> recognized standardization process. It provides no additional technical
> value over H.264, which is widely used in real-time video conferencing, has
> wide hardware support, and is included in various other video related
> standards.
>
> VP8 has not been developed and is not maintained through an open and
> recognized standardization process. It provides no additional technical
> value over H.264, which is widely used in real-time video conferencing, has
> wide hardware support, and is included in various other video related
> standards.
>
> Does not accomplish interoperability but still better than some of the
> either-or or lower quality fallback options. In case none of the other
> options gets a clear consensus behind it, the WG should accept this option
> for now rather than spending more time arguing. Otherwise we risk having
> many more areas of interop problems for the next 2-3 years, after which all
> of the codecs now considered may be legacy from competitive services
> perspective anyway.
>
> VP8 has not been developed and is not maintained through an open and
> recognized standardization process. It provides no additional technical
> value over H.264, which is widely used in real-time video conferencing, has
> wide hardware support, and is included in various other video related
> standards.
>
> This would achieve interoperability with reasonable minimum quality, but
> Option 13 would achieve the same in practice in a cleaner way. These
> two-out-of-three options should not be a preferred way for standards
> setting.
>
> VP8 has not been developed and is not maintained through an open and
> recognized standardization process. It provides no additional technical
> value over H.264, which is widely used in real-time video conferencing, has
> wide hardware support, and is included in various other video related
> standards.
>
> Benefits are not clear enough.
>
> VP8 has not been developed and is not maintained through an open and
> recognized standardization process. It provides no additional technical
> value over H.264, which is widely used in real-time video conferencing, has
> wide hardware support, and is included in various other video related
> standards.
>
> This is not the best option, but as a fallback better than H.261 or
> Theora. Quality would be acceptable for some use cases. H.263 is still
> somewhat widely available.
>

---

From: Gavin Llewellyn <[email-masked]>
Date: Thu, 9 Jan 2014 16:39:12 +0000

Acceptable

Yes

Acceptable

Acceptable

Acceptable

No
>  b. Do you have any objections to this option, if so please summarize them:
I think audio-only (perhaps accompanied with a still picture
transferred over a DataChannel) would give a better user experience
than poor quality video.

No
>  b. Do you have any objections to this option, if so please summarize them:
I think we should aim for guaranteed interoperability by implementing
at most two codecs.

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

Acceptable
> b. Do you have any objections to this option, if so please summarize them:
If you're going to mandate a single codec, at least make it one of the
two real contenders - don't try to achieve compromise by making
everyone equally unhappy.

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

Acceptable

Yes

No
>  b. Do you have any objections to this option, if so please summarize them:
Guarantees licensing headaches, but still gives you a sub-optimal result.

Acceptable

Acceptable

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

--
Principal Design Engineer
Crocodile RCS Ltd

---

From: Erik Lagerway <[email-masked]>
Date: Thu, 9 Jan 2014 09:13:38 -0800

>       Are you in favor of this option [Yes/No/Acceptable]: *NO*
>       2.
>
>       them: *Insisting on royalty bearing codec will have an adverse
>       effect on software development, specifically with indie development in
>       mind. I would take the IPR issues over royalties.*
>       2.
>
>       Are you in favor of this option [Yes/No/Acceptable]: *YES*
>       2.
>
>       them: *It seems this codec is getting closer to MPEG-LA thumbs up
>       so I don't see why we should not all use this codec as a minimum. It's also
>       the current codec in the majority of WebRTC implementations today.*
>       3.
>
>       Are you in favor of this option [Yes/No/Acceptable]: *NO*
>       2.
>
>       them: *See 1.*
>       Are you in favor of this option [Yes/No/Acceptable]: *YES*
>       2.
>
>       them: *This is likely the best scenario after VP8*
>       5.
>
>       Are you in favor of this option [Yes/No/Acceptable]:  *Acceptable*
>       2.
>
>       Are you in favor of this option [Yes/No/Acceptable]: *NO*
>       2.
>
>       them: *Feels like we are going backwards here.*
>       7.
>
>       Are you in favor of this option [Yes/No/Acceptable]: *Acceptable*
>       2.
>
>       them: *If we can't agree on a specific codec this could be a way
>       forward and put the MTI issue to rest.*
>       8.
>
>       Are you in favor of this option [Yes/No/Acceptable]: *NO*
>       2.
>
>       them: *See 6*
>       Are you in favor of this option [Yes/No/Acceptable]: *NO*
>       2.
>
>       them: *Too obscure.*
>       Are you in favor of this option [Yes/No/Acceptable]: *NO*
>       2.
>
>       them: *Mandating one codec is hard enough.*
>       11.
>
>       Are you in favor of this option [Yes/No/Acceptable]: *NO*
>       2.
>
>       them: *See 10*
>       Are you in favor of this option [Yes/No/Acceptable]: *NO*
>       2.
>
>       them: *See 10*
>       Are you in favor of this option [Yes/No/Acceptable]: *NO*
>       2.
>
>       them: *See 6*
>       Are you in favor of this option [Yes/No/Acceptable]: *NO*
>       2.
>
>       them: *See 10*
>       Are you in favor of this option [Yes/No/Acceptable]: *NO*
>       2.
>
>       them: *See 9*
>       Are you in favor of this option [Yes/No/Acceptable]: *NO*
>       2.
>
>       them: *See 9*

---

From: Benjamin Schwartz <[email-masked]>
Date: Thu, 9 Jan 2014 09:18:15 -0800

1.

   Do you have any objections to this option, if so please summarize them:
   We are discussing not just an IETF standard but a Web standard.  Web
   standards must take an even stronger stance against legal straitjackets
   because usage is enormous in scale and unpredictably creative in nature.

   1.

   Are you in favor of this option [Yes/No/Acceptable]: YES.  I think
   remaining opposition to VP8 MTI is based in large part on a perception of
   risk that will quickly dissipate.
   2.

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

   1.

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

   1.

   Do you have any objections to this option, if so please summarize them:
    An ecosystem where all the large browser providers support both codecs
   would be good for small providers of webrtc-enabled browsers, programs, and
   devices, who might only be able to ship one codec.  However, this option
   makes no distinction, e.g. requiring every copy of Gnome Epiphany and KDE
   Konqueror to include h.264 enc and dec in order to be compliant.  A "MUST
   support one, SHOULD support both" might be acceptable.

   1.

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

   1.

   Are you in favor of this option [Yes/No/Acceptable]:  YES, BUT I reject
   the phrasing of this question, because I believe the option on the mailing
   list was raised without resolving the distinction between H.261 and MPEG-1
   Part 2.  I believe that MPEG-1 Part 2 is a suitable MTI codec for rtcweb.
    It was completed 24 years ago, and finalized 22 years ago, so its IPR
   status is clear.  It has widespread hardware and software support, is very
   low complexity to decode in software, and has compression efficiency
   similar to DVD video.
   2.

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

   1.

   Do you have any objections to this option, if so please summarize them:
    Sometimes it is smarter to admit failure than to pretend success.

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]:  YES, with the
   caveat of #6 (MPEG-1 Part 2).
   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]:  YES.  Theora,
   a.k.a. VP3.2, is similar in techniques and performance to MPEG-4
Part 2 or H.263+.
    Its long-standing broad deployment, deliberately old-fashioned internal
   design, and MPEG LA's "granting Google a license to techniques that may be
   essential to VP8 and earlier-generation VPx video compression
   technologies", combine to make its IPR status exceptionally clear.
   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]:  Yes, with the
   caveat of #6 (MPEG-1 Part 2).
   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.  I'm not aware
   of any IPR benefit conferred by H.263 over H.264.
   2.

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

   1.

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

   1.

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

   1.

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

   Do you have any objections to this option, if so please summarize them:
    A decode-only MTI doesn't accomplish much, but I suppose it's better than
   nothing.

   1.

   Are you in favor of this option [Yes/No/Acceptable]:  ACCEPTABLE.  It
   wouldn't be interoperable video, but at least it would get us interoperable
   slideshows.
   2.

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

---

From: Robin Raymond <[email-masked]>
Date: Thu, 09 Jan 2014 13:35:22 -0500

1. All entities MUST support H.264
     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: Due to IPR. Markets forces will adequately
        determine where H.264 must be done and there is a strong
        incentive to add H.264 where-ever possible. We don't need to
        mandate in use cases where this is not true. Not all
        implementations can download a pre-compiled binary to "work
        around" the licensing fee issue at run-time.
 2. All entities MUST support VP8
     1. Are you in favor of this option [Yes/No/Acceptable]: Acceptable
     2. Do you have any objections to this option, if so please
        summarize them: While there is concern over IPR, this appears to
        be free at the moment. I would change my opinion the moment any
        licensing fees became attached. 
 3. All entities MUST support both H.264 and VP8
     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: See #1
 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]: Acceptable
     2. Do you have any objections to this option, if so please
        summarize them: Mandating for browser is fine so long as not
        every instance requires licensing issues.
 5. All entities MUST support at least one of H.264 and VP8
     1. Are you in favor of this option [Yes/No/Acceptable]: Acceptable
     2. Do you have any objections to this option, if so please
        summarize them: Market forces will ensure sufficient
        compatibility since there is an incentive to do both. 
 6. All entities MUST support H.261
     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: Would prefer market forces to mandating legacy
 7. There is no MTI video codec
     1. Are you in favor of this option [Yes/No/Acceptable]: Yes
     2. Do you have any objections to this option, if so please
        summarize them: Market forces / natural incentives to be
        compatible will ensure compatibility.
 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]: No
     2. Do you have any objections to this option, if so please
        summarize them: See #6 
 9. 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: While it's great that a free implementation
        exists, I worry about its optimization on mobile devices. 
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]: No
     2. Do you have any objections to this option, if so please
        summarize them: See #1, effectively causes many to need to
        implement H.261 if they can't do H.264 
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]: No
     2. Do you have any objections to this option, if so please
        summarize them: See #1, effectively causes many to need to
        implement H.263 even if they don't need it.
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]: No
     2. Do you have any objections to this option, if so please
        summarize them: See #1 
13. All entities MUST support H.263
     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: Would prefer no MTI / market forces to this 
14. All entities MUST implement at least two of {VP8, H.264, 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: See #1, effectively cause many to need to
        implement Theora even if they don't need it 
15. All entities MUST support decoding using 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: See #9 
16. All entities MUST support Motion JPEG
     1. Are you in favor of this option [Yes/No/Acceptable]: Acceptable
     2. Do you have any objections to this option, if so please
        summarize them: It's not ideal but it's fairly light weight for
        implementation (albeit high bandwidth relatively speaking).
        Effectively to me this means "let market forces decide
        compatibility" with an absolute bare minimal fallback.

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 9 Jan 2014 15:31:12 -0800

I'm using the 0.0-1.0 scale for "ACCEPTABLE" that some other people have used.

NO

Too many IPR issues which would cause an "Mandatory to Implement"
codec to be a "Mandatory to License" codec, which would lock out too
many smaller players from the WebRTC community.

YES

High quality with low IPR issues makes it a good MTI codec.

NO

Same as #1.

NO

Treating browsers special doesn't relieve the IPR issues enough.

ACCEPTABLE (0.1)

It doesn't really achieve anything, but there's not much to disagree with.

ACCEPTABLE (0.2)

The quality is low, but perhaps better than no MTI, and acceptable for
some use cases.

ACCEPTABLE (0.5)

If this means "we should never have an MTI", I'd say "NO".  If this
means "we admit we can't decide one right now in this forum, and we'll
either wait or try another forum", I'd find that acceptable.

ACCEPTABLE (0.2)

The same as #5 and #6.

ACCEPTABLE (0.4)

Lower quality than VP8, but not any better with IPR issues (as far as
I know), so I don't see the point.  But I could still live with it.

ACCEPTABLE (0.2)

Sort of the same as #5 and #6.

NO

Too many IPR issues.

NO

If it were clear that there were no IPR issues with decoding H.264,
then I would say this is "YES", but since it's not clear, I have to go
with "NO".

NO

Too many IPR issues.

ACCEPTABLE (0.8)

This is almost the same as #2.

NO

It doesn't accomplish anything, but leaves baggage in the standard.

ACCEPTABLE (0.2)

This isn't very useful for most use cases, but may be acceptable for
some (low-framerate screencast, or use on fast LANs)

---

From: Bo Burman <[email-masked]>
Date: Fri, 10 Jan 2014 00:23:01 +0000

Here's my input:

2. All entities MUST support VP8
 . 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:
VP8 does not provide any technical advantage over H.264, is not developed or maintained through any recognized standardization process, and is currently formally not possible to license.

3. All entities MUST support both H.264 and VP8
 . 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:
VP8 does not provide any technical advantage over H.264, is not developed or maintained through any recognized standardization process, and is currently formally not possible to license.

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]:
NO
a. Do you have any objections to this option, if so please summarize them:
It seems less than obvious how to define exactly what is a "browser" in this context.
VP8 does not provide any technical advantage over H.264, is not developed or maintained through any recognized standardization process, and is currently formally not possible to license.

5. All entities MUST support at least one of H.264 and VP8
. 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 between all WebRTC implementations.

6. All entities MUST support H.261
 . 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 cannot support sufficient quality or bandwidth efficiency and is not widely supported.

7. There is no MTI video codec
 . 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 as outcome if no other MTI consensus can be found.

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]:
NO
a. Do you have any objections to this option, if so please summarize them:
The fallback H.261 cannot support sufficient quality or bandwidth efficiency and is not widely supported.

9. All entities MUST support 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:
Theora has unclear performance and licensing and is not widely supported.

10. All entities MUST implement at least two of {VP8, H.264, H.261}
 . 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 cannot support sufficient quality or bandwidth efficiency and is not widely supported.

11. All entities MUST implement at least two of {VP8, H.264, H.263}
 . 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:
Expect that option 13 will effectively be the same and that option is preferable since it is more lightweight.

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]:
NO
a. Do you have any objections to this option, if so please summarize them:
Don't really see the benefit compared to option 3.
VP8 does not provide any technical advantage over H.264, is not developed or maintained through any recognized standardization process, and is currently formally not possible to license.

13. All entities MUST support H.263
 . 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:
Sufficient quality and bandwidth efficiency for some use cases and thus better fallback option than MJPEG, H.261 or Theora.

14. All entities MUST implement at least two of {VP8, H.264, 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:
VP8 does not provide any technical advantage over H.264, is not developed or maintained through any recognized standardization process, and is currently formally not possible to license.
Theora has unclear performance and licensing and is not widely supported.

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:
Don't see any practical point with just specifying decoding in a communication scenario.
Theora has unclear performance and licensing and is not widely supported.

16. All entities MUST support Motion JPEG
 . 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:
MJPEG does not provide sufficient bandwidth efficiency for most use cases.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 9 Jan 2014 21:54:11 -0500

My views:

   1.

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

      Do you have any objections to this option, if so please summarize
      them: *Unlicensable IPR claims; high risk of trolls coming out of the
      wordworks; lack of interoperability with install base of H.264 based
      systems; lack of current broad support for hardware acceleration*
      3.

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

      Do you have any objections to this option, if so please summarize
      them:* I put this down as acceptable, as opposed to NO, because I
      believe that primary problem here is what the browsers implement. As I am
      not a browser vendor, it would be OK by me if they all decide to
implement
      both - since it means H.264 is there, ensuring interoperability. In other
      words, I dont think rtcweb *compliance* is meaningful outside of the
      browser - only interoperability with webRTC. Thus I view #3 and #4 as
      effectively identical.*
      4.

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

      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: *Will not result in interoperability.*
      6.

      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: *Quality nowhere near acceptable for commercial application.*
      7.

      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: *Will not result in interoperability. *
      8.

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

      Are you in favor of this option [Yes/No/Acceptable]: *Will frequently
      result in H.261 ({Chrome to any other browser},{Chrome to install base})
      and this is not acceptable from a quality perspective. *
      2.

   All entities MUST support Theora: *NO.*
   1.

      Do you have any objections to this option, if so please summarize
      them: *Will not produce interoperability with install base. *
      10.

      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: Will result in H.261 in too many cases and this will not provide
      sufficient quality.
      11.

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

      Do you have any objections to this option, if so please summarize
      them: *Will result in H.263 in too many cases and this will not
      provide sufficient quality. *
      12.

      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: *From a patent perspective is equivalent to implementing both. *
      13.

      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: *Quality not sufficient for commercial use.*
      14.

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

      Do you have any objections to this option, if so please summarize
      them: *Will not produce interoperability with install base.*
      15.

   All entities MUST support decoding using Theora. *NO.*
   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: *Quality not sufficient for commercial use.*

-- 
Jonathan Rosenberg, Ph.D.
[email-masked]
http://www.jdrosen.net

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 9 Jan 2014 21:21:44 -0800

Hello Chairs,

Please find my inputs on the options.

   1.

      Do you have any objections to this option, if so please summarize
      them: *Lack of broad support with the existing install base.*
      3.

      Do you have any objections to this option, if so please summarize
      them: *Results in interoperable solutions with existing install base
      as well as future H264 and VP8 install bases.*
      4.

      Do you have any objections to this option, if so please summarize
      them: *Results in non inter-operable solutions or more sadly silo'ed
      communications.*
      6.

      Do you have any objections to this option, if so please summarize
      them: *WebRTC MUST attempt to deliver high quality Video experiences.*
      7.

   one of H.264 and VP8:
   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:  *Ends up in non-interoperability or poor video quality because
      of H.261*.
      9.

      Do you have any objections to this option, if so please summarize
      them: *Will not result in inter-operable solution. Very low install
      base.*
      10.

      Do you have any objections to this option, if so please summarize
      them: "*Atleast" ends up causing inter-operable complications and
      that is bad for WebRTC. H261 becomes Lowest Common Denominator and kills
      high quality video experience for the end-users. It would be worse, if
      end-users turn of video altogether rather than experiencing poor video
      quality *
      11.

      Do you have any objections to this option, if so please summarize
      them: * "Atleast" ends up causing inter-operable complications.
      More-over H.263 will not live up to the high quality video experience, if
      selected as the common codec. *
      12.

      Do you have any objections to this option, if so please summarize
      them: *Poor video quality, not good for WebRTC.*
      14.

      Do you have any objections to this option, if so please summarize
      them: *Will not produce interoperability with the install base.*
      15.

      Do you have any objections to this option, if so please summarize
      them:  *Poor interoperability with the existing install base. *
      16.

On Thu, Jan 9, 2014 at 6:54 PM, Jonathan Rosenberg <[email-masked]>wrote:

>       them: *Unlicensable IPR claims; high risk of trolls coming out of
>       the wordworks; lack of interoperability with install base of H.264 based
>       not a browser vendor, it would be OK by me if they all decide to implement
>       Are you in favor of this option [Yes/No/Acceptable]: *Will
>       frequently result in H.261 ({Chrome to any other browser},{Chrome to
>       install base}) and this is not acceptable from a quality perspective. *
>       2.
>

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Fri, 10 Jan 2014 08:41:26 +0000

YES

NO

-          VP8 has no interop with existing products in

Acceptable

Acceptable

NO

NO

-          Its old and has limited compression compared to H264

NO

-          This choice does not move us forward to having interoperable audio and video between vendords

NO

NO

NO

NO

NO

NO

NO

NO

NO

Regards

-Espen

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 10 Jan 2014 08:57:46 +0000

My response to the Straw poll.

	• All entities MUST support H.264
		• 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 entities MUST support 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: 
	Will cause lack of interop with existing products
	• All entities MUST support both 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: Ensures interop wih “legacy” products
	• 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:
	• 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: No interop
	• 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: Quality concerns
	• There is no MTI video 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: No interop 
	• All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8: NO.
		• 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: NO.
		• Are you in favor of this option [Yes/No/Acceptable]:
		• Do you have any objections to this option, if so please summarize them: No interop with “legacy” products  
	• 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: 
	• All entities MUST implement at least two of {VP8, H.264, H.263} NO. 
		• 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]: NO.
		• 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]: 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, Theora}: NO.
		• 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. NO. 
		• 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]: NO.
		• Do you have any objections to this option, if so please summarize them: 

.-.
Pål-Erik

---

From: Arnaud Morin <[email-masked]>
Date: Fri, 10 Jan 2014 10:37:03 +0100

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

b.Do you have any objections to this option, if so please summarize 
them: *Interco with legacy network needs transcoding, it's not 
acceptable for my company
*

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

them: *same as 2#
*

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

them: *same as 2#*

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

them: *same as 2#*

6.All entities MUST support H.261

b.Do you have any objections to this option, if so please summarize 
them: *Low quality or too high bandwidth
*

7.There is no MTI video codec

them: *same as 2#*

**

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

them: *same as 2#*

9.All entities MUST support Theora

them: *same as 2#*

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

them: *same as 2#***

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

them: *same as 2#*

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

them: *same as 2#*

13.All entities MUST support H.263

them: *same as 2#*

them: *same as 2#*

them: *same as 2#*

them: *same as 2#*

Basically in my company, we have many projects that allow users to 
communicate with, and as we're using h264, we would like not to transcode.

Cheers,
Arnaud

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 10 Jan 2014 10:20:52 +0000

My responses:

Keith

YES

Not applicable

NO

We are interested in interworking webrtc communications with the existing telecommunications infrastructure. All video there is currently H.264.

This would point the market to being only VP8 and would ensure that all communications outside webrtc would need the video transcoded. While that is technically feasible, we would prefer to limit those scenarios where it is necessary, e.g. multiparty conference.

ACCEPTABLE

The addition of VP8 means additional costs and real-time performance risks for interworking equipment with existing telecommunications infrastructure which we would prefer to avoid.

ACCEPTABLE

The addition of VP8 means additional costs and real-time performance risks for interworking equipment with existing telecommunications infrastructure which we would prefer to avoid.

If this option is adopted, then a clear definition of browser will need to be provided.

NO

This provides no solution to interworking with existing telecommunication infrastructure assuming the implementation decision is effectively made by the browser provider rather than the application.

NO

There is no existing current telecommunications infrastructure implementing this and therefore to promote this is as a solution would be wasted effort that would achieve no interoperability with existing telecommunications infrastructure. The quality over a wireless access technology is unknown.

ACCEPTABLE

Given the amount of resource spent trying to find a MTI codec without success, we would rather park the issue and move on. In any case, the decision on an MTI codec would need to be taken again in a few years time. We believe that lack of an MTI codec is not a major barrier to deployment.

NO

See answers to 5) and 6).

NO

See answers to 5) and 6).

NO

This option can result in the exclusion on H.264, which is the main codec deployed in existing telecommunications environments, and therefore there will be no interoperability with existing telecommunications environments without transcoding.

NO

See 10)

NO

See 10)

NO

See 10)

NO

See 10)

NO

See 10)

NO

See 10)

---

From: Martín Germán <[email-masked]>
Date: Fri, 10 Jan 2014 11:21:02 +0100

Hi all,
Here's my input.
BR,
   Martin.

 1.

     1.

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

     2.

 2.

     1.

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

     2.

 3.

     1.

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

     2.

 4.

     1.

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

     2.

 5.

     1.

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

     2.

 6.

     1.

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

     2.

 7.

     1.

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

     2.

 8.

     1.

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

     2.

 9.

     1.

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

     2.

10.

     1.

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

     2.

11.

     1.

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

     2.

12.

     1.

     2.

13.

     1.

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

     2.

14.

     1.

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

     2.

15.

     1.

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

     2.

16.

     1.

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

     2.

Thanks,

The Chairs

---

From: <[email-masked]>
Date: Fri, 10 Jan 2014 10:56:49 +0000

YES

NO

This option does not meet the use cases where compatibility with existing devices and services is required.

NO

Having two codecs brings no benefits to any use case (pure webrtc or compatibility with existing services) compared to H.264 only. On the contrary, it adds costs and risks to all devices that would need to support both codecs.

NO

Same as 2 and 3.

NO

Global compatibility will not be guaranteed, even between two browsers.

NO

Same as 2.

NO

Same as 5.

NO

Same as 2 and 5.

NO

Same as 2.

NO

Same as 3.

NO

Same as 3.

NO

Same as 5.

NO

Same as 2.

NO

Same as 3.

NO

Same as 5.

NO

Same as 2.

---

From: அலெக்ஸாண்டர் - Alexander <[email-masked]>
Date: Fri, 10 Jan 2014 17:46:59 +0530

1.

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

   1.

   1.

   1.

   1.

   Do you have any objections to this option, if so please summarize
them: *H.264
   is widely used. This might corner the existing installed base, if VP8 is
   chosen by majority of vendors.*

   1.

them: *Poor
   quality.*

   1.

   Do you have any objections to this option, if so please summarize
them: *This
   may not allow interoperability among browsers. *

   1.

them:* Poor
   quality of H.261.*

   1.

   1.

them: *Poor
   quality of H.261.*

   1.

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

   1.

   1.

them: *Prefer
   H.264 over H.263*

   1.

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

   1.

   1.

---

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 10 Jan 2014 15:49:39 +0000

Hi all,

Here's my input.

Many regards
Göran

2.	All entities MUST support VP8
 .	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:
The licensing situation is at the moment still uncertain.

7.	There is no MTI video codec
 .	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:
    In case a consensus cannot be reached this time, a no MTI Video is acceptable for the first version 
    of the API since further discussions will continue to delay and take focus from other parts of work.
    This has the effect of also delaying the start of the work in subsequent versions, or phases, of the
    API and the underlying implementation, which is also important for the WebRTC standard competitiveness. 
    It should however be noted that long term, an MTI video is preferable.

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

Thanks,

The Chairs

---

From: Frode Kileng <[email-masked]>
Date: Fri, 10 Jan 2014 18:48:14 +0100

1.

     1.

     2.

 2.

     1.

     2.

 3.

     1.

     2.

 4.

     1.

     2.

 5.

     1.

     2.

 6.

     1.

     2.

 7.

     1.

     2.

 8.

     1.

     2.

 9.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them: *If an old fallback is to be selected, H261 is
        the safest option*

10.

     1.

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

        **
     2. **

11.

     1.

     2.

12.

     1.

     2.

13.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them: *H.264 is a better option if non-royalty free
        codec to be selected*

14.

     1.

     2.

15.

     1.

     2.

16.

     1.

     2.

PS: IMHO "SHOULD support H264 and VP8" seems for me as the only 
potential option able to achieve consensus...

frodek

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 10 Jan 2014 18:09:34 +0000

My main concerns are interoperability and interworking as defined in charter work items 6 and 9. I have secondary concerns about inferior technology.

2. All entities MUST support 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: Hinders interworking with pervasive industry standards.

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: Hinders both webrtc interoperability and interworking with pervasive industry standards.

6. All entities MUST support 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: Hinders interworking with pervasive industry standards. Also inferior technology.

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: Hinders both webrtc interoperability and interworking with pervasive industry standards.

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: Hinders interworking with pervasive industry standards. Also inferior technology.

9. All entities MUST support 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: Hinders interworking with pervasive industry standards. Also inferior technology.

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]: NO
b. Do you have any objections to this option, if so please summarize them: Hinders interworking with pervasive industry standards. Also inferior technology.

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]: NO
b. Do you have any objections to this option, if so please summarize them: Hinders interworking with pervasive industry standards. Also inferior technology.

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. 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: Hinders interworking with pervasive industry standards.

13. All entities MUST support H.263
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: Hinders interworking with pervasive industry standards.

14. All entities MUST implement at least two of {VP8, H.264, 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: Hinders interworking with pervasive industry standards. Also inferior technology.

15. 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: Hinders both webrtc interoperability (no encoder mandated) and interworking with pervasive industry standards. Also inferior technology.

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: Hinders interworking with pervasive industry standards. Also inferior technology.

Mo

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 10 Jan 2014 20:35:46 +0000

Yes

Yes

Acceptable
> 		• Do you have any objections to this option, if so please summarize them:
Unnecessary duplication of engineering effort for little to no technical gain.

Acceptable
> 		• Do you have any objections to this option, if so please summarize them:
Unnecessary duplication of engineering effort for little to no technical gain; distinction between browsers and other entities is unclear.

No
> 		• Do you have any objections to this option, if so please summarize them:
Will not achieve interoperability

No
> 		• Do you have any objections to this option, if so please summarize them:
Insufficient quality for RTCWeb use cases.

Yes
> 		• Do you have any objections to this option, if so please summarize them:
Effectively this means deferring the decision to either another organization or the marketplace, which are likely better able to make the decision than the IETF is.

> 	• All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8
No
> 		• Do you have any objections to this option, if so please summarize them:
Will not achieve interoperability with sufficient quality for RTCWeb use cases.

> 	• All entities MUST support Theora
No.
> 		• Do you have any objections to this option, if so please summarize them:
Marginal quality for RTCWeb use cases, with no IPR advantages over VP8.

No
> 		• Do you have any objections to this option, if so please summarize them:
Unnecessary duplication of engineering effort for little to no technical gain; will not achieve interoperability with sufficient quality for RTCWeb use cases

> 	• All entities MUST implement at least two of {VP8, H.264, H.263}
Acceptable (0.2)
> 		• Do you have any objections to this option, if so please summarize them:
Unnecessary duplication of engineering effort for little to no technical gain; H.263 is marginal quality for RTCWeb use cases, with minimal IPR advantages over H.264.

Acceptable
> 		• Do you have any objections to this option, if so please summarize them:
Unnecessary duplication of engineering effort for little to no technical gain.

> 		• 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:
Marginal quality for RTCWeb use cases, with minimal IPR advantages over H.264.

> 	• All entities MUST implement at least two of {VP8, H.264, Theora}
No.
> 		• Do you have any objections to this option, if so please summarize them:
Unnecessary duplication of engineering effort for little to no technical gain; Theora is marginal quality for RTCWeb use cases, with no IPR advantages over VP8.

> 	• All entities MUST support decoding using Theora.
No.
> 		• Do you have any objections to this option, if so please summarize them:
Marginal quality for RTCWeb use cases, with no IPR advantages over 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:
Insufficient quality for RTCWeb use cases.

---

From: Svein Yngvar Willassen <[email-masked]>
Date: Fri, 10 Jan 2014 21:51:58 +0100

1.

      Do you have any objections to this option, if so please summarize
      them:  *Not always having a common codec requires transcoding. This
      option will create a barrier for extending web based services to mobile
      devices.*
      5.

      Do you have any objections to this option, if so please summarize
      them: *Not always having a common codec requires transcoding. This
      option will create a barrier for creating web based video services and
      limit the universe of services.*
      6.

      Do you have any objections to this option, if so please summarize
      them: *Not always having a common codec requires transcoding. This
      option will create a barrier for creating web based video services and
      limit the universe of services.*
      8.

*Acceptable *
      2.

      Do you have any objections to this option, if so please summarize
      them: *Not always having a common codec requires transcoding. This
      option will create a barrier for creating web based video services and
      limit the universe of services. (It is not enough to only have a
mandatory
      decoder)*
      16.

--
Svein Willassen, ph.d
https://appear.in/

---

From: Tim Panton <[email-masked]>
Date: Sat, 11 Jan 2014 12:36:28 +0000

On 10 Jan 2014, at 20:51, Svein Yngvar Willassen <[email-masked]> wrote:

> 		• Do you have any objections to this option, if so please summarize them:  Not always having a common codec requires transcoding. This option will create a barrier for extending web based services to mobile devices.

I'm not sure I understand how you see transcoding happening. 
The only occurrence I can see is where one non-browser app e.g. 'facebook for ios' implements only h264 and a different 
non-browser app e.g. 'linkedin for android' implements only VP8 AND users of these two apps choose to attempt to call each other.

I'd humbly suggest that the codec transcoding would be the least of their problems, it is unlikely that 2 single purpose apps
will be expected to interop. It isn't even clear that it is desirable. 
That's kinda the point of the 'browser' distinction - it isn't about laptop vs mobile it is 
multi purpose vs single purpose. or Generic vs Dedicated.

T.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 11 Jan 2014 16:49:04 +0100

* Ted Hardie wrote:
>if any, against a particular alternative. ...

Here is my current thinking. Some fields intentionally left blank.

  [    NO    ]  1. All entities MUST support H.264

The current Working Group charter says "the working group will try to
avoid encumbered technologies that require royalties or other encum-
brances that would prevent such technologies from being easy to use".

It seems many potential implementers and users would be unable to ob-
tain H.264 licenses under non-discriminatory and reasonable terms for
private and commercial use. Current H.264 licensing practises are also
often unclear and are likely to put various parties at risk.

A simple example for the latter point is the distribution of recorded
WebRTC sessions on a web site that generates revenue in some form. It
is likely people are going to do that, but doing so in a legally sound
manner is often unduly burdensome under current licensing practises.

(The second paragraph can stand on its own if a "short" form is needed.)

  [          ]  2. All entities MUST support VP8

Proponents of this exclusive option have not made a convincing case.
I note in passing that `video/webm` has not been registered with IANA.

  [    NO    ]  3. All entities MUST support both H.264 and VP8
  [    NO    ]  4. Browsers MUST support both H.264 and VP8, other
                   entities MUST support at least one of H.264 and VP8
  [    NO    ]  5. All entities MUST support at least one of H.264 and
                   VP8
  [ACCEPTABLE]  6. All entities MUST support H.261

  [    NO    ]  7. There is no MTI video codec
  
This might be acceptable after properly reviewed changes to the charter.
  
  [    NO    ]  8. All entities MUST support H.261 and all entities
                   MUST support at least one of H.264 and VP8
  [ACCEPTABLE]  9. All entities MUST support Theora
  [    NO    ] 10. All entities MUST implement at least two of
                   {VP8, H.264, H.261}
  [    NO    ] 11. All entities MUST implement at least two of
                   {VP8, H.264, H.263}
  [    NO    ] 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
  [    NO    ] 13. All entities MUST support H.263
  [    NO    ] 14. All entities MUST implement at least two of
                   {VP8, H.264, Theora}
  [ACCEPTABLE] 15. All entities MUST support decoding using Theora.
  [    NO    ] 16. All entities MUST support Motion JPEG

Thanks,
-- 
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: Svein Yngvar Willassen <[email-masked]>
Date: Sat, 11 Jan 2014 19:44:21 +0100

On Sat, Jan 11, 2014 at 1:36 PM, Tim Panton <[email-masked]> wrote:

> >               • Do you have any objections to this option, if so please
> summarize them:  Not always having a common codec requires transcoding.
> This option will create a barrier for extending web based services to
> mobile devices.
>
> The only occurrence I can see is where one non-browser app e.g. 'facebook
> for ios' implements only h264 and a different
> non-browser app e.g. 'linkedin for android' implements only VP8 AND users
> of these two apps choose to attempt to call each other.
>
> I'd humbly suggest that the codec transcoding would be the least of their
> problems, it is unlikely that 2 single purpose apps

Is all forms of browsing on all kinds of devices included in the term
"Browsers", including WebViews embedded in other applications?

However, I'm not sure I would change my position should the answer to the
above questions be yes. There may be other entities that are not browsers
that should be interoperable with each other. Two different native video
conferencing solutions could for example claim to be WebRTC compliant
without being interoperable with each other.

--
Svein Willassen, ph.d.
https://appear.in

---

From: Jan-Ivar Bruaroey <[email-masked]>
Date: Sat, 11 Jan 2014 15:16:27 -0500

1.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - Does not achieve interoperability, because it is not FOSS.
        - Still license encumbered. Even with decoder binary gift, this
        is still the blue pill.
        - Encoding is key to interoperability.

 2.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - Risk. It might be prudent to wait a bit for Nokia claim to
        unfold (or fold).
        - Still best option until Daala.

 3.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - A compromise that marginalizes FOSS (license-free gets
        noncomply-labeled).

 4.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - What's a non-browser? Weakness of tying limits to names.
        - Not interoperable.

 5.

     1.

     2.

        - Not interoperable.

 6.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - I'm unfamiliar with H.261, but claims of low quality makes me
        uninterested.

 7.

     1.

     2.

        - Not interoperable.

 8.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - Interoperably indistinguishable from #6 to me.

 9.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - Seems like a less famous yet-to-be-sued VP8.

10.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - I'm unfamiliar with H.261, but claims of low quality make me
        uninterested.

11.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - I'm unfamiliar with H.263, but claims of IPR make me
        uninterested + seems old.

12.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - Trojan!
        - At first seems like pragmatic result of #3 (why encode both
        when unnecessary)
        - But if few devices encode VP8 then even non-compliers cannot
        ignore licensing.
        - Hence not interoperable by my definition.

13.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - I'm unfamiliar with H.263, but claims of IPR make me
        uninterested + seems old.

14.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - Theora seems like a less famous yet-to-be-sued VP8.

15.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - Trojan! Incoming call, hello?
        - If few devices encode Theora then even non-compliers cannot
        ignore licensing.
        - Theora seems like a less famous yet-to-be-sued VP8.

16.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - Too bandwidth demanding.

Clarification: Why I call out "Trojan" in two answers above: Consistent 
with my other answers, a key to interoperability in my view is accepting 
(even non-compliant) license-unencumbered nodes in a network. I.e. Both 
sides of a call negotiation must agree to either of multiple formats, or 
"both" isn't truly both. - Thus, any question that separates encoding 
from decoding I call a Trojan, because incoming calls rule. I.e. If the 
other side requires a license, I need a license. True, I avoid an 
encoding license, so the distinction has merit, but beware of the 
licensing consequence when answering.

.: Jan-Ivar :.

---

From: "Mandyam, Giridhar" <[email-masked]>
Date: Sun, 12 Jan 2014 05:00:59 +0000

My responses.  Thanks,
-Giri Mandyam

2. All entities MUST support 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:
                Does not allow interop with legacy systems and standards such as 3GPP IMS Video Telephony.  VP8 standardization is incomplete.

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:
                Does not allow interop with legacy systems and standards such as 3GPP IMS Video Telephony. VP8 standardization is incomplete.

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]: NO
b. Do you have any objections to this option, if so please summarize them:
                Does not allow interop with legacy systems and standards such as 3GPP IMS Video Telephony. VP8 standardization is incomplete.

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:
This option potentially allows negotiation failure.

6. All entities MUST support 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:
               Section 7 of https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ provides performance data for H.264.  I do not believe that H.261 would provide equivalent or superior performance under identical testing conditions, and no data has been provided to the IETF or on the mailing lists proving otherwise.  This option would allow a presumably inferior codec (H.261) to be the fallback option. Moreover, this does not allow interop with legacy systems and standards such as 3GPP IMS Video Telephony.

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:
Section 7 of https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ provides performance data for H.264.  I do not believe that H.261 would provide equivalent or superior performance under identical testing conditions, and no data has been provided to the IETF or on the mailing lists proving otherwise.  This option would allow a presumably inferior codec (H.261) to be the fallback option. Moreover, H.261 does not allow for interop with legacy systems and standards such as 3GPP IMS Video Telephony.

9. All entities MUST support 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:
               Section 7 of https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ provides performance data for H.264.  I do not believe that Ogg would provide equivalent or superior performance under identical testing conditions, and no data has been provided to the IETF or on the mailing lists proving otherwise.  This option would allow a presumably inferior codec (Ogg) to be the fallback option. Moreover, this does not allow interop with legacy systems and standards such as 3GPP IMS Video Telephony.  In addition, Ogg has not been formally standardized by any recognized standards-defining organization.

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]: NO
b. Do you have any objections to this option, if so please summarize them:
               Section 7 of https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ provides performance data for H.264.  I do not believe that H.261 would provide equivalent or superior performance under identical testing conditions, and no data has been provided to the IETF or on the mailing lists proving otherwise.  This option would allow a presumably inferior codec (H.261) to be the fallback option. Moreover, H.261 does not allow for interop with legacy systems and standards such as 3GPP IMS Video Telephony.

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]: NO
b. Do you have any objections to this option, if so please summarize them:
                VP8 standardization is incomplete.

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. 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:
                Does not allow interop with legacy systems and standards such as 3GPP IMS Video Telephony.  VP8 standardization is incomplete.

13. All entities MUST support H.263
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:.

14. All entities MUST implement at least two of {VP8, H.264, 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:.
                Does not allow interop with legacy systems and standards such as 3GPP IMS Video Telephony.

15. 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:
Section 7 of https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ provides performance data for H.264.  I do not believe that Ogg would provide equivalent or superior performance under identical testing conditions, and no data has been provided to the IETF or on the mailing lists proving otherwise.  This option would allow a presumably inferior codec (Ogg) to be the fallback option. Moreover, this does not allow interop with legacy systems and standards such as 3GPP IMS Video Telephony.  In addition, Ogg has not been formally standardized by any recognized standards-defining organization.

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:
               Section 7 of https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ provides performance data for H.264.  I do not believe that M-JPEG would provide equivalent or superior performance under identical testing conditions, and no data has been provided to the IETF or on the mailing lists proving otherwise.  This option would allow a presumably inferior codec (M-JPEG) to be the fallback option. Moreover, this does not allow interop with legacy systems and standards such as 3GPP IMS Video Telephony.

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Monday, December 09, 2013 9:25 AM
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.

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.

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: Mike Linksvayer <[email-masked]>
Date: Sat, 11 Jan 2014 21:52:05 -0800

Had I responded sooner, there would be many more No answers and fewer
Acceptable answers. But watching responses come in, I'd rather not
contribute to stalemate to the extent possible, and I've been reflecting
(prompted list messages mentioning audio) that lack of guaranteed video
interoperability might not be as horrible in practice as it sounds in
theory -- many (I hesitate to say most, but that'd be my guess)
applications need to be able to usefully fall back to audio-only anyway,
as lack of video due to poor bandwidth, privacy, lost or misconfigured
camera, bad lighting, etc, is extremely common.

Mike

 1.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them: *Makes FLOSS projects 2nd class citizens at
        best, does not augur well for **escaping dependence on
        encumbered codecs in next generation.*

 2.

     1.

     2.

 3.

     1.

     2.

 4.

     1.

     2.

 5.

     1.

     2.

 6.

     1.

     2.

 7.

     1.

     2.

 8.

     1.

     2.

 9.

     1.

     2.

10.

     1.

     2.

11.

     1.

     2.

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

12.

     1.

     2.

13.

     1.

     2.

        Do you have any objections to this option, if so please
        summarize them: *Makes FLOSS projects 2nd class citizens at
        best, does not augur well for **escaping dependence on
        encumbered codecs in next generation.*

14.

     1.

     2.

15.

     1.

     2.

16.

     1.

     2.

---

From: <[email-masked]>
Date: Sun, 12 Jan 2014 08:27:58 +0100

Find below my responses.

Best regards,
Bernhard Feiten

b.    Do you have any objections to this option, if so please summarize them: YES, because of worse interoperability to other services.

b.    Do you have any objections to this option, if so please summarize them: YES, because of worse interoperability to other services in case of VP8

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

b.    Do you have any objections to this option, if so please summarize them: YES, because of worse interoperability with good quality to other services .

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

c.    Do you have any objections to this option, if so please summarize them: YES, because of worse interoperability with good quality to other services .

d.    Do you have any objections to this option, if so please summarize them: YES, because of worse interoperability to other services .

e.    Do you have any objections to this option, if so please summarize them: YES, because of worse interoperability to other services .

c.    Do you have any objections to this option, if so please summarize them: YES, quality too bad.

d.    Do you have any objections to this option, if so please summarize them: YES, quality too bad.

---

From: "HAYASHI, Tatsuya" <[email-masked]>
Date: Sun, 12 Jan 2014 20:10:10 +0900

My responses.

3.    All entities MUST support both H.264 and 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: Better

Thanks.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 12 Jan 2014 20:48:15 +0900

Below are my opinions. I'm using a numerical with 0.0 meaning NO and 1.0 
meaning YES, everything in between is acceptable, with various degrees.

The statements and opinions below are purely my own and were written 
without any support (e.g. from a lawyer).

>        Are you in favor of this option [Yes/No/Acceptable]:
0.2
>        Do you have any objections to this option, if so please summarize
Licensibility is a completely unsolved problem for open source. Every 
step towards solving this problem makes this solution more acceptable. 
Such steps include the Cisco binary (great move), creating a 
royality-free (+no reporting requirements!) version (underway but moving 
very slowly), making built-in hardware support more accessible (this 
looks like an easy move for the vendors in charge; surprised nobody has 
announced something in this direction yet), and so on.

The current licensing model used by MPEG and MPEG-LA works marginally 
well with hardware (but it's weird that somebody would have to pay extra 
license fees for a video taken on a home camera but broadcast 
commercially; it contradicts general expectations about patents, namely 
that if I buy a tool, I can use it any way I want). On the other hand, 
the MPEG model isn't suited for software. Once something can be 
implemented in software, and is supposed to be widely interoperable, any 
kind of licensing restrictions are unnecessary impediments. The best 
example is the WWW, which boomed among else because CERN put the 
software in the public domain and made clear it would never ask for any 
money
(see 
http://home.web.cern.ch/about/updates/2013/04/twenty-years-free-open-web). 
That's the way to create great value; bean-counting à la MPEG-LA isn't.

The fact that the MPEG licensing model can be "cheated on" as shown with 
the Cisco binary is another indication that it's not suited for software.

To some extent, this is recognized in jurisdictions that do not allow 
software patents, and I personally hope that the number of such 
jurisdictions will increase. Also, some jurisdictions may come to the 
recognition that video compression algorithms are nothing else than 
algorithms, and algorithms have traditionally not been protected by 
patents, for good reasons.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.8
>        Do you have any objections to this option, if so please summarize
In my judgment, the remaining 0.2 are mostly FUD (if Nokia or some third 
party thinks it's not, they should submit a much more precise 
declaration), and some "out of left field" patent troll risk that 
unfortunately never can be excluded.

Google has to be commended for doing virtually everything (except 
betting *all* the money of their company) possible to make VP8 usable 
widely. A Cisco-binary like binary may be helpful to the extent that it 
may make it more difficult for a troll to attack the user of the binary.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.1
>        Do you have any objections to this option, if so please summarize
This is the compromise that hurts everybody.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.2
>        Do you have any objections to this option, if so please summarize
The delineation between browsers and non-browsers is unclear, and there 
are open-source browsers (or installations thereof) that may not be able 
to use H.264, even in the form of the Cisco binary.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.05
>        Do you have any objections to this option, if so please summarize
Same as 7 (no MTI), just without admitting it.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.4
>        Do you have any objections to this option, if so please summarize
H.261 is the best quality available codec that we can assume to be 
without patent encumberment. There is also widespread (if slightly 
dated) industry experience.
It is clear that most video experts don't like its quality/performance. 
But then the pool of video experts tends to contain a lot of people who 
care about high video quality more than the average user, and even more 
than the user who really depends on video, in particular people who rely 
on sign language. As it has been shown that H.261 is okay for sign 
language, it's the minimum we can require to guarantee accessible 
interoperability.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.2
>        Do you have any objections to this option, if so please summarize
If we have to admit it, we'd better admit it. Of course I'd prefer 
another outcome, but maybe it would be better to postpone additional 
discussions until such time as the rest of RTCWeb is finished, and only 
then give it another try. If we can't find consensus, then the only 
reason to continue to actively discuss this issue is the pressure it may 
create on players to come forward with better solutions

>        Are you in favor of this option [Yes/No/Acceptable]:
0.3
>        Do you have any objections to this option, if so please summarize
This is similar to 6 (must support H.261), but in addition enshrines 
current "best of breed" codecs, which means more work to update specs 
when VP9 and the like become fully practical.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.05
>        Do you have any objections to this option, if so please summarize
I don't think there are significantly less risks with Theora than with 
VP8, so I don't think it's worth prescribing, because quality is less 
than VP8.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.3
>        Do you have any objections to this option, if so please summarize
This is similar to 8 (MUST H.261, must one of H.264 and VP8). It is less 
favorable because it locks in current best-of-breed codecs, but more 
favorable because it allows some players to support two modern codecs 
rather than an old and a new one.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.01
>        Do you have any objections to this option, if so please summarize
H.263 doesn't solve the H.264 licensing problems (unless we wait quite a 
few more years), and is lower in quality than H.264, so why bother.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.2
>        Do you have any objections to this option, if so please summarize
This would be a solution if either MPEG managed to at least make the 
decoding of H.264 royalty-free, or if a significant number of 
jurisdictions made patents non-applicable to decoding.

The later point may sound strange to some, but it can be argued both in 
theory for source coding and in practice for video coding that the 
difficulty is essentially all in the encoder; the decoder is just a set 
of instructions to re-create the original, and such sets of instructions 
aren't usually patentable, and the actual instruction sequence is sent 
to the receiver anyway.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.01
>        Do you have any objections to this option, if so please summarize
See choice 11.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.05
>        Do you have any objections to this option, if so please summarize
See choice 9.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.05
>        Do you have any objections to this option, if so please summarize
This is just a variant of choice 9, with the "encoding" part left implicit.

>        Are you in favor of this option [Yes/No/Acceptable]:
0.1
>        Do you have any objections to this option, if so please summarize
If it can be shown that Motion JPEG produces acceptable results for sign 
language, then this is an alternative to H.261.

Regards,   Martin.

---

From: "Karl Stahl" <[email-masked]>
Date: Sun, 12 Jan 2014 16:45:23 +0100

Karl Stahl's response (for Ingate and Intertex):

Yes

- Only if a downloadable codec (like Cisco's offering, for IPR concern) slot
and multiple codec slots are recommended: "SHOULD" - we must not get locked
into another 50 years of "Video G.711" base level now - and also other
services (IPR or not) should be able to use browsers if providing their own
downloadable codec - will also drive improvement and innovation (VP9,
H.26x.).

- Transcoding (which we got as priority request from day one of the "VP8
only days", from both SP and PBX/UC side, must be avoided [1] as being
against the core idea of WebRTC  

Yes

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

- Only if a downloadable codec (like Cisco's offering, for compatibility and
for VP8 itself for those that e.g. believes that Nokia IPR objections are
more than political) slot and multiple codec slots are mandated: "MUST" - we
must not get locked into another 50 years of "Video G.711" base level now -
and also other services (IPR or not) should be able to use browsers if
providing their own downloadable codec - will also drive improvement and
innovation (VP9, H.26x.).

- Transcoding (which we got as priority request from day one of the "VP8
only days", from both SP and PBX/UC side, must be avoided [1] as being
against the core idea of WebRTC  

Acceptable

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

Acceptable

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

Acceptable

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

Only if codec slots also are mandated: "MUST"

No, simply too old/bad

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

No

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

No

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

No

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

No

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

No

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

Acceptable

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

No

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

No

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

No

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

No

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

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: "Karl Stahl" <[email-masked]>
Date: Sun, 12 Jan 2014 18:05:53 +0100

[1] Transcoding VP8 ß> H.264 is very CPU intensive. Chrome with VP8 on old
laptops with 1 core 1.5 Ghz x86 is not even usable. Core i5 CPU is fine. 

Even the master of transcoding, ACME Packet/Oracle said at the last WebRTC
conference that they will not support transcoding, leaving that to others
real heavy DSP cabinets.

/Karl

Från: rtcweb [mailto:[email-masked]] För Karl Stahl
Skickat: den 12 januari 2014 16:45
Till: [email-masked]
Ämne: Re: [rtcweb] Straw Poll on Video Codec Alternatives

Karl Stahl’s response (for Ingate and Intertex):

Yes

- Only if a downloadable codec (like Cisco’s offering, for IPR concern) slot
and multiple codec slots are recommended: “SHOULD” – we must not get locked
into another 50 years of “Video G.711” base level now - and also other
services (IPR or not) should be able to use browsers if providing their own
downloadable codec – will also drive improvement and innovation (VP9,
H.26x…).

– Transcoding (which we got as priority request from day one of the “VP8
only days”, from both SP and PBX/UC side, must be avoided [1] as being
against the core idea of WebRTC  

Yes

- Only if a downloadable codec (like Cisco’s offering, for compatibility and
for VP8 itself for those that e.g. believes that Nokia IPR objections are
more than political) slot and multiple codec slots are mandated: “MUST” – we
must not get locked into another 50 years of “Video G.711” base level now -
and also other services (IPR or not) should be able to use browsers if
providing their own downloadable codec – will also drive improvement and
innovation (VP9, H.26x…).

– Transcoding (which we got as priority request from day one of the “VP8
only days”, from both SP and PBX/UC side, must be avoided [1] as being
against the core idea of WebRTC  

Acceptable

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

Acceptable

Acceptable

Only if codec slots also are mandated: “MUST”

No, simply too old/bad

No

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

No

No

No

No

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

Acceptable

No

No

No

No

Thanks,

The Chairs

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Sun, 12 Jan 2014 13:46:45 -0500

NO

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

H.264 carries with it an explicit licensing burden that will bring with
it exclusion of use cases, including but no limited to free software
implementations (as defined by the Free Software Foundation) and stifle
adoption of the standard as a result.  This will effectively limit
rtcweb to "the same old players" that are already entrenched in the
market and lock out smaller entities.

YES

NO

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

The same objections in #1 apply here.  Additionally, it should be noted
that the parallel of "two MTI audio codecs" cannot apply here because
there were no free software licensing issues in the two proposed codecs
that would impede adoption.  This is not the case with H.264, to be precise.

NO

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

In addition to the challenges presented by mandating H.264 as mentioned
above in my objections in #1 and #3 above, this one has the additional
challenge of applying different rules on an arbitrary and ambiguous
distinction.  What, exactly, is a browser?  Can the same application be
a "browser" sometimes, and a "phone" another time?  Having this in the
spec would likely be a great hindrance to adoption, even if the
currently known interested browser vendors agree, it would not be
representative of any future additional ones.

As a point to note, until relatively recently, Chrome as a browser did
not exist, and before that Safari did not, and before that Firefox did
not, and before that Opera did not, and before that Internet Explorer
did not.

NO

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

While this option gives a wider choice of what codec to implement, the
result will be two "islands" in the rtcweb world - the H.264 one and the
VP8 one.  This alone will not yield any mechanism with which to
guarantee interop between rtcweb clients.

YES

NO

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

This will result in the same problem as presented in 5, namely, islands
in the rtcweb world.  Therefore, it's not a good option.  Comparisons to
HTML5 <video> are apt, in that, despite being years old and supported,
no single standard codec emerged as suitable for all cases by market
choices, and we still have some sites only supporting certain codecs
(e.g., Vimeo) and even some switching the nature of what they support
(e.g., YouTube) isolating certain user agents and therefore users.

YES

YES

YES

NO

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

This option, while seemingly offering a wider choice, will force a valid
implementation of rtcweb to include royalty-bearing code for either
H.264 or H.263, neither of which can currently be implemented nor
deployed without exposing the implementor or the user to some licensing
fees.

NO

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

Only decoding H.264 video does not fully eliminate the licensing issues
that were mentioned in my previous points, therefore it is not any
better than them.

NO

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

H.263 is not any better off than H.264 from a licensing perspective, and
may actually be worse in that manner.

YES

Acceptable

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

This sounds like a weak option because it doesn't imply much about the
rest of the implementation.  It does, however, imply that at least one
side of each rtcweb communication setup support encoding with Theora,
which is something I am already for.

Acceptable

-- 
Libre Video
http://librevideo.org

---

From: "Coban, Muhammed" <[email-masked]>
Date: Sun, 12 Jan 2014 19:16:20 +0000

Dear all,

Here is my input:

VP8 has not completed an open standardization process. VP8 does not allow interoperability with existing solutions.

VP8 has not completed an open standardization process. VP8 does not allow interoperability with existing solutions.

VP8 has not completed an open standardization process. VP8 does not allow interoperability with existing solutions.

Does not provide interoperability.

Does not provide sufficient bandwidth efficiency and is not widely supported.

See #6 above.

Not widely supported.

See #5, #6 above.

Option 13 is cleaner.

See #3 above.

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

See #2, #5, #9 above.

See #9, not clear why support only decoding.

Best regards,

Muhammed Coban

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 12 Jan 2014 20:19:14 +0100

>meaning YES, everything in between is acceptable, with various degrees.

Among the single codec options your order of preference then is

  VP8 > H.261 > H.264 >= no MTI > MJPEG > Theora > H.263
  0.8 >   0.4 >   0.2 >=    0.2 >   0.1 >   0.05 >  0.01

>language, then this is an alternative to H.261.

An alternative to H.261 should have at least 0.2 in your rating system.
It looks as though you prefer MJPEG, even without sign language support,
to Theora, which has no difficulty with sign language at normal rates.
-- 
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: Badri Rajasekar <[email-masked]>
Date: Sun, 12 Jan 2014 11:35:50 -0800

Hi All,

Please find below TokBox's position with regards to the straw poll
responses.

1.    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 feasibility of supporting H264 in all platforms is questionable given
licensing issues (despite the Cisco binaries) and availability of APIs. The
burden of IPR issue is going to deter small application developers
especially in non-browser entities.

2.    All entities MUST support VP8
Are you in favor of this option [Yes/No/Acceptable]: YES.

3.    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 objections as point 1 and VP8 is a better alternative in this light.

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]: Acceptable.

5.    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:
Interoperability is key and this would necessitate transcoding at a server
or some equally non-viable option for effectively using WebRTC.

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

Do you have any objections to this option, if so please summarize them:
Although H.261 would be a step back in terms of quality needs of WebRTC
video.

7.   There is no MTI video 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:
There needs to be a consensus for platform adoption. Lack of an MTI video
codec is hurting forward progress of WebRTC.

Do you have any objections to this option, if so please summarize them:
H.261 is not viable from a quality perspective and this mostly going to end
up as fallback to H.261 in several scenarios without the advantages of
H264/VP8 quality.

9.    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:
Technically this seems like a step back.

10.    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:
While superficially it appears fine, in my opinion it will hurt
interoperability.

11.    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:
 IPR issues with H.263 and H.264 are problematic.

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]: NO.

Do you have any objections to this option, if so please summarize them:
The IPR risk of H.264 is only partially mitigated with decoding and I
believe this will hurt adoption by small developers.

13.    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:
 H.263 doesn't provide better quality (as compared to VP8/H264) and
potential IPR risks.

14.    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:
 Same problem as Point 10.

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

Same as 9.

16.    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:
Existing market support might be limited and again performance concerns.

Thanks,
Badri

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 12 Jan 2014 20:48:51 +0100

>laptops with 1 core 1.5 Ghz x86 is not even usable. Core i5 CPU is fine. 

My netbook with an Intel Atom N270 (1.60 GHz, 2008) with some recent
version of ffmpeg can transcode 352x288 VP8 video to H.264 at 30 fps
with default options; with `-vprofile "baseline"` at over 40 fps. The
machine is sure to turn on the fan if you also decode and encode some
audio simultaneously, but the single core can handle the workload.
-- 
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: Stockhammer Thomas <[email-masked]>
Date: Sun, 12 Jan 2014 16:48:32 -0800

Please find responses below:

2. All entities MUST support 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:
                VP8 standardization is incomplete. Threat of of unlicensable IPR. Not interoperable with 3GPP MTSI.  
 
                see #2
 
                see #2.
 
5. 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:
This option potentially results in negotiation failure.
 
6. All entities MUST support 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:
               Not widely supported, low coding efficiency and other restrictions
 
7. There is no MTI video 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:
	This option potentially results in negotiation failure, but deployments will solve issue.
 
	see #6
 
9. All entities MUST support 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:
               unclear licensing and not widely supported.
 
 see #6 and #2              
 
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:
                Double Implementation/testing but as H.263 and H.264 widely supported, so ok!
 
               see #2.
 
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:.
	prefer higher efficiency H.264, but ok
 
                see #2 and #9
 
		see #9
 
16. All entities MUST support Motion JPEG
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:
 	prefer higher efficiency H.264              

On 09 Dec 2013, at 09:24, 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.
> 
> 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.  
> 
> Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8
> All entities MUST support H.261 and all entities MUST support at least one of H.264 and 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

---
Dr. Thomas Stockhammer (CEO) || [email-masked] || phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 13 Jan 2014 13:06:56 +0900

Hello Björn,

On 2014/01/13 4:19, Bjoern Hoehrmann wrote:
>    VP8>  H.261>  H.264>= no MTI>  MJPEG>  Theora>  H.263
>    0.8>    0.4>    0.2>=    0.2>    0.1>    0.05>   0.01

Thanks for working that out.

> to Theora, which has no difficulty with sign language at normal rates.

As everybody in this discussion should know by now, there is more than 
one criterion to judge codecs. Almost everybody has considered at least 
quality and licencing, to mention two. What makes finding rough 
consensus difficult are not only the clear disagreements on the 
licensing side, but also the opinions about quality (degradation being 
okay or not,...).

In my case, Theora got that low because in my summary judgment, it 
doesn't provide any advantages when compared to VP8 with respect to 
licensing. On the other hand, MJPEG is clearly much less of a problem 
with respect to patents and stuff.

Regards,   Martin.

---

From: Ron <[email-masked]>
Date: Mon, 13 Jan 2014 15:45:20 +1030

On Mon, Jan 13, 2014 at 01:06:56PM +0900, "Martin J. Dürst" wrote:
> licensing.

It's not quite that simple.  Microsoft ships Theora video from its
Bing service, and Cisco ships VP8 in its hardware products.  And both
of them have very clear licences.

Maybe their lawyers can get together for lunch and reassure each
other of their respective positions.

  Ron

---

From: Randell Jesup <[email-masked]>
Date: Mon, 13 Jan 2014 00:28:09 -0500

>         The downloadable codec from Cisco does not cover everyone's
>         use-cases or requirements.  Cisco's download while offered for
>         the foreseeable future could in theory be yanked at any time,
>         perhaps due to circumstances beyond the management's control. 
>         (It does cost them money.) It's unclear how well this covers
>         the use-cases of WebRTC server developers.  Also, the Cisco
>         option only provides assurances from MPEG-LA; this does not
>         cover the encoder (and so an IPR claim against Cisco could
>         force it to be pulled).  See also
>         http://www.att.com/gen/sites/ipsales?pid=19116 which is not
>         covered by the Cisco MPEG-LA agreement.
>         Also, small entities that might need to license directly via
>         MPEG-LA would be blocked from the market due to legal costs,
>         time, accounting for uses, etc.
>
> 2.
>
>         A downloadable option similar to Cisco's H.264 may resolve
>         some of the issues that people have with VP8 IPR worries.
>
> 3.
>
>         *Acceptable (0.2)
>         Somewhat acceptable because it provides a guaranteed fallback
>         if H.264 got pulled.  This would still cause major problems
>         for both those who won't/can't do H.264 or won't/can't do
>         VP8.  (See downloadable option though.)  Those that won't do
>         one can break MTI; if those are only servers this won't be
>         horrible but if browsers break the MTI it could lead to
>         interop failure.
>
> 4.
>
>         *Acceptable (0.3)*
>         Same issues as #3.
>         Causes major problems for the feature due to inability to
>         complete video calls. Calls will fail and the user won't
>         understand.
>
> 6.
>
>         Does not provide reasonable quality interoperability.
>
> 7.
>
>         While we may end up there by default, it does not produce an
>         acceptable result.  Calls will fail and the user won't
>         understand.  Same problem as #5.  Acceptable only as a "will
>         be decided later" case, and pretty bad there.  Probably
>         perferred to some of the other No's though, so maybe
>         Acceptable (0.05)
>
> 8.
>
>         *Acceptable (0.1)*
>         Preferred only over the worse options like No MTI or H.261
>         only.  Barely acceptable as it will ensure completion of
>         calls.  Same issues as #6.  Would accept this over No MTI or
>         H.261 only.  #10 would be preferred over this.
>
> 9.
>
>         *Acceptable (0.2)*
>         Similar to objections to #6 (though likely better quality),
>         however with some added IPR risk.  Similar to #13 with perhaps
>         less IPR issues (to be seen though).
>
>10.
>
>         *Acceptable (0.3)*
>         Guarantees interoperability.  Doesn't guarantee high quality,
>         could cause real problems for people with constrained or
>         capped bandwidth (i.e. mobile). Similar issues to #3, though
>         somewhat better.  Prefer to #3.
>
>11.
>
>         *Acceptable (0.3)*
>         Better than #10 (lower bandwidth requirement, more impls
>         available) modulo that some entities would not feel
>         comfortable with being forced to implement H.263 (and license
>         it, fail to comply with the spec, or risk going
>         license-less).  Provides an acceptable (if not good) quality
>         interop fallback; slightly improves legacy interop with older
>         technologies.  Downloadable codecs for H.264 and VP8 will help
>         if those meet the MTI requirement.  If a downloadable H.263
>         codec were available and licensed, this would be more preferred.
>
>12.
>
>         Slightly preferred over requiring both, in that many IPR
>         pitfalls might be in the encoders (and may simplify devices
>         with only one hardware encoder).
>
>13.
>
>         Worse than #1 as there's no downloadable option and has IPR issues
>
>14.
>
>         *Acceptable (0.3)*
>         Similar to #11; no requirement to license H.263 but adds some
>         IPR risk and removes old-legacy interop.
>
>15.
>
>         Decode-only Theora MTI is weird/useless
>
>16.
>
>         Quality at bandwidth is unlikely to be good enough to ensure
>         acceptable interop.  Similar to H.261 with the improvement of
>         re-use of common implementations, but with a downside of
>         considerably lower quality at the same bitrate/resolution.
>

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 13 Jan 2014 15:37:08 +0900

On 2014/01/13 14:15, Ron wrote:
> It's not quite that simple.

Yes. That's why I very consciously wrote "my summary judgment".

Regards,   Martin.

> Microsoft ships Theora video from its

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 12 Jan 2014 22:39:44 -0800

I am not distinguishing between Yes and Acceptable. I think that's silly.

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

Yes.

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

Yes.

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

Yes.

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

Yes.

No.

No.

No.

No.

No.

No.

No.

No.

No.

No.

No.

No.

---

From: Mark Harris <[email-masked]>
Date: Sun, 12 Jan 2014 18:35:17 -0800

> 1. All entities MUST support H.264

 NO
 H.264 patent license restricts participation.

 YES

> 3. All entities MUST support both H.264 and VP8

 NO
 H.264 patent license restricts participation.

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

 NO
 H.264 patent license restricts browser participation.

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

 ACCEPTABLE
 Revisit to ensure interoperability when the codec landscape changes.

 ACCEPTABLE

> 7. There is no MTI video codec

 ACCEPTABLE
 Revisit to ensure interoperability when the codec landscape changes.

 ACCEPTABLE

 ACCEPTABLE

 ACCEPTABLE

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

 NO
 H.264 and H.263 patent licenses restrict participation.

> 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

 NO
 H.264 patent license restricts participation.

> 13. All entities MUST support H.263

 NO
 H.263 patent license restricts participation.

 ACCEPTABLE

 ACCEPTABLE

 ACCEPTABLE

Although it may not be suitable for full motion video over the
Internet, Motion JPEG is a nice option for sending individual photos,
presentation slides, screen shots, or even a single still profile
picture in the event that the user is unable or does not wish to
transmit live video for whatever reason.  Browsers already contain
optimized JPEG decoders which are unlikely to be going away any time
soon given the vast quantity of JPEG images on the web.  Although it
is possible to send images over the data channel, that requires the
JavaScript to handle this as a special case and does not allow the
browser to give the user the option to simply substitute a still JPEG
image (or series of images) when live video is requested.

If a common modern video codec could be guaranteed to be available,
there would be little reason to consider this option since modern
video codecs can also do a great job encoding still pictures.  However
it is looking increasingly likely that there will be no MTI modern
video codec for some time.  A guarantee that at least still images can
be processed, even in the absence of a common modern video codec, and
without special provisions in the JS to process images over the data
channel, still adds quite a bit of value over audio-only.  Most people
already have audio-only capabilities that are far better integrated
since they've been around much longer, and would therefore be
reluctant to move to WebRTC if it was also seen as only able to
guarantee audio communication.

Even the most basic feature phones can already decode JPEG images and
have a camera capable of producing single JPEGs, so it makes a great
lowest common denominator that all devices capable of meeting other
WebRTC requirements should be able to handle, even if they do not have
a camera, CPU, Internet connection, or hardware encoder APIs
sufficient to support full motion video.  Therefore there is little
reason to select no MTI over this, unless there is an explicit desire
to allow audio-only devices to claim WebRTC conformance, which in my
opinion would dilute the value of that label.

To clarify my position, I am not suggesting that all entities should
be required to support 30 fps Motion JPEG, which as others have
pointed out would require quite a bit of bandwidth.  Decoding and
display at 1 fps or possibly even less may be a suitable minimum
requirement, in order to ensure that at a minimum still images such as
photos, slides, and screen shots can be processed.  As for encoding, I
am open to any minimum requirement from an ability to send a single
preselected JPEG, to a requirement for 1 fps Motion JPEG live video,
with restart markers to facilitate decoding when some packets of a
frame are lost.  Any entity supporting more than 1 fps video should
also implement a more advanced video codec.  Adoption of Motion JPEG
as MTI should also not preclude adoption of an additional video codec
as MTI at a later date, once the video codec landscape changes and
consensus can be reached on a more advanced video codec.

 - Mark

---

From: Otto J Wittner <[email-masked]>
Date: Mon, 13 Jan 2014 11:04:50 +0100

My response to the straw poll:

    1.   All entities MUST support H.264
NO, truly (as possible) royalty free codec required
    2.   All entities MUST support VP8
YES
    3.   All entities MUST support both H.264 and VP8
NO, truly (as possible) royalty free codec required
    4.   Browsers MUST support both H.264 and VP8, other entities MUST 
support at least one of H.264 and VP8
NO, truly (as possible) royalty free codec required
    5.   All entities MUST support at least one of H.264 and VP8
NO, truly (as possible) royalty free codec required
    6.   All entities MUST support H.261
Acceptable
    7.   There is no MTI video codec
NO, failed negotiations between browser/entiteis will occur more often 
than acceptable
    8.   All entities MUST support H.261 and all entities MUST support 
at least one of H.264 and VP8
Acceptable
    9.   All entities MUST support Theora
Acceptable, but as VP8 is "next gen Theora" it seems like a step backwards
   10.   All entities MUST implement at least two of {VP8, H.264, H.261}
Acceptable
   11.   All entities MUST implement at least two of {VP8, H.264, H.263}
NO, unclear royalty situation for H.263
   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
NO, rtcweb is not only about streaming.
   13.  All entities MUST support H.263
NO, unclear royalty situation for H.263
   14.  All entities MUST implement at least two of {VP8, H.264, Theora}
Acceptable
   15.  All entities MUST support decoding using Theora.
NO, but a SHOULD would be fair legacy content   1.
   16.  All entities MUST support Motion JPEG
Acceptable

On 12/09/13 18:24, Ted Hardie 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.
>

-- 
Otto J Wittner   Tel 73557945
UNINETT AS       Mob 99550566

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Mon, 13 Jan 2014 11:02:52 +0000

Here is my straw below...

Chris Cavigioli
Intel Corp, Marketing & Product Planning, Graphics/Multimedia, Mobile and Communications Group (MCG)
+1 (415) 254-4545 mobile
+1 (408) 653-8348 desk
+1 (408) 884-2400 fax
This e-mail may contain confidential and privileged material for the sole use of the intended recipient(s).  Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

*SNIP*

NO, incomplete.  This is necessary, but not sufficient.

One codec isn't enough

NO, incomplete.  This is necessary, but not sufficient.

One codec isn't enough

YES, there is no commercially-viable alternative.  Transcoding must be avoided at all costs if we intend to provide a good end-user experience.

Given the passion behind each camp, we must deploy both.

Android, iOS and Windows commercial logo requirements mandate the presence of H.264 encode and decode anyhow.   No device will be missing H.264 ... all Android devices have H.264 and VP8 (both).

NO, this implies that browsers will be able to talk to each other, but some other entities will not .. unless they have a browser on board.  For commercial success, browsers must tap into native hardware codecs.

#3 is a better option

NO.

This forces a hodge-podge of transcoding and that won't work.

NO

H.261 is obsolete, cannot handle higher resolutions and contributes to the data tsunami in our networks.   That is exactly the reason we're moving to H.265 and VP9 ... to reduce bandwidth, increase quality ... let's not go backwards.

NO

The market will fragment into camps and nobody wins.  WebRTC becomes a passing "flash in the pan" because systems don't work with each other.

NO

Wasteful.  H.261 must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.

NO

Wasteful.  Rare codec - not widely available in hardware - and obsolete technology (same argument against H.261 above)

NO

Wasteful.  H.261 must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.  Transcoding issues.

NO

Wasteful.  H.263 must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.  Transcoding issues.

NO

So complex that this will be hard to explain ... and doesn't solve the transcoding issue

NO

Wasteful.  H.263 must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.

NO

Wasteful.  Theora must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.  Transcoding issues.

NO

Wasteful.  Theora must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.  Transcoding issues.

NO

Wasteful.  Motion JPEG must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.  Transcoding issues.

Thanks,

The Chairs

---

From: <[email-masked]>
Date: Mon, 13 Jan 2014 14:25:37 +0100

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

NO

No new arguments. Basically royalties with unclear business outlook for licenses buyers.

NO

As VP9 is approaching, I see this as a kind of backward looking sspecification. 

NO

Does not make any sense as previously stated by many others.

NO

It is already happening in major browsers, so why adding this here?

NO

See 1b/2b.

NO

User experience not state of the art. Backward looking technology.

YES

As it is not a technical problem, a technical body will not be able to solve the problem.

NO

See 6b.

NO

Also no clear future outlook regarding legal issues.

NO

Does not ensure interoperability. See 1b/2b/6b.

NO

See 10 b.

NO

Does not solve the issues mentioned above.

NO

See 1b and old technology.

NO

See above.

NO

See 9b.

NO

Historic.

---

From: Tim Panton <[email-masked]>
Date: Mon, 13 Jan 2014 13:48:57 +0000

On 11 Jan 2014, at 18:44, Svein Yngvar Willassen <[email-masked]> wrote:

> Is all forms of browsing on all kinds of devices included in the term "Browsers", including WebViews embedded in other applications?  
> 

It depends on the intent of the application. If it is using a webview as a way to render a UI to a fixed application, no,it isn't a browser.
If it is using the webview as  a way of communicating with an open ended number of different types of endpoint, then it is a browser.
(per my definition).

> However, I'm not sure I would change my position should the answer to the above questions be yes. There may be other entities that are not browsers that should be interoperable with each other. Two different native video conferencing solutions could for example claim to be WebRTC compliant without being interoperable with each other. 

Agreed, that's why the open ended number of different types of endpoint test is important.

---

From: OSCAR DIVORRA ESCODA <[email-masked]>
Date: Mon, 13 Jan 2014 15:31:54 +0000

Hi,

Please, find in the following my comments concerning this straw poll around video codec alternatives.

A. Are you in favor of this option [Yes/No/Acceptable]: No (for the moment, could change –see below-)

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

While probably, by maturity, technical quality, presence and deployment in the market, and legacy interoperability, H.264 could be the preferred MTI, its current IPR situation doesn’t seem right for adoption by the start-up environment. Hence, IPR licensing model should be addressed in order to be able to go with it as MTI.

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:

While it is somehow de-facto deployed, and already enabling current work in WebRTC (free of charge), its IPR situation, basically backed by Google, doesn’t seem completely cristal clear. Also, the predominant video codec in the general video market is H.264 and many applications are enabled with this last. By picking VP8 for WebRTC we can expect that at some point transcoding will be necessary to give VP8 streams interoperability with existing systems as well as in use cases like Archiving, it may be necessary transcoding to H.264 to give proper versatility to recorded video data. Hw support is still far from ideal.

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:

Considering #1 and #2 this would make things worse by adding costs to codecs support and service developments.

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:

As an exception to above, in the situation where #1 concerns where solved, and it was desired migration from #2 to #1, this case would be acceptable as a transitory situation. Also, if HW support for #2 does not really improve in non browser entities, this could help

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:

Problems with 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:

Very old technology. A significant step-back wrt VP8/H.264, and probably not practical for a successful WebRTC. It is probably similar to no MTI, forcing industry to integrate some other codec, without the consensus of an MTI, leading to Interoperability problems.

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:
Problems with 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:

#5 and #6 issues together.

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:

Similar to #6.

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:

Similar to #3 combined with #6.

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:

Similar to #3.

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:

Similar to #3.

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:

Not better than #1

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:

Similar to #6.

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:

Similar to #6 jointly with #7.

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:

Possible quality vs bitrate seems far from the requirements for RTC.

Best,

Òscar

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Badri Rajasekar <[email-masked]>
Date: Mon, 13 Jan 2014 09:44:47 -0800

Dear All,

Apologies, based on Matthew Kaufman's feedback, resubmitting as my personal
opinion.

Same as 9.

Thanks,

Badri

---

From: Badri Rajasekar <[email-masked]>
Date: Mon, 13 Jan 2014 09:46:25 -0800

Adding Point No 1 which got missed.

On Mon, Jan 13, 2014 at 9:44 AM, Badri Rajasekar <[email-masked]> wrote:

> Dear All,
>
> Apologies, based on Matthew Kaufman's feedback, resubmitting as my
> personal opinion.
>
> H.261 is not viable from a quality perspective and this mostly going to
> end up as fallback to H.261 in several scenarios without the advantages of
> H264/VP8 quality.
>
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Jan 2014 21:28:11 -0700

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

Oscar, I assumed that your answer to #14 was "No" based on the reason.  Let me know if I took that the wrong way. Thanks, Cullen

---

From: OSCAR DIVORRA ESCODA <[email-masked]>
Date: Tue, 14 Jan 2014 05:56:41 +0000

You got it right, Cullen.
Thanks!

Oscar

>> On 13/01/2014, at 20.28, Cullen Jennings <[email-masked]> wrote:
>>
>>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Jan 2014 09:31:52 +0100

WG,

To be explicit,

The Straw Poll has ended!

Thanks for participating, we have received 100 answers to my count at
the time of writing this. I think it has helped us all provides the
different views, and what different participants considers important.

We hope to be able to provide the chair's summary of the poll, we also
intended to provide our tabulation of the straw poll data. All hopefully
by the end of the week.

Cheers

Magnus Westerlund
WG chair

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Jan 2014 10:54:31 +0100

Hi Bernard and Tim,
(As document author)

I have reviewed this issue and have the following comments regarding it.
So, both VP8 and H.265 RTP Payload formats specifies how, but does not
mandate support of RPSI or SLI/SPLI. To my understanding such
requirement would be expressed by a user of the codec, like WebRTC. The
RTP usage document has so far avoided specifying any specifics for a
particular video codec and its payload format. And I would note that the
solution so far allows negotiation of these features, at least as long
as one accept to arrive at symmetric capabilities in send vs receive.

Thus the question is in which direction you think this should be addressed:

A) A generally changing the requirement on RPSI and SLI to enable its
usage with all video codecs (capable of using them) in WebRTC. Raising
the requirements level either to RECOMMENDED or SHALL.

B) Write a draft-ietf-rtcweb-video that has a section saying:
Codec Specific Requirements
---------------------------
- If you implement VP8 in WebRTC also RPSI and SLI SHALL be supported.
- If you implement H.265 in WebRTC also RPSI and SPLI SHALL be supported.

Note that SHALL could be replaced by RECOMMENDED depending on the WGs
consensus for what is appropriate here.

Note that the WG can choose to do both of the above alternative (A and
B) but for example use A) to raise these to RECOMMENDED and use B to
mandate them for specific codecs.

For the H.265 RTP Payload format and the SPLI message we might have
issues with its publication not finishing, less so with VP8, but not
impossible. We might have to deal with more unfinished pointers as we
get closer to the publication request state.

I believe that we need more input from the WG about this question. Both
what an appropriate way forward for this issue is, and what requirements
level people are interested in.

Cheers

Magnus

On 2013-12-30 16:28, Bernard Aboba wrote:
> Tim Panton said: 
> 
>> 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.  
> 
> 
> 
> 
> 

-- 

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 14 Jan 2014 12:06:17 +0100

On 01/12/2014 12:48 PM, "Martin J. Dürst" wrote:
> Below are my opinions. I'm using a numerical with 0.0 meaning NO and 
> 1.0 meaning YES, everything in between is acceptable, with various 
> degrees.

Martin, since you used neither 0.0 nor 1.0, I'm recording all your 
responses as ACCEPTABLE in my spreadsheet (not the official ones).

If you don't want this, you'd better give some more instructions on how 
to interpret them.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 14 Jan 2014 20:09:46 +0900

> responses as ACCEPTABLE in my spreadsheet (not the official ones).

That's fine with me.    Regards,   Martin.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 14 Jan 2014 12:14:48 +0100

On 01/12/2014 06:00 AM, Mandyam, Giridhar wrote:
> Does not allow interop with legacy systems and standards such as 3GPP 
> IMS Video Telephony. VP8 standardization is incomplete.
>
I have a problem interpreting the first sentence in the objections here.

If a system implements H.264, as required under this option, why would 
it not allow interop with legacy systems and standards such as 3GPP IMS 
Video Telephony?

And if it would not allow that, wouldn't that also be an objection to 
option 1 (H.264 only)?

---

From: "Mandyam, Giridhar" <[email-masked]>
Date: Tue, 14 Jan 2014 14:11:54 +0000

Harald,
Agreed - this response is inconsistent.  My apologies.  The objection should've simply stated that "VP8 standardization is incomplete"  (although I know that you are trying your best to address this issue).
-Giri

From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Tuesday, January 14, 2014 3:15 AM
To: [email-masked]
Subject: [rtcweb] Giri's choices - interoperability (Re: Straw Poll on Video Codec Alternatives)

If a system implements H.264, as required under this option, why would it not allow interop with legacy systems and standards such as 3GPP IMS Video Telephony?

And if it would not allow that, wouldn't that also be an objection to option 1 (H.264 only)?

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 14 Jan 2014 08:55:13 -0800

I'd prefer choice A.  It makes sense to me for all fb message recommendations to be handled within the same document.  Right now RPSI and SLI are discussed in the RTP usage document, but are OPTIONAL,  Since there will be substantial benefits in terms of interoperability,  I'd like to see commonly used fb messages RECOMMENDED for implementation (since implementation is not required in the codec documents a MUST is probably too much). 
 
It might also be appropriate to include a general statement that WebRTC implementations supporting a particular video codec need to conform to the requirements of the codec specification with respect to fb messages.  
 
I am indifferent to whether the RTP usage document includes a reference to the VP8 or H265 payload specifications or not (I'd suggest that either reference be non-normative). RFC 6184 does not have a section on fb messages similar to the ones in the VP8 and H265 payload specs, so that will not be of much help. 
 
> Date: Tue, 14 Jan 2014 10:54:31 +0100
> From: [email-masked]
> To: [email-masked]; [email-masked]
> CC: [email-masked]; [email-masked]
> Subject: Re: [rtcweb] Feedback messages (and problem with RTP usage document)
> 
> Hi Bernard and Tim,
> (As document author)
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Jan 2014 08:26:27 +0100

On 2014-01-14 17:55, Bernard Aboba wrote:
> I'd prefer choice A.  It makes sense to me for all fb message
> recommendations to be handled within the same document.  Right now RPSI
> and SLI are discussed in the RTP usage document, but are OPTIONAL, 
> Since there will be substantial benefits in terms of interoperability, 
> I'd like to see commonly used fb messages RECOMMENDED for implementation
> (since implementation is not required in the codec documents a MUST is
> probably too much).

I definitely wants more feedback on this. But, I think I am not
disagreeing with your view. Most of the video codecs that there exist
RTP payload formats today can use SLI and RPSI. RPSI don't make sense
for Motion JPEG and the video/raw or video/SMPTE292M that don't use
reference structures and SLI should be possible to use with also the RAW
formats so that has even wider applicability.

>  
> It might also be appropriate to include a general statement that WebRTC
> implementations supporting a particular video codec need to conform to
> the requirements of the codec specification with respect to fb messages. 

This, I don't see a problem with such a statement. Do you have a text
proposal?

>  
> I am indifferent to whether the RTP usage document includes a reference
> to the VP8 or H265 payload specifications or not (I'd suggest that
> either reference be non-normative). RFC 6184 does not have a section on
> fb messages similar to the ones in the VP8 and H265 payload specs, so
> that will not be of much help.

I would like to avoid these and let these be part of the
draft-ietf-rtcweb-audio and draft-ietf-rtcweb-video documents. The
intention with this structure was to enable piece wise revisioning if
required without needing to open up questions of all the media formats
at the same time. And that RTP usage changes would not require having to
deal with media format changes unless required.

Cheers

Magnus Westerlund

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Jan 2014 09:13:03 -0800

> formats so that has even wider applicability.

Those formats that don't need SLI/RPSI can just ignore this guidance,
or you can add a specific exception clause if you feel magnanimous,
i.e., "The SLI and RPSI feedback messages MUST be supported and acted
upon for video streams unless the codec does not support the concept
of macroblocks or reference frames (respectively)."  Or a statement to
that effect.

Basically, SLI and RPSI make sense for the codecs we actually care
about, so let's require them.  If people want to do raw video, then
they are either smart enough to know that SLI/RPSI can't help them, or
nothing an RFC says will help fix their issues.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 15 Jan 2014 10:20:55 -0800

> of macroblocks or reference frames (respectively)."  Or a statement to
[BA] I like this approach (though I'd suggest we consider SHOULD instead of MUST). 
> nothing an RFC says will help fix their issues.

[BA]  I agree.  Additional codecs could of course define requirements above and beyond this (as the H.265 payload document does with SPLI), but at least we'll have set baseline expectations.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 17 Jan 2014 19:06:53 +0100

>manner is often unduly burdensome under current licensing practises.

A practical example for the confusion around the subject is the recent
RfC in the Wikimedia community on H.264 support on their websites. On
https://commons.wikimedia.org/w/index.php?oldid=114053933 the proposal
claims that "Merely distributing MP4 files never requires a patent
license." On https://commons.wikimedia.org/w/index.php?oldid=114147018
on the other hand the proposal is "If this RFC passes, we would seek to
obtain an "Internet Broadcast" license", and that quote is part of a
larger text trying to address other points of confusion such as whether
users need or have license to upload their H.264 content to begin with.
-- 
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/