Subject: [rtcweb] Video codec selection - way forward

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 13 Nov 2013 21:23:56 +0100

Folks,

I hope everybody had a safe trip back home after Vancouver.

As you all know, we need to make progress regarding the selection of the
MTI video codec. The following are some of the alternatives we have on
the table:

 1. All entities MUST support H.264
 2. All entities MUST support VP8
 3. All entities MUST support both H.264 and VP8
 4. Browsers MUST support both H.264 and VP8
 5. All entities MUST support either H.264 or VP8
 6. All entities MUST support H.261
 7. There is no MTI video codec

If you want the group to consider additional alternatives to the ones
above, please let the group know within the following *two weeks*. At
that point, the chairs will be listing all the received alternatives and
proposing a process to select one among them.

Please, send your proposals in an email to the list. You do not need to
write a draft; just send the text you would like to see in the final
document regarding video codecs.

Thanks,

Gonzalo
Responsible AD for this WG

---

From: cowwoc <[email-masked]>
Date: Wed, 13 Nov 2013 15:46:37 -0500

Hi Gonzalo,

I like your proposal, except for #4. I believe that for this to work, 
all entities must follow the same rules, not just the browsers.

Can the person who proposed #4 please explain the reasoning behind it?

Thanks,
Gili

On 13/11/2013 3:23 PM, Gonzalo Camarillo wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 13 Nov 2013 22:17:07 +0000

Hi Gonzalo, 
Re your point 5.: ³either or² is often understood as an exclusive or.  I
don¹t think anyone proposed that.  A better way to express 5. would be
³All entities MUST support at least one of H.264 and VP8².
Stephan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Nov 2013 21:26:17 -0500

Regarding number 4, here is how I think of it:

If browsers implement both, it means that an application provider wishing
to offer a service (take Hangouts or Skype as examples), can pick the one
they like, implement just that in their native apps (mobile, desktop, etc.)
where the app provider has control over the full stack, and still work with
clients of that service which run in the browser, where the app provider
does not have control over the full stack as the real-time media stack is
provided by the browser and not the web app.

The benefit of this approach is that it enables interoperability between
clients on different platforms for the same provider.

The drawback is, for inter-service federation (which requires much more
than just codecs to be aligned), you might run into a case where a user
using a mobile app from provider 1 (say, Skype) calls a user using a mobile
app from provider 2 (say, Hangouts), and then since each chose a different
video codec, there is no common codec. Of course that assumes the two
providers in question are willing to even federate in the first place.

-Jonathan R.

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Nov 2013 20:02:08 -0800

Assuming we are talking about native support, Option #4 maximizes legal liability. Since this the major underlying issue it will be the hardest option to get past the legal department. If we aren't talking native but plugins then it is more forward thinking to focus on next generation codec support. Either way, Option 4 loses out to either 1, 2, or 7. 

> On Nov 13, 2013, at 18:26, "Jonathan Rosenberg" <[email-masked]> wrote:
> 
> If browsers implement both, it means that an application provider wishing to offer a service (take Hangouts or Skype as examples), can pick the one they like, implement just that in their native apps (mobile, desktop, etc.) where the app provider has control over the full stack, and still work with clients of that service which run in the browser, where the app provider does not have control over the full stack as the real-time media stack is provided by the browser and not the web app. 
> 
> The benefit of this approach is that it enables interoperability between clients on different platforms for the same provider.
> 
> The drawback is, for inter-service federation (which requires much more than just codecs to be aligned), you might run into a case where a user using a mobile app from provider 1 (say, Skype) calls a user using a mobile app from provider 2 (say, Hangouts), and then since each chose a different video codec, there is no common codec. Of course that assumes the two providers in question are willing to even federate in the first place. 
> 
> -Jonathan R.
> 
> 
> 
>

---

From: "cb.list6" <[email-masked]>
Date: Wed, 13 Nov 2013 20:11:25 -0800

