Subject: [rtcweb] A different perspective on the video codec MTI discussion

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Mar 2013 18:06:47 -0400

I’d like to put a different perspective on the video MTI discussion.

Much of the discussion has been around video quality, IPR, and
standardization status. While those are all important factors, to me they
are secondary to the core question: how does the choice impact uptake of
the webRTC APIs and protocols by developers who build applications ontop of
it? In this regard, I would like to suggest that, at this time, adoption of
VP8 as MTI will slow down adoption of webRTC by turning off developers that
would otherwise embrace it if H.264 were selected.

The reason is simple. For many application developers, what is interesting
about webRTC is NOT just browser to browser communications, but connecting
users in a browser to users elsewhere - on other devices, in other
networks. After all, the vast majority of web application developers do not
have the luxury of a massive social graph, or the luxury of their users
being parked persistently on their website and thus able to receive an
incoming call. Many websites that have customer support or service needs
would love to be able to allow their users to have a video call with an
agent. However, those agents are probably sitting on existing agent systems
which are not web based, and it’s almost certainly true that they do not
today support VP8, but rather H.264. Many developers would probably love to
connect users on the web with users on mobile apps. Most mobile platforms
today support H264 based hardware acceleration for decode and sometimes
encode, but not yet VP8. Developers who want to build business
communications clients will need to connect those users with other users in
the business, who may be using videophones, PC clients, telepresence units
or video room systems, the vast majority of which do not support VP8 today,
but many of which do support H.264.

The reality is – today’s Internet and IP communications systems are built
on H.264. And unless the developer cares only about living within the
island of the web browser – a VP8 based solution will simply not meet their
requirements.

This may not be true down the road. I applaud Google for working hard (and
spending much money no doubt) to secure an RF license for VP8 from these
patent holders. I think they should continue pushing and promoting the
technology because a  free, high quality video codec would be great for the
Internet. But today, it is not the video codec of the Internet. And, given
the relatively early days of video, I am sure there will be video codecs
after VP8. Maybe H.265, maybe the new video codec being developed here at
the IETF. And once those codecs become more broadly implemented and
available on the endpoints that matter, we can revise our specs and mandate
support for them. But this is not about the web of five years from now, its
about the web today. And if we mandate usage of a codec which is not widely
implemented in all the endpoints that matter (not just the browser), I fear
that it will hold developers back from using webRTC and thus prevent us
from ever having the opportunity to add these video codecs in the future.

And so – to the supporters of VP8 – I applaud your efforts and thank you
for them. Please continue. And when the industry is ready, we can make VP8
MTI in the browser. But we are not there yet.  I ask you to please put the
needs of the developers ahead of your own, and do not hold back webRTC for
the benefit of your ideals around an RF and open source video codec. WebRTC
is too important for that.

I have one more thing to say - speaking now as a developer.

As some of you may know, I recently returned to Cisco as CTO of the cloud
collaboration group, which is responsible for Webex. Webex was one of the
first services to do voice and video on the web, using plugins of course.
For our business, a key requirement is interoperability with other video
systems in the Cisco portfolio, including our video clients and
telepresence units. Those are all based on H.264. Consequently, much as I
would like to avoid the need for a plugin, the benefits of eliminating the
plugin do not outweigh the drawbacks of having to transcode from VP8 to
H.264. If IETF selects VP8 as the MTI codec, this will make it dramatically
more difficult and expensive for us to use webRTC. If H.264 is the MIT
codec, it will make it much easier for us to use webRTC.

Thx,

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

---

From: Justin Uberti <[email-masked]>
Date: Wed, 13 Mar 2013 15:41:28 -0700

Regarding your comment on the "web today", I think it is worthwhile to
point out that within weeks, there will be 2B+ deployed WebRTC endpoints,
across desktop and mobile, that support VP8.

Surely that dwarfs the total number of deployed H.264 endpoints by several
orders of magnitude.

On Wed, Mar 13, 2013 at 3:06 PM, Jonathan Rosenberg <[email-masked]>wrote:

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

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 14 Mar 2013 09:54:33 +1100

Also, it is worth pointing out that h.264 cannot meet the RF requirements
of W3C, so the only alternatives we can look at are VP8 or delaying the
decision for an MTI until the market decides.

I'd rather we specify for an environment 5 years down the track (and give
companies like CISCO a reason to replace all their old devices with new
ones that support VP8) than continuing decision avoidance.

Regards,
Silvia.
(Speaking for myself)
On 14 Mar 2013 09:42, "Justin Uberti" <[email-masked]> wrote:

>> The reason is simple. For many application developers, what is
>> interesting about webRTC is NOT just browser to browser communications, but
>> connecting users in a browser to users elsewhere - on other devices, in
>> other networks. After all, the vast majority of web application developers
>> do not have the luxury of a massive social graph, or the luxury of their
>> users being parked persistently on their website and thus able to receive
>> an incoming call. Many websites that have customer support or service needs
>> This may not be true down the road. I applaud Google for working hard
>> (and spending much money no doubt) to secure an RF license for VP8 from
>> these patent holders. I think they should continue pushing and promoting
>> the technology because a  free, high quality video codec would be great for
>> the Internet. But today, it is not the video codec of the Internet. And,
>> given the relatively early days of video, I am sure there will be video
>> codecs after VP8. Maybe H.265, maybe the new video codec being developed
>> here at the IETF. And once those codecs become more broadly implemented and

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Mar 2013 19:44:10 -0400

Justin - my point is that there are non-web endpoints that people care
about - including most importantly mobile endpoints. Its not just about
pure numbers, its about reaching users on the devices/platforms they need
to be reached on.

Surely you don't mean that its not important for developers (like Webex) to
reach users on mobile clients or other video systems outside of the web?

Thx,
Jonathan R.

On Wed, Mar 13, 2013 at 6:54 PM, Silvia Pfeiffer
<[email-masked]>wrote:

>> Surely that dwarfs the total number of deployed H.264 endpoints by
>> several orders of magnitude.
>>
>>
>>> The reality is – today’s Internet and IP communications systems are
>>> built on H.264. And unless the developer cares only about living within the
>>> As some of you may know, I recently returned to Cisco as CTO of the
>>> cloud collaboration group, which is responsible for Webex. Webex was one of
>>> the first services to do voice and video on the web, using plugins of
>>> course. For our business, a key requirement is interoperability with other
>>> video systems in the Cisco portfolio, including our video clients and

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 13 Mar 2013 16:54:16 -0700

