Subject: [rtcweb] Video codecs: Clear positions....

From: Harald Alvestrand <[email-masked]>
Date: Tue, 09 Dec 2014 10:44:45 +0100

I note that the "confirming sense of the room" thread has gotten a lot
of messages that are not declaring a position on the question.

I also note that from the messages on the thread, I can't figure out if
Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a
position (I could guess, but I don't want to - besides, they might not
want to take a position, which is perfectly OK).

It would be nice for me as a reader if people could:

- state their position on the "confirming sense of the room" thread
- change the subject line when they want to say anything else

That's my preference - of course, people who have "mute thread" in their
email readers might want the whole discussion to stay on thread, and
will hate me for the last suggestion....

Harald

---

From: David Singer <[email-masked]>
Date: Tue, 09 Dec 2014 09:32:46 -0800

> On Dec 9, 2014, at 1:44 , Harald Alvestrand <[email-masked]> wrote:
> 

Thanks, Harald, that would help.

I would also like to know from those confirming the sense of the room, whether THEY THEMSELVES intend to implement both codecs, or whether they conveniently think they don’t need to, and it’s just a problem for other people to handle.

Honestly, a +1 for “those other people should do it” is meaningless.  

David Singer
Manager, Software Standards, Apple Inc.

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Tue, 9 Dec 2014 17:36:36 +0000

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of David Singer
Sent: Tuesday, December 09, 2014 12:33 PM
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] Video codecs: Clear positions....

...

[GMC] Very much agree. And also clarifying in which category they belong.... browser, non browser, compatible endpoint.

---

From: cowwoc <[email-masked]>
Date: Tue, 09 Dec 2014 12:36:31 -0500

> Honestly, a +1 for “those other people should do it” is meaningless.

That's a fair point. I'm guessing the vast majority of people answering 
on the mailing list only plan to implement one codec because they are 
non-browser implementors.

Gili

---

From: tim panton <[email-masked]>
Date: Tue, 9 Dec 2014 17:40:17 +0000

> On 9 Dec 2014, at 17:32, David Singer <[email-masked]> wrote:

> Honestly, a +1 for “those other people should do it” is meaningless.  

That’s dangerous logic if you work for a company that won’t say it will implement or use rtcweb in any form at all, 
I could use it to say that your views are meaningless in this matter ;-)

---

From: Simon Perreault <[email-masked]>
Date: Tue, 9 Dec 2014 10:44:05 -0700

On Tue, Dec 9, 2014 at 10:36 AM, cowwoc <[email-masked]> wrote:

> I would also like to know from those confirming the sense of the room,
>> whether THEY THEMSELVES intend to implement both codecs, or whether they
>> conveniently think they don’t need to, and it’s just a problem for other
>> people to handle.
>>
> That's a fair point. I'm guessing the vast majority of people answering on
> the mailing list only plan to implement one codec because they are

FWIW, I'm planning on implementing both and, believe me or not, I'm not
writing a browser.

Simon

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 09 Dec 2014 18:45:33 +0100

On 09/12/2014 18:36, cowwoc wrote:
>> I would also like to know from those confirming the sense of the 
>> room, whether THEY THEMSELVES intend to implement both codecs, or 
>> whether they conveniently think they don’t need to, and it’s just a 
>> problem for other people to handle.
>>
> That's a fair point. I'm guessing the vast majority of people 
> answering on the mailing list only plan to implement one codec because 
> they are non-browser implementors.

No, that's not a fair point. I don't see most of the people making 
taking decisions on other topics (SDP, FEC,  DTLS, CC, 
SVC/Simulcasting/Multicasting, Plan A/PlanB/No plan) implementing them 
themselves. So if this going to be the rule about who-can-vote-what we 
should redefine the whole IETF process.

Everyone should be aware of what are they voting and what is the amount 
of burden/costs it requires to be implemented, and see how that will 
contribute to the success/failure of webrtc and vote accordingly. Not 
just in this topic, but in any topic.

Best regards
Sergio

---

From: tim panton <[email-masked]>
Date: Tue, 9 Dec 2014 17:46:26 +0000

> On 9 Dec 2014, at 17:36, cowwoc <[email-masked]> wrote:
> 
> That's a fair point. I'm guessing the vast majority of people answering on the mailing list only plan to implement one codec because they are non-browser implementors.

