Subject: [rtcweb] MTI Video Codec: a novel proposal

From: Adam Roach <[email-masked]>
Date: Sun, 09 Nov 2014 16:08:25 -1000

It appears that we're running headlong into another in-person discussion 
about the relative merits of H.264 and VP8 as MTI candidates again. 
Matthew Kaufman has argued that this conversation is doomed to failure 
because no major player has been willing to change their position. The 
players he cited were Cisco, Google, and Mozilla, who have represented 
the three main positions on this topic pretty effectively. Although we 
participate as individuals in the IETF, I think it's fair to say that 
the last time we had this conversation, the median positions of 
participants from those companies were "H.264 or die", "VP8 or die", and 
"either one as long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may 
have become quite important: we're all tired of this. Over two years 
ago, in March of 2012 -- before I even had an particular interest in 
WebRTC except as a user -- this had already become such a long-running 
acrimonious debate that I was brought in as a neutral third party to try 
to mediate. I'm weary of this argument; and, with the exception of a few 
aggressive voices who seem to enjoy the battle more than the outcome, 
I'm hearing a similar exhausted timbre in the messages of other 
participants (and the key stakeholders in particular).

So, I want to float a proposal that represents a compromise, to see if 
we can finally close this issue. First, I want to start out by 
reiterating a well-worn observation that the hallmark of a good 
compromise is that nobody leaves happy, but everyone can force 
themselves to accept it. And I want to be crystal clear: the solution 
I'm about to float just barely clears the bar of what I think I can live 
with. This proposal is based on an observation that the dominating 
issues in this conversation remain those of licensing, not technology or 
even incumbency. I’ve discussed this extensively with representatives of 
all three of the players I mention above, and they are willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent", 
"WebRTC device", and "WebRTC-compatible endpoint" in section 2.2 of 
draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:

 1. WebRTC User Agents MUST implement both VP8 and H.264.

 2. WebRTC devices MUST implement both VP8 and H.264. If compelling
    evidence arises that one of the codecs is available for use on a
    royalty-free basis, such as all IPR declarations known for the codec
    being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change
    this normative statement to indicate that only that codec is
    required. For absolute, crystal clarity, this provision is only
    applicable to WebRTC devices, and not to WebRTC User Agents.

 3. WebRTC-compatible endpoints are free to implement any video codecs
    they see fit, if any (this follows logically from the definition of
    "WebRTC-compatible endpoint," and doesn't really need to be stated,
    but I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can 
work with all devices and user agents. This has the property of giving 
no one exactly what they want. And, unlike any other previous plans, 
this has the property of coming to a decision while maintaining pressure 
on the only parties who can make a change in the IPR landscape to do so.

/a

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 10 Nov 2014 03:26:52 +0100

Hi Adam,

I was one of the "VP8 or die" advocates, but I can definitely
understand your points and frustration about where this endless fight
lead and left us.

As long as all the major user agents will actually comply (I'm
especially thinking about the one that are currently "missing"),
I'd be ok with mandating both as you suggest.

Lorenzo

On Sun, 09 Nov 2014 16:08:25 -1000
Adam Roach <[email-masked]> wrote:

> It appears that we're running headlong into another in-person
> discussion about the relative merits of H.264 and VP8 as MTI
> candidates again. Matthew Kaufman has argued that this conversation
> is doomed to failure because no major player has been willing to
> change their position. The players he cited were Cisco, Google, and
> Mozilla, who have represented the three main positions on this topic
> pretty effectively. Although we participate as individuals in the
> IETF, I think it's fair to say that the last time we had this
> conversation, the median positions of participants from those
> companies were "H.264 or die", "VP8 or die", and "either one as long
> as it's *only* one", respectively.
> 
> However, even if nothing else has changed, I think one salient point
> may have become quite important: we're all tired of this. Over two
> years ago, in March of 2012 -- before I even had an particular
> interest in WebRTC except as a user -- this had already become such a
> long-running acrimonious debate that I was brought in as a neutral
> third party to try to mediate. I'm weary of this argument; and, with
> the exception of a few aggressive voices who seem to enjoy the battle
> more than the outcome, I'm hearing a similar exhausted timbre in the
> messages of other participants (and the key stakeholders in
> particular).
> 
> So, I want to float a proposal that represents a compromise, to see
> if we can finally close this issue. First, I want to start out by 
> I'm about to float just barely clears the bar of what I think I can
> live with. This proposal is based on an observation that the
> dominating issues in this conversation remain those of licensing, not
> technology or even incumbency. I’ve discussed this extensively with
> representatives of all three of the players I mention above, and they
> are willing to sign on.
> 
>     royalty-free basis, such as all IPR declarations known for the
> codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will
> change this normative statement to indicate that only that codec is
>     they see fit, if any (this follows logically from the definition
> of "WebRTC-compatible endpoint," and doesn't really need to be stated,
> This has the property of ensuring that all devices and user agents
> can work with all devices and user agents. This has the property of
> giving no one exactly what they want. And, unlike any other previous
> plans, this has the property of coming to a decision while
> maintaining pressure on the only parties who can make a change in the
> IPR landscape to do so.
> 
> /a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 9 Nov 2014 21:27:39 -0500

Adam -

I'm willing to sign up for this.

As you point out, this issue has been brewing for a long time and is
slowing the adoption of webrtc. We need to find a solution that works and
move the industry forward.

For the "incumbents" as you call them - the presence of h264 in
browsers will allow interop between their browser apps and existing h264
devices which can be webrtc compatible. That is the primary use case to be
solved for them and this proposal addresses it.

I hope others can get behind this as well.

Thx,
Jonathan R.

On Sunday, November 9, 2014, Adam Roach <[email-masked]> wrote:

> about the relative merits of H.264 and VP8 as MTI candidates again. Matthew
> Kaufman has argued that this conversation is doomed to failure because no
> major player has been willing to change their position. The players he
> cited were Cisco, Google, and Mozilla, who have represented the three main
> positions on this topic pretty effectively. Although we participate as
> individuals in the IETF, I think it's fair to say that the last time we had
> this conversation, the median positions of participants from those
> companies were "H.264 or die", "VP8 or die", and "either one as long as
> it's *only* one", respectively.
>
> have become quite important: we're all tired of this. Over two years ago,
> in March of 2012 -- before I even had an particular interest in WebRTC
> except as a user -- this had already become such a long-running acrimonious
> debate that I was brought in as a neutral third party to try to mediate.
> I'm weary of this argument; and, with the exception of a few aggressive
> voices who seem to enjoy the battle more than the outcome, I'm hearing a
> similar exhausted timbre in the messages of other participants (and the key
> stakeholders in particular).
>
> So, I want to float a proposal that represents a compromise, to see if we
> can finally close this issue. First, I want to start out by reiterating a
> well-worn observation that the hallmark of a good compromise is that nobody
> leaves happy, but everyone can force themselves to accept it. And I want to
> be crystal clear: the solution I'm about to float just barely clears the
> bar of what I think I can live with. This proposal is based on an
> observation that the dominating issues in this conversation remain those of
> licensing, not technology or even incumbency. I’ve discussed this
> extensively with representatives of all three of the players I mention
> above, and they are willing to sign on.
>
> This proposal is based on the definitions of "WebRTC User Agent", "WebRTC
> device", and "WebRTC-compatible endpoint" in section 2.2 of
>    royalty-free basis, such as all IPR declarations known for the codec being
>    of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative
>    statement to indicate that only that codec is required. For absolute,
>    crystal clarity, this provision is only applicable to WebRTC devices, and
>    not to WebRTC User Agents.
>
>    "WebRTC-compatible endpoint," and doesn't really need to be stated, but I
>    want this proposal to be as explicit as possible).
>
>
> work with all devices and user agents. This has the property of giving no
> one exactly what they want. And, unlike any other previous plans, this has
> the property of coming to a decision while maintaining pressure on the only
> parties who can make a change in the IPR landscape to do so.
>
> /a
>

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

---

From: Ron <[email-masked]>
Date: Mon, 10 Nov 2014 14:30:42 +1030

Hi Adam,

I do need to say that I really appreciate the effort you've put into
trying to help guide this discussion, both previously and now.  You
speak an uncommon amount of good common sense.

It's not clear to me exactly how you expect this part to work though:

>    applicable to WebRTC devices, and not to WebRTC User Agents.

What would constitute "compelling evidence" in this context?

Since the IETF doesn't take any position on the validity of IPR
declarations, I'm not seeing how the conditional clause here can
be anything but a no-op that would be essentially impossible to
trigger.

There are plenty of proposed standards which have IPR declarations
made against them, which pretty much everyone who has analysed them
in any detail agree are utterly bogus and inapplicable, but for
which the organisation which declared them refuses to withdraw.

What am I missing that would encourage different behaviour to that
in this case?

  Cheers,
  Ron

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 10 Nov 2014 07:34:36 +0000

First of all can I point out that the correct point of reference within the overview document is I believe section 2.4, not 2.2. Section 2.2 is merely the introduction saying these terms will be defined. 2.4 is the definitive material.

I think your proposal thinks this is all about IPR, and it is not.

The argument from the H.264 side is about interoperability, both in making use of existing embedded H.264 codecs in devices that will support webrtc, and in the ability to interwork through gateways with other devices where the inherent population is H.264.

So the parallel conditional on your item 2) which currently states