>
> Surely you don't mean that its not important for developers (like Webex)
to reach users on mobile clients or other video systems outside of the web?

They too can have vp8 and opus. And if your legacy gear does not, then it
can negotiate appropriately to something that will work.

As a mobile operator offering fmc today, I look forward to opus and vp8
being ubiquitous in all devices.

CB

> Thx,
> Jonathan R.
>
>
> On Wed, Mar 13, 2013 at 6:54 PM, Silvia Pfeiffer <
[email-masked]> wrote:
>>
>> Also, it is worth pointing out that h.264 cannot meet the RF
requirements of W3C, so the only alternatives we can look at are VP8 or
delaying the decision for an MTI until the market decides.
>>
>> I'd rather we specify for an environment 5 years down the track (and
give companies like CISCO a reason to replace all their old devices with
new ones that support VP8) than continuing decision avoidance.
>>>>
>>>>
>>>>
>>>> And so – to the supporters of VP8 – I applaud your efforts and thank
you for them. Please continue. And when the industry is ready, we can make
VP8 MTI in the browser. But we are not there yet.  I ask you to please put
the needs of the developers ahead of your own, and do not hold back webRTC
for the benefit of your ideals around an RF and open source video codec.
WebRTC is too important for that.

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 14 Mar 2013 00:55:21 +0100

Hi Jonathan,

> As some of you may know, I recently returned to Cisco as CTO of the cloud collaboration group, which is responsible for Webex. Webex was one of the first services to do voice and video on the web, using plugins of course. For our business, a key requirement is interoperability with other video systems in the Cisco portfolio, including our video clients and telepresence units. Those are all based on H.264. Consequently, much as I would like to avoid the need for a plugin, the benefits of eliminating the plugin do not outweigh the drawbacks of having to transcode from VP8 to H.264. If IETF selects VP8 as the MTI codec, this will make it dramatically more difficult and expensive for us to use webRTC. If H.264 is the MIT codec, it will make it much easier for us to use webRTC. 
> 
> 

This statement looks quite 'ironic'. Seems like you're asking people to stick to H.264 because otherwise you can experience issues in keeping on doing your company's business with no modifications to your legacy stuff. I don't think this is the right thing to ask to an 'open standards' community like the IETF. Let me just tell you that there are plenty of young 'iconoclastic' companies out there which are looking at WebRTC/RTCWeb as a huge opportunity to enter the market by qualifying themselves for adopting cutting-edge technologies (like VP8) and are not afraid of putting their hands 'inside' the network by building rtcweb-enabled middle-boxes which provide functions going far beyond the original browser-to-browser use case.

My 2 cents,

Simon
> Jonathan R.

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 14 Mar 2013 00:55:28 +0100

Il giorno Wed, 13 Mar 2013 18:06:47 -0400
Jonathan Rosenberg <[email-masked]> ha scritto:

> cloud collaboration group, which is responsible for Webex. Webex was
> one of the first services to do voice and video on the web, using
> plugins of course. For our business, a key requirement is
> interoperability with other video systems in the Cisco portfolio,
> including our video clients and telepresence units. Those are all
> based on H.264. Consequently, much as I would like to avoid the need
> for a plugin, the benefits of eliminating the plugin do not outweigh
> the drawbacks of having to transcode from VP8 to H.264. If IETF
> selects VP8 as the MTI codec, this will make it dramatically more
> difficult and expensive for us to use webRTC. If H.264 is the MIT

Speaking as a developer working for a company with much less money than
yours, if the IETF selects H.264 as the MTI codec, this will make it
even more dramatically difficult and expensive (if not impossible) for
pretty much everybody else to use webRTC, or at least to develop
services based on it.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Justin Uberti <[email-masked]>
Date: Wed, 13 Mar 2013 16:58:22 -0700

As I mentioned, hundreds of millions of mobile endpoints will support
WebRTC and VP8 within weeks.

The mobile-device-hardware-codec argument is a non-starter to me, since as
you know, the popular realtime video applications on these platforms
already use software codecs in the vast majority of cases. Regardless,
Android devices have been shipping with HW VP8 codecs for some time now.

On Wed, Mar 13, 2013 at 4:44 PM, Jonathan Rosenberg <[email-masked]>wrote:

>>> On Wed, Mar 13, 2013 at 3:06 PM, Jonathan Rosenberg <[email-masked]
>>> > wrote:
>>>

---

From: Andrew Allen <[email-masked]>
Date: Thu, 14 Mar 2013 02:11:06 +0000

Lorenzo

A good piece of advice when shopping is to always beware of the places where the price is not well advertised - the fact that the price is not known in advance does not mean its free - and often quite the opposite!

Andrew

----- Original Message -----
From: Lorenzo Miniero [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 06:55 PM Central Standard Time
To: Jonathan Rosenberg <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] A different perspective on the video codec MTI discussion

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

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

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 13 Mar 2013 19:26:48 -0700

On Mar 13, 2013 7:11 PM, "Andrew Allen" <[email-masked]> wrote:
>
>
>
> Lorenzo
>
> A good piece of advice when shopping is to always beware of the places
where the price is not well advertised - the fact that the price is not
known in advance does not mean its free - and often quite the opposite!
> Andrew
Since we are handing out advice.

Here is another piece if advice.

If it's free, take 2.

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 Mar 2013 23:00:30 -0400

Hi Jonathan,

A quick comment in-line

On Wed, Mar 13, 2013 at 6:06 PM, Jonathan Rosenberg <[email-masked]> wrote:
> users in a browser to users elsewhere - on other devices, in other networks.
> After all, the vast majority of web application developers do not have the
> luxury of a massive social graph, or the luxury of their users being parked
> persistently on their website and thus able to receive an incoming call.
> Many websites that have customer support or service needs would love to be
> able to allow their users to have a video call with an agent. However, those
> agents are probably sitting on existing agent systems which are not web
> based,