I think you may find quite a few people here building APIs toolkits, libraries and gateways who will want the webRTC-compatible
sticker on their product or project, so will probably end up offering a free version with VP8 support and a crazy expensive one
that does both codecs.

T.

---

From: Adam Roach <[email-masked]>
Date: Tue, 09 Dec 2014 11:46:29 -0600

On 12/9/14 11:32, David Singer wrote:
> I would also like to know from those confirming the sense of the room, whether THEY THEMSELVES intend to...

Wait, you're pressing other companies for future product plans? With the 
implication that doing so is a prerequisite to participating in the 
discussion?

That's a mighty sharp blade there. You might check where it's pointed.

/a

---

From: Gustavo Garcia <[email-masked]>
Date: Tue, 9 Dec 2014 09:46:59 -0800

We are planning on implementing both and we are not writing a browser
either.

On Tue, Dec 9, 2014 at 9:45 AM, Sergio Garcia Murillo <
[email-masked]> wrote:

> No, that's not a fair point. I don't see most of the people making taking
> decisions on other topics (SDP, FEC,  DTLS, CC,
> Everyone should be aware of what are they voting and what is the amount of
> burden/costs it requires to be implemented, and see how that will
> contribute to the success/failure of webrtc and vote accordingly. Not just
> in this topic, but in any topic.
>
> Best regards
> Sergio
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: cowwoc <[email-masked]>
Date: Tue, 09 Dec 2014 12:51:40 -0500

On 09/12/2014 12:45 PM, Sergio Garcia Murillo wrote:
>> answering on the mailing list only plan to implement one codec 
>> because they are non-browser implementors.
>
> Everyone should be aware of what are they voting and what is the 
> amount of burden/costs it requires to be implemented, and see how that 
> will contribute to the success/failure of webrtc and vote accordingly. 
> Not just in this topic, but in any topic.

Sergio,

I think this warrants a discussion. It might not be very politically 
correct to say so, but I support the idea that only those who are 
implicated should have a say. The alternative leads to armchair politics 
and bikeshedding.

That said, I echo Simon's point that until Apple and Microsoft 
officially declare their intent to implement WebRTC they are not 
"implicated", hence they should not really get to vote. Sorry guys :)

Gili

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 09 Dec 2014 18:55:42 +0100

On 09/12/2014 18:51, cowwoc wrote:
>> SVC/Simulcasting/Multicasting, Plan A/PlanB/No plan) implementing 
>> them themselves. So if this going to be the rule about 
>> who-can-vote-what we should redefine the whole IETF process.
>>
>> amount of burden/costs it requires to be implemented, and see how 
>> that will contribute to the success/failure of webrtc and vote 
>> accordingly. Not just in this topic, but in any topic.
>
> Sergio,
>
> implicated should have a say. The alternative leads to armchair 
> politics and bikeshedding.

Indeed. I could be in favor of that, but not about changing the rules in 
the middle of the game just because some don't like the result so far.

BR
Sergio

---

From: Simon Perreault <[email-masked]>
Date: Tue, 9 Dec 2014 10:55:47 -0700

On Tue, Dec 9, 2014 at 10:51 AM, cowwoc <[email-masked]> wrote:

> That said, I echo Simon's point that until Apple and Microsoft officially
> declare their intent to implement WebRTC they are not "implicated", hence
> they should not really get to vote.
>

Just for the record, I did not say that.

Simon

---

From: cowwoc <[email-masked]>
Date: Tue, 09 Dec 2014 12:56:23 -0500

On 09/12/2014 12:55 PM, Simon Perreault wrote:
>
> On Tue, Dec 9, 2014 at 10:51 AM, cowwoc <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     "implicated", hence they should not really get to vote.
>
>

Sorry for misquoting you. I think it was Tim Panton who first hinted in 
this direction.

Gili

---

From: Tim Panton <[email-masked]>
Date: Tue, 9 Dec 2014 18:07:32 +0000

> On 9 Dec 2014, at 17:56, cowwoc <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Tue, Dec 9, 2014 at 10:51 AM, cowwoc <[email-masked] <mailto:[email-masked]>> wrote:
>> That said, I echo Simon's point that until Apple and Microsoft officially declare their intent to implement WebRTC they are not "implicated", hence they should not really get to vote.
>> 
> Sorry for misquoting you. I think it was Tim Panton who first hinted in this direction.

I was being flippant. 

I do think however better standards emerge when people who consume webAPIs or build services upon ietf protocols 
are included in the discussion, not just the established browser vendors.