"If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents."

would be something like...

"If evidence arises that a significant population of webrtc devices and other video capable IP devices beyond gateways support (or are otherwise mandated to support, e.g. by a GSMA specification) a specific video codec (either one of these two or a third) the IETF will change this normative statement to indicate that only that codec is required."

And this condition would need to be ANDed with the first condition.

I can work with 1) 3) and otherwise the first half of 2)

regards

Keith

________________________________
From: rtcweb [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 10 November 2014 02:08
To: [email-masked]
Subject: [rtcweb] MTI Video Codec: a novel proposal

It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and "either one as long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, with the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbre in the messages of other participants (and the key stakeholders in particular).

So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I've discussed this extensively with representatives of all three of the players I mention above, and they are willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent", "WebRTC device", and "WebRTC-compatible endpoint" in section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:

  2.  WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents.

  3.  WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn't really need to be stated, but I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so.

/a

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Nov 2014 22:00:30 -1000

On Nov 9, 2014, at 6:00 PM, Ron <[email-masked]> wrote:
> 
> What am I missing that would encourage different behaviour to that in this case?

[BA] The IETF professes no expertise in assessing legal risk, nor does it make any warranties or provide indemnification. As a result implementers need to make their own risk assessments based on legal counsel, independent of any IETF recommendations. It is particularly telling that perhaps the most salient piece of new information is a draft summarizing legal proceedings.

Given that the key issue involves licensing fees and legal risk, the fullness of time is probably our best ally. Unfortunately time only provides legal clarity in spoonfuls, and a lengthy discussion between engineers about a legal matter probably would add a grain at best.

---

From: Ron <[email-masked]>
Date: Mon, 10 Nov 2014 19:31:14 +1030

On Sun, Nov 09, 2014 at 10:00:30PM -1000, Bernard Aboba wrote:
> [BA] The IETF professes no expertise in assessing legal risk, nor does
> it make any warranties or provide indemnification. As a result
> implementers need to make their own risk assessments based on legal
> counsel, independent of any IETF recommendations.

Yes, I believe that's more or less exactly what I said in the part of
my question that you snipped :)

If you agree with that part, then I assume you also don't see how the
"compelling evidence" clause could ever be triggered?

So maybe someone can explain what both you and I are missing here ...

> It is particularly telling that perhaps the most salient piece of
> new information is a draft summarizing legal proceedings.

I've heard it said that one of the most telling things about that
document is that some of the proceedings it mentions are *also*
being prosecuted against H.264, yet strangely it doesn't seem to
mention that at all ...

But I profess no expertise in assessing legal risk, so maybe the
experts who compiled that document can enlighten us on that too.
I assume it was not their intention to somehow mislead this group.

  Ron

---

From: tim panton <[email-masked]>
Date: Mon, 10 Nov 2014 10:29:14 +0000

Adam, thanks for sticking you head above the parapet ! 
I’m largely in favour of this solution, further, I think it represents the realities on the ground better
than any other proposal to date, as such it merits support.

On 10 Nov 2014, at 02:08, Adam Roach <[email-masked]> wrote:

> WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents. 

I do have a slight qualm about the " ‘both’ or perhaps only ‘one’ “ language above. I think irrespective of new data, there will 
always be devices who’s hardware or business model is best served by a specific codec, but that can meet every other requirement
of a webRTC device.

I feel the appropriate language here is ‘either’ , ensuring that every device can always interact with a user agent
but that devices can’t necessarily communicate video between each other without a transcoding middle man.

This leaves WebRTC-compatible endpoint as a category for things that implement neither video codec (e.g. audio only devices), or
don’t implement the data channel because it isn’t relevant to their application domain or only implement SDES (etc) - This gives a 
clearer separation.

This language choice matters most for developers who are selecting a native library to use when building a webRTC device. They need to
know what is supported -  'WebRTC-compatible’ means that they have to look very carefully at all the missing features, WebRTC-device
says that it will work with any user agent. 

With the current formulation there are no libraries that I know of suitable for building a webRTC device, making it an empty category.

Tim.

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Mon, 10 Nov 2014 17:51:10 +0100

On 10/11/14 11:29, tim panton wrote:
> I’m largely in favour of this solution, further, I think it represents the realities on the ground

It looks more like the reality on the ground of a few groups of
interests (e.g, GSMA, telco vendors) trying to protect themselves. But
again, in the web/internet world I don't see the same reality, they must
stay competitive with features, not with restrictions or barriers to
potential competitors.

If something costly or with other restrictions is technically better or
improving the user experience a lot in some medium of communication,
then the developer of some app can decide to use/implement it. There is
no reason of enforcing limits and financial constraints to everyone in
open web via specs supposed to become standard.

Rather than forcing now something inconvenient to be re-evaluated later
for removal, better don't force anything now and re-evaluate later for
inclusion. It will allow the market (besides the big players) to decide
freely where it wants to move. The current proposal looks like: let's
close the group now and later decide if we allow others in. Why not the
other way around, keep the market fully open for new comers now and see
what is going to be out there in few years, whether it makes sense to
start building the walls at that moment.

Daniel

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

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

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 10 Nov 2014 09:08:35 -0800

> on the only parties who can make a change in the IPR landscape to do so.

I think this is a good proposal, and I can support it. It's obviously 
not my preferred outcome, but it's better than a lot of other places we 
could have wound up. Of course, with Daala/VP10/etc. I'll still be 
working to get us to that better place, but for now I want to thank the 
fine folks at Cisco and Google for being willing to discuss this in a 
productive manner and help WebRTC move forward.

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Mon, 10 Nov 2014 17:21:00 +0000

+1

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Timothy B. Terriberry
Sent: Monday, November 10, 2014 9:09 AM
To: [email-masked]
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal

Adam Roach wrote:
> this has the property of coming to a decision while maintaining 
> pressure on the only parties who can make a change in the IPR landscape to do so.

I think this is a good proposal, and I can support it. It's obviously not my preferred outcome, but it's better than a lot of other places we could have wound up. Of course, with Daala/VP10/etc. I'll still be working to get us to that better place, but for now I want to thank the fine folks at Cisco and Google for being willing to discuss this in a productive manner and help WebRTC move forward.

---

From: Tim Panton <[email-masked]>
Date: Mon, 10 Nov 2014 17:40:27 +0000

> On 10 Nov 2014, at 16:51, Daniel-Constantin Mierla <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 

On the subject of codecs, I discount the opinion of the GSMA utterly,
they have had 10 years  to make video calling (and wideband audio)
a desirable user proposition and have failed completely. 

The realities I’m thinking of are the ones facing someone building a
video enabled pet phone (for example). I can get H264 hardware very
cheaply (eg a raspberry Pi) and have it communicate with an ios App
or firefox on a laptop without any license (as far as I can tell).
Getting the same setup to work with VP8 will consume significantly 
more battery power at both ends.

I wish this were not the case, but that’s the reality I see.

> open web via specs supposed to become standard.

If we mandate both codecs for devices, I agree, we are imposing an unacceptable
burden on everyone.
However I’m doubtful that any entity who can afford to build a new
w3c standards compatible browser will be unable to afford the (capped) h264 fee,
that’s simply a measure of how much work I think it is to do a new user agent now.
So the penalty in terms of restricting new browser innovation is small  (IMHO)
I’m much more worried about innovative devices.

> start building the walls at that moment.

That’s where we disagree. I really do not want to have to have a complex
matrix of versions of my parrot phone that correctly interop with other devices and
other pairings that don’t.

(E.G. buy a new android tablet and our android app if you use chrome, but if you reuse
an old ipad, you’ll have to use firefox).

We need an MTI statement. If we don’t get one we will be stuck with little
facetime-like islands again.

>> On 10 Nov 2014, at 02:08, Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>
> http://twitter.com/#!/miconda <http://twitter.com/#!/miconda> - http://www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> 
> [email-masked] <mailto:[email-masked]>

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk <http://www.westhawk.co.uk/>

---

From: cowwoc <[email-masked]>
Date: Mon, 10 Nov 2014 13:27:21 -0500

> I wish this were not the case, but that’s the reality I see.

I was/am under the impression that this reality will change over the 
coming year as devices roll out with hardware VP8 support.

According to http://wiki.webmproject.org/hardware/devices Raspberry Pi 
already supports hardware decoding. The assumption is that they are 
working on hardware encoding in a future release.

Gili

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Mon, 10 Nov 2014 19:27:55 +0100

> I wish this were not the case, but that’s the reality I see.