I've made the cut here because the point I want to make isn't really
codec specific. It's that the core requirement of this working group
is laid out as enabling a new real time platform based on the web.
That's set out in the charter in this language:

"There are a number of proprietary implementations that provide direct
    interactive rich communication using audio, video, collaboration,
    games, etc. between two peers' web-browsers. These are not
    interoperable, as they require non-standard extensions or plugins to
    work.  There is a desire to standardize the basis for such
    communication so that interoperable communication can be established
    between *any compatible browsers*. The goal is to enable innovation on
    top of a set of basic components.  One core component is to enable
    real-time media like audio and video, a second is to enable data
    transfer directly between clients."

The emphasis on "*any compatible browsers*" is mine.  That is the
focus of the work; that new, web-based ecology is its reason for
being.

We have understood from the beginning that there are many other
endpoints that it would be useful to interconnect with browsers, but
we have also understood that some choices would mean that those
connections would likely travel through gateways.  There may be agent
systems like those you describe above that are capable of DTLS-SRTP,
continued consent based on ICE, and all the other pieces of our
overall system, but there are certainly also many that are not.
Gatewaying will be common, and I personally hope companies with
histories of producing successful middle boxes enter the market with a
will.

WebRTC will not produce a successful new ecology if it focuses its
technical decisions on full interoperability with non-WebRTC systems;
while the initial opportunity looks bigger, it is ultimately something
that circumscribes the possibilities for success.  You and I have both
seen the complications which arise from following that path, and this
group and its W3C partner group made a conscious decision not to
require it.  Time will tell if the choice was the right one, but, in
the mean time, the charter is clear.  I personally think that was the
right choice, and it is certainly, for me, the more exciting
possibility.

Speaking as an individual, not as chair,

regards,

Ted Hardie

---

From: Andrew Allen <[email-masked]>
Date: Thu, 14 Mar 2013 03:03:00 +0000

The operative word being "IF" - and always read the fine print first!

From: Cameron Byrne [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 09:26 PM Central Standard Time
To: Andrew Allen
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [rtcweb] A different perspective on the video codec MTI discussion

If it's free, take 2.

CB
> From: Lorenzo Miniero [mailto:[email-masked]<mailto:[email-masked]>]
> To: Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
> Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>> ha scritto:
>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Daryl Malas <[email-masked]>
Date: Thu, 14 Mar 2013 04:18:13 +0000

I would like to add my support to Jonathan's comments.  I have had discussions with multiple cable operators, which are evaluating the potential use cases of deploying webRTC.  The resounding comment is that if webRTC supports H.264, their flexibility to deploy it in the near-term on a number of devices improves dramatically.  If VP8 is the only allowable codec, this will significantly limit the deployment, because the relevant devices out there already support H.264 and not VP8.

In addition, by saying that we will only support a royalty-free codec (VP8), it is effectively saying we will not allow people to pay the necessary license fees (whether new or already realized) at their choosing in order to deploy more webRTC clients and further the overall adoption of webRTC.

Does it really increase the complexity so dramatically by supporting two video codecs that it outweighs the potential for faster adoption and deployment of webRTC?

I also second Jonathan's comments related to, "I applaud your efforts and thank you for them."  This is absolutely valuable from my perspective, and it has great potential for future use.

Regards,

Daryl

From: Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 13, 2013 6:06 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [rtcweb] A different perspective on the video codec MTI discussion

Much of the discussion has been around video quality, IPR, and standardization status. While those are all important factors, to me they are secondary to the core question: how does the choice impact uptake of the webRTC APIs and protocols by developers who build applications ontop of it? In this regard, I would like to suggest that, at this time, adoption of VP8 as MTI will slow down adoption of webRTC by turning off developers that would otherwise embrace it if H.264 were selected.

The reason is simple. For many application developers, what is interesting about webRTC is NOT just browser to browser communications, but connecting users in a browser to users elsewhere - on other devices, in other networks. After all, the vast majority of web application developers do not have the luxury of a massive social graph, or the luxury of their users being parked persistently on their website and thus able to receive an incoming call. Many websites that have customer support or service needs would love to be able to allow their users to have a video call with an agent. However, those agents are probably sitting on existing agent systems which are not web based, and it’s almost certainly true that they do not today support VP8, but rather H.264. Many developers would probably love to connect users on the web with users on mobile apps. Most mobile platforms today support H264 based hardware acceleration for decode and sometimes encode, but not yet VP8. Developers who want to build business communications clients will need to connect those users with other users in the business, who may be using videophones, PC clients, telepresence units or video room systems, the vast majority of which do not support VP8 today, but many of which do support H.264.

The reality is – today’s Internet and IP communications systems are built on H.264. And unless the developer cares only about living within the island of the web browser – a VP8 based solution will simply not meet their requirements.

This may not be true down the road. I applaud Google for working hard (and spending much money no doubt) to secure an RF license for VP8 from these patent holders. I think they should continue pushing and promoting the technology because a  free, high quality video codec would be great for the Internet. But today, it is not the video codec of the Internet. And, given the relatively early days of video, I am sure there will be video codecs after VP8. Maybe H.265, maybe the new video codec being developed here at the IETF. And once those codecs become more broadly implemented and available on the endpoints that matter, we can revise our specs and mandate support for them. But this is not about the web of five years from now, its about the web today. And if we mandate usage of a codec which is not widely implemented in all the endpoints that matter (not just the browser), I fear that it will hold developers back from using webRTC and thus prevent us from ever having the opportunity to add these video codecs in the future.

And so – to the supporters of VP8 – I applaud your efforts and thank you for them. Please continue. And when the industry is ready, we can make VP8 MTI in the browser. But we are not there yet.  I ask you to please put the needs of the developers ahead of your own, and do not hold back webRTC for the benefit of your ideals around an RF and open source video codec. WebRTC is too important for that.

Thx,

Jonathan R.

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

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 13 Mar 2013 21:26:58 -0700

On Wed, Mar 13, 2013 at 9:18 PM, Daryl Malas <[email-masked]> wrote:
> I would like to add my support to Jonathan's comments.  I have had
> discussions with multiple cable operators, which are evaluating the
> potential use cases of deploying webRTC.  The resounding comment is that if
> webRTC supports H.264, their flexibility to deploy it in the near-term on a
> number of devices improves dramatically.  If VP8 is the only allowable
> codec, this will significantly limit the deployment, because the relevant
> devices out there already support H.264 and not VP8.
>

You can negotiate any codec you want
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-3.2

There is now limitation on the number of codecs that you may support.

I hope this helps.

CB

ps.  my position remains that the idea of MTI needs be dropped,
consensus will not be found.  Let the market figure it out.

> In addition, by saying that we will only support a royalty-free codec (VP8),
> it is effectively saying we will not allow people to pay the necessary
> license fees (whether new or already realized) at their choosing in order to
> deploy more webRTC clients and further the overall adoption of webRTC.
>
> Does it really increase the complexity so dramatically by supporting two
> video codecs that it outweighs the potential for faster adoption and
> deployment of webRTC?
>

> I also second Jonathan's comments related to, "I applaud your efforts and
> thank you for them."  This is absolutely valuable from my perspective, and
> it has great potential for future use.
>
> Regards,
>
> Daryl
>
> From: Jonathan Rosenberg <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> are secondary to the core question: how does the choice impact uptake of the
> webRTC APIs and protocols by developers who build applications ontop of it?
> In this regard, I would like to suggest that, at this time, adoption of VP8
> as MTI will slow down adoption of webRTC by turning off developers that
> based, and it’s almost certainly true that they do not today support VP8,
> but rather H.264. Many developers would probably love to connect users on
> the web with users on mobile apps. Most mobile platforms today support H264
> based hardware acceleration for decode and sometimes encode, but not yet
> VP8. Developers who want to build business communications clients will need
> to connect those users with other users in the business, who may be using
> videophones, PC clients, telepresence units or video room systems, the vast
> majority of which do not support VP8 today, but many of which do support
> H.264.
>
> The reality is – today’s Internet and IP communications systems are built on
> H.264. And unless the developer cares only about living within the island of
> the web browser – a VP8 based solution will simply not meet their
> requirements.
>
> that it will hold developers back from using webRTC and thus prevent us from
> ever having the opportunity to add these video codecs in the future.
>
>
>
> And so – to the supporters of VP8 – I applaud your efforts and thank you for
> them. Please continue. And when the industry is ready, we can make VP8 MTI
> in the browser. But we are not there yet.  I ask you to please put the needs
> of the developers ahead of your own, and do not hold back webRTC for the
> benefit of your ideals around an RF and open source video codec. WebRTC is
> too important for that.
>
> systems in the Cisco portfolio, including our video clients and telepresence
> units. Those are all based on H.264. Consequently, much as I would like to
> avoid the need for a plugin, the benefits of eliminating the plugin do not
> outweigh the drawbacks of having to transcode from VP8 to H.264. If IETF
> selects VP8 as the MTI codec, this will make it dramatically more difficult
> and expensive for us to use webRTC. If H.264 is the MIT codec, it will make
> it much easier for us to use webRTC.
>
>
> Thx,
>
> Jonathan R.
>
> --

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Mar 2013 00:42:29 -0400

On 3/14/13 00:18, Daryl Malas wrote:
>  If VP8 is the only allowable codec

We are not having, and will never have, a "mandatory not to implement" 
conversation.

/a

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 12:19:07 +0000

>We are not having, and will never have, a "mandatory not to implement"

Exect that there have been quite many statements by participants saying they will never implement a particular codec regardless of its merits or  benefits to the users, mainly due to IPR/cost reasons. So we do get a bit of that flavor. 

Markus

---

From: Randell Jesup <[email-masked]>
Date: Thu, 14 Mar 2013 08:29:44 -0400

> I’d like to put a different perspective on the video MTI discussion.

Note: I haven't read the whole thread yet, but I'll make a comment 
anyways and read the rest this morning. :-)