Tim.

---

From: cowwoc <[email-masked]>
Date: Tue, 09 Dec 2014 13:13:37 -0500

On 09/12/2014 1:07 PM, Tim Panton wrote:
> I do think however better standards emerge when people who consume 
> webAPIs or build services upon ietf protocols

I strongly agree for the general case, but maybe not in the case of MTI 
codecs.

If, for example, you were to argue that interoperability between browser 
and non-browser systems is of high importance then we should have a 
single MTI discussion across both systems. Right now we are advocating 
different MTIs for each system, which leads me to conclude that 
non-browser implementors are not implicated in the outcome of the 
browser-specific MTI codec.

Gili

---

From: David Singer <[email-masked]>
Date: Tue, 09 Dec 2014 10:44:39 -0800

> On Dec 9, 2014, at 9:46 , Adam Roach <[email-masked]> wrote:
> 
> Wait, you're pressing other companies for future product plans? With the implication that doing so is a prerequisite to participating in the discussion?
> 

Yes, I realize that almost no-one can make promises about what they will ship. And some companies will be in a position where they can’t say anything.  And yes, my company has a strict policy of not promising what we will or won’t do in the future.  But, hypothetically, if the statement was “must support H.264” I could clearly indicate that that I expect it to be unproblematic.

But surely those that see the dual mandate as unproblematic for them to implement can say that, can’t they?  Surely we can see at least a reasonable number of “yes, we would hope/expect/intend to ship both”, as a non-binding indication?

I mean, the draft ‘must do both’ would require people who have a principled objection to paying fees, having to pay for H.264. I am curious, are people willing to let their principles (and money) go, in order to comply with the ‘must’?

Obviously, I am trying to assess whether this compromise would, in fact, be effective in practice — would enough people abide by its intent that we’d get the interoperability that is the point of the mandate?  I don’t want to be citing RFC 6919 :-).

David Singer

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 9 Dec 2014 11:08:01 -0800

Gili

[BA] I agree that the vast majority of people answering probably believe
that the requirements don't apply to the non-browser category, but actually
the proposal is that dual MTI does apply to non-browsers, right? It's just
the WebRTC-compatible endpoints that are exempt.  So it's actually worse
than "those other people should do it" - it's really "I intend to ignore
the requirements myself and pretend that they don't apply to me while
holding other people to  them".

On Tue, Dec 9, 2014 at 9:46 AM, Adam Roach <[email-masked]> wrote:

>> whether THEY THEMSELVES intend to...
>>
>

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Tue, 9 Dec 2014 19:11:31 +0000

Paying for codecs is cost of doing business.

-          The whole TV ecosystem uses MPEG-2, H.264, etc ... MPEG or Dolby audio ...

-          The whole mobile phone ecosystem uses H.264, AMR, etc …

-          All cameras and displays use standard codecs

-          Almost all online content today is using standard codecs

-          Paying for codecs pays for research labs to continue their research to invent new things

-          There is no performant codec today that is 100% guaranteed royalty free – that is a mirage

The problem I see is that MPEG-LA or other patent pooling organizations don’t typically have a provision for small and medium-sized businesses as they probably don’t have a deep IP portfolio in this space.  That is the problem that should be fixed going forward.

-chris

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of David Singer
Sent: Tuesday, December 09, 2014 10:45 AM
To: Adam Roach
Cc: [email-masked]
Subject: Re: [rtcweb] Video codecs: Clear positions....

> On Dec 9, 2014, at 9:46 , Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

David Singer

rtcweb mailing list

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

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Tue, 9 Dec 2014 19:13:20 +0000

To be clear, the statement below is a Chris Cavigioli statement, not an official statement from my employer.   -chris

From: rtcweb [mailto:[email-masked]] On Behalf Of Cavigioli, Chris
Sent: Tuesday, December 09, 2014 11:12 AM
To: [email-masked]
Subject: Re: [rtcweb] Video codecs: Clear positions....

-chris

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of David Singer
Sent: Tuesday, December 09, 2014 10:45 AM
To: Adam Roach
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Video codecs: Clear positions....

David Singer

rtcweb mailing list

---

From: Adam Roach <[email-masked]>
Date: Tue, 09 Dec 2014 13:20:06 -0600

