Subject: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees

From: "Jonathan Rosenberg (jdrosen)" <[email-masked]>
Date: Wed, 30 Oct 2013 12:28:50 +0000

I'd like to make an announcement material to the conversations around MTI video codecs in rtcweb.

Cisco is announcing today that we will take our H.264 implementation, and open source it under BSD license terms. Development and maintenance will be overseen by a board from industry and the open source community.  Furthermore, we will provide a binary form suitable for inclusion in applications across a number of different operating systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and make this binary module available for download from the Internet. We will not pass on our MPEG-LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use on supported platforms.

We believe that this contribution to the community can help address the concerns many have raised around selection of H.264 as MTI. I firmly believe that with H.264 we can achieve maximal interoperability and now, do it with open source and for free (well, at least for others - its not free for Cisco :))
More information on the open source project can be found at http://www.openh264.org, which is sparse now but more coming soon.

Thx,
Jonathan R.

--
Jonathan Rosenberg, PhD
VP, CTO Collaboration
Cisco Systems
[email-masked]

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 30 Oct 2013 14:20:47 +0100

Thanks for this surprise! 

Hope that it will result in that we can keep codecs in the endpoints and can
avoid video transcoding in gateways.

/Karl

 

Från: [email-masked] [mailto:[email-masked]] För Jonathan
Rosenberg (jdrosen)
Skickat: den 30 oktober 2013 13:29
Till: [email-masked]
Ämne: [rtcweb] Cisco to open source its H.264 implementation and absorb
MPEG-LA licensing fees

I’d like to make an announcement material to the conversations around MTI
video codecs in rtcweb.

Cisco is announcing today that we will take our H.264 implementation, and
open source it under BSD license terms. Development and maintenance will be
overseen by a board from industry and the open source community.
Furthermore, we will provide a binary form suitable for inclusion in
applications across a number of different operating systems (Windows, MacOS,
Linux x86, Linux ARM and Android ARM), and make this binary module available
for download from the Internet. We will not pass on our MPEG-LA licensing
costs for this module, and based on the current licensing environment, this
will effectively make H.264 free for use on supported platforms. 

We believe that this contribution to the community can help address the
concerns many have raised around selection of H.264 as MTI. I firmly believe
that with H.264 we can achieve maximal interoperability and now, do it with
open source and for free (well, at least for others – its not free for Cisco
J)

More information on the open source project can be found at
http://www.openh264.org, which is sparse now but more coming soon.

Thx,

Jonathan R.

--

Jonathan Rosenberg, PhD

VP, CTO Collaboration

Cisco Systems

[email-masked]

---

From: Leon Geyser <[email-masked]>
Date: Wed, 30 Oct 2013 15:43:23 +0200

Great news.

I see this in the Q/A:
*Q. iOS is noticeably absent from the list of platforms. Why is that?*
A: Unfortunately, iOS does not allow for applications to fetch and install
modules from the Internet once that application has been installed on the
device. Consequently, it is simply not feasible for us to provide a
distribution at this time.
--
Does the same apply to other platforms like Windows Phone 7/8, Windows RT?
Also if we want to use the module on a different platform not listed by you
and that allow fetch+install can we ask for the module to be compiled?

On 30 October 2013 15:20, Karl Stahl <[email-masked]> wrote:

> Thanks for this surprise! ****
>
> ** **
>
> Hope that it will result in that we can keep codecs in the endpoints and
> can avoid video transcoding in gateways.****
>
> ** **
>
> /Karl****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *Från:* [email-masked] [mailto:[email-masked]] *För *Jonathan
> Rosenberg (jdrosen)
> *Skickat:* den 30 oktober 2013 13:29
> *Till:* [email-masked]
> *Ämne:* [rtcweb] Cisco to open source its H.264 implementation and absorb
> MPEG-LA licensing fees****
>
> ** **
>
> video codecs in rtcweb.****
>
> ** **
>
> applications across a number of different operating systems (Windows,
> MacOS, Linux x86, Linux ARM and Android ARM), and make this binary module
> available for download from the Internet. We will not pass on our MPEG-LA
> licensing costs for this module, and based on the current licensing
> environment, this will effectively make H.264 free for use on supported
> platforms. ****
>
> ** **
>
> concerns many have raised around selection of H.264 as MTI. I firmly
> believe that with H.264 we can achieve maximal interoperability and now, do
> it with open source and for free (well, at least for others – its not free
> for Cisco J)****
>
> http://www.openh264.org, which is sparse now but more coming soon.****
>
> ** **
>
> ** **
>
> Thx,****
>
> Jonathan R.****
>
> ** **
>
> --****
>
> Jonathan Rosenberg, PhD****
>
> VP, CTO Collaboration****
>
> Cisco Systems****
>
> [email-masked]****
>
> ** **
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Oct 2013 10:08:13 -0400