> Many developers would probably love to connect users on the web with 
> users on mobile apps. Most mobile platforms today support H264 based 
> hardware acceleration for decode and sometimes encode, but not yet 
> VP8. Developers who want to build business communications clients will 
> need to connect those users with other users in the business, who may 
> be using videophones, PC clients, telepresence units or video room 
> systems, the vast majority of which do not support VP8 today, but many 
> of which do support H.264.

I'll note that (no new arguments here):
a) not all H.264 hardware is good at low-delay coding, or will support 
all the knobs we would like for realtime use
b) software encoding generally uses more power, but WiFi at constant 
send/receive and device displays use a lot of power, such that the 
reduction in talk time for software encoding (at least at lower 
resolutions)
c) existing applications using H.264 variants (i.e. Hangouts) are in 
wide use using software encoding (to the best of my knowledge)

Mobile devices without HW encode may be limited by running out of CPU 
due to resolution & framerate.

-- 
Randell Jesup
[email-masked]

---

From: Ben Strong <[email-masked]>
Date: Thu, 14 Mar 2013 11:24:36 -0500

I've been talking to developers who are interested in building WebRTC apps
regularly for the past year and have drawn the opposite conclusion about
their preferences.

Before going into what they want and why, let me give you a flavor of who
I'm talking to: These are primarily inbound contacts who are interested in
the vLine WebRTC platform. I think they're pretty representative of the
non-legacy use-cases for WebRTC, but almost certainly under-represent the
existing enterprise market.

* Over half are building apps for healthcare or education. I'd say it's a
pretty even split between those categories, and within each category it's a
pretty even split between startups and more established organizations.
Non-profits make up a substantial fraction of both groups.

* Over half are outside the US, with most of the international interest
coming from developing countries (e.g., India, Brazil, and China).

* Not one of them has been interested in enabling video for customer
service calls (though a number have been interested in voice). I mention
this because it's frequently cited as an important use-case and I expected
it to be an important market for us, but I'm beginning to wonder if
businesses actually want this. I'll admit that those who _are_ interested
are more likely to be talking to Jonathan than to me, so take this with a
grain of salt.

* A sampling of other apps people are building: translation services (both
for foreign languages and sign language), social commerce services, and
social apps with all sorts of interesting new interaction models.

Here's what I've heard from them:

* The only questions I have ever gotten about interop with legacy equipment
are in regard to voice. I do occasionally talk to people with existing
investments in video conferencing systems, but they are mostly interested
in moving away from them (huge sample bias here, of course).