On 12/9/14 13:08, Bernard Aboba wrote:
> [BA] I agree that the vast majority of people answering probably 
> believe that the requirements don't apply to the non-browser category, 
> but actually the proposal is that dual MTI does apply to non-browsers, 
> right? It's just the WebRTC-compatible endpoints that are exempt.  So 
> it's actually worse than "those other people should do it" - it's 
> really "I intend to ignore the requirements myself and pretend that 
> they don't apply to me while holding other people to  them".

So, even though no one has stood up and said as much, you're 
hypothesizing that some vast majority of people who disagree with you 
must be doing so only because they're bad actors? I think you need more 
evidence than what amounts to a conspiracy theory if you're going to 
level that kind of accusation.

/a

---

From: David Singer <[email-masked]>
Date: Tue, 09 Dec 2014 11:31:23 -0800

> On Dec 9, 2014, at 11:20 , Adam Roach <[email-masked]> wrote:
> 
>> [BA] I agree that the vast majority of people answering probably believe that the requirements don't apply to the non-browser category, but actually the proposal is that dual MTI does apply to non-browsers, right? It's just the WebRTC-compatible endpoints that are exempt.  So it's actually worse than "those other people should do it" - it's really "I intend to ignore the requirements myself and pretend that they don't apply to me while holding other people to  them".
> 
> So, even though no one has stood up and said as much, you're hypothesizing that some vast majority of people who disagree with you must be doing so only because they're bad actors? I think you need more evidence than what amounts to a conspiracy theory if you're going to level that kind of accusation.

Jeepers, guys, do we have to resort to this kind of language?  

I honestly DO NOT KNOW how many endpoints, of any kind, would expect to support both codecs.  Getting a rough sense of that would be really useful. Happily I don’t need to care about why people land where they do, how conspiratorial, deceitful, or anything they may be. In fact, I expect most people are trying to do their best, balancing everything. But I don’t know what that means.

That’s why I said that saying that a WebRTC implementation, in a browser, is not a WebRTC Browser but a WebRTC-Compatible Endpoint, though formally possible, is questionable — it would appear to be skirting the intent of the spec.

For example, I *think* that Firefox would if H.264 is either available on the platform, or available via the Cisco download for that platform. So if I am right, they get pretty close.  Beyond that, who knows?

So, please, can we assume people are trying to do the best they can?

David Singer

---

From: Mohammed Raad <[email-masked]>
Date: Tue, 9 Dec 2014 21:31:34 +0200

You know, that's a very strange path to take. I mean it really does sound
like attempting to come to an agreement regarding what features future
products should have by limiting participation in this technical decision
process to those committed to deploy specific technologies. I think you
ought to read the definition of anti competitive practice again.

Mohammed

---

From: David Singer <[email-masked]>
Date: Tue, 09 Dec 2014 11:35:05 -0800

> On Dec 9, 2014, at 11:31 , Mohammed Raad <[email-masked]> wrote:
> 
> You know, that's a very strange path to take. I mean it really does sound like attempting to come to an agreement regarding what features future products should have by limiting participation in this technical decision process to those committed to deploy specific technologies. I think you ought to read the definition of anti competitive practice again.

Please be respectful of your language.

I am trying to find out a simple answer:  how many endpoints would, in fact, expect to support both codecs?

I am not trying to limit participation.  I am trying to find out whether we would actually get the purported effect.

If all the people humming yes make webrtc-compatible endpoints, we do not get the effect we want.  Is it that hard to see that?

David Singer

---

From: Tim Panton <[email-masked]>
Date: Tue, 9 Dec 2014 19:50:25 +0000

> On 9 Dec 2014, at 19:31, David Singer <[email-masked] <mailto:[email-masked]>> wrote:

> That’s why I said that saying that a WebRTC implementation, in a browser, is not a WebRTC Browser but a WebRTC-Compatible Endpoint, though formally possible, is questionable — it would appear to be…