One of the reasons we're open sourcing it is so that interested parties
could build the module for other platforms. So, yes. If the platform allows
for fetch+install the community can build for that and Cisco will not pass
on any MPEG-LA licensing costs for applications on that platform.

I believe neither WinRT nor Winphone 7/8 allow for apps to fetch/install so
that the fetch+install model won't work there.

On Wed, Oct 30, 2013 at 9:43 AM, Leon Geyser <[email-masked]> wrote:

> Also if we want to use the module on a different platform not listed by
> you and that allow fetch+install can we ask for the module to be compiled?
>
>
>> *Ämne:* [rtcweb] Cisco to open source its H.264 implementation and
>> absorb MPEG-LA licensing fees****
>>
>> ** **
>>

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

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 30 Oct 2013 08:13:56 -0700

> on any MPEG-LA licensing costs for applications on that platform.

You keep using the phrase "Cisco will not pass on any MPEG-LA licensing
costs for applications" in a careful way, which I'm sure you have to for
legal reasons, but it does leave some of us wondering what it really means.

As a specific example, what about a Linux distribution?   I think it's
clear that  Debian, for example, cannot make this source code part of their
distribution because of the patent implications.  Are you suggesting that a
linux distribution could take the Cisco source code, compile their own
binary module, and host it on Cisco servers as a way to distribute h264
functionality that avoids the need to pay the MPEG-LA?  You seem to be
implying that, but not outright saying it.

>> A: Unfortunately, iOS does not allow for applications to fetch and
>> install modules from the Internet once that application has been installed
>> on the device. Consequently, it is simply not feasible for us to provide a
>>> I’d like to make an announcement material to the conversations around
>>> MTI video codecs in rtcweb.****
>>>
>>> ** **
>>>
>>> Cisco is announcing today that we will take our H.264 implementation,
>>> and open source it under BSD license terms. Development and maintenance
>>> will be overseen by a board from industry and the open source community.

---

From: Matt Fredrickson <[email-masked]>
Date: Wed, 30 Oct 2013 10:20:18 -0500

Does this mean that system information (for systems that this is installed
on) may be tracked and sent back to the Cisco servers for accurate license
usage count?  (ethernet MAC address, or some other system specific info) so
that redownloads of modules on the same system are not counted towards your
license usage accounting?

Matthew Fredrickson

On Wed, Oct 30, 2013 at 9:08 AM, Jonathan Rosenberg <[email-masked]>wrote:

> I believe neither WinRT nor Winphone 7/8 allow for apps to fetch/install
> so that the fetch+install model won't work there.
>
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Oct 2013 10:37:01 -0500

On 10/30/13 10:13, Peter Thatcher wrote:
> clear that  Debian, for example, cannot make this source code part of 
> their distribution because of the patent implications.  Are you 
> suggesting that a linux distribution could take the Cisco source code, 
> compile their own binary module, and host it on Cisco servers as a way 
> to distribute h264 functionality that avoids the need to pay the MPEG-LA?

I think you're looking for the third, fourth, and fifth questions on 
this page: http://www.openh264.org/faq.html

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Oct 2013 10:41:27 -0500

On 10/30/13 10:20, Matt Fredrickson wrote:
> Does this mean that system information (for systems that this is 
> installed on) may be tracked and sent back to the Cisco servers for 
> accurate license usage count?  (ethernet MAC address, or some other 
> system specific info) so that redownloads of modules on the same 
> system are not counted towards your license usage accounting?

My understanding is that MPEG-LA has a per-organization royalty cap for 
H.264 (13 MUSD, if my memory serves), and that Cisco reaches that cap 
quite easily with their own products.

/a

---

From: Ted Hardie <[email-masked]>
Date: Wed, 30 Oct 2013 08:44:08 -0700

Dr. Rosenberg, it's always good to have your contributions.

Thanks for today's announcement; I have a couple of questions.

In March, Cullen announced that Cisco would open source an H.264
implementation if the working group selected H.264 as the MTI.  I assume
that today's announcement is a follow-on to that intention, removing the
requirement for H.264 to be the MTI for this generous gift, since there is
no similar requirement in your statement.  Is that correct?  This will
remain available even in the case some other codec is selected as MTI?