* Very rarely does the subject of codecs come up other than the context of
whether the browsers will all interoperate. The only concerns I ever hear
about VP8 quality are from people who haven't actually used WebRTC in
Chrome. The feedback I get from people who have used it is consistently
that they are surprised by how good the video quality is.

* All of them care about having a good mobile experience and
do occasionally express concerns about the battery life and performance
impact of software codecs.

* _Everyone_ is concerned about cross-browser interoperability. It is far
and away the biggest concern I hear about WebRTC, and I can't remember the
last time it didn't come up in a conversation with a customer.

Finally, here's my take on it all:

>From a power and performance point of view, H.264 is undoubtedly a better
option on devices with a hardware codec for it. Implementations on those
devices should by all means support it and attempt to negotiate it.
Implementations on other platforms where it is feasible to support it,
either because the implementation vendor has a license or the OS includes
it, should by all means support it as well, for the sake of allowing mobile
devices with a hardware codec to use it whenever possible.

I'm happy to grant that H.264 is technically superior to VP8 in every way
(though I think the differences are negligible in real-world use). By all
means implementations that wish to should attempt to negotiate it for that
reason, as well.

However, I fail to see how either one of those points has any bearing on
the MTI decision. The whole point of MTI is guaranteed interoperability
across all WebRTC implementations, which is absolutely critical to WebRTC
adoption. The only criteria should be the best quality codec which can be
supported by all implementations. And because some implementations are open
source, it absolutely must be royalty free.

I've already gone on too long here, but I want to make one final point on
open source. There are two new mobile platforms that have the potential to
drive innovation around mobile apps in general and the mobile web in
particular, and both are open source: FirefoxOS and Ubuntu Mobile. Neither
will be able to be WebRTC compatible unless a royalty-free codec is chosen.

I would argue that FirefoxOS and Ubuntu should be of special concern to the
working group for three reasons: 1) They support web apps as first class
citizens. Since the main goal of WebRTC is to make it possible to build
rich apps entirely with web technologies, I would hope that the innovators
in that arena will be able to support it. 2) I expect that some of the
areas where WebRTC will have the biggest impact (e.g., telemedicine in
rural India) will be most concerned about using a low-cost, open source
platform. 3) Even without every being market-share leaders, open source
platforms tend to drive innovation across the whole market. The best
example of this is how Firefox kickstarted a decade of innovation in
browsers and web apps. I have high hopes that FirefoxOS will do the same.

Adopting a codec that will more firmly entrench legacy providers at the
expense of some of the most innovative new platforms out there seems like a
bad trade-off to me.

Ben

[this post will probably need moderator approval, so apologies if it shows
up after the conversation has moved on]

--
Ben Strong
[email-masked]

---

From: David Singer <[email-masked]>
Date: Thu, 14 Mar 2013 09:44:14 -0700

On Mar 14, 2013, at 9:24 , Ben Strong <[email-masked]> wrote:

> However, I fail to see how either one of those points has any bearing on the MTI decision. The whole point of MTI is guaranteed interoperability across all WebRTC implementations, which is absolutely critical to WebRTC adoption. The only criteria should be the best quality codec which can be supported by all implementations. And because some implementations are open source, it absolutely must be royalty free.

I think you make a key point here; making a mandate that doesn't have consensus is empty, as if (for example) companies are forced to choose between formally complying with the mandate, or taking on excessive risk, they'll probably be risk-averse. Or a mandate that carries a license fee will be ignored by those who don't pay such fees on principle.

We all need a decision we can all stand behind, and we're making progress to that goal, and I appreciate all the data and efforts.  There is some very important data (notably, the names of the 11 and the resulting license) which is promised to be available in only a few weeks. Let's not decide in haste (and possibly repent at leisure).

By the way, open-source and license fees are not in direct conflict; it's the principles that are.  To pick a directly-relevant example, there are open-source implementations of H.264 (AVC).

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 14 Mar 2013 13:18:49 -0400

On 03/14/2013 12:44 PM, David Singer wrote:
> By the way, open-source and license fees are not in direct conflict;
> it's the principles that are. To pick a directly-relevant example,
> there are open-source implementations of H.264 (AVC).  
This is skirting the issue by using the vague term "open-source" in a
way that illustrates the discrepancy of the argument.  For this purpose,
it is important to outline the main argument against the usage of H.264
(AVC) in terms of the free software definition, which can be found here:
https://www.gnu.org/philosophy/free-sw.html
>
> A program is free software if the program's users have the four
> essential freedoms:
>
>   * The freedom to run the program, for any purpose (freedom 0).
>   * The freedom to study how the program works, and change it so it
>     does your computing as you wish (freedom 1). Access to the source
>     code is a precondition for this.
>   * The freedom to redistribute copies so you can help your neighbor
>     (freedom 2).
>   * The freedom to distribute copies of your modified versions to
>     others (freedom 3). By doing this you can give the whole community
>     a chance to benefit from your changes. Access to the source code
>     is a precondition for this.
>
*Requiring* a license fee to allow one or more of these points would
directly intervene in that freedom being available without restriction,
and thus, would prevent the implementation from being free software
according to the above definition.  Though I am not as familiar with
OSI's Open Source Definition (http://opensource.org/osd-annotated), a
cursory reading also indicates that a *requirement* of a license fee
would, by necessity, exclude it from fitting the open source definition
as well.

MPEG-LA's licensing structure for H.264 is strange in that it is a
license for /end-users/, meaning, such as the people that finally use a
product (e.g., the web browser him/herself).  So, the producers of the
software may themselves not require a license, but their users would. 
This is the issue by which a *required* licensing fee (which, due to
encumbrance by patents, is legally binding at this time by choice of the
owners of said patents in many jurisdictions) excludes something from
being free, open source software in this situation.

I talked about this with direct answers from the MPEG-LA here:
http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/

The point you make above is, apparently, talking from the perspective of
software producers.  Free software advocates always talk from the
perspective of the *users*, which includes software producers that use
other free software.  The blurring of the meaning of the term
open-source to imply only the software developers/producers is why many
prefer the term free software to this date.

The conclusion of this is that, yes, actually, licensing fee and
open-source (and also free) software are in direct conflict, by
definition.  The fact that some software is released under an
open-source license does not mean all users of that software have access
to it under the conditions of that license.