I’m deeply confused by that remark. To answer the question I think you are asking, (i.e. ’can you show me a non-browser webrtc compliant endpoint?'). The best example I can think of that is public is E/// ’s openwebRTC - which implements both codecs, but doesn’t implement a browser or the w3C javascript API. - Note that they leave the issue of h264 licence fees to the app developer to sort out (although they plan to let it use native os exposed codecs and ride that license I think)

Or did I misunderstand?

Tim.

---

From: Mohammed Raad <[email-masked]>
Date: Tue, 9 Dec 2014 21:51:05 +0200

Well, that's a much clearer question without  implications. However, I
think it is impossible to answer at this point regardless how many people
indicate that they will implement both codecs or not at this point.

Mohammed
On Dec 10, 2014 6:35 AM, "David Singer" <[email-masked]> wrote:

> > You know, that's a very strange path to take. I mean it really does
> sound like attempting to come to an agreement regarding what features
> future products should have by limiting participation in this technical
> decision process to those committed to deploy specific technologies. I
> think you ought to read the definition of anti competitive practice again.
>
> I am not trying to limit participation.  I am trying to find out whether
> we would actually get the purported effect.
>
> If all the people humming yes make webrtc-compatible endpoints, we do not
> get the effect we want.  Is it that hard to see that?
>
>
>
> David Singer

---

From: Tim Panton <[email-masked]>
Date: Tue, 9 Dec 2014 20:02:51 +0000

> On 9 Dec 2014, at 19:35, David Singer <[email-masked] <mailto:[email-masked]>> wrote:
> 

I’ve said before - my view is that most toolkits for building webRTC compliant native apps  will ship with support for both codecs, but with levers to
allow the developer to disable the use of a specific codec where it is in appropriate to their use-case for one reason or another.

It is unknowable what choices individual app developers will make.

- But remember webRTC is unlike most web technologies, it takes 2 peers to tango, so most app developers will probably
enable both codecs if they can. Especially if they intend to allow web based users to communicate with native app users. They will do so 
because hopefully O/A can make a better codec choice at runtime than they can at compile time, given the huge variety in 
possible endpoint hardware.

Tim

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 9 Dec 2014 12:10:51 -0800

David Singer said:

"I am trying to find out a simple answer:  how many endpoints would, in
fact, expect to support both codecs?"

[BA]  The proposal has built-in incentives for implementers in each
category to either ignore the recommendations or ignore interoperability
(or both).

As it stands, the proposal doesn't require that "WebRTC-compatible
endpoints" support either H.264 or VP8.  I understand why an endpoint not
supporting video shouldn't have to, but if the WebRTC-compatible endpoint
does support video, why shouldn't it support at least one of the MTI
codecs?   The way it is written a WebRTC-compatible endpoint that supported
only H.261 would be compliant while being able to communicate with either
browsers or non-browsers, which seems silly.

The "non-browser" is required to support both codecs, but only until a
clause is triggered to choose a single MTI.  For a  "non-browser" such as a
mobile application, there is no real need to support both VP8 and H.264,
assuming that browsers support both.  So I would expect most folks in this
category to ignore the recommendation or wait for the "trigger" (then
ignore that too if the selected codec isn't the one they've already
chosen).   It would make more sense for this category to mandate
implementation of either VP8 or H.264 (implementer's choice) and dump the
trigger clause.

The "browser" subset is supposed to support both codecs.  However, the
"trigger" clause for the "non-browser" case muddies the waters,
particularly in situations where implementing a previously non-supported
codec could take a while.  Who wants to spend a lot of effort implementing
a codec that  might not even be required by the time the implementation is
complete (and that will probably be guaranteed to be obsolete by then
anyway)?

---

From: Silvia Pfeiffer <[email-masked]>
Date: Wed, 10 Dec 2014 07:19:16 +1100

Nice question, seeing Apple makes so many statements about what they intend
to implement. :-)
Fwiw, we have an iOS webrtc stack and have vp8 support in it. If Apple
opens access to the h264 hardware support on iOS, we would likely hand that
through, too.

Best Regards,
Silvia.

---

From: David Singer <[email-masked]>
Date: Tue, 09 Dec 2014 12:29:46 -0800

> On Dec 9, 2014, at 11:50 , Tim Panton <[email-masked]> wrote:
> 
> 
>> On 9 Dec 2014, at 19:31, David Singer <[email-masked]> wrote:
> 
>> 

> Or did I misunderstand?’

Only slightly.  An earlier suggestion on this thread was that one could be conformant with the WebRTC specs if one simply claimed that one was building a webrtc-compatible endpoint;  even if the implementation was of webrtc, in a browser, it would not be labeled as “WebRTC Browser”.

That, to me, is sleight of hand;  a neat trick, but not quite what we want to have happen.  I’d rather not suggest it to anyone.

David Singer

---

From: Adam Roach <[email-masked]>
Date: Tue, 09 Dec 2014 14:53:18 -0600

On 12/9/14 12:44, David Singer wrote:
> I mean, the draft ‘must do both’ would require people who have a 
> principled objection to paying fees, having to pay for H.264. I am 
> curious, are people willing to let their principles (and money) go, in 
> order to comply with the ‘must’?

I'd like to point out that Ron (@debian.com -- I actually don't know his 
last name) has consistently and admirably made the most principled 
objections in the MTI codec conversation, over the course of several 
years. And Ron has posted many times in support of this plan.