The web site and your announcement say H.264, without naming specific
profiles.  Will the details of which will be included come when the source
code is available?  Do you have a timeline for when the source code might
become available?  Since the board will also name supported platforms, can
you give a timeline for when they might be disclosed?

The current announcement describes this as a single donation, but my read
is that it is really two, in that someone may *either* have the source code
under BSD license term* or* they may have the downloadable module with
Cisco paying the MPEG-LA license fees, but that these offers cannot be
combined.  This is based on my reading of this question and answer:

*Q. Why is Cisco making both source and binary versions available?*
A: The source code is available so that an implementation of H.264 is
available for the community to use across any project, and to leverage the
community to make the codec better for all. We will select licensing terms
that allow for this code to be used in commercial products as well as open
source projects. In order for Cisco to be responsible for the MPEG LA
licensing royalties for the module, Cisco must provide the packaging and
distribution of this code in a binary module format (think of it like a
plug-in, but not using the same APIs as existing plugins), in addition to
several other constraints. This gives the community the best of all worlds
- a team can choose to use the source code, in which case the team is
responsible for paying all applicable license fees, or the team can use the
binary module distributed by Cisco, in which case Cisco will cover the MPEG
LA licensing fees.

Can you confirm that understanding?  If so, I have to note that I find the
phrase "best of all worlds" a bit hyperbolic--a technology license that
applied to all implementations would seem a bit better.  This may, of
course, be the best of all worlds available to H.264.  I also note, by the
way, that your announcement says BSD license, but this Q & A discuss this
as if the licensing terms were still undefined.  Can you confirm that the
license is BSD and update the FAQ?

I also read it to say that Cisco will not indemnify users of either the
source code or module against other patent holder's assertions of license,
based on this question and answer:

*Q: Is Cisco guaranteeing that it will pay other licensing fees for H.264,
should additional patent holders assert claims in the future?
*A: Cisco is providing no such guarantee. We are only covering the
royalties that would apply to the binary module under MPEG LA's AVC/H.264
patent pool.

This seems quite clear to me, but I would appreciate your confirming it on
the list.

Many thanks again for your contribution,

regards,

Ted Hardie

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 30 Oct 2013 16:47:16 +0100

Il giorno Wed, 30 Oct 2013 10:41:27 -0500
Adam Roach <[email-masked]> ha scritto:

> My understanding is that MPEG-LA has a per-organization royalty cap
> for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that
> cap quite easily with their own products.
> 
> /a

Which doesn't preclude the fact the module may do tracking anyway.

Lorenzo

---

From: Matt Fredrickson <[email-masked]>
Date: Wed, 30 Oct 2013 10:48:17 -0500

> you give a timeline for when they might be disclosed?

I think the FAQ said the baseline profile will be initially included.

Matthew Fredrickson

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Oct 2013 10:50:06 -0500

On 10/30/13 10:44, Ted Hardie wrote:
> profiles.  Will the details of which will be included come when the 
> source code is available?

You seem to have found the FAQ, but not read all the way to the bottom:

*Q. Which profiles of H.264 will be supported?*
A: The initial code has the baseline profile. We look forward to working 
with the open source community to add high profile and others.

> Do you have a timeline for when the source code might become available?

Or the top:

*Q. When will the H.264 source code and binary module be available?*
A: Shortly, Cisco will form a governance board for the open source 
initiative, establish the project, and make the source code and binary 
module available for download. We will move quickly to carry out these 
steps, but past experience suggests that it will take a few months 
before the entire process is complete.

/a

---

From: Ethan Hugg <[email-masked]>
Date: Wed, 30 Oct 2013 08:52:12 -0700

Lorenzo,

You will be able to inspect the source yourself for nefarious things like
tracking as the code will be freely available.

-EH

---

From: Monty Montgomery <[email-masked]>
Date: Wed, 30 Oct 2013 11:53:12 -0400

I have been informed by several people that the $13M cap mentioned in
my blog post is wrong.  The licensing math is different from the older
MPEG codecs, and the correct number is $65.M until 2015.  I corrected
my post to reflect this.

On Wed, Oct 30, 2013 at 11:41 AM, Adam Roach <[email-masked]> wrote:
> H.264 (13 MUSD, if my memory serves), and that Cisco reaches that cap quite
> easily with their own products.
>
> /a
>

---

From: Monty Montgomery <[email-masked]>
Date: Wed, 30 Oct 2013 11:54:49 -0400