-- 
Libre Video
http://librevideo.org

---

From: David Singer <[email-masked]>
Date: Thu, 14 Mar 2013 10:30:32 -0700

On Mar 14, 2013, at 10:18 , Basil Mohamed Gohar <[email-masked]> wrote:

> way that illustrates the discrepancy of the argument.  

I think you'll see that in general I agree with you, in that I said it was principles other than simply open-source that were at work here; you work it out in more detail, to be sure.  (It wasn't me that used the term initially.)

David Singer

---

From: Monty Montgomery <[email-masked]>
Date: Thu, 14 Mar 2013 13:37:22 -0400

> To pick a directly-relevant example, there are open-source implementations of H.264 (AVC).

Also directly relevant, I'm not allowed to use these implementations
without negotiating a license which MPEG LA will not sell me.  The
restriction/control element is more important than the money.

It's clear by inference that Ben was speaking of fully FOSS software.

Monty
Xiph.Org

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 14 Mar 2013 17:39:03 +0000

> http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/

Interesting - I hadn't realized their license was as viral to 'derivative' works as GPLv3.

So does this mean if a mobile phone vendor had the license for H.264 in their hardware encoder/decoder, and provided an API to applications to use that hardware, that any application using the API would also be a new end-product and have to acquire the license as well?

Likewise, if a web-based app framework such as PhoneGap/Titanium/etc. acquired a license for H.264 and provided an API for using it to their customers'(the app creators) code, that their customers (the app creators) would also need to get the license?

-hadriel

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 14 Mar 2013 18:55:51 +0100

Il giorno Thu, 14 Mar 2013 17:39:03 +0000
Hadriel Kaplan <[email-masked]> ha scritto:

> 
> On Mar 14, 2013, at 1:18 PM, Basil Mohamed Gohar
> <[email-masked]> wrote:
> 
> So does this mean if a mobile phone vendor had the license for H.264
> in their hardware encoder/decoder, and provided an API to
> applications to use that hardware, that any application using the API
> would also be a new end-product and have to acquire the license as
> well?
> 
> Likewise, if a web-based app framework such as PhoneGap/Titanium/etc.
> acquired a license for H.264 and provided an API for using it to
> their customers'(the app creators) code, that their customers (the
> app creators) would also need to get the license?
> 
> -hadriel
> 

This is indeed an interesting read, thanks Basil for sharing this.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 14 Mar 2013 14:03:50 -0400

> Likewise, if a web-based app framework such as PhoneGap/Titanium/etc. acquired a license for H.264 and provided an API for using it to their customers'(the app creators) code, that their customers…
Hadriel,

If you read the documentation that comes with your, for example, AVCHD
camcorder, you'll see that the licensee (the hardware manufacturer) can
give to their users is a private, non-commericial license to the usage
of the encoded media produced by it.  Windows users, as well, are
granted a license via Microsoft to the usage of the decoder shipped with
the OS for the same limited usages.  Commercial usages beyond this would
seem to require an additional license (e.g., a paid performance where an
H.264 video is played on a Windows machine, perhaps?).

I don't know what to say about the other issues you've raised.  IANAL
and such. :)  Such questions may be directed to MPEG-LA.

-- 
Libre Video
http://librevideo.org

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 14 Mar 2013 14:06:46 -0400

> Interesting - I hadn't realized their license was as viral to 'derivative' works as GPLv3.
I forgot to point out in my last reply that the observation I made about
CC-licensed material might not be completely sound, from a legal
standpoint.  The confusion, however, is definitely present, but the
point is that that case may not be present.  Your license via CC
basically doesn't overlap with the need for licensing.  If I can find
the relevant text about that, I will try to share it and/or post again
on the blog.

-- 
Libre Video
http://librevideo.org

---

From: Roman Shpount <[email-masked]>
Date: Thu, 14 Mar 2013 14:11:53 -0400

One thing that was not clear for me from your blog was if an application
running on Windows OS and using OS provided API for H.264 playback is
licensed to do so.
_____________
Roman Shpount

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 14 Mar 2013 15:08:21 -0400

On 03/14/2013 02:11 PM, Roman Shpount wrote:
> One thing that was not clear for me from your blog was if an
> application running on Windows OS and using OS provided API for H.264
> playback is licensed to do so.
Roman,

I again have to put out there *very clearly* that I am not a lawyer.  I
can only take some clear statements I've been given and/or read and
present them together.  But the license that Microsoft provides their
users as stated in the manual is a private, non-commercial license.  So,
if the usage fits those definitions, it seems to be the case.  The
attorney from MPEG-LA made clear that their licensing is for end-user
products.  That's why someone can write an H.264 decoder or encoder, and
ship it without much problem, but it's the *users* of said
decoder/encoder that would face the licensing question.

Does that make sense?  This is what I mean by the licensing being
somewhat odd.  It's totally not a problem (maybe not *totally*, but I
hope you get the idea) for software producers.  It's *totally* a problem
for the users.

It's a shame that people like me, who do not have any real legal
background, and the ones having to explain this, and people that
actually know better are either not speaking about it or are not being
heard.  The problems posed by H.264 licensing for users, and thus the
free software community, are very severe and confusing.

-- 
Libre Video
http://librevideo.org

---

From: Ben Strong <[email-masked]>
Date: Thu, 14 Mar 2013 14:44:55 -0500

> It's clear by inference that Ben was speaking of fully FOSS software.

Thanks for clarifying. That's what I should have said. Let me try to say
the whole thing more briefly:

Choosing H.264 means that there will be no standards-compliant FOSS
implementations. So to any argument for H.264, you can tack on "which is
more important that having FOSS implementations".

Real developers (at least the ones I talk to) care a lot about the
practical interoperability problems this will cause. They care _more_ about
this than they care about most of the other arguments that come up. And
they are much more concerned about interoperability among browsers than
between browsers and legacy equipment.

Ben

---

From: Mark Weidick <[email-masked]>
Date: Thu, 14 Mar 2013 13:11:28 -0800

+1
Ben has this right based on our in market experience to make a commercially
viable service based on WebRTC - and we can corroborate his analysis with
real data.  