To be clear, I'm arguing from what I think is a principled place as 
well, and I'm the one who brought this plan to the WG (even though it's 
not what I would have preferred) -- but Ron seems to really be the 
torchbearer for a clearly principled stand here.

/a

---

From: Ron <[email-masked]>
Date: Wed, 10 Dec 2014 09:13:45 +1030

On Tue, Dec 09, 2014 at 12:29:46PM -0800, David Singer wrote:
> 
> An earlier suggestion on this thread was that one could be conformant
> with the WebRTC specs if one simply claimed that one was building a
> webrtc-compatible endpoint;  even if the implementation was of webrtc,
> in a browser, it would not be labeled as “WebRTC Browser”.
> 
> That, to me, is sleight of hand;  a neat trick, but not quite what we
> want to have happen.  I’d rather not suggest it to anyone.

Those definitions aren't badges you get to sew onto your scout uniform
to claim as some level of achievement or entitlement.

They are descriptive jargon that lets us refer to those things in
other areas of the spec without having to be repetitively verbose.

If what you build is a compatible endpoint, then what you have is a
compatible endpoint.  If what you build is a half-assed browser, then
what you have is a half-assed browser.  What your marketing dept.
chooses to call it is none of our business.

There are people who like to call Theora a "proprietary codec" and call
H.264 an "open standard", but nobody actually buys that bullshit either.

Nothing about this proposal is about weasel words or smoke and mirrors,
it's about establishing the benchmarks we think are needed to have the
best chance of interoperability.  Some people will have extenuating
circumstances that mean they simply can't fulfill every requirement.
This compromise acknowledged that from the outset.  Some of us *are*
going to have difficulties complying with the onerous requirements of
the selectively enforced H.264 licencing, and in some cases may not be
able to distribute it at all in any general way, even if the code does
ostensibly have support for it.  Or even if we distribute it, the end
user may not be permitted to use it in the way they wish to, or at all.

Don't forget that you aren't licenced to shoot and freely distribute
videos in H.264 using the professional video camera you bought which
came with a licence to H.264 ...  if that's not the pinnacle of
braindead restrictive practices, founded on a sense of unrestrained
entitlement to a stranglehold on the work of others, then I can't
wait to see the full glorious irony of what is.

Some of us have code that is freely distributed in unrestrictedly
international markets.  That includes countries that would laugh at
any attempt to enforce IPR on software -- and possibly even countries
where the H.264 patent holders are embargoed from being able to legally
enter into business agreements with users and companies there (I've not
actually looked to see if that is currently the case, but even if it is
not at present, it seems like a not impossible future circumstance).

There are a long list of principles and problems beyond "objecting to
paying fees" (which afaics is a complete strawman that nobody has ever
claimed to object to).

If everybody who actually can makes a best effort, I think we'll manage
a high level of interop, despite these known problems, until the video
codec WG gives us a real solution (where we can reprise the fun of
having the same group of people try to obstruct it in the same tiring
ways again too!).  We have commitments from enough of the major players
to put that on a fairly solid foundation right from the start.

If people who could comply to this simply don't want to, and would
prefer to make up some meretricious pretense about that instead of
doing so, then we can't stop them from doing that.  But as people
opposing this have been so fond of pointing out - the market will
in all probability decide on their fate, right?

It's never easy to get a dead whale off your beach.  But if some
of us don't pull together and try, it's going to stink the place up
for a whole lot longer and ruin it for everyone.  I'm willing to
hold my nose for a little while to help with that, though I don't
speak for anyone but myself.

  Vomeronasally,
  Ron

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 10 Dec 2014 05:48:50 +0100

It's perhaps not surprising that I disagree with Bernard on every point
he makes below, but since I respect Bernard quite a lot, I'll try to
make it clear why.