Very cheaply for one user, but can be very costly for a service or an
app distributed to the masses. Then it was not clear (unless I missed
some resolution on the topic during the summer) if you can rely on the
license given to the hardware.

Why not standardize the h264 and vp8 hardware control API, the
manufactures of hardware devices have to implement it and the app
developers have to use them?!? Then practically, the apps devs don't
need to mess with ipr of h264 or vp8 -- if there is hardware support
with appropriate API, then will be enabled.

> w3c standards compatible browser will be unable to afford the (capped)

You can have one in minutes by making own built of firefox or chromium,
discarding the non-source-code licensed/copyrighted items such as logos,
icons, etc ... then tailor it for your specific needs (e.g., more
privacy, no automatic reports, etc.) The problem is that the new built
app doesn't have the financial power as the original one, but still
distributed to the masses in an uncontrollable way (e.g., linux distros,
with mirrors, etc.).

I already pointed that such cases exists already (e.g., debian). Also,
repeating, some those big browsers started as forks from rather small
and non-financial-powerful projects.

I see I missed to follow up on a previous discussion thread -- KHTML is
on more or less the same level with WebKit (which started as a fork of
the former, getting on board some extra libs), the browsers relies on
them as html/js engines. Now opera is using chorme html engine and
benefits of all webrtc features chrome has -- in reality they are still
different browsers with the specific features mainly related to
interaction to the users rather than the protocol or other specific
technical aspects (html/http).

> facetime-like islands again.

Otherwise we get stuck to some browsers that can vanish your
expectations on security.

And if there is a different set of requirements for a WebRTC device and
a WebRT UA, you still have to keep a matrix: it is working with Chrome,
but not working with X-Lite Communicator. I don't see an easy way to
explain to an end user that webrtc endpoints don't have same
capabilities on media.

There are benefits on having a MTI for video codec, but one that doesn't
impose any kind of restrictions, otherwise it brings more disadvantages
now and in long term.

Daniel

>>>> WebRTC devices MUST implement both VP8 and H.264. If compelling
>>> I do have a slight qualm about the " ‘both’ or perhaps only ‘one’ “
>>> language above. I think irrespective of new data, there will
>>> always be devices who’s hardware or business model is best served by
>>> a specific codec, but that can meet every other requirement
>>> of a webRTC device.
>>>
>>> I feel the appropriate language here is ‘either’ , ensuring that
>>> every device can always interact with a user agent
>>> This leaves WebRTC-compatible endpoint as a category for things that
>>> implement neither video codec (e.g. audio only devices), or
>>> don’t implement the data channel because it isn’t relevant to their
>>> application domain or only implement SDES (etc) - This gives a
>>> clearer separation.
>>>
>>> This language choice matters most for developers who are selecting a
>>> native library to use when building a webRTC device. They need to
>>> know what is supported -  'WebRTC-compatible’ means that they have
>>> to look very carefully at all the missing features, WebRTC-device
>>> With the current formulation there are no libraries that I know of
>>> suitable for building a webRTC device, making it an empty category.
>>>
>>> Tim.
>>>
>> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
>> http://www.linkedin.com/in/miconda
>>
> www.westhawk.co.uk <http://www.westhawk.co.uk>
>
>
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 10 Nov 2014 08:50:49 -1000

On Nov 10, 2014, at 7:08 AM, Timothy B. Terriberry <[email-masked]> wrote:

> I think this is a good proposal, and I can support it. It's obviously not my preferred outcome, but it's better than a lot of other places we could have wound up. Of course, with Daala/VP10/etc. I'll still be working to get us to that better place, 

+1 - Tim text above pretty much gets my feeling on this.

Cullen (in my individual contributor role)

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Mon, 10 Nov 2014 18:56:15 +0000

As a preview of future devices, see this page: http://wiki.webmproject.org/hardware/socs showing several chips (SoCs) supporting full HD VP8 (and H.264) encode AND decode hardware acceleration.
Intel launched phone/tablet platforms at MWC in February that demonstrated hardware WebRTC.  Thus our codec neutrality in this debate.
-chris

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of cowwoc
Sent: Monday, November 10, 2014 10:27 AM
To: [email-masked]
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal

On 10/11/2014 12:40 PM, Tim Panton wrote:
> The realities I'm thinking of are the ones facing someone building a 
> cheaply (eg a raspberry Pi) and have it communicate with an ios App or 
> firefox on a laptop without any license (as far as I can tell).
> I wish this were not the case, but that's the reality I see.

I was/am under the impression that this reality will change over the coming year as devices roll out with hardware VP8 support.

According to http://wiki.webmproject.org/hardware/devices Raspberry Pi already supports hardware decoding. The assumption is that they are working on hardware encoding in a future release.

Gili

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 10 Nov 2014 19:14:37 +0000

Hi,
I like and support the spirit of this proposal, but have one issue with the formulation below, and would like to see it clarified.
Stephan

From: Adam Roach <[email-masked]<mailto:[email-masked]>>
Date: Sunday, November 9, 2014 at 18:08
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [rtcweb] MTI Video Codec: a novel proposal

[...]
If compelling evidence arises that one of the codecs is
available for use on a royalty-free basis, such as all IPR
declarations known for the codec being of (IETF) Royalty-Free
or (ISO) type 1, the IETF will change this normative statement
to indicate that only that codec is required.
[...]

First: "the IETF WILL CHANGE": I don't think that such forward looking, absolute statements are appropriate.  And probably also not correct.  Some of the objections here are not over royalties, but over ecosystem dominance; never mind the money.  Whether or not the IETF changes its opinion will at least partly be based based on the power distribution of players subscribing to ecosystem agendas at the time the situation changes.

Second, "all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1" is IMO not compelling evidence for a royalty free codec; for many reasons that have been spelled out before.  Similarly, type 2 RAND statements are not evidence that royalties are necessarily being paid.
To me, evidence for a (practically) RF H.264 codec would be an MPEG-LA pool rightholder decision not to require the payment of royalties.  For VP[8,9], the licensing arrangement google has made got a long way to convince me, but what would be needed in addition is to overcome known objections by players, however expressed.  (Note that legal departments will typically be very reluctant to submit type 1 statements, whereas the business groups may be more easily able to communicate a company decision for zero royalty.)  For newer codecs, what would be needed is both very wide participation (including all the key players in both IETF and VCEG/MPEG) and RF declarations in whatever organization doing the work.  Clearly, at this point, none of H.265, VP10, or Daala fulfill those conditions.

Thanks,
Stephan

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Nov 2014 09:42:33 -1000

Ron:

You are correct in that the IETF doesn't take a position on the validity 
of IPR declarations, and I'd like to thank you for bringing the topic up 
so that I could clarify the proposal. Rather than evaluating the 
*validity* of declarations, we would be evaluating the licensing 
statements associated with those declarations (where applicable).

In terms of what would constitute "compelling evidence", that's going to 
have to be something that the working group (or some successor group, 
depending on timing) comes to consensus around. I believe that examples 
of such situations would include things like "MPEG-LA announces 
non-discriminatory, royalty-free H.264 licensing for WebRTC" or "ISO 
publishes VP8 specification with only Type-1 IPR declarations".

With regards to bad actors' impact on the process, I fear this is an 
unfortunate consequence of international IPR law as it is currently 
defined that we are not in a position to fix. The best we can hope for 
is that the associated parties recognize the goodwill implications of 
standing in the way of progress, and the potential implications of 
developing bad blood between their company and the rest of the standards 
community.

It's not awesome, but it's better than anything else that I've seen 
proposed so far.

/a

---

From: Justin Uberti <[email-masked]>
Date: Mon, 10 Nov 2014 11:54:55 -0800

Adam, thanks for your work on this.