Argh, $6.5M!

[I don't want to substitute conviction for truth.  I do wish I could
substitute conviction for sleep.]

Monty

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 30 Oct 2013 16:54:45 +0100

Il giorno Wed, 30 Oct 2013 08:52:12 -0700
Ethan Hugg <[email-masked]> ha scritto:

> Lorenzo,
> 
> You will be able to inspect the source yourself for nefarious things
> like tracking as the code will be freely available.
> 
> -EH
> 

Considering we're to choose between either the source code (paying
licence fees ourselves) or a binary module (free as a bird) I hope I'm
allowed to have my doubts.

Lorenzo

> > > > installed on) may be tracked and sent back to the Cisco servers
> > > > for accurate license usage count?  (ethernet MAC address, or
> > > > some other system specific info) so that redownloads of modules
> > > > on the same system are not counted towards your license usage
> > > > accounting?
> > >
> > > My understanding is that MPEG-LA has a per-organization royalty
> > > cap for H.264 (13 MUSD, if my memory serves), and that Cisco
> > > reaches that cap quite easily with their own products.
> > >
> > > /a
> >
> >

---

From: Max Jonas Werner <[email-masked]>
Date: Wed, 30 Oct 2013 16:55:16 +0100

> tracking as the code will be freely available.

This implies there exists a way to verify that the code under review is
actually the exact same code used to compile the binary which is not
trivial IIRC.

Max

---

From: Matt Fredrickson <[email-masked]>
Date: Wed, 30 Oct 2013 10:55:19 -0500

That is only as long as the binary versions don't have any additions or
changes for such things.  Nothing says that the binary modules cannot be
built in this way.

Matthew Fredrickson

---

From: Ted Hardie <[email-masked]>
Date: Wed, 30 Oct 2013 08:58:32 -0700

On Wed, Oct 30, 2013 at 8:50 AM, Adam Roach <[email-masked]> wrote:

> code is available?
I did, but that didn't seem to use the  names I am used to; that is, are we
talking about the same constrained baseline that is in the MTI draft?