On 12/09/2014 09:10 PM, Bernard Aboba wrote:
> David Singer said: 
>
> "I am trying to find out a simple answer:  how many endpoints would,
> in fact, expect to support both codecs?"
>
> category to either ignore the recommendations or ignore
> interoperability (or both).   
>
> endpoints" support either H.264 or VP8.  I understand why an endpoint
> not supporting video shouldn't have to, but if the WebRTC-compatible
> endpoint does support video, why shouldn't it support at least one of
> the MTI codecs?   The way it is written a WebRTC-compatible endpoint
> that supported only H.261 would be compliant while being able to
> communicate with either browsers or non-browsers, which seems silly.

This is irrelevant to the proposal made.
The term "WebRTC-compatible" is introduced solely to point out that
there are things that will talk (successfully!) to WebRTC endpoints that
aren't WebRTC - and there's nothing whatsoever we or anyone else can do
to prevent that.

> clause is triggered to choose a single MTI.  For a  "non-browser" such
> as a mobile application, there is no real need to support both VP8 and
> H.264, assuming that browsers support both.  So I would expect most
> folks in this category to ignore the recommendation or wait for the
> "trigger" (then ignore that too if the selected codec isn't the one
> they've already chosen).   It would make more sense for this category
> to mandate implementation of either VP8 or H.264 (implementer's
> choice) and dump the trigger clause. 
>
> particularly in situations where implementing a previously
> non-supported codec could take a while.  Who wants to spend a lot of
> effort implementing a codec that  might not even be required by the
> time the implementation is complete (and that will probably be
> guaranteed to be obsolete by then anyway)? 

I think the incentives here make sense.

First off, let's assume that codec agility is a Good Thing.
Most implementors I've talked to about codecs say that they intend to
support codecs that aren't in the MTI, and won't be in the MTI any time
soon. (this includes AVC-High profile as well as the next generation
codecs HEVC and VP9).

So the extra cost of implementing two MTI codecs is strictly limited to
the cost of supporting the codec; the rest of the machinery for picking
a codec is already present.

People have sharply differing opinions on the quality they expect to get
out of the two codecs. So we can assume from the get-go that there will
be different preferences stated during negotiation.
However, among those who don't prefer one codec for special reasons, one
would expect market forces to work here; they will, over time, tend to
prefer what works best (for whatever value of "best" makes sense for
them). Implementing both gives flexibility here, which is a Good Thing.

With regard to the stability of MTI (the "trigger clause"), I heard two
concerns voiced:

- The people for whom H.264 interoperability without transcoding is of
paramount importance want assurance that their investment in
browser-based systems is not lost due to a later MTI change.

- The people for whom cost, silicon area or license freedom is of
paramount importance want to make sure that if we're in a situation
where a single codec clearly makes sense, they can go there.

Given the size of a modern browser, the last group are *not* the browser
vendors - supporting another middle-aged codec in software is just
another piece of code. (modulo the Firefox "download dance", which *is*
a complicating factor.)

Having the "trigger clause", formulated the way it is, gives something
to both these groups: The first group gets assurance that its
browser-targeted investment is protected - the second group gets
assurance that if a clearly sane (from their viewpoint) outcome is later
possible, they can go for it.

And the "trigger cause" serves as an additional incitement for *current*
implementors to actually do both, in order to be future-proof; there's
no telling which, if any, of the MTI codecs will actually reach the
trigger condition first - and those implementors who have implemented
both know that in the event of an MTI change, and a rollout of a large
number of devices with only one codec, they will be able to interoperate
without an upgrade - no matter which codec gets dropped.

Summary: I think a lot of people have incentive to follow the
recommendation.
We should stick to our recommendation and move on.

Harald

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 10 Dec 2014 13:36:17 +0100

> non-browser implementors.

And probably many people give +1 to "MUST implement both codecs" so
they will just implement H264 in their systems and win anyhow.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 10 Dec 2014 13:41:44 +0100

> That's a mighty sharp blade there. You might check where it's pointed.

According to what I understand, someone announcing that he or his
company will implement both codecs is not about announcing a "product
feature", but just the fact that such a product will be "WebRTC
compliant". And that is what all of this subject is about, isn't?

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 10 Dec 2014 13:54:29 +0100

2014-12-09 20:11 GMT+01:00 Cavigioli, Chris <[email-masked]>:
> Paying for codecs pays for research labs to continue their research to
> invent new things

Please, don't go there. The business model of research labs is not the
subject here, and I assume you agree that the W3C's goal is not to
satisfy any business model.

Said that, there are some "minor" examples in the world that may
contradict what you said, such as the Linux and open source whole
ecosystem. Anyhow, that is not the subject.

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

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Thu, 11 Dec 2014 02:40:13 +0800

Temasys supports the dual codec proposal.

We will support at least vp8 and H.264 in most of our products (BE, plugin,
SDKs) and of course more codecs where it makes sense (AVC high profile is a
good example, VP8 with temporal scalability is another).

We plan to provide support for at least VP8 and H.264 (with hardware acc
when possible i.e. iOS 8+) when porting webrtc to webkit. What will be
supported in the ports/browsers using webkit as a rendering engine (*cough*
*safari**cough*) will be up to those ports maintainers.

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

   -

---

From: Richard Barnes <[email-masked]>
Date: Wed, 10 Dec 2014 16:34:49 -0500

> Honestly, a +1 for “those other people should do it” is meaningless.

This is a reminder that in IETF discussions, participants are individuals,
and entitled to come to their technical positions however they want.  I'd
like to ask folks to refrain from calling the opinions of others
"meaningless" or otherwise using derogatory language. In the IETF, every
individual is entitled to put forward opinions and we debate those opinions
on their own merits, not based on the putative motivations of the
proponent.  That is standard practice in the IETF, and this WG is no
exception.

Thanks,
--Richard

---

From: Randell Jesup <[email-masked]>
Date: Wed, 10 Dec 2014 16:57:56 -0500

> communicate with either browsers or non-browsers, which seems silly.

I've seen a device that supports webrtc but can't reasonably handle VP8 
or H.264, but can run an implementation of H.261, so this really 
exists.  I wouldn't call it great, but it's not non-sensical.

As mentioned, Firefox as shipping (for months now) in release supports 
H.264 and VP8 (and perhaps more soon).

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 11 Dec 2014 14:35:13 -0700

> want to take a position, which is perfectly OK).