We have more than 1,000 businesses using our reference application and
dozens of companies have used our APIs to embed WebRTC based video within
their applications.  They care most about 1) working in the browser of their
choice, so cross-browser interop in Ben's words, 2) mobile and 3) cost.

Based on our real world interaction and across each of the use cases that
Ben highlights, interop with legacy endpoints isn't even on the radar.  In
fact, with increasing frequency we encounter video "room systems" that
consist of a flat panel display, a webcam, a PC/Mac and a browser that can
run a WebRTC app.  The so-called legacy endpoints seem to be going to zero
in terms of relevancy.

Mark

From:  Ben Strong <[email-masked]>
Date:  Thu, 14 Mar 2013 11:24:36 -0500
To:  "[email-masked]" <[email-masked]>
Subject:  Re: [rtcweb] A different perspective on the video codec MTI
discussion

* Not one of them has been interested in enabling video for customer service
calls (though a number have been interested in voice). I mention this
because it's frequently cited as an important use-case and I expected it to
be an important market for us, but I'm beginning to wonder if businesses
actually want this. I'll admit that those who _are_ interested are more
likely to be talking to Jonathan than to me, so take this with a grain of
salt.

* The only questions I have ever gotten about interop with legacy equipment
are in regard to voice. I do occasionally talk to people with existing
investments in video conferencing systems, but they are mostly interested in
moving away from them (huge sample bias here, of course).

* Very rarely does the subject of codecs come up other than the context of
whether the browsers will all interoperate. The only concerns I ever hear
about VP8 quality are from people who haven't actually used WebRTC in
Chrome. The feedback I get from people who have used it is consistently that
they are surprised by how good the video quality is.

* All of them care about having a good mobile experience and do occasionally
express concerns about the battery life and performance impact of software
codecs.

However, I fail to see how either one of those points has any bearing on the
MTI decision. The whole point of MTI is guaranteed interoperability across
all WebRTC implementations, which is absolutely critical to WebRTC adoption.
The only criteria should be the best quality codec which can be supported by
all implementations. And because some implementations are open source, it
absolutely must be royalty free.

I would argue that FirefoxOS and Ubuntu should be of special concern to the
working group for three reasons: 1) They support web apps as first class
citizens. Since the main goal of WebRTC is to make it possible to build rich
apps entirely with web technologies, I would hope that the innovators in
that arena will be able to support it. 2) I expect that some of the areas
where WebRTC will have the biggest impact (e.g., telemedicine in rural
India) will be most concerned about using a low-cost, open source platform.
3) Even without every being market-share leaders, open source platforms tend
to drive innovation across the whole market. The best example of this is how
Firefox kickstarted a decade of innovation in browsers and web apps. I have
high hopes that FirefoxOS will do the same.

Ben

--
Ben Strong
[email-masked]

On Wed, Mar 13, 2013 at 5:06 PM, Jonathan Rosenberg <[email-masked]>
wrote:
> I¹d like to put a different perspective on the video MTI discussion.
> 
> Much of the discussion has been around video quality, IPR, and standardization
> status. While those are all important factors, to me they are secondary to the
> core question: how does the choice impact uptake of the webRTC APIs and
> protocols by developers who build applications ontop of it? In this regard, I
> would like to suggest that, at this time, adoption of VP8 as MTI will slow
> down adoption of webRTC by turning off developers that would otherwise embrace
> it if H.264 were selected.
> 
> persistently on their website and thus able to receive an incoming call. Many
> websites that have customer support or service needs would love to be able to
> allow their users to have a video call with an agent. However, those agents
> are probably sitting on existing agent systems which are not web based, and
> it¹s almost certainly true that they do not today support VP8, but rather
> H.264. Many developers would probably love to connect users on the web with
> users on mobile apps. Most mobile platforms today support H264 based hardware
> acceleration for decode and sometimes encode, but not yet VP8. Developers who
> want to build business communications clients will need to connect those users
> with other users in the business, who may be using videophones, PC clients,
> telepresence units or video room systems, the vast majority of which do not
> support VP8 today, but many of which do support H.264.
> 
> The reality is  today¹s Internet and IP communications systems are built on
> the web browser  a VP8 based solution will simply not meet their
> requirements.
> 
> Internet. But today, it is not the video codec of the Internet. And, given the
> relatively early days of video, I am sure there will be video codecs after
> VP8. Maybe H.265, maybe the new video codec being developed here at the IETF.
> And once those codecs become more broadly implemented and available on the
> endpoints that matter, we can revise our specs and mandate support for them.
> But this is not about the web of five years from now, its about the web today.
> And if we mandate usage of a codec which is not widely implemented in all the
> endpoints that matter (not just the browser), I fear that it will hold
> developers back from using webRTC and thus prevent us from ever having the
> opportunity to add these video codecs in the future.
> 
>  
> 
> And so  to the supporters of VP8  I applaud your efforts and thank you for
> them. Please continue. And when the industry is ready, we can make VP8 MTI in
> the browser. But we are not there yet.  I ask you to please put the needs of
> the developers ahead of your own, and do not hold back webRTC for the benefit
> of your ideals around an RF and open source video codec. WebRTC is too
> important for that.
> 
> first services to do voice and video on the web, using plugins of course. For
> our business, a key requirement is interoperability with other video systems
> in the Cisco portfolio, including our video clients and telepresence units.
> Those are all based on H.264. Consequently, much as I would like to avoid the
> need for a plugin, the benefits of eliminating the plugin do not outweigh the
> drawbacks of having to transcode from VP8 to H.264. If IETF selects VP8 as the
> MTI codec, this will make it dramatically more difficult and expensive for us
> to use webRTC. If H.264 is the MIT codec, it will make it much easier for us
> to use webRTC. 
> 
> 
> 
> Thx,
> 
> Jonathan R.
> -- 

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

---

From: Chris Wendt <[email-masked]>
Date: Thu, 14 Mar 2013 18:41:09 -0400

As mostly an observer over the past year or two, this issue of MTI has come a long way, both good and bad.  