> steps, but past experience suggests that it will take a few months before
> the entire process is complete.
>
>
I was hoping Jonathan might be willing to say something more (like "before
the London meeting"), and I still am, so I have explicitly cc'ed him on
this message.

In case this is not clear, these are neither chair questions nor questions
from my employer, just my own personal questions.

Ted

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 30 Oct 2013 16:12:11 +0000

On Oct 30, 2013, at 9:20 AM, Matt Fredrickson <[email-masked]> wrote:

> Does this mean that system information (for systems that this is installed on) may be tracked and sent back to the Cisco servers for accurate license usage count?  (ethernet MAC address, or some other system specific info) so that redownloads of modules on the same system are not counted towards your license usage accounting?
> 
> Matthew Fredrickson
> 

Good question Matt and wish that had been in the FAQ. No we don't need to track MAC or any systems specific stuff. The download can be just a HTTP get with no identifying information other than of course Cisco will see the IP address the HTTP get came from.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Oct 2013 12:16:55 -0400

Great questions Ted. My answers inline:

> remain available even in the case some other codec is selected as MTI?

Correct. This is not contingent on IETF selecting H.264 as MTI. We will
proceed with this if VP8 is chosen or if no decision is made next week.
Though obviously we and I hope this helps get a decision made in favor of
H.264.

> you give a timeline for when they might be disclosed?

We'll start with constrained baseline profile. However part of the benefit
of open sourcing is that the community can help bring this to high profile.

As for timeline - we're not ready to say anything yet on that - but "soon".
We understand that if this doesnt show up for a long time it kind of
defeats the purpose, and that all eyes are on this to actually ship. Same
with supported platforms, though we hope the community can help with this
too.

> is that it is really two, in that someone may *either* have the source
> code under BSD license term* or* they may have the downloadable module
> with Cisco paying the MPEG-LA license fees, but that these offers cannot be

Yes. There is a relationship in that the binary module is a compiled
version of that source code. So if the community makes changes to the
source code those would show up in our distribution. But in terms of
licenses you are correct. There will be a BSD license for the source code.
But if folks want to avoid the MPEG-LA license costs, they do that by
taking the compiled binary version from us, and most importantly it needs
to be distributed to the user's computer or device by us.

> Can you confirm that understanding?
>

Yes.

> If so, I have to note that I find the phrase "best of all worlds" a bit
> hyperbolic--a technology license that applied to all implementations would
> seem a bit better.  This may, of course, be the best of all worlds
> available to H.264.  I also note, by the way, that your announcement says
> BSD license, but this Q & A discuss this as if the licensing terms were
> still undefined.  Can you confirm that the license is BSD and update the
> FAQ?
>

Hmm thats a bug. Should be BSD.

> *Q: Is Cisco guaranteeing that it will pay other licensing fees for
> H.264, should additional patent holders assert claims in the future?

Confirmed. This is why we're using words like "we won't pass on our MPEG-LA
licensing costs". Meaning - we cannot guarantee there won't be other future
unknown costs and we cannot make any guarantees that we'd absorb them. This
is legal 101 - you cannot indemnify against potentially unbounded costs.
You can form your own opinion on the risks of new patent holders showing up.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 30 Oct 2013 16:17:02 +0000

On Oct 30, 2013, at 9:55 AM, Matt Fredrickson <[email-masked]> wrote:

> That is only as long as the binary versions don't have any additions or changes for such things.  Nothing says that the binary modules cannot be built in this way.

The binary module will be build that way. 

All the build scripts etc that Cisco uses will be part of the open source project so that anyone can build it them selves and check that their build matches the Cisco binary and check the code does not have backdoors to send all your video to the NSA.

> You will be able to inspect the source yourself for nefarious things like tracking as the code will be freely available.
> 
> -EH
> 
> 
> 
> On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero <[email-masked]> wrote:

---

From: Matt Fredrickson <[email-masked]>
Date: Wed, 30 Oct 2013 11:41:56 -0500

Thanks for the clarification on both of my questions (about the tracking,
and how the module would be build).

Matthew Fredrickson

On Wed, Oct 30, 2013 at 11:17 AM, Cullen Jennings (fluffy) <[email-masked]
> wrote:

> All the build scripts etc that Cisco uses will be part of the open source
> project so that anyone can build it them selves and check that their build
> matches the Cisco binary and check the code does not have backdoors to send
> all your video to the NSA.
>
>
> >
> > Matthew Fredrickson
> >
> >

---

From: Steve Sokol <[email-masked]>
Date: Wed, 30 Oct 2013 11:42:05 -0500

Jonathan and Fluffy,

In regards to Apple's restriction on the installation of binary modules the
prevents iOS from being included in the list of supported platforms: what
precludes Cisco from offering a binary static library built for iOS? If
it's because the licensing terms you've struck with MPEG LA require you
count downloads, could you offer an iOS version that simply does a one-time
"phone-home" to cover the count requirement? The phone-home call could be
anonymous and unique (hash of MAC or similar). Not necessarily ideal from a
privacy perspective, but better than leaving a large, affluent and vocal
part of the digital ecosystem out.

-- 

*Steven Sokol*
Digium, Inc. · Director of Strategic Programs
445 Jan Davis Drive NW · Huntsville, AL 35806 · US

---

From: Leon Geyser <[email-masked]>
Date: Wed, 30 Oct 2013 18:42:45 +0200

It is all great, but how do we solve the problem to support current or
future platforms that don't support downloading a BLOB onto the device and
then using it?

---

From: Matt Fredrickson <[email-masked]>
Date: Wed, 30 Oct 2013 12:07:32 -0500

> all your video to the NSA.

:-)

Sorry, wasn't implying as such, but it's good to be reassured.  Thanks
again for the response.

Matthew Fredrickson

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Oct 2013 13:37:33 -0400

This covers all of the desktop platforms (Windows, Mac, Linux), and
Android, and probably others. I think thats a pretty solid set. For small
volume platforms where this doesnt work,  they can use the source code and
then we cannot cover any MPEG-LA licensing fees - but you should check the
MPEG-LA terms since they don't kick in until a certain volume is reached
anyway.

On Wed, Oct 30, 2013 at 12:42 PM, Leon Geyser <[email-masked]> wrote:

> On 30 October 2013 18:17, Cullen Jennings (fluffy) <[email-masked]>wrote:
>
>>

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Oct 2013 12:45:41 -0500

On 10/30/13 12:37, Jonathan Rosenberg wrote:
> Android, and probably others. I think thats a pretty solid set. For 
> small volume platforms where this doesnt work,  they can use the 
> source code and then we cannot cover any MPEG-LA licensing fees - but 
> you should check the MPEG-LA terms since they don't kick in until a 
> certain volume is reached anyway.
>