Why no SHOULD implement vp8 and h248? SHOULD means you will do it unless
you have a real good reason.

MUST is too hard for this WG.  Many implementations have a really good
reason to not do vp8 OR h248.

Saying that all webrtc MUST do one or the other or both is disingenuous.

SHOULD for both is as good as we are going to get with this complicated IPR
environment.  Using MUST is simply not going to work and we have 10,000 on
this mailer to back that up.

Cameron
On Nov 13, 2013 12:24 PM, "Gonzalo Camarillo" <

---

From: Robin Raymond <[email-masked]>
Date: Wed, 13 Nov 2013 20:34:45 -0800

+1 to SHOULD option for both VP8 and H264.

MUST is too strong.

I think there's strong reasons why most people would include both and 
that's simply because of market forces and install base. Why be 
incompatible and make your product look weak and incompatible if there 
is a reasonable option. With Cisco's announcement that people who can 
take H264 likely will if they feel comfortable enough with IPR exposure. 
For those whom have IPR issues, they will either license or no amount of 
"mandate" is going to force them to accept exposure they aren't willing 
to risk even listed as an MTI.

"SHOULD" seems reasonable and logical to me with no MTI.

Robin

> cb.list6 <mailto:[email-masked]>
> 13 November, 2013 8:11 PM
>
> Why no SHOULD implement vp8 and h248? SHOULD means you will do it 
> unless you have a real good reason.
>
> SHOULD for both is as good as we are going to get with this 
> complicated IPR environment.  Using MUST is simply not going to work 
> and we have 10,000 on this mailer to back that up.
>
> Cameron
>
>

---

From: cowwoc <[email-masked]>
Date: Thu, 14 Nov 2013 00:22:26 -0500

That's reasonable. Thanks for the clarification :)

Gili

On 13/11/2013 9:26 PM, Jonathan Rosenberg wrote:
> If browsers implement both, it means that an application provider 
> wishing to offer a service (take Hangouts or Skype as examples), can 
> pick the one they like, implement just that in their native apps 
> (mobile, desktop, etc.) where the app provider has control over the 
> full stack, and still work with clients of that service which run in 
> the browser, where the app provider does not have control over the 
> full stack as the real-time media stack is provided by the browser and 
> not the web app.
>
> The benefit of this approach is that it enables interoperability 
> between clients on different platforms for the same provider.
>
> The drawback is, for inter-service federation (which requires much 
> more than just codecs to be aligned), you might run into a case where 
> a user using a mobile app from provider 1 (say, Skype) calls a user 
> using a mobile app from provider 2 (say, Hangouts), and then since 
> each chose a different video codec, there is no common codec. Of 
> course that assumes the two providers in question are willing to even 
> federate in the first place.
>
> -Jonathan R.
>
>
>
>
> On Wed, Nov 13, 2013 at 5:17 PM, Stephan Wenger <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Gonzalo,
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     >Folks,
>     >
>     >[email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> http://www.jdrosen.net
>
>

---

From: cowwoc <[email-masked]>
Date: Thu, 14 Nov 2013 00:22:24 -0500

> unless you have a real good reason.

SHOULD doesn't carry any accountability. Anyone will tell you they have 
a "real good reason" to avoid implementing one codec or another. We've 
heard plenty of excuses on this list of why one party or another 
believes it is legally risky to implement VP8 or H.264, respectively. So 
in that sense, it is meaningless.

> and we have 10,000 on this mailer to back that up.

What you say is true, but if we accept this (and go with SHOULD) we are 
essentially ending up with "no MTI" which leads to the dark side 
(transcoding or dropped calls).

Rock --> WebRTC <-- Hard place :)

Gili

---

From: Gustavo Garcia <[email-masked]>
Date: Wed, 13 Nov 2013 21:35:36 -0800

8. All entities MUST support VP8 and H.264 is RECOMMENDED to implement