+0. I neither support nor object to The Honolulu Compromise (THC).

As Mo Zanaty pointed out, its primary benefit is that it necessitates 
codec negotiation, capabilities discovery, and other features that can 
will prove helpful once we have a truly open and technically superior 
video codec (think "Opus for video").

Until then, THC is merely a temporary palliative.

Peter

P.S. https://blog.andyet.com/2014/12/11/video-codecs-past-present-future

---

From: Ron <[email-masked]>
Date: Fri, 12 Dec 2014 09:18:22 +1030

On Thu, Dec 11, 2014 at 02:35:13PM -0700, Peter Saint-Andre - &yet wrote:
> As Mo Zanaty pointed out, its primary benefit is that it necessitates codec
> negotiation, capabilities discovery, and other features that can will prove
> helpful once we have a truly open and technically superior video codec
> (think "Opus for video").
> 

I still would be very interested in seeing some sort of rationale text
that lays this side of things out a bit more openly, if only to give
some sort of guidance (even if not normative) to future folk (and the
broader internet community when this gets to them for review) about
how we arrived at this state and why we've accepted it as an interim
workaround even if a lot of us do think it's a kind of dopey situation
to have ended up wedged in.  I certainly don't think you're alone in
criticising it in this way, whatever the concern may be for upsetting
a delicate consensus.

I'd like to think there is some way we can elaborate on this without
risking pulling the ground out from under what people have been resigned
to agreeing to here.  Even Cisco folk are on the record for saying they
would greatly prefer the kind of Final Solution that an "Opus for video"
could bring us.

I'd hinted at that again here:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg13819.html

  You are right that there are more than just these two camps though.
  There's also a (clearly large) subset of both that cares enough about
  the success of this project to compromise with each other in its best
  interests.  With enough options and workarounds to get by until we have
  an IETF video codec to solve it properly (and I still do think that
  clarifying that is important here.  If we're going to do something as
  audacious as mandate a patent minefield like H.264 when there is an
  equivalent that actually meets the IETF's aspirational requirements for
  RF technology, we need a better reason for that than "some people with
  H.264 patents insisted" if it's going to survive being challenged, or
  ridiculed, in later review).

and in one or two other comments here.  But I could easily forgive
anyone for missing that in the current frenzied scrum.

As I understand things we not only need to get consensus on this here,
but it also needs to stand up to scrutiny from the IESG and internet
community in general, who still could reject it as a load of hazy tosh
if we haven't made our reasoning clear and acceptable to them.

I don't know what the odds of that actually are, but I can only assume
they are worse if we don't clearly explain not only "what" but "why"
in a case like this.

  Cheers,
  Ron