Also (from the FAQ): " As long as there are ports of the source code and 
automatic build scripts contributed as part of the open source, we do 
not see difficulties in adding additional platforms."

/a

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Wed, 30 Oct 2013 18:22:46 +0000

I think questions like these will be answered and satisfied under the framework set up so that "Development and maintenance will be overseen by a board from industry and the open source community."

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 30 Oct 2013 18:24:00 +0000

On Oct 30, 2013, at 11:07 AM, Matt Fredrickson <[email-masked]>
 wrote:

> On Wed, Oct 30, 2013 at 11:17 AM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> 
> Sorry, wasn't implying as such, but it's good to be reassured.  Thanks again for the response.

No apology needed, I did not think you were implying as much. I was just looking for an excuse to say that :-)

---

From: Göran Eriksson AP <[email-masked]>
Date: Wed, 30 Oct 2013 18:44:14 +0000

> No apology needed, I did not think you were implying as much. I was just looking for an excuse to say that :-) 

Noted and appreciated. Concerns about this need to be taken seriously and I foresee us discussing this in more detail in the future, together with the relevant W3C groups. 

Regards
Göran

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Wed, 30 Oct 2013 18:44:08 +0000

+1

I suppose from a WebRTC platform support perspective, the gods at Apple could easily adopt WebRTC in Safari and deliver their own hardware-accelerated .264 implementation. Developers could surface that in a UIWebView, although I have not noodled what types of additional hooks may be needed.

Ultimately this falls into the Apple bucket.

On Oct 30, 2013, at 12:42 PM, Steve Sokol <[email-masked]> wrote:

> Jonathan and Fluffy,
> 
> In regards to Apple's restriction on the installation of binary modules the prevents iOS from being included in the list of supported platforms: what precludes Cisco from offering a binary static library built for iOS? If it's because the licensing terms you've struck with MPEG LA require you count downloads, could you offer an iOS version that simply does a one-time "phone-home" to cover the count requirement? The phone-home call could be anonymous and unique (hash of MAC or similar). Not necessarily ideal from a privacy perspective, but better than leaving a large, affluent and vocal part of the digital ecosystem out.
> 
> 
> 
> Steven Sokol

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 30 Oct 2013 20:16:51 +0100

Il giorno Wed, 30 Oct 2013 12:28:50 +0000
"Jonathan Rosenberg (jdrosen)" <[email-masked]> ha scritto:

> and open source it under BSD license terms. Development and
> maintenance will be overseen by a board from industry and the open
> source community.  Furthermore, we will provide a binary form
> suitable for inclusion in applications across a number of different
> operating systems (Windows, MacOS, Linux x86, Linux ARM and Android
> ARM), and make this binary module available for download from the
> Internet. We will not pass on our MPEG-LA licensing costs for this
> module, and based on the current licensing environment, this will
> effectively make H.264 free for use on supported platforms.
> 
> We believe that this contribution to the community can help address
> the concerns many have raised around selection of H.264 as MTI. I
> firmly believe that with H.264 we can achieve maximal
> interoperability and now, do it with open source and for free (well,
> at least for others - its not free for Cisco :)) More information on
> the open source project can be found at http://www.openh264.org,
> which is sparse now but more coming soon.
> 
> 
> Thx,
> Jonathan R.
> 
> --
> Jonathan Rosenberg, PhD
> VP, CTO Collaboration
> Cisco Systems
> [email-masked]
> 

Am I really the only one not that enthusiastic about this?

Don't get me wrong, I appreciated Cisco's statement. I just don't think
it changes anything. It doesn't make H.264 more open (or less closed,
if you prefer) than it was before. It just says that, if you download
their module from them when installing your stuff, your applications
can use it to encode/decode H.264 and not worry about fees (hoping with
your fingers crossed that the platform is supported, that is). I still
cannot use x264, ffmpeg, randomsuperawesomeopensourceH264codec or even
a version of Cisco's H.264 code I compile myself: at least, not if I
don't want (or just can't afford) to pay license fees, that is. Which
means we're back to step one again. Under those premises, I still think
it's not MTI material.