Ensure interoperability with a common codec and avoid transcoding when
interconnecting with non-WebRTC platforms/devices as much as possible.

---

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

>>SHOULD doesn't carry any accountability. Anyone will tell you they have a
"real good reason" to avoid implementing one >>codec or another. We've
heard plenty of excuses on this list of why one party or another believes
it is legally risky to >>implement VP8 or H.264, respectively. So in that
sense, it is meaningless.

I agree. SHOULD is just like 'no MTI' and point 5 also implies 'no MTI'

On 14 November 2013 07:22, cowwoc <[email-masked]> wrote:

> SHOULD doesn't carry any accountability. Anyone will tell you they have a
> "real good reason" to avoid implementing one codec or another. We've heard
> plenty of excuses on this list of why one party or another believes it is
> legally risky to implement VP8 or H.264, respectively. So in that sense, it
> is meaningless.
>
>
>> SHOULD for both is as good as we are going to get with this complicated
>> IPR environment.  Using MUST is simply not going to work and we have 10,000
>> on this mailer to back that up.
>>
>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Nov 2013 09:38:20 +0200

Hi Stephan,

yes, the wording you suggest captures the idea in a clearer way.

Thanks,

Gonzalo

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Nov 2013 09:57:26 +0100

Hi,

If no one is protesting I would suggest that we update four to say:

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

This makes this alternative clearer I believe.

Cheers

Magnus

On 2013-11-14 03:26, Jonathan Rosenberg wrote:
> (mobile, desktop, etc.) where the app provider has control over the full
> stack, and still work with clients of that service which run in the
> browser, where the app provider does not have control over the full
> stack as the real-time media stack is provided by the browser and not
> the web app. 
> 
> using a mobile app from provider 1 (say, Skype) calls a user using a
> mobile app from provider 2 (say, Hangouts), and then since each chose a
> different video codec, there is no common codec. Of course that assumes
> the two providers in question are willing to even federate in the first
> place. 
> 
> -Jonathan R.
> 
> 
> 
> 

-- 

Magnus Westerlund

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Nov 2013 10:07:52 +0100

WG,

I have put the given video codec selection alternatives on this wikipage:

http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart

It is not acceptable to simply add things on this list. You need to send
email to the list.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Leon Geyser <[email-masked]>
Date: Thu, 14 Nov 2013 11:37:15 +0200

Point 6 can change to:
All entities MUST support H.261 and all entities MUST support at least one
of H.264 and VP8
or it can be made a new point?

I don't like point 5 at all since it doesn't really help with negotiation
failure IMO. Implement the codec that you want to implement = No MTI.

On 14 November 2013 11:07, Magnus Westerlund <[email-masked]
> wrote:

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Nov 2013 11:51:51 +0200

Hi,

with respect to what types of alternatives will be considered, at this
point I would prefer to focus on agreeing on a MUST-level statement.
Once we do that, we can consider SHOULD-level statements if the group
considers them important.

Additionally, there have been a few suggestions related to combining
several options. For example, 4+5 or 5+6. I would suggest to keep these
combinations separate and not to treat them as completely new options
for clarity. Such separation would help us decide among atomic options
(which is already difficult enough) as opposed to deciding among
more-complex combinations.

In any case, these are just my preferences. As usual, I will let the
chairs manage this process with the inputs of the WG.

Cheers

Gonzalo

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Nov 2013 11:19:31 +0100

On 2013-11-14 10:37, Leon Geyser wrote:
> Point 6 can change to:
> All entities MUST support H.261 and all entities MUST support at least
> one of H.264 and VP8

I think that would be a new point. It has a significantly different
implications than the current 6. I will add it as 9. to the list.
Unless you like to withdraw it from consideration.

> 
> I don't like point 5 at all since it doesn't really help with
> negotiation failure IMO. Implement the codec that you want to implement
> = No MTI.

I agree that is not an MTI. However, it reduces the space of possible
video codec implementations a transcoder absolutely need to support to
only two, instead of any. Thus, I has merit in the set of proposals for
alternatives.

