Subject: Re: [rtcweb] On the topic of MTI video codecs

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 1 Nov 2013 08:07:41 +0100

On 31 Oct 2013, at 21:51, Daniel-Constantin Mierla <[email-masked]> wrote:

> 
> On 10/31/13 10:35 AM, Olle E. Johansson wrote:
>> On 30 Oct 2013, at 22:40, Cullen Jennings (fluffy) <[email-masked]> wrote:
>> 
>>> On Oct 30, 2013, at 12:20 PM, Leon Geyser <[email-masked]> wrote:
>>> 
>>>> Unfortunately like Jonathan pointed out H.264 will only be able to be used royalty free on certain(most popular) platforms.
>>>> To be able to avoid negotiation failure we need a MTI codec that every potential now/future browser would be able to implement freely.
>>>> I like what Cisco did, but the solution seems a bit half-baked.
>>>> 
>>> I think that Mozilla put it pretty nicely in their blog. What this annoucement gives us is not a perfect world. Mozilla is working towards a better future but in the mean time, this is the best thing we could possibly figure out on how to make the internet today be the best it can be for users.
>>> 
>> For the Open Source community in general I beleve this is a big move forward and I want to thank everyone involved in getting this done. It can not have been an easy internal struggle through all layers of the company. Everyone will benefit from it.
>> 
>> For us in the Asterisk community I believe this opens up for use of video in a whole new way.
> To my understanding, the release of the codec is for webrtc only, and particularly for client side/browsers. For clarification, is this codec/blob available to use for free in any application, no matter its relation with webrtc sessions?

THe text on OpenH264.org says:

"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."

Doesn't even mention WebRTC - does it?

/O

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Fri, 01 Nov 2013 08:37:35 +0100

> Doesn't even mention WebRTC - does it?
quick check on that site and I couldn't sport it, maybe there were other 
blogs/news/... claiming that. On the site, it is still one questionable 
FAQ, imo:

*Q. Can I take advantage of the H.264 codec binary module in my project?*
A: Yes. Your users can download this module to utilize the H.264 video 
codec with your project.

"Your users" -- that sound like "not you" as service provider, more 
like: it can be used by client applications, not servers.

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
   - more details about Kamailio trainings at http://www.asipto.com -

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 1 Nov 2013 09:16:48 +0100

On 01 Nov 2013, at 08:37, Daniel-Constantin Mierla <[email-masked]> wrote:

> quick check on that site and I couldn't sport it, maybe there were other blogs/news/... claiming that.
Yes, there was a lot of opinions flying around yesterday :-)

> On the site, it is still one questionable FAQ, imo:
> 
> Q. Can I take advantage of the H.264 codec binary module in my project?
> A: Yes. Your users can download this module to utilize the H.264 video codec with your project.
> 
> "Your users" -- that sound like "not you" as service provider, more like: it can be used by client applications, not servers.

I think they mean "the users of your project". In the Asterisk example we could not distribute the binary as part of our tar.gz but let the Asterisk admin download the binary manually. We're doing that with some Digium firmware for cards, sound files and have done it in the past with some codec source code too.

But you are right, the word "users" here is propably just a bad choice of wording and Cisco could propably clarify a bit better.

/O

---

From: Simon Perreault <[email-masked]>
Date: Fri, 01 Nov 2013 09:06:14 -0400

Le 2013-10-31 18:36, Richard Barnes a écrit :
> You would need something more than that if you don't trust Cisco not to
> tinker with the binaries (no offense).  But even that doesn't have to be
> complicated.  You could just do something like have the software call
> back to the vendor whenever it gets a new binary from Cisco to check
> that the binary it just got is good (say, by comparing hashes).

Is it even necessary that Cisco do the actual compiling of source code?

As far as I understand, Cisco only needs to be distributing the 
binaries. So here's a crazy idea... how about a self-serve binary 
hosting service? You compile your code, upload it to Cisco, Cisco does 
the download tracking and accounting, and you and your users just need 
to download and verify the checksum. Heck, Cisco could even host 
binaries of x264!

That would be much simpler on Cisco's part: much less investment in 
manpower, much fewer things to maintain and care for. It would just be a 
glorified FTP server. Unlicensed binary comes in, licensed binary comes 
out. Platforms could multiply without any effort from Cisco. Win win.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 1 Nov 2013 14:27:42 +0000

I suspect the fallacy in your argument is in the statement

"Unlicensed binary comes in, licensed binary comes out."

If it was as simple as that, you ISP would them become liable for you H264 license fees.

I suspect that what occurs for Cisco to become liable to the license fees is some degree of ownership of the product they are distributing.

That ownership means they are also take responsibility for any of the liabilities arising from defective code they so distribute. I see no reason why Cisco would want to do that under anything but a controlled evironment, which would have its own set of non-trivial costs.

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: 01 November 2013 13:06
> To: [email-masked]
> Subject: Re: [rtcweb] On the topic of MTI video codecs
> 
> > You would need something more than that if you don't trust 
> Cisco not 
> > to tinker with the binaries (no offense).  But even that 
> doesn't have 
> > to be complicated.  You could just do something like have 
> the software 
> > call back to the vendor whenever it gets a new binary from Cisco to 
> > check that the binary it just got is good (say, by 
> comparing hashes).
> 
> As far as I understand, Cisco only needs to be distributing 
> the binaries. So here's a crazy idea... how about a 
> self-serve binary hosting service? You compile your code, 
> upload it to Cisco, Cisco does the download tracking and 
> accounting, and you and your users just need to download and 
> verify the checksum. Heck, Cisco could even host binaries of x264!
> 
> That would be much simpler on Cisco's part: much less 
> investment in manpower, much fewer things to maintain and 
> care for. It would just be a glorified FTP server. Unlicensed 
> binary comes in, licensed binary comes out. Platforms could 
> multiply without any effort from Cisco. Win win.
> 
> Simon
> --
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Emil Ivov <[email-masked]>
Date: Fri, 1 Nov 2013 16:14:34 +0100

On Fri, Nov 1, 2013 at 3:27 PM, DRAGE, Keith (Keith)
<[email-masked]> wrote:
>
> That ownership means they are also take responsibility for any of the liabilities arising
> from defective code they so distribute. I see no reason why Cisco would want to do
> that under anything but a controlled evironment, which would have its own set of
> non-trivial costs.

They could have the same by distributing x264 binaries that they have
compiled by themselves.

One of the things in the Cisco grand, that sound a bit incoherent to
me is their declared will on building a healthy open source community
around their implementation. Specifically, what baffles me is that
there is already a very well oiled implementation that does a lot more
than just baseline. That implementation already has a vibrant
community, significant popularity and, again, it sounds like it would
be considerably superior to what Cisco are planning on rolling out in
OpenH264.

In addition to wondering at the pure waste of resources (with a casual
reference to NIH), potential contributors could legitimately ask "why
would we contribute to your project when you made the exact opposite
choice when faced with the decision?".

Emil

--
https://jitsi.org

---

From: Chris Wendt <[email-masked]>
Date: Fri, 1 Nov 2013 11:20:33 -0400

x264 is GPL.

---

From: Emil Ivov <[email-masked]>
Date: Fri, 1 Nov 2013 16:25:31 +0100

> x264 is GPL.

I am not sure I see how that is relevant. It's not supposed to be
distributed with proprietary software, is it? It would just be a
single binary with available source code. Perfectly compatible with
GPL.

--
https://jitsi.org

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 1 Nov 2013 09:56:04 -0600

> choice when faced with the decision?".

We considered just using x264 (I like x264 myself) that but Mozilla told us it would not work for them because it is GPL.