The problem is, I don't want to rely on Cisco's generosity[*] (or
anyone else's, for that matter) to work with video, especially when
we're building an (allegedly) open web communication framework. What if
their module sucks? I'm sure it won't, but I still don't have any
choice, there are no free alternatives. Besides, we have no assurance
at all that this is something we can rely on. If Cisco wakes up in a
couple of months and decides it's all not worth it and shuts all of
this down, what happens to WebRTC implementations, to companies that
decided to depend on it, to their clients/customers? We wait for
another generous "mecenate", while big companies thrive? We complain on
social networks? We cry at the moon?  And this is not such a remote
possibility: after all (and I'm quoting one of Jonathan's latest tweets
here), "We cannot say forever but unless things change we will continue
this indefinitely". If this is supposed to convince me H.264 is now the
best solution as MTI for WebRTC then, especially as a developer, I'm
not convinced.

I see this opening more as the (welcome, no denying that) software
equivalent of daddy pinching you on the cheek and giving you a coupon
for your "free ice cream (for a while)". Everyone loves free stuff, I
do as well. But IMHO it's not more than that, a free gift to convince
the unconvinced. Ancient Romans would have called this "Panem et
Circenses", and according to all the enthusiastic posts on Twitter and
the like, I guess it still works: people are entertained.

Make the codec REALLY free, without any license fee required at all,
and then you'll entertain me as well.

Lorenzo

[*] I must shamefully admit I sniggered a bit when I read the "it's not
free for Cisco" part, as if you were really paying for this. I have
trouble thinking Cisco doesn't already pay the infamous cap every year.
You're doing something you really don't have to (and we really
appreciate this, make no mistake), but that's not the same thing.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 30 Oct 2013 19:51:03 +0000

> trouble thinking Cisco doesn't already pay the infamous cap every year.

I'm not going to provide numbers but I will say just for the record that Cisco does not even come close to paying the cap right now. I also realize that compared to Cisco overall budget, the MEPG LA cap is a very small percentage.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 30 Oct 2013 20:09:36 +0000

But to work with VP8 you are also relying on Google's generosity. 

Google have IPR on VP8; you are relying on a statement from them they will continue to offer it royalty free. 

Google and Cisco are both reputable organisations, but ultimately you trust who you trust, and I don't see that being different whichever path you follow.

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lorenzo Miniero
> Sent: 30 October 2013 19:17
> To: Jonathan Rosenberg (jdrosen)
> Cc: [email-masked]
> Subject: Re: [rtcweb] Cisco to open source its H.264 
> implementation and absorb MPEG-LA licensing fees
> 
> Il giorno Wed, 30 Oct 2013 12:28:50 +0000 "Jonathan Rosenberg 
> (jdrosen)" <[email-masked]> ha scritto:
> 
> > I'd like to make an announcement material to the 
> conversations around 
> > MTI video codecs in rtcweb.
> > 
> > source community.  Furthermore, we will provide a binary 
> form suitable 
> > for inclusion in applications across a number of different 
> operating 
> > systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and 
> > make this binary module available for download from the 
> Internet. We 
> > will not pass on our MPEG-LA licensing costs for this module, and 
> > based on the current licensing environment, this will 
> effectively make 
> > H.264 free for use on supported platforms.
> > 
> interoperability 
> > and now, do it with open source and for free (well, at least for 
> > others - its not free for Cisco :)) More information on the open 
> > source project can be found at http://www.openh264.org, which is 
> > sparse now but more coming soon.
> > 
> > 
> > Thx,
> > Jonathan R.
> > 
> > --
> > Jonathan Rosenberg, PhD
> > VP, CTO Collaboration
> > Cisco Systems
> > [email-masked]
> > 
> 
> 
> Don't get me wrong, I appreciated Cisco's statement. I just 
> don't think it changes anything. It doesn't make H.264 more 
> open (or less closed, if you prefer) than it was before. It 
> just says that, if you download their module from them when 
> installing your stuff, your applications can use it to 
> encode/decode H.264 and not worry about fees (hoping with 
> your fingers crossed that the platform is supported, that 
> is). I still cannot use x264, ffmpeg, 
> randomsuperawesomeopensourceH264codec or even a version of 
> Cisco's H.264 code I compile myself: at least, not if I don't 
> want (or just can't afford) to pay license fees, that is. 
> Which means we're back to step one again. Under those 
> premises, I still think it's not MTI material.
> 
> The problem is, I don't want to rely on Cisco's generosity[*] 
> (or anyone else's, for that matter) to work with video, 
> especially when we're building an (allegedly) open web 
> communication framework. What if their module sucks? I'm sure 
> it won't, but I still don't have any choice, there are no 
> free alternatives. Besides, we have no assurance at all that 
> this is something we can rely on. If Cisco wakes up in a 
> couple of months and decides it's all not worth it and shuts 
> all of this down, what happens to WebRTC implementations, to 
> companies that decided to depend on it, to their 
> clients/customers? We wait for another generous "mecenate", 
> while big companies thrive? We complain on social networks? 
> We cry at the moon?  And this is not such a remote
> possibility: after all (and I'm quoting one of Jonathan's 
> latest tweets here), "We cannot say forever but unless things 
> change we will continue this indefinitely". If this is 
> supposed to convince me H.264 is now the best solution as MTI 
> for WebRTC then, especially as a developer, I'm not convinced.
> 
> I see this opening more as the (welcome, no denying that) 
> software equivalent of daddy pinching you on the cheek and 
> giving you a coupon for your "free ice cream (for a while)". 
> Everyone loves free stuff, I do as well. But IMHO it's not 
> more than that, a free gift to convince the unconvinced. 
> Ancient Romans would have called this "Panem et Circenses", 
> and according to all the enthusiastic posts on Twitter and 
> Make the codec REALLY free, without any license fee required 
> at all, and then you'll entertain me as well.
> 
> Lorenzo
> 
> 
> [*] I must shamefully admit I sniggered a bit when I read the 
> "it's not free for Cisco" part, as if you were really paying 
> for this. I have trouble thinking Cisco doesn't already pay 
> the infamous cap every year.
> You're doing something you really don't have to (and we 
> really appreciate this, make no mistake), but that's not the 
> same thing.

---

From: cowwoc <[email-masked]>
Date: Wed, 30 Oct 2013 16:33:45 -0400

While I appreciate Cisco's huge contribution in this area, Lorenzo 
and Keith bring up some good points.

     How about this approach?

  * Mandate both codecs as MTI
  * If either codec becomes problematic (requiring us to pay royalties)
    we simply drop that codec as MTI (implementation becomes optional)
    and searching for a replacement to add as MTI. In the meantime, we
    have that other codec to fall back on.

     With this approach we no longer have to depend on the generosity of 
Cisco or Google, and it reduces the incentive of patent trolls (it's 
harder to squeeze us for royalties when we have a fallback).

Gili

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 30 Oct 2013 21:43:18 +0100

On Wed, 30 Oct 2013 20:09:36 +0000

> Google and Cisco are both reputable organisations, but ultimately you trust who you trust, and I don't see that being different whichever path you follow.

True, but that "royalty free" makes all the difference in the world. I can make my own ice cream, if I want (and there's people doing this).

Lorenzo

-- 
Lorenzo Miniero, COB

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

---

From: David Singer <[email-masked]>
Date: Thu, 31 Oct 2013 10:14:14 +0100

On Oct 30, 2013, at 21:33 , cowwoc <[email-masked]> wrote:

> 
>     While I appreciate Cisco's huge contribution in this area, Lorenzo and Keith bring up some good points.
> 
>     How about this approach?
> 	• Mandate both codecs as MTI
> 	• If either codec becomes problematic (requiring us to pay royalties) we simply drop that codec as MTI (implementation becomes optional) and searching for a replacement to add as MTI. In the meantime, we have that other codec to fall back on.

That is, alas, not the only way a codec becomes problematic.  One can also get sued.

>     With this approach we no longer have to depend on the generosity of Cisco or Google, and it reduces the incentive of patent trolls (it's harder to squeeze us for royalties when we have a fallback).
> 
> Gili
> 
>>> [
>>> mailto:[email-masked]
>>> ] On Behalf Of Lorenzo Miniero
>>> Cc: 
>>> (jdrosen)" 
>>> <[email-masked]>
>>>  ha scritto:
>>>> Cisco is announcing today that we will take our H.264 
>>>> 
>>> implementation, 
>>> 
>>>> source project can be found at 
>>>> http://www.openh264.org
>>>> , which is 

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: cowwoc <[email-masked]>
Date: Thu, 31 Oct 2013 05:32:32 -0400

>>      With this approach we no longer have to depend on the generosity of Cisco or Google, and it reduces the incentive of patent trolls (it's harder to squeeze us for royalties when we have a fall…

     I'm no lawyer but, my understanding is that this could happen no 
matter what codec we choose. Our goal should be to minimize the 
probability of infringement, reduce the profitability of suing, and 
provide a backup plan if we're forced to move off a codec.

     At least with this approach our liability is limited to past 
infringement. They can't blackmail us with unreasonable licensing fees 
because we can switch to the other codec without losing our business. 
This lowers the profitability of suing which reduces the chance that 
they'll sue in the first place. At least, that's my reasoning :)

Gili