Cheers

Magnus

> 
> 
> On 14 November 2013 11:07, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     WG,
> 
>     <tel:%2B46%2010%207148287>
>     <tel:%2B46%2073%200949079>
>     <mailto:[email-masked]>

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Nov 2013 11:23:30 +0100

Hi,

I have currently not added this SHOULD alternative to the list.

I think the important question is what alternatives in regard to what
will be required to implement, i.e. Mandatory to Implement.

After we have run this process regarding mandatory to implement we can
consider additional recommendations that the WG likes to make.

Cheers

Magnus

On 2013-11-14 08:23, Leon Geyser wrote:
>>>SHOULD doesn't carry any accountability. Anyone will tell you they
> have a "real good reason" to avoid implementing one >>codec or another.
> We've heard plenty of excuses on this list of why one party or another
> believes it is legally risky to >>implement VP8 or H.264, respectively.
> So in that sense, it is meaningless.
> 
> On 14 November 2013 07:22, cowwoc <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>         Why no SHOULD implement vp8 and h248? SHOULD means you will do
>         it unless you have a real good reason.
> 
> 
>     SHOULD doesn't carry any accountability. Anyone will tell you they
>     have a "real good reason" to avoid implementing one codec or
>     another. We've heard plenty of excuses on this list of why one party
>     or another believes it is legally risky to implement VP8 or H.264,
>     respectively. So in that sense, it is meaningless.
> 
> 
>         MUST is too hard for this WG.  Many implementations have a
>         really good reason to not do vp8 OR h248.
> 
>         complicated IPR environment.  Using MUST is simply not going to
>         work and we have 10,000 on this mailer to back that up.
> 
> 
>     What you say is true, but if we accept this (and go with SHOULD) we
>     are essentially ending up with "no MTI" which leads to the dark side
>     _________________________________________________
>     rtcweb mailing list
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> 
> 
> 

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Nov 2013 11:25:01 +0100

Gustavo,

I will remove this alternative from the list. I request all alternatives
to be focused on only what is Mandatory to Implement. We can discuss
recommendations or should levels after we have made a decision on the
mandatory level.

Cheers

Magnus

On 2013-11-14 06:35, Gustavo Garcia wrote:
> On Wed, Nov 13, 2013 at 12:23 PM, Gonzalo Camarillo
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     Folks,
> 

-- 

Magnus Westerlund

---

From: Gili <[email-masked]>
Date: Thu, 14 Nov 2013 15:24:17 -0500