I think this plan represents a legitimate compromise in what had previously
seemed like a stalemate. While not our (Google's) ideal outcome, we think
this is good for the WebRTC ecosystem - it ensures interoperability, and
provides a reasonably clear path for reaching a completely RF solution.

In the meantime, WebRTC devices can use APIs such as Android's MediaCodec
or iOS' VideoToolkit to provide H.264 support without having to distribute
it themselves. (MediaCodec, of course, can also be used for VP8, and soon,
VP9).

Lastly, on the point of whether any codec can meet the bar of being
considered RF, note that the text provides some discretion:

*If compelling evidence arises that one of the codecs is available for use
on a royalty-free basis, *such as* all IPR declarations known for the codec
being of (IETF) Royalty-Free or (ISO) type 1, ...*

This allows the IETF to make a decision based on the preponderance of the
evidence.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 10 Nov 2014 12:06:25 -0800

FWIW, I'm firmly with Tim on the proposal: I don't like to declare that
a royalty-bearing technology is mandatory to implement in an IETF
standard, but given the realities of the situation, I think it is better
to adopt this proposal than continuing to leave the MTI decision in flux.

About the language on "reconsideration": Given all the legal issues
involved, it would in my opinion be foolhardy to adopt a prescriptive,
mechanical trigger for a reclassification - but I would be unhappy about
abandoning all hope that the situation could improve - if we are in a
situation (years from now?) where it's obvious that we have a royalty
free, safely deployable codec available, it would be a strange thing not
to say "the way is clear, let's pick the freely available alternative!"

I do expect that, if the proposal is adopted, browsers will support both
codecs for the foreseeable future (and probably longer than that - "the
foreseeable future" tends to be short these days). Adam's
"reconsideration" proposal applies only to the class of non-browser
things that implement RTCWEB (aka "devices").

Harald

On 11/10/2014 11:14 AM, Stephan Wenger wrote:
> Hi,
> I like and support the spirit of this proposal, but have one issue
> with the formulation below, and would like to see it clarified.
> Stephan
>
>
> From: Adam Roach <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> […]
> […]
> First: “the IETF WILL CHANGE”: I don’t think that such forward
> looking, absolute statements are appropriate.  And probably also not
> correct.  Some of the objections here are not over royalties, but over
> ecosystem dominance; never mind the money.  Whether or not the IETF
> changes its opinion will at least partly be based based on the power
> distribution of players subscribing to ecosystem agendas at the time
> the situation changes.
>
> Second, “all IPR declarations known for the codec being of (IETF)
> Royalty-Free or (ISO) type 1” is IMO not compelling evidence for a
> royalty free codec; for many reasons that have been spelled out
> before.  Similarly, type 2 RAND statements are not evidence that
> royalties are necessarily being paid.  
> To me, evidence for a (practically) RF H.264 codec would be an MPEG-LA
> pool rightholder decision not to require the payment of royalties.
>  For VP[8,9], the licensing arrangement google has made got a long way
> to convince me, but what would be needed in addition is to overcome
> known objections by players, however expressed.  (Note that legal
> departments will typically be very reluctant to submit type 1
> statements, whereas the business groups may be more easily able to
> communicate a company decision for zero royalty.)  For newer codecs,
> what would be needed is both very wide participation (including all
> the key players in both IETF and VCEG/MPEG) and RF declarations in
> whatever organization doing the work.  Clearly, at this point, none of
> H.265, VP10, or Daala fulfill those conditions.
>
> Thanks,
> Stephan
>
>

-- 
Surveillance is pervasive. Go Dark.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Nov 2014 10:13:08 -1000

+1

As should be obvious from Mozilla's decision to implement both VP8
and H.264 in Firefox, we believe that supporting both codecs is the
best path forward for now.

In the future, hopefully we can have one MTI best-in-class codec that
is also RF -- as Opus is for audio -- but in the meantime this
seems like the solution that is best for helping the ecosystem
move forward.

-Ekr

On Mon, Nov 10, 2014 at 9:54 AM, Justin Uberti <[email-masked]> wrote:

> I think this plan represents a legitimate compromise in what had
> previously seemed like a stalemate. While not our (Google's) ideal outcome,
> we think this is good for the WebRTC ecosystem - it ensures
> interoperability, and provides a reasonably clear path for reaching a
> completely RF solution.
>
>>     3. WebRTC-compatible endpoints are free to implement any video
>>    codecs they see fit, if any (this follows logically from the definition of

---

From: Mary Barnes <[email-masked]>
Date: Mon, 10 Nov 2014 14:57:29 -0600

I agree with the proposal - I think this is as close as we will ever get on
an agreed way forward.

Regards,
Mary.

---

From: Emil Ivov <[email-masked]>
Date: Mon, 10 Nov 2014 21:57:11 +0100

Thanks for coming up with that Adam!

It does look like a reasonable compromise! In our project's community
we are happy that it would provide a means for people with different
browsers to participate in conferences based on video
routing/selective forwarding (as opposed to mixing), which we consider
to be a big win for WebRTC!

So, +1 to that!

Emil

On Mon, Nov 10, 2014 at 3:08 AM, Adam Roach <[email-masked]> wrote:
> major player has been willing to change their position. The players he cited
> were Cisco, Google, and Mozilla, who have represented the three main
> this conversation, the median positions of participants from those companies
> were "H.264 or die", "VP8 or die", and "either one as long as it's *only*
> one", respectively.
>
> have become quite important: we're all tired of this. Over two years ago, in
> March of 2012 -- before I even had an particular interest in WebRTC except
> as a user -- this had already become such a long-running acrimonious debate
> that I was brought in as a neutral third party to try to mediate. I'm weary
> of this argument; and, with the exception of a few aggressive voices who
> seem to enjoy the battle more than the outcome, I'm hearing a similar
> exhausted timbre in the messages of other participants (and the key
> be crystal clear: the solution I'm about to float just barely clears the bar
> of what I think I can live with. This proposal is based on an observation
> that the dominating issues in this conversation remain those of licensing,
> not technology or even incumbency. I’ve discussed this extensively with
> representatives of all three of the players I mention above, and they are
> willing to sign on.
>
> WebRTC User Agents MUST implement both VP8 and H.264.
>
> WebRTC devices MUST implement both VP8 and H.264. If compelling evidence
> arises that one of the codecs is available for use on a royalty-free basis,
> such as all IPR declarations known for the codec being of (IETF)
> Royalty-Free or (ISO) type 1, the IETF will change this normative statement
> to indicate that only that codec is required. For absolute, crystal clarity,
> this provision is only applicable to WebRTC devices, and not to WebRTC User
> Agents.
>
> WebRTC-compatible endpoints are free to implement any video codecs they see
> fit, if any (this follows logically from the definition of
> This has the property of ensuring that all devices and user agents can work
> with all devices and user agents. This has the property of giving no one
> exactly what they want. And, unlike any other previous plans, this has the
> property of coming to a decision while maintaining pressure on the only

-- 
https://jitsi.org

---

From: Roman Shpount <[email-masked]>
Date: Mon, 10 Nov 2014 16:14:47 -0500

Even though I am not 100% happy with this proposal and that it probably
needs a bit of language clean up, I do support this proposal.

_____________
Roman Shpount

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 10 Nov 2014 13:55:13 -0800

I cited those three players just as examples of known positions. There are several others, of course.

This proposal puts the large initial burden of IPR risk and/or cost on the browser vendors... 

I think we would need to know how happy Apple, Google, Microsoft, and Mozilla (plus the other major browser vendors ) are with a requirement that both H.264 and VP8 be included with their browser and/or operating system.

We may be tired of this, but it isn't like we have a royalty-free option for H.264 MPEG-LA or IP risk indemnification from Google.. So what's changed for the browser makers?

Matthew Kaufman

(Sent from my iPhone)

> On Nov 9, 2014, at 6:08 PM, Adam Roach <[email-masked]> wrote:
> 
> So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I’ve discussed this extensively with representatives of all three of the players I mention above, and they are willing to sign on.
> 
> WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn't really need to be stated, but I want this proposal to be as explicit as possible).
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 10 Nov 2014 23:20:59 +0100

> 1. WebRTC User Agents MUST implement both VP8 and H.264.

If "WebRTC User Agent" means web browser (and I think so), I am in
favour of non mandating web browsers to implement non-free&open
codecs.

This is, a MTI codec must be open, free, and free of royalty/licensing stuff.

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

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 10 Nov 2014 14:41:06 -0800

Do you believe that making a codec mandatory in an IETF spec will force the corporate lawyers at the browser vendors to drop their objections to that codec?

Matthew Kaufman

(Sent from my iPhone)

> On Nov 10, 2014, at 2:20 PM, Iñaki Baz Castillo <[email-masked]> wrote:
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 10 Nov 2014 23:53:52 +0100

> Do you believe that making a codec mandatory in an IETF spec will force the corporate lawyers at the browser vendors to drop their objections to that codec?

And do you believe that avoiding MTI privative codecs an IETF spec
will force the corporate lawyers at browser vendors to drop their
interest in using privative codecs?

I'm not proposing that browsers MUST NOT implement non-open-and-free
codecs, but just that those codecs MUST NOT be MTI given their nature.

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Nov 2014 12:58:12 -1000

On Mon, Nov 10, 2014 at 11:55 AM, Matthew Kaufman <[email-masked]>
wrote:

> I think we would need to know how happy Apple, Google, Microsoft, and
> Mozilla (plus the other major browser vendors ) are with a requirement that
> both H.264 and VP8 be included with their browser and/or operating system.
>

As I said previously, we're fine with this requirement.

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 10 Nov 2014 15:03:52 -0800

On 11/10/2014 02:58 PM, Eric Rescorla wrote:
>
>
> On Mon, Nov 10, 2014 at 11:55 AM, Matthew Kaufman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I think we would need to know how happy Apple, Google, Microsoft,
>     and Mozilla (plus the other major browser vendors ) are with a
>     requirement that both H.264 and VP8 be included with their browser
>     and/or operating system.
>
>

Google is also fine with this requirement.

---

From: David Singer <[email-masked]>
Date: Mon, 10 Nov 2014 15:04:04 -0800

> We may be tired of this, but it isn't like we have a royalty-free option for H.264 MPEG-LA or IP risk indemnification from Google.. So what's changed for the browser makers?

That is my question too;  what has changed since this was (effectively) one of the options in the notorious long-ago poll?

On the face of it, this requires proponents of ‘must be free’ to take on a non-free license (in principle, though rarely in practice), which is unacceptable to them, and for the ‘must be reasonably clear of IPR risk and independently implementable’ people to have to take on IPR risk and try (?) to implement from the specs, which seems unacceptable to them.

So, am puzzled. Yes, this proposal would make everyone unhappy (if they actually do it), or non-compliant (if, as I suspect, people implement only what they were going to implement anyway, no matter what the spec. says).  (A mandate is only effective if followed.)

Can anyone explain what’s changed, or what I am missing?

>> 	• WebRTC User Agents MUST implement both VP8 and H.264.
>> 
>> 	• WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents. 
>> 
>> 	• WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn't really need to be stated, but I want this proposal to be as explicit as possible).
>> 

David Singer
Manager, Software Standards, Apple Inc.

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 10 Nov 2014 13:06:31 -1000

+1 on this proposal . Hope IETF91  would be a decision making for this
pending item

Cheers
Suhas

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Nov 2014 13:10:40 -1000

Are there any browser vendors beyond Mozilla indicating they would ship both codecs simply as a result of the proposal being adopted (no other conditions)?  

> On Nov 10, 2014, at 12:41 PM, Matthew Kaufman <[email-masked]> wrote:
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Nov 2014 13:41:48 -1000

On 11/10/14 12:30, Tim Lindsey wrote:
> Last I read Apple did not support and had no definitive plan to begin 
> support for VP8/9.

I'm curious about what you read and where: Apple is quite famous for not 
publishing its plans, definitive or otherwise.

/a

---

From: Tim Lindsey <[email-masked]>
Date: Mon, 10 Nov 2014 16:30:22 -0600

Agreed. Last I read Apple did not support and had no definitive plan to
begin support for VP8/9. If this stance hasn't wavered I think it presents
an immediate and significant road block to ever making this proposal a
reality, however reasonable it may seem.

On Mon, Nov 10, 2014 at 3:55 PM, Matthew Kaufman <[email-masked]> wrote:

> We may be tired of this, but it isn't like we have a royalty-free option
> for H.264 MPEG-LA or IP risk indemnification from Google.. So what's
> changed for the browser makers?
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 10 Nov 2014 19:25:36 -0500

> changed for the browser makers?
May be I am missing something, but MPEG-LA does not provide IP risk
indemnification for H.264. All they sell is a very limited license to the
patent pool from the group members.

---

From: Ron <[email-masked]>
Date: Tue, 11 Nov 2014 11:40:55 +1030

On Mon, Nov 10, 2014 at 03:04:04PM -0800, David Singer wrote:
> That is my question too;  what has changed since this was
> (effectively) one of the options in the notorious long-ago poll?

I think Adam explained this in his original rationale.

There appears to be a growing consensus that, "The only thing worse
than this current stalemate is people wanting us to remain stalled
indefinitely in a state of stalemate over this decision".

His option guarantees that anyone implementing only their preferred
codec will be able to interop with any compliant implementation,
though it may not be able to do so with another non-compliant
implementation that similarly opted out of supporting that codec.

It also gives the people who are ultimately in the position of
prolonging this stalemate indefinitely a mechanism whereby they
could, at their option, end it in favour of their preferred codec
becoming the sole MTI.

Whatever the odds of that actually happening may be, we'll all know
exactly who to blame if this compromise ends in its worst case outcome
for everyone rather than its best one.

> On the face of it, this requires proponents of ‘must be free’ to take
> on a non-free license (in principle, though rarely in practice), which
> is unacceptable to them, and for the ‘must be reasonably clear of IPR
> risk and independently implementable’ people to have to take on IPR
> risk and try (?) to implement from the specs, which seems unacceptable
> to them.

It doesn't "require" any such thing.  It requires a compliant
implementation to be fully compatible with any non-compliant
implementation that for one reason or another finds it impossible
to achieve full compliance with the MTI video codec(s).

If the escape clause is exercised, we all win and everyone can
interop.  If it isn't there may be some implementations which
give a poorer experience to their users than others do.

That's still better than the state of total chaos which would exist
if no MTI at all was specified.

> So, am puzzled. Yes, this proposal would make everyone unhappy (if
> they actually do it), or non-compliant (if, as I suspect, people
> implement only what they were going to implement anyway, no matter
> what the spec. says).  (A mandate is only effective if followed.)
> 

All of the major players in the browser market have said they are
on board and will follow this mandate.

If some of the remainder don't, or won't, or can't, they get to weigh
up their reasons for that against the possibility of having their
users simply switch to a browser that does.

If some of those players are in a position to be able to exert the
pressure they feel upon the other people who are blocking us from
being able to exercise the tie-breaker clause, then maybe our odds
of triggering it are slightly improved too.

Nobody can be forced into providing a fully compliant implementation,
but even in the worst case under this, given the assurances we already
have, the people who have protested that they absolutely can't ship
one of these codecs will still be able to interop with all the major
players if they can find no other way around that problem.

It's certainly not my preferred solution, but it's definitely not
the worst one I can imagine, and is both measurably better than the
status quo, and seems to provide reasonable incentives for the people
who turn the screws to still try to improve the situation further in
their favour, should they actually choose to do so.

I eagerly await the next surprising announcement of something we all
thought was simply unimaginable a year or two ago!

  Ron

---

From: David Singer <[email-masked]>
Date: Mon, 10 Nov 2014 17:20:28 -0800

> implementation that similarly opted out of supporting that codec.

I am sorry, I don’t get it.  The spec. defines “WebRTC-compatible endpoint”

A WebRTC-compatible endpoint is an endpoint that is capable of
      successfully communicating with a WebRTC endpoint, but may fail to
      meet some requirements of a WebRTC endpoint.  This may limit where
      in the network such an endpoint can be attached, or may limit the
      security guarantees that it offers to others.

but says nothing about it being ‘non-compliant’.  So anyone can say “I claim that this is compliant to the spec.” (as a webrtc-compatible endpoint) — and it might not interoperate. Basically, this proposal assigns different names to the devices that implement both, and those that implement only one or none, but does that really further the cause of interoperability?

David Singer

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 10 Nov 2014 17:45:31 -0800

> but says nothing about it being ‘non-compliant’.  So anyone can say “I claim that this is compliant to the spec.” (as a webrtc-compatible endpoint) — and it might not interoperate. Basically, this…
Video codecs weren't part of the discussion when we introduced those terms.

The obvious examples were ICE-Lite for gateways that reside at public IP
addresses, and datachannel and video for POTS telephone gateways - and
yes, also OPUS codecs for POTS gateways. (those that have *only* g.711
on the other side - there are better codecs in that environment too,
where bridging to OPUS may make sense.)

The theory is that those devices will exist and do what they will do no
matter what we specify here, so we might as well

We'll go through terminology in an hour or so in the meeting.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 10 Nov 2014 18:41:01 -0800

On Mon, Nov 10, 2014 at 3:04 PM, David Singer <[email-masked]> wrote:

> That is my question too;  what has changed since this was (effectively)
> one of the options in the notorious long-ago poll?
>
> On the face of it, this requires proponents of ‘must be free’ to take on a
> non-free license (in principle, though rarely in practice), which is
> unacceptable to them, and for the ‘must be reasonably clear of IPR risk and
> independently implementable’ people to have to take on IPR risk and try (?)
> to implement from the specs, which seems unacceptable to them.
>
>
I'm not sure what you are implying with your comment of "independently
implementable" and parenthetical question mark, but there are multiple
independent implementations of VP8 at this time.

Besides the software implementations in libvpx and ffvp8, there are also
many independent implementations in SoCs from Qualcomm, Nvidia, and
Samsung, amongst others.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Nov 2014 17:19:08 -1000

I do not get it either. It seems like mobile apps (which count as devices) using a WEBRTC stack now have to include both codecs regardless of whether they need them. Do we really think app developers will pay attention? Why should they?

> On Nov 10, 2014, at 3:20 PM, David Singer <[email-masked]> wrote:
> 
>

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Tue, 11 Nov 2014 13:23:16 +0800

+1 for this proposal.

Thanks adam for doing the background work to bring some parties closer to a
consensus.

On Tue, Nov 11, 2014 at 11:19 AM, Bernard Aboba <[email-masked]>
wrote:

> I do not get it either. It seems like mobile apps (which count as devices)
> using a WEBRTC stack now have to include both codecs regardless of whether
> they need them. Do we really think app developers will pay attention? Why
> should they?
>
>
>
> > but says nothing about it being ‘non-compliant’.  So anyone can say “I
> claim that this is compliant to the spec.” (as a webrtc-compatible
> endpoint) — and it might not interoperate. Basically, this proposal assigns
> different names to the devices that implement both, and those that
> implement only one or none, but does that really further the cause of
> interoperability?
> >
> > David Singer

-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 10 Nov 2014 21:29:40 -0800

On 11/10/2014 4:25 PM, Roman Shpount wrote:
> On Mon, Nov 10, 2014 at 4:55 PM, Matthew Kaufman <[email-masked] 
>     We may be tired of this, but it isn't like we have a royalty-free
>     option for H.264 MPEG-LA or IP risk indemnification from Google..
>     So what's changed for the browser makers?
>
>
> indemnification for H.264. All they sell is a very limited license to 
> the patent pool from the group members.

I am not my employer's lawyers, nor am I the lawyers for any of the 
other folks who've spoken up about the IPR issues over the years. But 
these folks apparently feel that there's something different between 
"specification developed in an open standards process" + "licenses to 
listed IPR available from patent pool" and "some code Google says is 
free" for whatever reasons they have.

You'd have to ask them to see why that's different.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 10 Nov 2014 21:32:30 -0800

On 11/10/2014 3:03 PM, Harald Alvestrand wrote:
>>     requirement that both H.264 and VP8 be included with their
>>     browser and/or operating system.
>>
>>

So that's two browser vendors who are fine with that requirement.

I can't speak for my employer, but I hear that we are a well-known 
browser vendor as well.

Nor can I speak for Apple,  but I know they're a browser vendor as I use 
their browser on some of my personal devices.

Would sure be nice to get closer to 100% agreement from the people who 
actually ship the code in question.

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 10 Nov 2014 21:35:21 -0800

> I do not get it either. It seems like mobile apps (which count as devices) using a WEBRTC stack now have to include both codecs regardless of whether they need them. Do we really think app develope…

Because they can then depend on interoperability with other non-browsers?

---

From: Roman Shpount <[email-masked]>
Date: Tue, 11 Nov 2014 00:47:04 -0500

On Tue, Nov 11, 2014 at 12:29 AM, Matthew Kaufman <[email-masked]>
wrote:

>> option for H.264 MPEG-LA or IP risk indemnification from Google.. So what's
> I am not my employer's lawyers, nor am I the lawyers for any of the other
> folks who've spoken up about the IPR issues over the years. But these folks
> apparently feel that there's something different between "specification
> developed in an open standards process" + "licenses to listed IPR available
> from patent pool" and "some code Google says is free" for whatever reasons
> they have.
>
I am not the lawyer either, but there is a difference
between "specification developed in an open standards process" + "licenses
to listed IPR available from patent pool" vs Google offering indemnity
against third party IPR claims. I believe everyone can agree that "open
standards process"  is a requirement for an MTI video codec. Royalty free
RAND terms are highly desired. The indemnity is just wishful thinking. I
cannot think of a single codec patent pool that offer indemnity. I also do
not see much difference between  "licenses to listed IPR available from
patent pool" and "licenses to listed IPR are available from Google" as long
as they are available under royalty free RAND terms. I doubt anybody will
form the patent pool to collect no money.
_____________
Roman Shpount

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 10 Nov 2014 21:51:26 -0800

On 11/10/2014 9:47 PM, Roman Shpount wrote:
>
> On Tue, Nov 11, 2014 at 12:29 AM, Matthew Kaufman <[email-masked] 
>>     On Mon, Nov 10, 2014 at 4:55 PM, Matthew Kaufman
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         We may be tired of this, but it isn't like we have a
>>         royalty-free option for H.264 MPEG-LA or IP risk
>>         indemnification from Google.. So what's changed for the
>>         browser makers?
>>
>>
>>     May be I am missing something, but MPEG-LA does not provide IP
>>     risk indemnification for H.264. All they sell is a very limited
>>     license to the patent pool from the group members.
>
>     I am not my employer's lawyers, nor am I the lawyers for any of
>     the other folks who've spoken up about the IPR issues over the
>     years. But these folks apparently feel that there's something
>     different between "specification developed in an open standards
>     process" + "licenses to listed IPR available from patent pool" and
>     "some code Google says is free" for whatever reasons they have.
>
> between "specification developed in an open standards process" + 
> "licenses to listed IPR available from patent pool" vs Google offering 
> indemnity against third party IPR claims. I believe everyone can agree 
> that "open standards process"  is a requirement for an MTI video 
> codec. Royalty free RAND terms are highly desired. The indemnity is 
> just wishful thinking. I cannot think of a single codec patent pool 
> that offer indemnity. I also do not see much difference between 
>  "licenses to listed IPR available from patent pool" and "licenses to 
> listed IPR are available from Google" as long as they are available 
> under royalty free RAND terms. I doubt anybody will form the patent 
> pool to collect no money.
> _____________
> Roman Shpount
>

I was giving examples like "royalty-free option for H.264 MPEG-LA" or 
"IP risk indemnification from Google" as things that would indicate real 
change in the IPR landscape, which is one of the major things driving 
the positions of the browser makers. Neither has happened. They're both 
equivalently "wishful thinking" at this point. If and when something 
changes, we should discuss what that means. Until then, I ask again: 
what's changed?

Matthew Kaufman

---

From: Ron <[email-masked]>
Date: Tue, 11 Nov 2014 16:32:07 +1030

> from patent pool" and "some code Google says is free" for whatever reasons

Something other than "we invested a lot in being a member of that pool, and
a whole bunch more in buying a company with lots of H.264 patents which
remain outside of it"?

> You'd have to ask them to see why that's different.

If you do that, ask them what's different about bottled water too.
I've always been curious about that.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Nov 2014 20:48:23 -1000

> On Nov 10, 2014, at 7:35 PM, Harald Alvestrand <[email-masked]> wrote:
> 

[BA] Isn't the non-browser in question the mobile app the developer wrote? Most of these apps only need to interop with the app on another platform, a browser app and/or their own service. So they typically only need one codec or the other not both.

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 11 Nov 2014 09:54:59 +0100

+1

On Mon, Nov 10, 2014 at 9:57 PM, Mary Barnes <[email-masked]> wrote:
>> WebRTC-compatible endpoints are free to implement any video codecs they
>> see fit, if any (this follows logically from the definition of

-- 
Victor Pascual Ávila

---

From: Andrew Allen <[email-masked]>
Date: Tue, 11 Nov 2014 14:16:17 +0000

Adam

"In terms of what would constitute "compelling evidence", that's going to 
have to be something that the working group (or some successor group, 
depending on timing) comes to consensus around"

If this compromise was to move forward I think any "compelling evidence", is likely to be many years down the road (things will likely need to play out in the courts first etc) which means that the RTCweb group likely doesn't exist anymore or is by then a rump group that doesn't have the broad industry participation that we have now.

Would we really go through the process to constitute a new WG just in order to debate whether there is "compelling evidence"?

I certainly would have a big concern if a much smaller group like IESG or a rump remnants of RTCweb were in the end to make such a determination without a full long (months) high profiled public discussion. Also a BoF would not in my view be appropriate to make this determination either.

So if we go this approach aren't we effectively mandating both codecs for RTCweb 1.0 with the possibility that in any future RTCweb 2.0 we might revisit that decision?

We need to be cast iron now about the process for revisiting this if this goes forward and also with some guidance as to what developments are appropriate to trigger revisiting it, as we can't have someone just propose at every IETF to reopen this discussion until they get the decision they want.

Andrew

----- Original Message -----
From: Adam Roach [mailto:[email-masked]]
Sent: Monday, November 10, 2014 02:42 PM Eastern Standard Time
To: Ron <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal

Ron:

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 11 Nov 2014 11:39:15 -0800

> [BA] Isn't the non-browser in question the mobile app the developer wrote? Most of these apps only need to interop with the app on another platform, a browser app and/or their own service. So they…
I'm pretty certain that will be the most common scenario.

I'm also pretty certain this will not be the only scenario; there will
be services that are usable from multiple applications.

I don't want to foreclose that possibility.

---

From: Ron <[email-masked]>
Date: Wed, 12 Nov 2014 06:16:03 +1030

On Tue, Nov 11, 2014 at 02:16:17PM +0000, Andrew Allen wrote:
> If this compromise was to move forward I think any "compelling
> evidence", is likely to be many years down the road (things will
> likely need to play out in the courts first etc) which means that the
> RTCweb group likely doesn't exist anymore or is by then a rump group
> that doesn't have the broad industry participation that we have now.

I think Adam clarified this already too.  The shell game of IP law
effectively makes it impossible to consider questions of validity,
and that includes not just the IETF, but court rulings too (since
another court in another jurisdiction could rule differently and
both judgements could stand simultaneously).

So the only thing we can look at is the formal declarations that
have been made (and not withdrawn).  In that environment, the only
court ruling that might be relevant would be an injunction to
withdraw a blatantly false and anti-competitive declaration, and
I'm not aware of any such cases actually being prosecuted.

None of the court cases people have currently indicated would be
directly relevant to this question for us afaics.

> Would we really go through the process to constitute a new WG just in
> order to debate whether there is "compelling evidence"?
> 
> I certainly would have a big concern if a much smaller group like IESG
> or a rump remnants of RTCweb were in the end to make such a
> determination without a full long (months) high profiled public
> discussion. Also a BoF would not in my view be appropriate to make
> this determination either.
> 
> So if we go this approach aren't we effectively mandating both codecs
> for RTCweb 1.0 with the possibility that in any future RTCweb 2.0 we
> might revisit that decision?
> 
> We need to be cast iron now about the process for revisiting this if
> this goes forward and also with some guidance as to what developments
> are appropriate to trigger revisiting it, as we can't have someone
> just propose at every IETF to reopen this discussion until they get
> the decision they want.

I thought about the question of what the window for triggering this
would be too, but it seemed like a relatively small yak to shave if
we had in-principle agreement on the other details of it (and quite
pointless to worry about if we didn't).

Given that the examples Adam elaborated on (H.264 becomes RF, VP8 is
certified RF by ISO) are possibly the only realistic triggers here
unless something Really surprising happens, we kind of have a natural
bound on this being decided anyway.

Either the H.264 cabal gets its shit together before the ISO process
is completed, and tips it in their favour, or we find out whether what
comes out of the ISO will do so or not.  It doesn't seem likely that
much will happen after that point until declared IPR expires, or the
IETF forms a video codec WG and gives us all an Opus for video.

Possibly the only outcome that would have our bowl of petunias thinking
"Oh no, not again" would be if team H.264 bottles it on the eve of an
RF announcement for VP8 by ISO and declares their codec to be also RF
at the same time.  Which might be good for the world in general, but
would leave us back at a stalemate again over our decision trigger.

Whether it's worth adding some "you acted in bad faith, so you lose"
clause to cover that outcome, or whether we just say "everybody has
already implemented both, and now they're both free so stuff it we
can keep both" I'm undecided on.  That would kind of depend on how
strongly someone might argue the cost of supporting both if both
were RF.  And maybe how much we think that might apply positive
pressure on the H.264 patent holders to act in a timely way if they
are going to ever act at all.

Either way, the natural bound would seem to be "This has to happen
before WGLC on the relevant documents" since after that they become
immutable unless we publish a superseding proposed standard.  It
will be this group that gets to decide if there is anything we
should wait before before taking that step.  What any future group
decides is a matter for them, we can't constrain them for all time
here and now.

Do you see some other way this might unexpectedly come unstuck?

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 11 Nov 2014 12:47:05 -0700

> I don't want to foreclose that possibility.

What is a non-browser mobile app or native app in terms of the entity 
taxonomy from draft-ietf-rtcweb-overview? Is it a WebRTC device or a 
WebRTC-compatible endpoint?

It's nice that people don't want to foreclose possibilities, but I think 
it's important to recognize that one person's desire might turn out to 
be someone else's significant work effort.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Nov 2014 11:56:18 -0800

> Would we really go through the process to constitute a new WG just in order to debate whether there is "compelling evidence"?

I think that all we can do right now is try to establish what the
intent is.  Whether any future effort happens will depend on whether
there is sufficient will (and a venue) to have that discussion at that
time.  We can't predict that that will happen, so I don't think that
there is much value in spending a whole lot of time on the subject.
Getting the text of a statement like this precisely right is going to
be tricky, but I suggest that we give Adam a little discretion in
producing it.

---

From: tim panton <[email-masked]>
Date: Tue, 11 Nov 2014 20:13:16 +0000

On 11 Nov 2014, at 19:47, Peter Saint-Andre - &yet <[email-masked]> wrote:

> What is a non-browser mobile app or native app in terms of the entity taxonomy from draft-ietf-rtcweb-overview? Is it a WebRTC device or a WebRTC-compatible endpoint?

If it implements all the wire protocol (DataChannel etc) including both video codecs it is a WebRTC device.
If it omits a protocol feature (or codec) but can usefully interoperate, it is a WebRTC-compatible endpoint. 
At least that’s my reading.

My personal preference would be to replace ‘both’ with ‘either’ in the device rule, but I understand
the thinking behind the ‘both’ phrasing.

T.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 11 Nov 2014 12:37:04 -0800

On 11/11/2014 11:47 AM, Peter Saint-Andre - &yet wrote:
>>>>> I do not get it either. It seems like mobile apps (which count as
>>>>> devices) using a WEBRTC stack now have to include both codecs
>>>>> regardless of whether they need them. Do we really think app
>>>>> developers will pay attention? Why should they?
>>> [BA] Isn't the non-browser in question the mobile app the developer
>>> wrote? Most of these apps only need to interop with the app on
>>> another platform, a browser app and/or their own service. So they
>>> typically only need one codec or the other not both.

The tendency in the room yesterday was to take the term "WebRTC device"
and replace it with "WebRTC non-browser".

Discussion also concluded that a mobile / native app is an example of a
"WebRTC non-browser"; the term "WebRTC native application" was also
suggested, but "WebRTC non-browser" had more support in the room.

>
> It's nice that people don't want to foreclose possibilities, but I
> think it's important to recognize that one person's desire might turn
> out to be someone else's significant work effort.

Or - more relevant - one person's desire might turn out to be someone
else's need to license codecs.....

---

From: Adam Roach <[email-masked]>
Date: Tue, 11 Nov 2014 10:46:39 -1000

> would leave us back at a stalemate again over our decision trigger.

This scenario certainly came up in thinking about the possible solution 
space. I simply filed it off into the "problems I wish I had" bucket and 
moved on. Given how remote this possibility is, I think we can cross 
this bridge when we come to it.

/a

---

From: cowwoc <[email-masked]>
Date: Tue, 11 Nov 2014 16:02:28 -0500

> the thinking behind the ‘both’ phrasing.

Same here. I would also prefer replacing "both" with "either" in the 
device rule. What is the practical benefit of forcing both codecs on 
non-browsers? If you proceed this way, won't most applications accept 
being declared non-compliant instead of investing the extra work/cost of 
implementing both codecs?

Implementing both codecs only makes sense when you need interoperability 
between applications written by different authors. The same argument 
does not apply when both endpoints are written by the same author. 
Furthermore, I would argue that when separate authors want their 
applications to inter-operate they will have the necessary incentive to 
make that happen, with or without the specification dictating how it 
should be done.

Another spin on this would be to say: all libraries/platforms 
(abstraction layers used to write applications) must implement both 
codecs, whereas applications (end-users) can implement as many codecs as 
they'd like.

Gili

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 11 Nov 2014 22:12:51 +0100

2014-11-11 22:02 GMT+01:00 cowwoc <[email-masked]>:
> Same here. I would also prefer replacing "both" with "either" in the device
> rule. What is the practical benefit of forcing both codecs on non-browsers?
> If you proceed this way, won't most applications accept being declared
> non-compliant instead of investing the extra work/cost of implementing both
> codecs?

Is just that? Without the royalty/patents/licensing stuff being clear
in both H264 and VP8, the current agreement means that someone
building a new browser will be mandated to include two
non-open-royalty-free codecs in order to be "compliant" with a ***W3C
specification***. This is insane IMHO, even more given that nobody
here can claim whether no legal actions could be made in the future
against the author of this such a new browser.

And of course, by "including both codecs" I don't mean "including the
Cisco binary+wrapper".

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

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Tue, 11 Nov 2014 22:41:02 +0000

Thanks for the effort Adam.

We would still prefer a single video MTI codec. That said, here is an alternative to/modification of the ‘novel proposal’ to try to mitigate the concerns.

When video interoperability is required, the following applies:

- All WebRTC endpoints SHOULD implement decoding for at least

   VP8 and H.264.

- In operating environments that expose a platform provided

   implementation of H.264, WebRTC endpoints MUST implement H.264

- In operating environments that expose a platform provided

   implementation of VP8, WebRTC endpoints MUST implement VP8

- Otherwise (in operating environments that do not expose a

   platform provided implementation of H.264 and/or VP8):

     - WebRTC "Devices/non-browser" SHALL implement at least

       one of VP8 and H.264.

     - WebRTC "UAs/browsers" SHALL implement encoding for at

       least one of VP8 and H.264.

The rationales are as follow:

If RF is a requirement, I don't see how the proposal meets the requirement.

If interoperability is a requirement, one agreed upon codec/API is enough.

Multiplying non-agreed upon codecs, at all or at different levels, does not seem to fulfill any of those two requirements and is mechanically increasing the cost of WebRTC implementations.

I believe we should aim at being inclusive and not making some of the WebRTC endpoints, particularly device/non browser, webRTC-compatible endpoints only if they would differ just by one codec.

Elsewhere that is called profiling. Is that a way to go? That is somewhat what the gateway draft looks like.

Some device/OS vendors have released API to hardware supported codec (BlackBerry included). One of the goal is to offer codec access without additional cost to non-platform-native UA/browser/device/non-browser, hence maximizing interoperability for WebRTC endpoints. And without having multiple occurrences of codecs being loaded on the platform.

We should leverage this possibility as this becomes more widely available across platforms.

The IETF RFCs will serve many use-cases and may be implemented with other specifications than the W3C WebRTC 1.0. or without any additional specifications. Most non-browser/device endpoints while implementing (some/all) the IETF WebRTC RFCs will not interop with other non-browser/device endpoints by choice and that has nothing to do with codec support (they might well support the same codec). I think the distinction between native and non-native endpoints also matters a lot.

Interoperability at the codec level for apps/Non-browser/device endpoints is not an obvious requirement for all cases.

"... the IETF will change this normative statement..." It will take some time to have a clear assessment. The ISO process is not finished. It takes an even longer time to deprecate a codec from a platform/non-browser/device. I doubt this will be practical. Opinions changes over time. Agreement to revisit now may not stand in few months. Instead of being unclear on what will trigger the revisit of that text, it would be preferable to avoid creating such a burden.

I hope this helps.

Gaëlle

From: rtcweb [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Sunday, November 09, 2014 9:08 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] MTI Video Codec: a novel proposal

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 11 Nov 2014 16:35:48 -0800

On 11/11/2014 01:02 PM, cowwoc wrote:
> being declared non-compliant instead of investing the extra work/cost
> of implementing both codecs?
>
> Implementing both codecs only makes sense when you need
> interoperability between applications written by different authors.

Don't forget the case where one author wants to write the same
application in two different environments, and wants to use some
toolkits not written by himself.

If those toolkits don't support the same codecs ... he can't
interoperate with himself.

> The same argument does not apply when both endpoints are written by
> the same author. Furthermore, I would argue that when separate authors
> want their applications to inter-operate they will have the necessary
> incentive to make that happen, with or without the specification
> dictating how it should be done.
>
> codecs, whereas applications (end-users) can implement as many codecs
> as they'd like.

That would indeed be a possible spin, but a somewhat strange one.

---

From: cowwoc <[email-masked]>
Date: Tue, 11 Nov 2014 20:36:17 -0500

On 11/11/2014 7:35 PM, Harald Alvestrand wrote:
> toolkits not written by himself. If those toolkits don't support the 
> same codecs ... he can't interoperate with himself. 

Agreed.

> That would indeed be a possible spin, but a somewhat strange one.

I don't think a "WebRTC compliant" logo would be relevant for 
applications (the end-user couldn't care less) but for 
toolkits/frameworks/libraries this is suddenly relevant. Developers will 
look for such things when researching libraries. The same applies for 
browsers. So yes, this approach might sound weird at first but the more 
I think about it the more I think these groups would benefit from 
different expectations.

Gili

---

From: <[email-masked]>
Date: Wed, 12 Nov 2014 08:00:40 +0000

Considering the time spent on this issue, I could live now with any compromise that would avoid the "no decision" situation.  No decision on video MTI codec at this meeting would be very bad news for the WebRTC technology and for its extended usage in services because of the interoperability issue. Any kind of reasonable "two codecs" compromise like this one would make at least a clear step forward with respect to this interop. issue.  So if it can fly, +1 for myself !

Stéphane

De : rtcweb [mailto:[email-masked]] De la part de Adam Roach
Envoyé : lundi 10 novembre 2014 03:08
À : [email-masked]
Objet : [rtcweb] MTI Video Codec: a novel proposal

/a

_________________________________________________________________________________________________________________________

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: Randell Jesup <[email-masked]>
Date: Wed, 12 Nov 2014 09:41:35 -0500

> Thanks for the effort Adam.

Agreed.  This is an incredibly thorny issue due to politics, ideology, 
money, etc - almost none of which is technical, except in the 
ramifications of various not-clean-1-codec-MTI options, as mentioned 
somewhat here.  While I personally (this is the IETF) would prefer a 
pure VP8 MTI, I realize that isn't going to happen right now, and this 
may be (to steal a quote from B5) our last best hope for peace... I mean 
MTI.

> We would still prefer a single video MTI codec. That said, here is an 
> alternative to/modification of the 'novel proposal' to try to mitigate 
> the concerns.
>

You assume "platform" codec implementations (H.264 and VP8) are 
inherently useful for WebRTC.  They often aren't.  You can include 
wiggle words about "usable" or "realtime", which helps but certainly 
makes the decision the domain of the implementing device/browser (to 
decide if it's usable).  I would extend this to must support both if 
they have "usable" platform-provided implementations.

> Some device/OS vendors have released API to hardware supported codec 
> (BlackBerry included). One of the goal is to offer codec access 
> without additional cost to non-platform-native 
> UA/browser/device/non-browser, hence maximizing interoperability for 
> WebRTC endpoints. And without having multiple occurrences of codecs 
> being loaded on the platform.
>

Agreed - but this can be easier said than done, especially on Android, 
and may require per-device/OS-version validation to use. Older OS's 
(Windows pre 8.x for example) don't have viable realtime H.264 codecs by 
default, and we haven't yet verified if the Win8 codec meets the WebRTC 
needs (though likely it does), and so far as I know it's software-only.  
Others may not be available to applications (iOS? especially older iOS).

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

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Wed, 12 Nov 2014 15:40:22 +0000

(gmc] Please see inline.

From: rtcweb [mailto:[email-masked]] On Behalf Of Randell Jesup
Sent: Wednesday, November 12, 2014 9:42 AM
To: [email-masked]
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal

Agreed.  This is an incredibly thorny issue due to politics, ideology, money, etc - almost none of which is technical, except in the ramifications of various not-clean-1-codec-MTI options, as mentioned somewhat here.  While I personally (this is the IETF) would prefer a pure VP8 MTI, I realize that isn't going to happen right now, and this may be (to steal a quote from B5) our last best hope for peace... I mean MTI.
[GMC] except that it does not mitigate any issues.
As an example, I can't think of a single good justification to implement two encoders. Can anyone elaborate?
Interop might not be in a better place if a number of WebRTC-compatible-endpoints-that-are-compatible-endpoints-but-by-one-codec are not implementing the same codec.

We would still prefer a single video MTI codec. That said, here is an alternative to/modification of the 'novel proposal' to try to mitigate the concerns.

   VP8 and H.264.

You assume "platform" codec implementations (H.264 and VP8) are inherently useful for WebRTC.  They often aren't.  You can include wiggle words about "usable" or "realtime", which helps but certainly makes the decision the domain of the implementing device/browser (to decide if it's usable).  I would extend this to must support both if they have "usable" platform-provided implementations.
[GMC] No that is not the assumption. The platform supplied  implementation would be "good enough" for many not for all endpoints. That is pretty clear. An endpoints that wishes to have its own implementation of a required codec would do it and would be willing to afford the additional cost implications.
The proposed requirement here does not mandate an endpoint to use the supplied platform codec implementation. It can chose to use it, or implement its own. This is about mitigating the concerns and cost to various actors.

Agreed - but this can be easier said than done, especially on Android, and may require per-device/OS-version validation to use.
[GMC] I guess the (web) industry has demonstrated its willingness to support a variety of endpoints/actors by exposing platform codec implementations. APIs will evolve. Yes, it might takes time before we reach a perfect world.
The 'novel proposal' will not remove the need of per-device/OS version validation. Even in the 'novel proposal' some endpoints will leverage and use H264/VP8 codecs provided by a platform implementations to claim "H264/VP8 support".

Older OS's (Windows pre 8.x for example) don't have viable realtime H.264 codecs by default, and we haven't yet verified if the Win8 codec meets the WebRTC needs (though likely it does), and so far as I know it's software-only.  Others may not be available to applications (iOS? especially older iOS).
[GMC] this is true for VP8 too.  Hence the proposed "otherwise" requirements.

--

---

From: Shijun Sun <[email-masked]>
Date: Wed, 12 Nov 2014 18:41:09 +0000

On Wednesday, November 12, 2014 6:42 AM, Randell Jesup wrote
> we haven't yet verified if the Win8 codec meets the WebRTC needs (though likely it does), and so far as I know it's software-only.

Folks interested in leveraging the hardware H.264 codec support on Windows devices are welcome to check out the Windows Hardware Certification Requirements [1].  Search for "H.264 encoder" once you have opened the pdf.  BTW, the Skype and Lync applications have been using the hw encoders on Win8.1 devices since the Win8.1 release.

[1] http://download.microsoft.com/download/F/1/C/F1C62227-2D6A-4915-9EF2-0BDAE0F323BD/windows8-1-hardware-cert-requirements-device.pdf

Thanks, Shijun

---

From: Florian Weimer <[email-masked]>
Date: Sat, 15 Nov 2014 22:04:57 +0100

> being loaded on the platform.

The API maybe there, but it does not necessarily confer a patent
license to application developers, just like a patent license obtained
by a WebRTC implementor does not necessarily extend to a service that
integrates WebRTC.