First, I will state, my employer, Comcast, has millions of boxes deployed and more in the pipeline where one could imagine webrtc capabilities being utilized.  
Short term, VP8 does pose us the most challenge in terms of either suboptimal or total lack of support because of limited cpu/gpu capabilities, etc. 
Longer term, this would be less of an issue, certainly, but perhaps in that time frame we will be talking the virtue of a brand new set of codecs anyway.

In terms of quality per bit/cpu/transistor, I believe nobody can credibly say that either codec is a horrible choice.  To me, any further argument or quantitative/perceptual testing on that is wasting time.

IPR, I'm not going to comment, because the clarity of the IPR situation is in the eye of the beholder.

While it would be wonderful if everybody agreed on a single video codec, I don't see any possibility that one can satisfy all use-cases in any practical way.  Whether it's browser to browser or browser to terminal, one can argue that her use-case is more valuable than the other, but we can't all agree on that either.

To me, the only choice left, and I think many others agree and some have stated it already, is either to make both codecs MTI or remove the MTI requirement.  The former, likely would take an act of God and for various reasons I don't think is the right choice anyway.  So, I would strongly encourage the latter, in full acknowledgement that there have been decisions made against this.  
(ASCII codec being a third choice, but I haven't seen the draft )
Note, regardless of either choice, we would likely be required to implement both codecs anyway to avoid the transcoding penalty if we want to reasonably support interoperability.

In the end, we currently sit in the likely position that the market will decide this debate anyway, it already seems to be underway, so why keep wasting time debating.  Besides being a complete waste of valuable brain cycles, and delaying more important work to resolve, I think it has become or is close to becoming much more destructive to the process than the value of having a half-supported, forced choice MTI codec.

-Chris

---

From: Erik Lagerway <[email-masked]>
Date: Thu, 14 Mar 2013 17:17:36 -0700

+1

Well said Chris, this is pretty much what I wrote earlier today...
http://blog.webrtc.is/2013/03/14/rtcweb-webrtc-mti-video-codec-debate-continues/

The WG has been through this debate many times and it seems rather obvious
that this is not likely to get resolved anytime soon.

Let's remove the MTI video codec requirement now and get on with life.

/Erik
****

On Thu, Mar 14, 2013 at 3:41 PM, Chris Wendt <[email-masked]> wrote:

> First, I will state, my employer, Comcast, has millions of boxes deployed
> and more in the pipeline where one could imagine webrtc capabilities being
> utilized.
> Short term, VP8 does pose us the most challenge in terms of either
> suboptimal or total lack of support because of limited cpu/gpu
> capabilities, etc.
> Longer term, this would be less of an issue, certainly, but perhaps in
> that time frame we will be talking the virtue of a brand new set of codecs
> anyway.
>
> In terms of quality per bit/cpu/transistor, I believe nobody can credibly
> say that either codec is a horrible choice.  To me, any further argument or
> quantitative/perceptual testing on that is wasting time.
>
> While it would be wonderful if everybody agreed on a single video codec, I
> don't see any possibility that one can satisfy all use-cases in any
> practical way.  Whether it's browser to browser or browser to terminal, one
> can argue that her use-case is more valuable than the other, but we can't
> all agree on that either.
>
> To me, the only choice left, and I think many others agree and some have
> stated it already, is either to make both codecs MTI or remove the MTI
> requirement.  The former, likely would take an act of God and for various
> reasons I don't think is the right choice anyway.  So, I would strongly
> encourage the latter, in full acknowledgement that there have been
> decisions made against this.
> Note, regardless of either choice, we would likely be required to
> implement both codecs anyway to avoid the transcoding penalty if we want to
> reasonably support interoperability.
>
> In the end, we currently sit in the likely position that the market will
> decide this debate anyway, it already seems to be underway, so why keep
> wasting time debating.  Besides being a complete waste of valuable brain
> cycles, and delaying more important work to resolve, I think it has become
> or is close to becoming much more destructive to the process than the value
> of having a half-supported, forced choice MTI codec.
>
> -Chris
>
>

---

From: Daryl Malas <[email-masked]>
Date: Fri, 15 Mar 2013 15:41:37 +0000

+1 to both Chris and Erik's follow-up.

--Daryl

From: Erik Lagerway <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 14, 2013 8:17 PM
To: Chris Wendt <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] A different perspective on the video codec MTI discussion

+1

The WG has been through this debate many times and it seems rather obvious that this is not likely to get resolved anytime soon.

/Erik

On Thu, Mar 14, 2013 at 3:41 PM, Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:
As mostly an observer over the past year or two, this issue of MTI has come a long way, both good and bad.

-Chris

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 15 Mar 2013 19:31:15 +0100

On 03/14/2013 05:18 AM, Daryl Malas wrote:
> potential use cases of deploying webRTC.  The resounding comment is 
> that if webRTC supports H.264, their flexibility to deploy it in the 
> near-term on a number of devices improves dramatically.  If VP8 is the 
> only allowable codec, this will significantly limit the deployment, 
> because the relevant devices out there already support H.264 and not VP8.
Repeat message: There will never be a restriction on additional codecs.
It's a business decision by product vendors which codecs they offer in 
addition to the MTI.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 15 Mar 2013 19:37:32 +0100

At a very high level, I find this line of argument puzzling.
I understand a lot of the details presented, but not this line....

"when the industry is ready, we can make VP8 MTI in the browser."

We live in a growing market.

When we have a growing market, and are intending to do a change, we 
always have a choice between early and late change.

The later we leave the change, the more devices there will be out there 
with "before-the-change" technology deployed.

If we think the switch to VP8 makes sense at any time in the future, 
it's less expensive to start the switch now than to start the switch later.

              Harald

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 26 Mar 2013 13:51:43 +0900

> and such. :)  Such questions may be directed to MPEG-LA.

I'm not a lawyer either, never was, and never plan to be. The above is 
probably an appropriate explanation of the license as intended by the 
licencers.

But I'm wondering whether such a licence would actually hold tight when 
considering patent exhaustion (first sale). Under patent exhaustion, it 
seems impossible to e.g. sell patented bottle openers but restrict their 
use to home use, in exclusion to commercial use (e.g. in a restaurant or 
bar). What is it that would allow such distinctions for cameras but not 
for bottle openers and the like? Or is it just that nobody yet has 
brought a case before a court?

Just wondering aloud.

Regards,   Martin.