I would argue this should be a new point. I am advocating H.261 as MTI 
and all other codecs are optional and I want this option to stand in its 
own right. I don't think we need to mandate what other codecs vendors 
must implement (I'm not sure it would make a practical difference anyway).

Gili

On 14/11/2013 4:37 AM, Leon Geyser wrote:
> negotiation failure IMO. Implement the codec that you want to 
> implement = No MTI.
>
>
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     WG,
>
>     SE-164 80 Stockholm, Sweden| mailto:
>     [email-masked] <mailto:[email-masked]>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 15 Nov 2013 13:50:05 +0100

* Gonzalo Camarillo wrote:
>above, please let the group know within the following *two weeks*.

Whatever the Working Group will eventually decide, I think it would be
bad if people could easily say "But they did not consider Theora!", so
I think it would be good to either list Theora as an alternative, or to
make sure any such a list for consideration by the Working Group does
mention Theora in some other form, like explaining why it is not listed
as an alternative.
-- 
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: Leon Geyser <[email-masked]>
Date: Fri, 15 Nov 2013 15:03:01 +0200

+1, Theora should be in the list.

---

From: cowwoc <[email-masked]>
Date: Fri, 15 Nov 2013 08:51:51 -0500

+1 with the caveat that I think option 6 should simply state:

6. All entities MUST support a specific IPR-expired codec (to be decided 
at a later meeting) such as H.261 or Theora.

The goal remains the same. I don't think people voting for this option 
need to know up-front what the specific codec would be so long as we 
explain that we'll try to pick the best codec possible. Correct me if 
I'm wrong :)

Gili

On 15/11/2013 8:03 AM, Leon Geyser wrote:
> On 15 November 2013 14:50, Bjoern Hoehrmann <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Björn Höhrmann · mailto:[email-masked]
>     <mailto:[email-masked]> · http://bjoern.hoehrmann.de
>     Am Badedeich 7 · Telefon: +49(0)160/4415681
>     <tel:%2B49%280%29160%2F4415681> · http://www.bjoernsworld.de

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Nov 2013 15:22:44 +0100

> explain that we'll try to pick the best codec possible. Correct me if

I would believe there are a lot of people in the WG that consider the
IPR risks between Theora and H.261 significantly different. I realize
that list each alternative code will result in a significantly longer
list, but at the same time, I don't see how the above MUST statement
allows the WG to conclude on video codec selection. If we would agree on
the above, we would spend another year discussing our IPR beliefs around
various codecs. From that perspective I do think there is better to have
the individuals in the WG form their own opinions regarding an explicit
proposal.

At the same time, I would recommend that the people who believe in the
above option, coming to an agreement now, before the process starts, on
which codec alternative they want to support. This is after all also a
question of how to best trade IPR risk vs capability and quality per
bit. Thus improving that options chance.

Cheers

Magnus Westerlund

---

From: cowwoc <[email-masked]>
Date: Fri, 15 Nov 2013 10:42:52 -0500

Magnus,

In light of Harald and your responses, I'm in favor of two separate 
options for H.261 and Theora respectively. If we find a narrow those 
options down to one within the next two weeks, great, but otherwise I'd 
list them as separate options.

Also, how would the "voting" work exactly? I was imagining the following 
mechanism:

  * Each person is given the 10 or so options we'll end up with in 2 weeks.
  * The person throws out all options they don't consider acceptable
    under any circumstances
  * They sort the remaining options in order of preference
  * We tabulate the results across everyone, assigning a decreasing
    number of points to the options as the priority decreases (meaning,
    1st choice gets the most points, 2nd choice less, and so on)
  * We publish the results, how many "points" each option had and if
    there is a huge margin for the top one, it wins.

Gili

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 15 Nov 2013 08:23:10 -0800

On Fri, Nov 15, 2013 at 7:42 AM, cowwoc <[email-masked]> wrote:

>    - Each person is given the 10 or so options we'll end up with in 2
>    weeks.
>    - The person throws out all options they don't consider acceptable
>    under any circumstances
>    - They sort the remaining options in order of preference
>    - We tabulate the results across everyone, assigning a decreasing
>    number of points to the options as the priority decreases (meaning, 1st
>    choice gets the most points, 2nd choice less, and so on)
>    - We publish the results, how many "points" each option had and if
Please please please let's not try to invent new voting systems on this
mailing list. This is an incredibly technical area
(see http://en.wikipedia.org/wiki/Arrow's_impossibility_theorem if you're
not convinced).

-Ekr

>    - Gili

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Nov 2013 17:38:06 +0100

>     there is a huge margin for the top one, it wins.

We chairs are working on a proposal for a process for the selection for
the WG to review and do a consensus call on to use. We hope to have
something next week.

Cheers

Magnus Westerlund

---

From: cowwoc <[email-masked]>
Date: Fri, 15 Nov 2013 12:20:02 -0500

On 15/11/2013 11:23 AM, Eric Rescorla wrote:
> On Fri, Nov 15, 2013 at 7:42 AM, cowwoc <[email-masked] 
>     In light of Harald and your responses, I'm in favor of two
>     separate options for H.261 and Theora respectively. If we find a
>     narrow those options down to one within the next two weeks, great,
>     but otherwise I'd list them as separate options.
>
>     Also, how would the "voting" work exactly? I was imagining the
>     following mechanism:
>
>       * The person throws out all options they don't consider
>         acceptable under any circumstances
>       * We tabulate the results across everyone, assigning a
>         decreasing number of points to the options as the priority
>         decreases (meaning, 1st choice gets the most points, 2nd
>         choice less, and so on)
>       * We publish the results, how many "points" each option had and
>         if there is a huge margin for the top one, it wins.
>
>
> (see http://en.wikipedia.org/wiki/Arrow's_impossibility_theorem 
> <http://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem> if you're
> not convinced).
Eric,

I'm not trying to achieve what is mentioned in that Wikipedia post. 
Meaning, I believe it is acceptable for the resulting tally to violate 
the wishes of individual priorities.

But anyway, let's say you still object, what is your counter-proposal? 
What were we planning to do?

Gili

---

From: cowwoc <[email-masked]>
Date: Fri, 15 Nov 2013 12:22:44 -0500

> the WG to review and do a consensus call on to use. We hope to have

Okay, got it. Eric, please disregard my last post.

Thanks,
Gili

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 15 Nov 2013 09:27:46 -0800

> I'm not trying to achieve what is mentioned in that Wikipedia post.

I have no idea what you think you are trying to do, then. What you
described is
precisely a voting system (though not a good one) and so we have all the
usual
problems.

> Meaning, I believe it is acceptable for the resulting tally to violate the
> wishes of individual priorities.
>

I don't know what you mean by "violate the wishes of individual priorities".
The task here is to try to come to an overall decision that aggregates
people's individual preferences. That's hard for the reasons I indicated.

> What were we planning to do?

I was planning to let the chairs propose something.

With that said, there's a huge literature on voting systems so no doubt one
of the many
well-known systems (Approval, IRV, ...) can be used without the need for us
to invent
something new.

-Ekr

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 15 Nov 2013 16:56:33 -0500

I am forwarding the following on behalf of Hervé.  You can consider this
also a +1 from me for the proposal, for what it's worth:

> Proposal for MTI video codec: All entities MUST support Theora.
> 
> Theora was derived from VP3 (a codec from 2000).
> Theora bitstream format freeze in June 2004.
> 
> Theora documentation (including link to spec pdf) : http://theora.org/doc/
> 
> If you want to try out the codec, rather than write your own from scratch, please consider using the reference implementation's latest sources (rather than version 1.1) : http://git.xiph.org/?p=mirrors/theora.git
> 
> There have been several commercial products that apparently weren't sued into bankruptcy: http://wiki.xiph.org/Games_that_use_Theora
> 
> No license fees are owed to Xiph for implementation.
> 
> See also:
> http://wiki.xiph.org/TheoraSoftwarePlayers
> http://wiki.xiph.org/Theora_Hardware
> http://wiki.xiph.org/TheoraSoftwareEncoders
> http://wiki.xiph.org/TheoraDecoders
> http://wiki.xiph.org/TheoraEncoders
> 
> 
> - Hervé

-- 
Libre Video
http://librevideo.org

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Nov 2013 11:55:05 +0100

Hi,

As requested I have added this to the list of proposals.

/Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Nov 2013 13:45:12 +0100

WG,

The current list of proposed alternative are the following one:

 The following alternatives has been proposed:

  1. All entities MUST support H.264
  2. All entities MUST support VP8
  3. All entities MUST support both H.264 and VP8
  4. Browsers MUST support both H.264 and VP8, other entities MUST
     support at least one of H.264 and VP8
  5. All entities MUST support at least one of H.264 and VP8
  6. All entities MUST support H.261
  7. There is no MTI video codec
  8. 5+6, i.e. All entities MUST support H.261 and all entities MUST
     support at least one of H.264 and VP8
  9. All entities MUST support Theora.
 10. All entities SHOULD support both H.264 and VP8. All entities MUST
     at least implement one of those. Entities that do not support both
     H.264 and VP8 MUST implement H.261.

The deadline to propose additional alternatives are: 27th of November 2013

Cheers

Magnus

-- 

Magnus Westerlund

---

From: cowwoc <[email-masked]>
Date: Mon, 18 Nov 2013 11:44:56 -0500

Looks good! I'd like to get a clarification which affects multiple 
options, but #10 most of all.

Does the WG commit to providing reference implementations that supports 
VP8, H.264, H.261 with a commercially-friendly license? I am talking 
strictly about the software license, not the codec IPR. Meaning, libx264 
requires a GPL license and ffmpeg requires either a LGPL or GPL license. 
I would argue that libx264 is a non-starter for commercial use on any 
platform (due to GPL) and ffmpeg is not usable under iOS (since LGPL + 
static linking is equivalent to GPL). It is my understanding that the 
current WebRTC reference implementation is published under the BSD 
license. I am asking for the final reference implementation (supporting 
these codecs) to be published under the same license.

I'm not saying that anyone has to ship a reference implementation 
supporting all 3 codecs, but rather that the WG should publish a 
reference implementation demonstrating how it can be done and proving 
interoperability actually works as expected.

Thanks,
Gili

---

From: Maik Merten <[email-masked]>
Date: Mon, 18 Nov 2013 18:14:47 +0100

Regarding H.261, apart from ffmpeg there's also a maintained 
implementation over at

http://sourceforge.net/p/opalvoip/code/29319/tree/opal/trunk/plugins/video/H.261-vic/h261vic.cxx

which is covered by the Mozilla Public License 1.0 
(http://www.mozilla.org/MPL/1.0/).

"3.7. Larger Works.
You may create a Larger Work by combining Covered Code with other code 
not governed by the terms of this License and distribute the Larger Work 
as a single product. In such a case, You must make sure the requirements 
of this License are fulfilled for the Covered Code."

The H.261 *en*coder of that project looks rather primitive (only 
generating I-frames), but the *de*coder should be feature-complete. 
Perhaps that's something to build upon.

I would also suspect that complete and battle-tested implementations 
gather dust at some vendors of telco stuff, but nobody seems to have 
open sourced one.

Maik

---

From: cowwoc <[email-masked]>
Date: Mon, 18 Nov 2013 12:38:15 -0500

Okay, so I believe this is an open issue. I've changed the topic to 
avoid hijacking the old thread.

Gili

On 18/11/2013 12:14 PM, Maik Merten wrote:
> not governed by the terms of this License and distribute the Larger 
> Work as a single product. In such a case, You must make sure the 
> requirements of this License are fulfilled for the Covered Code."
>

---

From: cowwoc <[email-masked]>
Date: Mon, 18 Nov 2013 13:38:44 -0500

Could the chairs comment on this? Is this the WG's position? (Do you 
need more time to think this over?)

I ask because this would affect which option we'd vote for.

Thanks,
Gili

On 18/11/2013 12:58 PM, Eric Rescorla wrote:
> On Mon, Nov 18, 2013 at 8:44 AM, cowwoc <[email-masked] 
>     Does the WG commit to providing reference implementations that
>     supports VP8, H.264, H.261 with a commercially-friendly license? I
>     am talking strictly about the software license, not the codec IPR.
>     Meaning, libx264 requires a GPL license and ffmpeg requires either
>     a LGPL or GPL license. I would argue that libx264 is a non-starter
>     for commercial use on any platform (due to GPL) and ffmpeg is not
>     usable under iOS (since LGPL + static linking is equivalent to
>     GPL). It is my understanding that the current WebRTC reference
>     implementation is published under the BSD license. I am asking for
>     the final reference implementation (supporting these codecs) to be
>     published under the same license.
>
>     reference implementation demonstrating how it can be done and
>     proving interoperability actually works as expected.
>
>
> Huh?
>
> IETF WGs almost never provide reference implementations. Given the 
> scale of the effort and the
> state of the existing implementations, I can't imagine why would do
> so in this case.
>
> -Ekr
>
>
>     Thanks,
>     Gili
>
>

---

From: Maik Merten <[email-masked]>
Date: Mon, 18 Nov 2013 20:12:22 +0100

FWIW, I think I found a BSD-stlye H.261 implementation, which appears to 
include contributions from Cisco:

http://mpeg4ip.cvs.sourceforge.net/viewvc/mpeg4ip/mpeg4ip/server/mp4live/h261/encoder-h261.cpp?revision=1.12&view=markup

A BSD-style implementation thus wouldn't have to start from scratch, 
albeit some extensive massaging may be needed to plug it into a WebRTC 
context.

Maik

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 18 Nov 2013 19:44:04 +0000

Maybe you can explain how the WG is able to commit any of this.

Neither IETF or the WG are legal entities!

Individuals may express opinions on various options, but you will get nothing beyond this in my understanding.

Regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of cowwoc
> Sent: 18 November 2013 16:45
> To: [email-masked]
> Subject: Re: [rtcweb] Video codec selection - way forward
> 
> 
> Looks good! I'd like to get a clarification which affects 
> multiple options, but #10 most of all.
> 
> Does the WG commit to providing reference implementations 
> that supports VP8, H.264, H.261 with a commercially-friendly 
> license? I am talking strictly about the software license, 
> not the codec IPR. Meaning, libx264 requires a GPL license 
> and ffmpeg requires either a LGPL or GPL license. 
> I would argue that libx264 is a non-starter for commercial 
> use on any platform (due to GPL) and ffmpeg is not usable 
> under iOS (since LGPL + static linking is equivalent to GPL). 
> It is my understanding that the current WebRTC reference 
> implementation is published under the BSD license. I am 
> asking for the final reference implementation (supporting 
> I'm not saying that anyone has to ship a reference 
> implementation supporting all 3 codecs, but rather that the 
> WG should publish a reference implementation demonstrating 
> how it can be done and proving interoperability actually 
> works as expected.
> 
> Thanks,
> Gili
> 
> > The deadline to propose additional alternatives are: 27th 
> of November 
> > 2013
> >
> > Cheers
> >
> > Magnus
> >
> >> As you all know, we need to make progress regarding the 
> selection of 
> >> the MTI video codec. The following are some of the alternatives we 
> >> have on the table:
> >>
> >> that point, the chairs will be listing all the received 
> alternatives 
> >> and proposing a process to select one among them.
> >>
> >> Please, send your proposals in an email to the list. You 
> do not need 
> >> to write a draft; just send the text you would like to see in the 
> >> final document regarding video codecs.
> >>
> >> Thanks,
> >>
> >> Gonzalo

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 18 Nov 2013 19:44:04 +0000

While I do not think it is an alternative in itself, and therefore orthogonal to this discussion, I would like to see any draft resulting from this also containing a set of requirements leading to work that makes any hardware based codec available to the application via the browser.

I agree any APIs that already exist in this area do need more work and that work is not the work of rtcweb (and it is also not my area of expertise), but we seem to be drifting round in circles trying to deal with rights issues on downloaded codecs, and ignoring the use of codecs that may already be installed on the device for which the rights have already been paid.

Regards

Keith

> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: 18 November 2013 12:45
> To: [email-masked]
> >  3. All entities MUST support both H.264 and VP8  4. Browsers MUST 
> > support both H.264 and VP8  5. All entities MUST support 
> either H.264 
> > or VP8  6. All entities MUST support H.261  7. There is no 
> MTI video 
> > codec
> > 
> > Please, send your proposals in an email to the list. You do 
> not need

---

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

> Does the WG commit to providing reference implementations 

IETF process does not require the WG to provide any implementations at all - I do not think the WG is committing to provide implementations of anything. Of course individuals or companies might but not the IETF. 

Cullen (as one of the chairs) …