Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 01 Nov 2013 12:02:56 -0700

Harald Alvestrand wrote:
> Google still believes that VP8 - a freely available, fully open,
> high-quality video codec that you can download, compile for your
> platform, include in your binary, distribute and put into production
> today - is the best choice of a Mandatory to Implement video codec for
> the WebRTC effort.

+1

---

From: Adam Roach <[email-masked]>
Date: Fri, 01 Nov 2013 14:43:52 -0500

On 10/31/13 13:47, Harald Alvestrand wrote:
>
> We congratulate Cisco on their intention to make an open source H.264 
> codec available and usable by the community. We look forward to seeing 
> the result of this effort.
>
>

I agree with Harald that VP8 is a better codec than H.264 baseline in a 
number of important ways.

But I also want to reiterate that having an MTI codec has never been 
about choosing the best codec or even a good codec. It's about choosing 
an emergency backup codec-of-last-resort. It's about having one single 
mandated codec that everyone has in their back pocket in case nothing 
else works.

The core of RTCWEB is about session *negotiation*. Endpoints will 
negotiate the best codec they have in common. Once the next generation 
of codecs come out, this "best codec in common" will only be the MTI if 
they were about to fail anyway.

So it doesn't have to be good.

It just has to be better than failure.

/a

---

From: Doug Geistkemper <[email-masked]>
Date: Fri, 1 Nov 2013 14:56:35 -0500

-1

On Nov 1, 2013, at 2:02 PM, Timothy B. Terriberry <[email-masked]> wrote:

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

---

From: Justin Uberti <[email-masked]>
Date: Fri, 1 Nov 2013 13:13:59 -0700

I also want to reiterate that having a MTI codec means Mandatory To
Implement.

That means, that should we decide to go down the H.264 path, Firefox and
others will be forced to support this Rube Goldberg machine for obtaining
H.264 for an indeterminate amount of time, long after WebRTC has moved on
to prefer other codecs.

On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach <[email-masked]> wrote:

> codec available and usable by the community. We look forward to seeing the
> result of this effort.
>
> high-quality video codec that you can download, compile for your platform,
> include in your binary, distribute and put into production today - is the
> best choice of a Mandatory to Implement video codec for the WebRTC effort.
>
>
> But I also want to reiterate that having an MTI codec has never been about
> choosing the best codec or even a good codec. It's about choosing an
> emergency backup codec-of-last-resort. It's about having one single
> mandated codec that everyone has in their back pocket in case nothing else
> works.
>
> negotiate the best codec they have in common. Once the next generation of
> codecs come out, this "best codec in common" will only be the MTI if they
> were about to fail anyway.
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 1 Nov 2013 21:19:22 +0100

On Fri, 01 Nov 2013 14:43:52 -0500

> It just has to be better than failure.

Those are good points. But were that the case, we could have sticked with an older codec, one that didn't have to carry the burden of royalty fees: a choice that several people have often discarded exactly because it wasn't good enough.

That's also why I, as it is probably redundant to restate, actually support Harald's view. My concern is that, with H.264, MTI will not mean *a* codec in a negotiatiated session, which is what we all agree RTCWEB still is, or should be. It will be *the* codec, because several implementations, including two currently missing browsers (whenever they'll start to care), will *only* provide H.264, thus forcing everyone to comply with it. Who's going to do anything else, when you know the only way to reach all browsers is *the* codec? And for a lot of people, including me, there's currently (or actually, will be) only one way to do so, which is a plugin (in RTCWEB, ironic) that may or may not be available two months after we start using it.

I'm at the wrong edge of the knife, and I don't like it.

Lorenzo

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Sat, 2 Nov 2013 16:53:32 +0800

+1

On Fri, Nov 1, 2013 at 2:47 AM, Harald Alvestrand <[email-masked]> wrote:

> Harald (sending this from my Google address)
>
>

---

From: Leon Geyser <[email-masked]>
Date: Sat, 2 Nov 2013 10:59:47 +0200

+1

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sat, 2 Nov 2013 20:26:13 +1100

+1  (is the vote on the MTI codec going to happen via email?)
Silvia.

---

From: Simon Pietro Romano <[email-masked]>
Date: Sat, 02 Nov 2013 10:31:44 +0100

+1 from me (just in case...)

Simon

Silvia Pfeiffer <[email-masked]> ha scritto:
>> On 2 November 2013 10:53, Alexandre GOUAILLARD
><[email-masked]>
>> wrote:
>>>
>>> +1
>>>
>>>
>platform,

---

From: Alessandro Amirante <[email-masked]>
Date: Sat, 02 Nov 2013 11:10:30 +0100

> Those are good points. But were that the case, we could have sticked with an older codec, one that didn't have to carry the burden of royalty fees: a choice that several people have often discarded…

I could not agree more.

> That's also why I, as it is probably redundant to restate, actually support Harald's view. My concern is that, with H.264, MTI will not mean *a* codec in a negotiatiated session, which is what we a…

+1 for VP8 as MTI.

Alessandro

-- 
Alessandro Amirante, Ph.D.
Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione
Universita' degli Studi di Napoli "Federico II"
Via Claudio, 21 - 80125 Napoli - Italy

Phone:    +39 081 7683821
Fax:      +39 081 19730464
E-mail:   [email-masked]
Skype-ID: alessandro.amirante
Web:      http://wpage.unina.it/alessandro.amirante

---

From: Emil Ivov <[email-masked]>
Date: Sat, 2 Nov 2013 11:14:50 +0100

> +1  (is the vote on the MTI codec going to happen via email?)

There is no voting on the IETF so, no. There would probably be "hum"s
called during the meeting. You can take part in these either directly or
through the XMPP chatroom: [email-masked]

This is not to say that expressing your opinion here is inappropriate.
Quite on the contrary.

Emil

--
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Sat, 2 Nov 2013 11:34:51 +0100

+1 for VP8 as MTI.

Compared to VP8, H.264 baseline is only marginally better than H.263. This
makes it hard to justify the inconvenience of post-installation additions.

The whole point of WebRTC was: NO PLUGINS NEEDED!

Let's not through this out the window.

Also, while Cisco's grant is quite interesting for certain scenarios it
could be very problematic for others. For example: enterprises where
installations are handled in a controlled and automated way (e.g. scripted
image deployment) and where subsequent Internet access could be limited for
various reasons.

Emil

--
https://jitsi.org

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 2 Nov 2013 04:31:45 -0700

Not sure I understand this completely. Isn't support for "the Rube Goldberg Machine" needed only on platforms that do not natively support H.264? 

> On Nov 1, 2013, at 1:14 PM, "Justin Uberti" <[email-masked]> wrote:
> 
> I also want to reiterate that having a MTI codec means Mandatory To Implement.
> 
> That means, that should we decide to go down the H.264 path, Firefox and others will be forced to support this Rube Goldberg machine for obtaining H.264 for an indeterminate amount of time, long after WebRTC has moved on to prefer other codecs.
> 
> 
>>>  We
>>>               congratulate Cisco on their intention to make an open
>>>               source H.264 codec available and usable by the community.
>>>               We look forward to seeing the result of this effort.
>>> 
>>>  Google
>>>               still believes that VP8 - a freely available, fully open,
>>>               high-quality video codec that you can download, compile
>>>               for your platform, include in your binary, distribute and
>>>               put into production today - is the best choice of a
>>>               Mandatory to Implement video codec for the WebRTC effort.
>> 
>> I agree with Harald that VP8 is a better codec than H.264 baseline in a number of important ways.
>> 
>> But I also want to reiterate that having an MTI codec has never been about choosing the best codec or even a good codec. It's about choosing an emergency backup codec-of-last-resort. It's about having one single mandated codec that everyone has in their back pocket in case nothing else works.
>> 
>> The core of RTCWEB is about session *negotiation*. Endpoints will negotiate the best codec they have in common. Once the next generation of codecs come out, this "best codec in common" will only be the MTI if they were about to fail anyway.
>>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 02 Nov 2013 05:45:04 -0600

+1.  +1 also on everything Lorenzo said.

> Harald (sending this from my Google address)

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Leon Geyser <[email-masked]>
Date: Sat, 2 Nov 2013 13:56:31 +0200

Like Firefox and Opera...and the browser I might create in the future? :)
Firefox only has decoding support on some platforms, because it uses the
operating system's H.264 decoder if it has one so far as I know.

On 2 November 2013 13:31, Bernard Aboba <[email-masked]> wrote:

> Not sure I understand this completely. Isn't support for "the Rube
> Goldberg Machine" needed only on platforms that do not natively support
> H.264?
>
>> about choosing the best codec or even a good codec. It's about choosing an

---

From: "Karl Stahl" <[email-masked]>
Date: Sat, 2 Nov 2013 13:04:33 +0100

>From below:> "will *only* provide H.264, thus forcing everyone to comply
with it. Who's going to do anything else, when you know the only way to
reach all browsers is *the* codec?"

--- That fear should not be underestimated: Compare telephony, where 3.5kHz
G.711 still is 99% of the traffic, and use of wide band audio codecs to
reach 7kHz AM-radio quality between two different carriers is yet to be seen
(in spite of IP/IMS/VoLTE)... 

I thanked Cisco for their free H.264 offering - WebRTC needs video
compatibility when connecting with existing services - but many thanks to
Google also: That free baseline H.264 would hardly have happened without
their free VP8 offering...

Note that neither free H.264 nor free VP8 are conditioned any one of them
being selected MTI!

For compatibility using Cisco's free H.264 offering, the codec plug-in slot
and download of a H.264 codec are required, so that must be made mandatory,
must it not?

Then, when minimum video compatibility thus is assured, maybe IETF could
reach consensus about a free and good video codec that could be included in
a WebRTC browser from the beginning?

BTW: In an IETF recommendation, mustn't such codec plug-in slot be open for
more than download from Cisco and for more than H.264 baseline?

And, with compatibility assured, wouldn't VP9 be an even better video codec
MTI?

/Karl

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För
Alessandro Amirante
Skickat: den 2 november 2013 11:10
Till: [email-masked]
Ämne: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still
prefer VP8

Il 01/11/2013 21:19, Lorenzo Miniero ha scritto:
>>> We congratulate Cisco on their intention to make an open source 
>>> H.264 codec available and usable by the community. We look forward 
>>> to seeing the result of this effort.
>>>
>>>
>>> today - is the best choice of a Mandatory to Implement video codec 
>>> for the WebRTC effort.
>>>
>>
>> about choosing the best codec or even a good codec. It's about 
>> choosing an emergency backup codec-of-last-resort. It's about having 
>> one single mandated codec that everyone has in their back pocket in 
>> case nothing else works.
>>
>> negotiate the best codec they have in common. Once the next 
>> generation of codecs come out, this "best codec in common" will only 
>> be the MTI if they were about to fail anyway.
>>
> Those are good points. But were that the case, we could have sticked with
an older codec, one that didn't have to carry the burden of royalty fees: a
choice that several people have often discarded exactly because it wasn't
good enough.

I could not agree more.

>
> That's also why I, as it is probably redundant to restate, actually
support Harald's view. My concern is that, with H.264, MTI will not mean *a*
codec in a negotiatiated session, which is what we all agree RTCWEB still
is, or should be. It will be *the* codec, because several implementations,
including two currently missing browsers (whenever they'll start to care),
will *only* provide H.264, thus forcing everyone to comply with it. Who's
going to do anything else, when you know the only way to reach all browsers
is *the* codec? And for a lot of people, including me, there's currently (or
actually, will be) only one way to do so, which is a plugin (in RTCWEB,
ironic) that may or may not be available two months after we start using it.

+1 for VP8 as MTI.

Alessandro

Phone:    +39 081 7683821
Fax:      +39 081 19730464

---

From: Ron <[email-masked]>
Date: Sat, 2 Nov 2013 23:18:01 +1030

On Thu, Oct 31, 2013 at 07:47:31PM +0100, Harald Alvestrand wrote:
> We congratulate Cisco on their intention to make an open source H.264 codec
> available and usable by the community. We look forward to seeing the result
> of this effort.
> 

This is my belief also.

While the Cisco announcement is certainly an interesting approach to trying
to extricate their existing technology investment from the deep quagmire of
encumbrances that currently bind it, the result still falls well short of
not only the ideal, but also the already existing alternative choices that
we have available to us.

Given the choice between a genuinely Free option, that anyone is free to
improve and distribute however they wish - and a no-cost binary-only option
that is available from only a single supplier, while Happy Hour lasts - the
decision still seems to be something of a no-brainer.  Even before you also
consider that the Free Option is not constrained to only its lowest possible
performance mode in the implementation that is available to people today.

VP8 still seems like the only obvious and enduring choice for an MTI codec
for WebRTC at present.

  Ron

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 2 Nov 2013 07:00:48 -0700

Those enterprise scenarios often either involve a defined software image that could include the Cisco plugin (does it always have to be downloaded?) OR involve a relatively recent OS, with native H.264 support. So I am not sure this need come up that often.

> On Nov 2, 2013, at 3:35 AM, "Emil Ivov" <[email-masked]> wrote:
> Also, while Cisco's grant is quite interesting for certain scenarios it could be very problematic for others. For example: enterprises where installations are handled in a controlled and automated way (e.g. scripted image deployment) and where subsequent Internet access could be limited for various reasons. 
> 
> Emil
> 
> --
> https://jitsi.org
> 
> > We congratulate Cisco on their intention to make an open source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.
> >
> >
> > Google still believes that VP8 - a freely available, fully open, high-quality video codec that you can download, compile for your platform, include in your binary, distribute and put into production today - is the best choice of a Mandatory to Implement video codec for the WebRTC effort.
> >
> >

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Nov 2013 07:09:16 -0700

> operating system's H.264 decoder if it has one so far as I know.

I anticipate that Firefox will use HW codecs on phones. We haven't
determined what we will do on operating systems with good H.264
codecs built in to the platform.

-Ekr

---

From: cowwoc <[email-masked]>
Date: Sat, 02 Nov 2013 10:37:48 -0400

How many platforms *really* support H.264 natively today?

     iOS is a great example. On paper, it supports H.264 but in reality 
the public API only supports H.264 decoding (not encoding). Then, when 
you try using that API for decoding you discover that it does not 
support real-time decoding (only decoding from file). So really, iOS 
doesn't actually support H.264 as required by WebRTC. Android is only 
marginally better in that respect.

     I can't think of a single platform that supports real-time H.264 
encoding/decoding natively today.

Gili

On 02/11/2013 7:31 AM, Bernard Aboba wrote:
> Goldberg Machine" needed only on platforms that do not natively 
> support H.264?
>
> On Nov 1, 2013, at 1:14 PM, "Justin Uberti" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> That means, that should we decide to go down the H.264 path, Firefox 
>> and others will be forced to support this Rube Goldberg machine for 
>> obtaining H.264 for an indeterminate amount of time, long after 
>> WebRTC has moved on to prefer other codecs.
>>
>>
>> On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>>     H.264 codec available and usable by the community. We look
>>>     forward to seeing the result of this effort.
>>>
>>>
>>>     platform, include in your binary, distribute and put into
>>>     production today - is the best choice of a Mandatory to
>>>     Implement video codec for the WebRTC effort.
>>>
>>
>>     But I also want to reiterate that having an MTI codec has never
>>     been about choosing the best codec or even a good codec. It's
>>     about choosing an emergency backup codec-of-last-resort. It's
>>     about having one single mandated codec that everyone has in their
>>     back pocket in case nothing else works.
>>
>>     generation of codecs come out, this "best codec in common" will
>>     only be the MTI if they were about to fail anyway.
>>
>>     [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Sat, 2 Nov 2013 07:38:52 -0700

On 2 November 2013 02:26, Silvia Pfeiffer <[email-masked]> wrote:
>  (is the vote on the MTI codec going to happen via email?)

I still hold out hope that a vote will not be necessary.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 2 Nov 2013 08:02:56 -0700

> encoding/decoding natively today.

That's a very strange way to put the question.

Let me put another spin on it, and please excuse the example...

Skype runs on more platforms than you might think.  Those platforms
can all support H.264 to the extent that Skype requires.

Cisco's generous offer opens almost the same capability to anyone,
with the caveat that some platforms currently remain closed.  Of
course, you could let your ideals get in the way of progress.  Me, I'm
a pragmatist.  This gift represents a great opportunity for people who
actually care about the practical outcomes.

There's been a lot of mouth-gazing of gift horses on this list of
late.  I sure hope that this isn't representative of the real
sentiment of the community.  I'd like to think that people are better
than that.

(BTW, I understand and respect Harald's position.  From where he sits,
I'm sure that his conclusion makes perfect sense.)

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Sat, 2 Nov 2013 15:16:23 +0000

I suspect iOS will be the worst example. Apple likes h.264 and I think is actually most likely to release a Safari native h.264 WebRTC implementation vs any other option.... And I highly doubt they'll be using Cisco's module

To the degree this is about "enabling web browsers with Real-Time Communications (RTC) capabilities via simple Javascript APIs." they actually could check the box easily... And give you a UiWebView... Which may well make WebRTC wind up being the best way to get hardware 264 support in 3rd party apps... And hence push WebRTC even further.

And as always say "Apple iOS is supporting openness"...

Can't wait for those discussions  :-)

Sent from my iPhone

On Nov 2, 2013, at 10:38 AM, "cowwoc" <[email-masked]<mailto:[email-masked]>> wrote:

    iOS is a great example. On paper, it supports H.264 but in reality the public API only supports H.264 decoding (not encoding). Then, when you try using that API for decoding you discover that it does not support real-time decoding (only decoding from file). So really, iOS doesn't actually support H.264 as required by WebRTC. Android is only marginally better in that respect.

    I can't think of a single platform that supports real-time H.264 encoding/decoding natively today.

Gili

On Nov 1, 2013, at 1:14 PM, "Justin Uberti" <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:
On 10/31/13 13:47, Harald Alvestrand wrote:

/a

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

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

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

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 02 Nov 2013 08:53:47 -0700

> I still hold out hope that a vote will not be necessary.

Me, too. Especially since we don't vote. :-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: tim panton <[email-masked]>
Date: Sat, 2 Nov 2013 16:56:41 +0000

> can all support H.264 to the extent that Skype requires.

Martin, can I ask you to talk with your Skype engineering team and check up on 
the exact way that works on iOS. Last time I looked, it seemed you couldn’t use the 
Apple supplied (hardware accelerated) h264 library for realtime encode/decode and
it wasn’t at all clear to me that the hardware encoder licence covered any soft implementation of h264 we
added.

I’d like to caveat that:
 1) it was a while ago. 2) I’m not a lawyer. 3) it was a thought experiment.
So it would be interesting to get a current view from the trenches.

T.

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Sat, 2 Nov 2013 17:03:41 +0000

You are right, it's not possible to get hardware accelerated

Sent from my iPhone

> On Nov 2, 2013, at 12:57 PM, "tim panton" <[email-masked]> wrote:
> 
>

---

From: Emil Ivov <[email-masked]>
Date: Sat, 2 Nov 2013 18:14:15 +0100

Same questions for OS X and Windows actually. Last time we checked (which
was also some time ago) there was no way to get the OS to *encode* H.264
for you.

--sent from my mobile

---

From: Bossiel thioriguel <[email-masked]>
Date: Sat, 2 Nov 2013 17:27:46 +0000 (GMT)

@Emil
Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for Media foundation). The only issue with Windows 7 is the the encoder doesn't support realtime encoding (up to 3s delay).
You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync for Intel). Nothing to install for the end-user.
If you want reference code:
Media Foundation (Windows OS and Intel Quick Sync): https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginWinMF
Nvidia Cuda: https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginCUDA

Le Samedi 2 novembre 2013 18h14, Emil Ivov <[email-masked]> a écrit :
 
Same questions for OS X and Windows actually. Last time we checked (which was also some time ago) there was no way to get the OS to *encode* H.264 for you.
--sent from my mobile

---

From: Gili <[email-masked]>
Date: Sat, 02 Nov 2013 13:41:47 -0400

So... the only platform that supports H.264 natively (real-time 
encoding/decoding) is Windows 8? Any others?

Gili

On 11/2/2013 1:27 PM, Bossiel thioriguel wrote:
> @Emil
> Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for 
> Media foundation). The only issue with Windows 7 is the the encoder 
> doesn't support realtime encoding (up to 3s delay).
> You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync for 
> Intel). Nothing to install for the end-user.
> Media Foundation (Windows OS and Intel Quick 
> Sync): https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginWinMF
> Nvidia 
> Cuda: https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginCUDA
>
>
>
> Same questions for OS X and Windows actually. Last time we checked 
> (which was also some time ago) there was no way to get the OS to 
> *encode* H.264 for you.
> --sent from my mobile
> On 2 Nov 2013 17:57, "tim panton" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     On 2 Nov 2013, at 15:02, Martin Thomson <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     > On 2 November 2013 07:37, cowwoc <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     the exact way that works on iOS. Last time I looked, it seemed you
>     couldn't use the
>     it wasn't at all clear to me that the hardware encoder licence
>     covered any soft implementation of h264 we
>     added.
>
>     I'd like to caveat that:
>      1) it was a while ago. 2) I'm not a lawyer. 3) it was a thought
>     experiment.

---

From: Bossiel <[email-masked]>
Date: Sat, 2 Nov 2013 19:00:51 +0100

On windows 7 you have CUDA and Intel Quick Sync

Sent from my iPhone

On Nov 2, 2013, at 18:41, Gili <[email-masked]> wrote:

> 
>     So... the only platform that supports H.264 natively (real-time encoding/decoding) is Windows 8? Any others?
> 
> Gili
>

---

From: Bossiel <[email-masked]>
Date: Sat, 2 Nov 2013 19:08:25 +0100

In addition to CUDA and Intel Quick Sync there are also many webcams supporting H264 encoding (eg. Logitech)

Sent from my iPhone

---

From: Martin Thomson <[email-masked]>
Date: Sat, 2 Nov 2013 11:26:57 -0700

On 2 November 2013 09:56, tim panton <[email-masked]> wrote:
> Last time I looked, it seemed you couldn’t use the

That is my understanding also.  It's the weekend, so I won't be able
to get a fixed answer, but I believe that Skype uses a largely
software-based implementation of H.264 on iOS devices.  It's not that
there isn't hardware acceleration on the device, it's that the APIs
that are made available to applications do not include a way to access
those functions.

---

From: Gili <[email-masked]>
Date: Sat, 02 Nov 2013 16:01:18 -0400

Martin,

     I fully understand why Firefox would be happy but as someone who 
plan to integrate WebRTC into a non-browser application, especially on 
iOS, Cisco's solution simply does not work. I appreciate their 
contribution, but again, it simply doesn't help my use-case.

Gili

---

From: Gili <[email-masked]>
Date: Sat, 02 Nov 2013 16:01:52 -0400

With respect, no. As I keep on repeating, there is a strong need 
for WebRTC outside of the browser. I don't see how I am supposed to 
integrate WebRTC into a closed-source iOS application if H.264 is MTI. I 
would be more than happy to revisit my position once someone provides a 
credible solution.

Gili

On 11/2/2013 11:16 AM, Jeremy Laurenson (jlaurens) wrote:
> I suspect iOS will be the worst example. Apple likes h.264 and I think 
> is actually most likely to release a Safari native h.264 WebRTC 
> implementation vs any other option.... And I highly doubt they'll be 
> using Cisco's module
>
> To the degree this is about "enabling web browsers with Real-Time 
> Communications (RTC) capabilities via simple Javascript APIs." they 
> actually could check the box easily... And give you a UiWebView... 
> Which may well make WebRTC wind up being the best way to get hardware 
> 264 support in 3rd party apps... And hence push WebRTC even further.
>
>>     iOS is a great example. On paper, it supports H.264 but in 
>> reality the public API only supports H.264 decoding (not encoding). 
>> Then, when you try using that API for decoding you discover that it 
>> does not support real-time decoding (only decoding from file). So 
>> really, iOS doesn't actually support H.264 as required by WebRTC. 
>> Android is only marginally better in that respect.
>>
>>>> That means, that should we decide to go down the H.264 path, 
>>>> Firefox and others will be forced to support this Rube Goldberg 
>>>> machine for obtaining H.264 for an indeterminate amount of time, 
>>>> long after WebRTC has moved on to prefer other codecs.
>>>>
>>>>
>>>>>     We congratulate Cisco on their intention to make an open
>>>>>     source H.264 codec available and usable by the community. We
>>>>>     look forward to seeing the result of this effort.
>>>>>
>>>>>
>>>>>     Google still believes that VP8 - a freely available, fully
>>>>>     open, high-quality video codec that you can download, compile
>>>>>     for your platform, include in your binary, distribute and put
>>>>>     into production today - is the best choice of a Mandatory to
>>>>     about having one single mandated codec that everyone has in
>>>>     their back pocket in case nothing else works.
>>>>
>>>>     The core of RTCWEB is about session *negotiation*. Endpoints
>>>>     will negotiate the best codec they have in common. Once the
>>>>     next generation of codecs come out, this "best codec in common"
>>>>     will only be the MTI if they were about to fail anyway.
>>>>

---

From: Gili <[email-masked]>
Date: Sat, 02 Nov 2013 16:06:08 -0400

Hi Bossiel,

     Thanks for the clarification. Are there existing libraries on top 
of CUDA and Intel Quick Sync that provide real-time H.264 
encoding/decoding (with a reasonable license), or is this something we'd 
need to build ourselves?

     Also, please note that not all video cards support CUDA (only 
NVidia by last count), or run Intel CPUs (in spite of the fact that many 
do), so we still have a portability problem.

Thanks,
Gili

On 11/2/2013 2:00 PM, Bossiel wrote:
> On Nov 2, 2013, at 18:41, Gili <[email-masked] 
>>> You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync 
>>> for Intel). Nothing to install for the end-user.
>>> Media Foundation (Windows OS and Intel Quick Sync): 
>>> https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginWinMF
>>> Nvidia Cuda: 
>>> https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginCUDA
>>>
>>>
>>>
>>>     On 2 Nov 2013, at 15:02, Martin Thomson
>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>     it wasn’t at all clear to me that the hardware encoder licence

---

From: Bossiel <[email-masked]>
Date: Sat, 2 Nov 2013 21:27:02 +0100

CUDA works on windows XP and later. The developer needs the SDK and the end-user up-to-date drivers.

For Intel QuickSync there is an SDK but not needed if you're using Microsoft Media Foundation (Windows Platform SDK).

With CUDA, Intel Quick Sync, Win8-builtin- encoder, Webcams with UVC 1.5... you can have native H264 in 99% cases. We have a x264 fallback plugin in our open source products but rarely used.

Also note that Windows *Phone* 8 natively support H264 encoding/decoding. For reference implementation (open source SIP video client) you can follow the links I sent.

Sent from my iPhone

On Nov 2, 2013, at 21:06, Gili <[email-masked]> wrote:

> Hi Bossiel,
> 
>     Thanks for the clarification. Are there existing libraries on top of CUDA and Intel Quick Sync that provide real-time H.264 encoding/decoding (with a reasonable license), or is this something we'd need to build ourselves?
> 
>     Also, please note that not all video cards support CUDA (only NVidia by last count), or run Intel CPUs (in spite of the fact that many do), so we still have a portability problem.
> 
> Thanks,
> Gili
>

---

From: Gili <[email-masked]>
Date: Sat, 02 Nov 2013 18:15:33 -0400

According to 
http://www.tekrevue.com/2013/08/19/nvidia-takes-62-of-discrete-gpu-market-share-in-q2-2013/ 
NVidia owns 62% of the market, while according to 
http://www.cpubenchmark.net/market_share.html Intel owns 75.6% of the 
market.

     Whether the union of these two translates to 99% market share 
remains to be seen, but one thing is sure:  it sounds like a deployment 
nightmare. I'd have build an abstraction layer on top of CUDA + Intel 
Quick Sync and update device drivers on each user machine. This is 
hardly trivial stuff. Don't get me wrong, VP8 is even worse when it 
comes to hardware-acceleration. For this reason, I'd probably forgo 
hardware acceleration on Windows 7 and use software codecs for the sake 
of simplicity. Desktop PCs are fast enough anyway.

     When it comes to software-based codecs, VP8 is in a much better 
position than H.264. It has a better royalty, licensing and deployment 
story. I think both VP8 and H.264 need a better story when it comes to a 
portable hardware accelerated APi.

     So when it comes to hardware-accelerated real-time H.264 
encoding/decoding support, here is what we've got:

Windows 7: Yes, if you jump through many hoops
Windows 8: Yes
OSX: No
iOS: No
Android: No

     By last check, Windows 8 had approximately 10% market share.

     When it comes to software-based H.264 codecs, I'm not aware of a 
single portable implementation with a commercially-friendly license. On 
the flip side, the software-based VP8 codec is available on all these 
platforms (today, not in some distant future) with very reasonable 
performance and ease of deployment.

     My point is, when considering using H.264 vs VP8 for MTI it's not 
clear that H.264 has any real advantage over VP8. H.264 has 
industry-wide support when it comes to playing pre-recorded YouTube 
videos, but that's hardly relevant to our discussion. WebRTC requires 
real-time encoding/decoding support and in that context, the two codecs 
are on equal footing.

Gili

On 11/2/2013 4:27 PM, Bossiel wrote:
> For Intel QuickSync there is an SDK but not needed if you're using 
> Microsoft Media Foundation (Windows Platform SDK).
>
> With CUDA, Intel Quick Sync, Win8-builtin- encoder, Webcams with UVC 
> 1.5... you can have native H264 in 99% cases. We have a x264 fallback 
> plugin in our open source products but rarely used.
>
> Also note that Windows *Phone* 8 natively support H264 
> encoding/decoding. For reference implementation (open source SIP video 
> client) you can follow the links I sent.
>
> Sent from my iPhone
>
> On Nov 2, 2013, at 21:06, Gili <[email-masked] 
>> encoding/decoding (with a reasonable license), or is this something 
>> we'd need to build ourselves?
>>
>> NVidia by last count), or run Intel CPUs (in spite of the fact that 
>> many do), so we still have a portability problem.
>>
>> Thanks,
>> Gili
>>
>>>>> Media foundation). The only issue with Windows 7 is the the 
>>>>> encoder doesn't support realtime encoding (up to 3s delay).

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Nov 2013 15:16:22 -0700

If only there was some piece of software that you could download
that provided H.264 encoders for those platforms.

-Ekr

On Sat, Nov 2, 2013 at 10:14 AM, Emil Ivov <[email-masked]> wrote:

>> couldn’t use the

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Nov 2013 15:18:04 -0700

On Sat, Nov 2, 2013 at 1:01 PM, Gili <[email-masked]> wrote:

> Martin,
>
>     I fully understand why Firefox would be happy but as someone who plan
> to integrate WebRTC into a non-browser application, especially on iOS,
> Cisco's solution simply does not work. I appreciate their contribution, but
> again, it simply doesn't help my use-case.
>

I haven't seen  you explain how your use case is different from that of
a browser. Could you please do so?

-Ekr

---

From: Emil Ivov <[email-masked]>
Date: Sat, 2 Nov 2013 23:28:01 +0100

I'd encourage you to read back.

This part of the thread started with the claim that most of the time it
won't come to downloading Cisco's binary because there is already
widespread OS support for H.264 encoding on all OSes.

--sent from my mobile

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Nov 2013 15:43:09 -0700

On Sat, Nov 2, 2013 at 3:28 PM, Emil Ivov <[email-masked]> wrote:

> widespread OS support for H.264 encoding on all OSes
>

I assume you're referring to Bernard's comment? If so, I don't think that's
actually
what he said.

In any case, speaking as someone who actually has to deal with this, it's
more
work to maintain more code paths. Thus, I anticipate using Cisco's binary on
all desktop platforms and only using platform codecs where it offers a
significant
performance advantage, e.g., on mobile.

On a related note: it's a mistake to assume that just because there aren't
currently good interfaces to the existing H.264 encoding hardware that those
interfaces will never exist. For instance, the iPhone clearly has real-time
capable encoding hardware, and Apple certainly could make it available
if they wanted. That's a much simpler proposition than adding hardware
where none exists.

-Ekr

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Sat, 2 Nov 2013 22:48:56 +0000

I don't think this is the case.

The rationale is that H.264 can be accelerated by hardware.
Some rightly question how much this is actually the case natively today.
To Ekr's point, if Cisco works with the top providers to enable true acceleration....
Or in the case of Apple, if ultimate delivery of true h/w acceleration of 264 is ultimately delivered through WebRTC...
Then at least we' have *more* h/w acceleration than we do today

Sent from my iPhone

On Nov 2, 2013, at 6:28 PM, "Emil Ivov" <[email-masked]<mailto:[email-masked]>> wrote:

This part of the thread started with the claim that most of the time it won't come to downloading Cisco's binary because there is already widespread OS support for H.264 encoding on all OSes.

--sent from my mobile

On 2 Nov 2013 23:17, "Eric Rescorla" <[email-masked]<mailto:[email-masked]>> wrote:
If only there was some piece of software that you could download
that provided H.264 encoders for those platforms.

-Ekr

On Sat, Nov 2, 2013 at 10:14 AM, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:

--sent from my mobile

On 2 Nov 2013 17:57, "tim panton" <[email-masked]<mailto:[email-masked]>> wrote:

On 2 Nov 2013, at 15:02, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

> On 2 November 2013 07:37, cowwoc <[email-masked]<mailto:[email-masked]>> wrote:

I’d like to caveat that:

T.

---

From: Kaiduan Xie <[email-masked]>
Date: Sat, 2 Nov 2013 19:41:35 -0400

Every BlackBerry 10 phone has H.264 hardware encoder/decoder.

/Kaiduan

---

From: tim panton <[email-masked]>
Date: Sun, 3 Nov 2013 10:49:39 +0000

On 2 Nov 2013, at 22:43, Eric Rescorla <[email-masked]> wrote:

> This part of the thread started with the claim that most of the time it won't come to downloading Cisco's binary because there is already widespread OS support for H.264 encoding on all OSes
> 
> 
> I assume you're referring to Bernard's comment? If so, I don't think that's actually
> what he said.
> 
> In any case, speaking as someone who actually has to deal with this, it's more
> all desktop platforms and only using platform codecs where it offers a significant

Unfortunately it is on mobile that these codecs are not available.

> if they wanted. That's a much simpler proposition than adding hardware

I’m not sure that the situation is quite that simple, I think that many of the currently
deployed GPUs would be capable of accelerating VP8 with a firmware update.

One can speculate endlessly about the future, but one of the benefits of h264 is
that the hardware is deployed. However when you examine this claim, we find that it is only 
available to the platform owner, so we risk having a vendor lock-in where the
platform browser has access to performance that 3rd party browsers don’t .

Tim.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 3 Nov 2013 17:52:00 +0000

And this is where it would be useful to see some work done, although probably not by IETF.

There a a few bits of API work out there, but nowhere do we see much push for adoption. As fae as I see there is no political reason why they should not be adopted, or even a fresh effort adopted to create some new ones. The only thing seems to be lack of impetus.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of tim panton
Sent: 03 November 2013 10:50
To: Eric Rescorla
Cc: [email-masked]
Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8)

On 2 Nov 2013, at 22:43, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Nov 2, 2013 at 3:28 PM, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:

I'm not sure that the situation is quite that simple, I think that many of the currently
deployed GPUs would be capable of accelerating VP8 with a firmware update.

One can speculate endlessly about the future, but one of the benefits of h264 is
that the hardware is deployed. However when you examine this claim, we find that it is only
available to the platform owner, so we risk having a vendor lock-in where the
platform browser has access to performance that 3rd party browsers don't .

Tim.

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 03 Nov 2013 19:10:19 +0100

On 11/03/2013 06:52 PM, DRAGE, Keith (Keith) wrote:
> There a a few bits of API work out there, but nowhere do we see much
> push for adoption. As fae as I see there is no political reason why
> they should not be adopted, or even a fresh effort adopted to create
> some new ones. The only thing seems to be lack of impetus.

What's the industry state on standardization of APIs for phones?

Most of what I see seems to be platform specific, with some exceptions
(OpenGL / WebGL for graphics, OpenES for audio).

But it's not where I spend the most time looking; it would be good to
have someone who knows this space summarize.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 3 Nov 2013 20:34:56 +0000

The only stuff I am aware of is done by

http://www.khronos.org/

But that is as far as my knowledge goes.

It would certainly be desireable that there is an standardised API that everyone uses to get access to embedded hardware codec support.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 03 November 2013 18:10
To: [email-masked]
Subject: [rtcweb] API standardization on phones? (Re: Platforms that support H264)

Most of what I see seems to be platform specific, with some exceptions (OpenGL / WebGL for graphics, OpenES for audio).

But it's not where I spend the most time looking; it would be good to have someone who knows this space summarize.

---

From: cowwoc <[email-masked]>
Date: Sun, 03 Nov 2013 18:39:54 -0500

Hi Eric,

In general,

  * Browsers are more likely to be open-source than applications, and
    therefore are more flexible regarding the plugin licenses that are
    acceptable.
  * Most browsers have a plug-in architecture, allowing them to download
    codecs on demand. The same is not true of most applications.

I suspect that if we find a solution that works for non-browser 
applications, it'll likely work for browsers but not necessarily the 
other way around. These are generalizations, so I expect you will find 
exceptions to the rule.

Gili

On 02/11/2013 6:18 PM, Eric Rescorla wrote:
>
>
>
> On Sat, Nov 2, 2013 at 1:01 PM, Gili <[email-masked] 
>         I fully understand why Firefox would be happy but as someone
>     who plan to integrate WebRTC into a non-browser application,
>     especially on iOS, Cisco's solution simply does not work. I
>     appreciate their contribution, but again, it simply doesn't help
>     my use-case.
>
>

---

From: cowwoc <[email-masked]>
Date: Sun, 03 Nov 2013 18:41:10 -0500

I have no idea what the future will hold, but I know that as of 
today H.264 does not seem to enjoy much stronger platform support than 
VP8 (with respect to real-time encoding/decoding support).

Gili

On 02/11/2013 6:43 PM, Eric Rescorla wrote:
>     This part of the thread started with the claim that most of the
>     time it won't come to downloading Cisco's binary because there is
>     already widespread OS support for H.264 encoding on all OSes
>
>

---

From: Randell Jesup <[email-masked]>
Date: Sun, 03 Nov 2013 20:20:03 -0800

On 11/2/2013 7:00 AM, Bernard Aboba wrote:
> Those enterprise scenarios often either involve a defined software 
> image that could include the Cisco plugin (does it always have to be 
> downloaded?) OR involve a relatively recent OS, with native H.264 
> support. So I am not sure this need come up that often.

IANAPL (I Am Not A Patent Lawyer) - but if you make an image that 
includes Cisco's plugin for imaging machines, that would be a violation 
of the rules - you would be the one distributing it to end-use systems.  
While you're unlikely to get pinged on it, the company lawyers may not 
see it that way, and it might show up flagged in an audit, and IT guys 
don't like that.

There are also some systems that don't generally allow plugins of any 
sort (such as Metro IIRC); though those might have native H.264 
encode/decode support.  Note that platform encode/decode support for 
WebRTC is more problematic than software support, since the H.264 
encoders (hell, even decoders) may be of questionable stability. (You'll 
note the blacklists/whitelists Mozilla uses for platform decoder support 
on Android, for example, because some of them have problems.)  How 
serious that problem is (and how serious it is for encoders) is not 
clear.   There's also the issue of what knobs are available to tune the 
encoder, especially for resiliency options.

>
> On Nov 2, 2013, at 3:35 AM, "Emil Ivov" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>
>> Also, while Cisco's grant is quite interesting for certain scenarios 
>> it could be very problematic for others. For example: enterprises 
>> where installations are handled in a controlled and automated way 
>> (e.g. scripted image deployment) and where subsequent Internet access 
>> could be limited for various reasons.
>>
>> Emil
>>
>> --
>>

-- 
Randell Jesup
[email-masked]

---

From: David Singer <[email-masked]>
Date: Mon, 04 Nov 2013 22:51:26 +0900

>     So... the only platform that supports H.264 natively (real-time encoding/decoding) is Windows 8? Any others?

The fact that there currently isn't an API is different from whether the platform can do it (in the iOS case).  reverse engineering suggests that FaceTime uses AVC (H.264).

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: cowwoc <[email-masked]>
Date: Mon, 04 Nov 2013 09:02:16 -0500

> The fact that there currently isn't an API is different from whether the platform can do it (in the iOS case).  reverse engineering suggests that FaceTime uses AVC (H.264).

     Same difference. Whether you need to implement a new API or simply 
expose existing an implementation, it takes months for users to upgrade 
to this new version and for it to actually work as expected (initial 
releases tend to be unstable or missing features). Furthermore, there is 
no guarantee that Apple will release said API anytime soon. For these 
reasons, I stand by my comment that real-time H.264 support does not 
exist (for developers outside of Apple).

Gili

---

From: David Singer <[email-masked]>
Date: Mon, 04 Nov 2013 23:12:27 +0900

On Nov 4, 2013, at 23:02 , cowwoc <[email-masked]> wrote:

>    Same difference.

No, it really isn't.  There is a world of difference between implementing something and making an API to it public or available.  Good grief.

> Whether you need to implement a new API or simply expose existing an implementation, it takes months for users to upgrade to this new version and for it to actually work as expected (initial releases tend to be unstable or missing features). Furthermore, there is no guarantee that Apple will release said API anytime soon. For these reasons, I stand by my comment that real-time H.264 support does not exist (for developers outside of Apple).
> 
> Gili

David Singer

---

From: cowwoc <[email-masked]>
Date: Mon, 04 Nov 2013 09:18:16 -0500

On 04/11/2013 9:12 AM, David Singer wrote:
> No, it really isn't. There is a world of difference between 
> implementing something and making an API to it public or available. 
> Good grief. 

Yes, yes, obviously... but my point was that there is a huge hump even 
after you publish the API. There is still a long ramp-up time until that 
API becomes publicly available, garners sufficient market-share and is 
proven to have the necessary stability for production use. We're talking 
about what exists *today*, not a few months in the future. Today, iOS 
does not have real-time H.264 support.

Gili

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 4 Nov 2013 09:58:23 -0500

I do not believe that "genuinely free" is the only, nor even the primary,
consideration here.

I believe we should in general be thinking about what it takes to make
webRTC successful. And more than anything else, that means making it a
platform that application developers can utilize. If we do our jobs well,
we'll have many thousands (hundreds of thousands even) of applications on
the web that are enabled with real-time comms and frankly a great many of
them will know nothing about codecs or the nuances of MPEG-LA licensing.
What are the considerations for making webRTC attractive to them?

I assert that the primary thing they'll want is to interconnect their
application with some kind of video network or user base that can add value
to their application. Let me give an example. Lets say there is a bank, and
this bank wants to add the ability for a user to look at their investment
portfolio online, click a button, and have a voice/video call with their
investment advisor. To build such an app into their existing banking web
app, the bank will need webRTC to connect to the voice and video contact
center and clients their investment advisors have. Today, all of that is
based on H.264.

So - I would assert that frankly our primary consideration for webRTC is
interoperability. And interoperability as a requirement clearly points to
H.264.

There are other considerations too. Some of the ones I'd list are:

* Interoperates with install base
* Widespread deployment
* Appeals to the existing set of video application developers - in other
words, the biggest consumers of webRTC should be the folks who are already
providing video communications applications on the Internet (which by
definition none of them do so natively from the browser). Don't we want
them to come to the web with webRTC?
* Available widely in hardware - especially mobile phones
* Broad availability of expertise
* Broad availability of toolsets
* Multiple codebases and implementations to choose from

And none of that has anything to do with IPR or royalties.

-Jonathan R.

On Sat, Nov 2, 2013 at 8:48 AM, Ron <[email-masked]> wrote:

> codec

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

---

From: Randell Jesup <[email-masked]>
Date: Mon, 04 Nov 2013 08:26:42 -0800

On 11/4/2013 6:58 AM, Jonathan Rosenberg wrote:
> platform that application developers can utilize. If we do our jobs 
> well, we'll have many thousands (hundreds of thousands even) of 
> applications on the web that are enabled with real-time comms and 
> frankly a great many of them will know nothing about codecs or the 
> nuances of MPEG-LA licensing. What are the considerations for making 
> webRTC attractive to them?

Those are all important considerations.

> application with some kind of video network or user base that can add 
> value to their application. Let me give an example. Lets say there is 
> a bank, and this bank wants to add the ability for a user to look at 
> their investment portfolio online, click a button, and have a 
> voice/video call with their investment advisor. To build such an app 
> into their existing banking web app, the bank will need webRTC to 
> connect to the voice and video contact center and clients their 
> investment advisors have. Today, all of that is based on H.264.

Here you're stretching - most of these don't have an existing system 
"based on H.264" for this.  Some may, but most do not; video access 
would be something new in any case.  And for many of those use-cases, 
end-to-end WebRTC would be preferable to gatewaying to another system.

>
> So - I would assert that frankly our primary consideration for webRTC 
> is interoperability. And interoperability as a requirement clearly 
> points to H.264.

Interop is certainly a consideration and that's where H.264's advantage 
lies.  (H.264's only real technical advantages are interop and the 
possibility of existing hardware support).

> * Interoperates with install base

Not in of itself a consideration.

> * Appeals to the existing set of video application developers - in 
> other words, the biggest consumers of webRTC should be the folks who 
> are already providing video communications applications on the 
> Internet (which by definition none of them do so natively from the 
> browser). Don't we want them to come to the web with webRTC?

This is just the interop argument again.

> * Broad availability of expertise

I don't see this as a consideration.

> * Broad availability of toolsets

It's unclear if this has any import or not.

> * Multiple codebases and implementations to choose from

Only of use to those willing to pay MPEG-LA fees.   Everyone else has to 
use platform OS codecs, HW codecs, or Cisco's plugin.

   Randell Jesup, Mozilla

> On Sat, Nov 2, 2013 at 8:48 AM, Ron <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     H.264 codec
> [email-masked] <mailto:[email-masked]>
> http://www.jdrosen.net
>
>

-- 
Randell Jesup
[email-masked]

---

From: cowwoc <[email-masked]>
Date: Mon, 04 Nov 2013 11:35:19 -0500

On 04/11/2013 11:26 AM, Randell Jesup wrote:
> Interop is certainly a consideration and that's where H.264's 
> advantage lies.  (H.264's only real technical advantages are interop 
> and the possibility of existing hardware support).

     When was Constrained Baseline Profile defined? Based on Wikipedia 
I'm guessing it was sometime in 2009. If so, how widely is it implemented?

     We keep on referring to H.264 as a black box that is supported 
universally, but when you dig into the specifics (specific profile on 
specific platforms) the story is a lot less clear.

Gili

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 4 Nov 2013 11:37:54 -0500

+1

Well stated. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Monday, November 04, 2013 9:58 AM
To: Ron
Cc: [email-masked]
Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we
still prefer VP8

* Widespread deployment

* Appeals to the existing set of video application developers - in other
words, the biggest consumers of webRTC should be the folks who are already
providing video communications applications on the Internet (which by
definition none of them do so natively from the browser). Don't we want them
to come to the web with webRTC?

-Jonathan R.

On Sat, Nov 2, 2013 at 8:48 AM, Ron <[email-masked] <mailto:[email-masked]>

codec

This is my belief also.

  Ron

 

--

---

From: Tim Panton <[email-masked]>
Date: Mon, 4 Nov 2013 16:01:22 +0000

On 4 Nov 2013, at 14:58, Jonathan Rosenberg <[email-masked]> wrote:

> I do not believe that "genuinely free" is the only, nor even the primary, consideration here.
> 
> I believe we should in general be thinking about what it takes to make webRTC successful. And more than anything else, that means making it a platform that application developers can utilize. If we do our jobs well, we'll have many thousands (hundreds of thousands even) of applications on the web that are enabled with real-time comms and frankly a great many of them will know nothing about codecs or the nuances of MPEG-LA licensing. What are the considerations for making webRTC attractive to them?
> 
> I assert that the primary thing they'll want is to interconnect their application with some kind of video network or user base that can add value to their application. Let me give an example. Lets say there is a bank, and this bank wants to add the ability for a user to look at their investment portfolio online, click a button, and have a voice/video call with their investment advisor. To build such an app into their existing banking web app, the bank will need webRTC to connect to the voice and video contact center and clients their investment advisors have. Today, all of that is based on H.264. 

But the scale of such _video_ deployments is so negligible compared to current VP8 deployment in chrome and firefox as to make that 
argument unconvincing to me.

> 
> So - I would assert that frankly our primary consideration for webRTC is interoperability. And interoperability as a requirement clearly points to H.264. 
> 

An irrelevant install base, mostly consisting of non-realtime decoders.

> * Widespread deployment

Deployments that can't interoperate with web RTC because they don't support the required security features, or don't
support APIs that expose realtime H264.

> * Appeals to the existing set of video application developers - in other words, the biggest consumers of webRTC should be the folks who are already providing video communications applications on the Internet (which by definition none of them do so natively from the browser). Don't we want them to come to the web with webRTC?

Really? That's quite some assertion. I suppose many web designers did come from a print-design background initially, 
but they have rapidly been overcome by webnative developers.

> * Available widely in hardware - especially mobile phones

But entirely in-accessible to developers- except to the platform players, giving the platform browser an unfair advantage.

> * Broad availability of toolsets

I'll grant these two, but with the caveat that if VP8 were to be an MTI in webRTC we could expect toolsets and expertise
to grow pretty fast, and probably overtake h264 before long. I say this because creating such tools in h264-land requires
lawyers and licences. The VP8 coders can do their initial work in a garage in spare time.

> * Multiple codebases and implementations to choose from

That's the best argument for h264 I've seen so far. 

> And none of that has anything to do with IPR or royalties. 

That's where we disagree. The legal framework shapes every decision in this space. Open source hackers will
be very edgy of messing with h264 for fear of falling off the legal straight and narrow.

T.
> VP8 still seems like the only obvious and enduring choice for an MTI codec

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk

---

From: Tim Panton <[email-masked]>
Date: Mon, 4 Nov 2013 16:04:22 +0000

> The fact that there currently isn't an API is different from whether the platform can do it (in the iOS case).  reverse engineering suggests that FaceTime uses AVC (H.264).

Which nicely encapsulates the problem, only the platform owner gets to use the accelerated hardware,
where as the 3rd party developers have to use a software emulation, and pay for it. That's hardly the open
model the IETF espouses.

T.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 4 Nov 2013 17:32:30 +0000

On: 03 November 2013 20:20 Randell Jesup Wrote:

> of the rules - you would be the one distributing it to end-use
> systems.  While you're unlikely to get pinged on it, the company
> lawyers may not see it that way, and it might show up flagged in an
> audit, and IT guys don't like that.
> 

I also have a concern about this issue and made the same assumption however yesterday I was told by one of the Cisco experts that as long as it is the owner of the end devices (i.e. An enterprise) that is doing the distribution that would be within the rules. However IANAPL and those that are will need to examine the small print. 

Maybe this is something that Cisco could clarify in the FAQ's.

Andy

---

From: Erik Lagerway <[email-masked]>
Date: Mon, 4 Nov 2013 09:37:36 -0800

+1 Tim

Not sure if forcing developers to implement a royalty bearing codec is
helpful at all, whether they be indie or corporate.

Furthermore, it seems that the industry should be allowed to make their own
decisions with this in mind.  Many will end up supporting both codecs
anyways, at least that is what we are hearing from our customers and
prospect customers building with WebRTC and Object RTC in mind.

*Erik Lagerway <http://ca.linkedin.com/in/lagerway> |
*Hookflash<http://hookflash.com/>* |
1 (855) Hookflash ext. 2 | Twitter
<http://twitter.com/elagerway> | WebRTC.is Blog <http://webrtc.is/> *

On Mon, Nov 4, 2013 at 8:01 AM, Tim Panton <[email-masked]> wrote:

> But the scale of such _video_ deployments is so negligible compared to
> current VP8 deployment in chrome and firefox as to make that
> Deployments that can't interoperate with web RTC because they don't
> support the required security features, or don't
> Really? That's quite some assertion. I suppose many web designers did come
> from a print-design background initially,
> But entirely in-accessible to developers- except to the platform players,
> giving the platform browser an unfair advantage.
>
> I'll grant these two, but with the caveat that if VP8 were to be an MTI in
> webRTC we could expect toolsets and expertise
> to grow pretty fast, and probably overtake h264 before long. I say this
> because creating such tools in h264-land requires

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Mon, 4 Nov 2013 17:47:22 +0000

Baseline Profile was in the original 2003 version of H.264, along with the optional constraint (constraint_set1_flag) to exclude some rather exotic error resilience tools (ASO/FMO/RS). This constrained Baseline Profile was universally deployed. The unconstrained Baseline Profile was not as widely deployed. The 2009 version merely acknowledged industry practice by giving it an official name, Constrained Baseline Profile, which is easier to say than Baseline Profile with constraint_set1_flag=1. There were no changes in the bitstream or tools, just an easier official name.

To be fair, H.264 interop has not been a painless endeavor over the years, in part due to multiple profiles. Implementers have worked through many issues to achieve the nearly universal interop enjoyed today across hundreds or thousands of vendors and implementations. VP8 should have an easier time, since it doesn’t have multiple profiles, packetization modes, etc. But VP8 will go through some of the same pains when many implementations flourish (software and hardware). The pain is not felt yet since there are only two vendors (Google and Mozilla) in close contact using a shared software implementation.

Mo

On 11/4/13, 11:35 AM, cowwoc <[email-masked]<mailto:[email-masked]>> wrote:

On 04/11/2013 11:26 AM, Randell Jesup wrote:
Interop is certainly a consideration and that's where H.264's advantage lies.  (H.264's only real technical advantages are interop and the possibility of existing hardware support).

    When was Constrained Baseline Profile defined? Based on Wikipedia I'm guessing it was sometime in 2009. If so, how widely is it implemented?

    We keep on referring to H.264 as a black box that is supported universally, but when you dig into the specifics (specific profile on specific platforms) the story is a lot less clear.

Gili

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Mon, 04 Nov 2013 12:48:52 -0500

> Maybe this is something that Cisco could clarify in the FAQ's.

The problem is that, while on the surface Cisco's offer seems to solve a
major problem, in fact it poses so many unanswered questions or unclear
situations that it may not be a net gain.  No doubt, we have our
wonderful Western patent system to blame for this, but that is what we
have to navigate around.  If things are still muddy after this offer,
then we likely have gained very little, as that was the main complaint
against VP8 from the beginning.

-- 
Libre Video
http://librevideo.org

---

From: Emil Ivov <[email-masked]>
Date: Mon, 4 Nov 2013 18:52:21 +0100

On Mon, Nov 4, 2013 at 6:32 PM, Hutton, Andrew <[email-masked]> wrote:
> I also have a concern about this issue and made the same assumption
> however yesterday I was told by one of the Cisco experts that as long
> as it is the owner of the end devices (i.e. An enterprise) that is doing
> the distribution that would be within the rules.

So as long as no one subcontracts IT maintenance, we should be fine ;).

-- 
https://jitsi.org

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Mon, 04 Nov 2013 12:53:32 -0500

On 11/04/2013 12:47 PM, Mo Zanaty (mzanaty) wrote:
> 
> To be fair, H.264 interop has not been a painless endeavor over the
> years, in part due to multiple profiles. Implementers have worked
> through many issues to achieve the nearly universal interop enjoyed
> today across hundreds or thousands of vendors and implementations. VP8
> should have an easier time, since it doesn’t have multiple profiles,
> packetization modes, etc. But VP8 will go through some of the same pains
> when many implementations flourish (software and hardware). The pain is
> not felt yet since there are only two vendors (Google and Mozilla) in
> close contact using a shared software implementation.
> 
> Mo

To be even more fair, in fact, there are more than just Google and
Mozilla on the VP8 playing field.  The ffmpeg/libav community(-ies?)
have made a successful implementation of a vp8 decoder (ffvp8) that is
also widely deployed and, to the best of my knowledge, has no known
major problems.

There was also the xvp8 project which, while I believe stalled, was not
due to incompatibilities or challenges, just lack of energy for that
project and motivation.

And there have been many hardware VP8 implementations in silicon across
multiple vendors no less, both for encoding and decoding.

And yes, while H.264 no doubt has a larger market segment, to say Google
and Mozilla are the only two players would not be accurate, and the
design and spec have shown they can be implemented widely and without as
much pain as the, arguably much more complex, (full) H.264 spec.

-- 
Libre Video
http://librevideo.org

---

From: Ron <[email-masked]>
Date: Tue, 5 Nov 2013 04:35:36 +1030

> center and clients their investment advisors have. Today, all of that is

And 'tomorrow' it will be based on something else that is better.
I don't think anyone in either camp doubts that change is in progress.

> interoperability. And interoperability as a requirement clearly points to

Interoperability as a requirement clearly points to the fact that selection
of a MTI codec that is Free in as many dimensions as possible is absolutely
*essential* for the future success of WebRTC.

How can you have interoperability if a significant portion of potential
implementers are fundamentally prohibited from distributing the MTI codec?

You are talking here of interoperability with legacy equipment, which the
WG charter explicitly notes is something to be considered on a best effort
basis only, not something to sacrifice other goals over.

I'm talking about interoperability with _all_ future implementations of
*this* standard.  If some people can't distribute the MTI codec, then
we have already guaranteed interoperability failure and a forking of the
developer and user base.  Before we've even got started.

The Cisco announcement does indeed make it possible that more people
than otherwise might have would also be able to provide H.264, both as
a negotiation option and for creating gateways to legacy equipment.
That can only be a good thing, for which I'm sure many will be grateful.

But it's still not without significant problems, as many people here
have already indicated, and it still doesn't come close to either the
immediate freedom, or assurance of future availability, or out of the
box quality, that we would have by choosing VP8 today.  And that _is_
more than anything what it will take for WebRTC to be successful in an
already fragmented application space.

> * Interoperates with install base

Which means all installed WebRTC applications need a freely available
codec and solid guarantees of always being able to distribute it.

> * Widespread deployment

Which will come once there are many implementations of WebRTC that
meet a wide range of users needs.  A codec with limited freedoms
means limited deployment.  Kind of by definition.

> them to come to the web with webRTC?

As you noted above, most of them care nothing about the nuances of
codec selection - they just need it to be available on all of their
target platforms, and they need to be able to distribute their apps
on their own terms, that meet their needs and the needs of their
users.

Requiring all their users to download a separate plugin blob before
their application will work at all, if it's actually still even
available at the time they need it, is both a huge barrier and a
huge risk.

Who do I complain to and what recourse do I have if my customers
cannot download it because of a temporary or permanent outage of
the only legal download site?

> * Available widely in hardware - especially mobile phones

I think the earlier discussion on this point has cast a pretty
deep shadow over how actually available hardware H.264 is to
developers in general on pretty much every platform.

> * Multiple codebases and implementations to choose from

Again, all excellent points that point to the necessity of a Free
codec selection which encourages the maximum possible diversity.

> And none of that has anything to do with IPR or royalties.

I wouldn't go quite that far, but indeed the important question is
which choice places the least restrictions on the broadest number
of potential WebRTC developers and users.

And on that question, it still seems clear that the evidence indicates
it is a no-brainer to see that of the currently proposed candidates,
VP8 wins on this very important point hands down.

  Ron

---

From: Ralph Giles <[email-masked]>
Date: Mon, 04 Nov 2013 10:33:00 -0800

On 2013-11-04 5:51 AM, David Singer wrote:

> reverse engineering suggests that FaceTime uses AVC (H.264).

Reverse engineering isn't necessary to establish this, although it's
nice to have ongoing confirmation of the details. :-)

http://cdn1.appleinsider.com/facetime.002.jpg

 -r

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Mon, 4 Nov 2013 18:52:49 +0000

> ffvp8Šhas no known major problems.

There were indeed problems, some rather severe, like bugs in the ON2
encoder implementation that became enshrined in the bitstream itself and
forced decoders to mirror the ON2 encoder bugs. See ³Practical problems²
in Jason¹s old rant at: http://x264dev.multimedia.cx/archives/377

> xvp8Šstalled

Too bad, it would have likely been a very fast/good vp8 encoder. If you
followed that project, you would learn just how similar vp8 and h.264
truly are. (Hint: the base is x264 not libvpx.)

> many hardware VP8 implementations

True for decoders, not yet for encoders, but the latter will improve over
time. Since app devs don¹t understand how to use hardware codecs (there
are unofficial/hacky ways in Android and iOS, and official ways in Android
4.1+), actual interop has not been widely attempted yet despite hardware
support.

> arguably much more complex, (full) H.264 spec

Agreed, the spec sucks as a practical implementers guide, although some
argue that is not its main purpose. I find it silly to need a separate
implementers guide. Both H.264 and VP8 suffer from this, for opposite
reasons; the H.264 spec is far too verbose, the VP8 spec is far too terse,
essentially making the code the spec. Maybe Daala will strike the right
balance? ;)

Mo

On 11/4/13, 12:53 PM, Basil Mohamed Gohar <[email-masked]>
wrote:

On 11/04/2013 12:47 PM, Mo Zanaty (mzanaty) wrote:
> should have an easier time, since it doesn¹t have multiple profiles,

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 4 Nov 2013 18:32:08 -0500

That has been confirmed by independent Wireshark analysis. 

http://www.packetstan.com/2010/07/special-look-face-time-part-1.html

Its also SIP with some Apple "enhancements" 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ralph Giles
Sent: Monday, November 04, 2013 1:33 PM
To: [email-masked]
Subject: Re: [rtcweb] Platforms that support H264

> reverse engineering suggests that FaceTime uses AVC (H.264).

Reverse engineering isn't necessary to establish this, although it's nice to
have ongoing confirmation of the details. :-)

 -r

---

From: David Singer <[email-masked]>
Date: Tue, 05 Nov 2013 11:25:54 +0900

>     When was Constrained Baseline Profile defined? Based on Wikipedia I'm guessing it was sometime in 2009. If so, how widely is it implemented?

It got its name then, yes.  Previously it was known as that portion of baseline that was compatible also with the main profile, which was such a mouthful, people finally gave it a name.

David Singer

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 5 Nov 2013 02:52:33 +0000

I think you meant *every* phone, tablet, laptop, desktop, set-top, camera…

On 11/2/13, 7:41 PM, Kaiduan Xie <[email-masked]<mailto:[email-masked]>> wrote:

/Kaiduan

On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Nov 2, 2013 at 1:01 PM, Gili <[email-masked]<mailto:[email-masked]>> wrote:
Martin,

    I fully understand why Firefox would be happy but as someone who plan to integrate WebRTC into a non-browser application, especially on iOS, Cisco's solution simply does not work. I appreciate their contribution, but again, it simply doesn't help my use-case.

-Ekr

Gili

---

From: cowwoc <[email-masked]>
Date: Tue, 05 Nov 2013 01:10:36 -0500

I'm not sure if you're being sarcastic or not...

     In any case, I had a question regarding BlackBerry 10. Are you 
implying that every BlackBerry 10 phone includes an API for real-time 
encoding/decoding of H.264 video streams? If so, which API is it? I took 
a quick look but couldn't find it.

Thanksm
Gili

On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote:
> I think you meant *every* phone, tablet, laptop, desktop, set-top, 
> camera...
>
>
>             I fully understand why Firefox would be happy but as
>         someone who plan to integrate WebRTC into a non-browser
>         application, especially on iOS, Cisco's solution simply does
>         not work. I appreciate their contribution, but again, it
>         simply doesn't help my use-case.
>
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 5 Nov 2013 08:55:52 +0000

I’m serious. Name a device in mass production that is relevant to rtcweb but does not have H.264 hardware.

Your second point is valid; hardware is useless without supporting software. OS APIs to access codecs (both hardware and software, real-time and buffered) is an important issue. Android is the dominant OS on the planet. If you are not happy with its OS APIs, just change them; it’s open source like VP8 right?

Mo

On 11/5/13, 1:10 AM, cowwoc <[email-masked]<mailto:[email-masked]>> wrote:

    In any case, I had a question regarding BlackBerry 10. Are you implying that every BlackBerry 10 phone includes an API for real-time encoding/decoding of H.264 video streams? If so, which API is it? I took a quick look but couldn't find it.

Thanksm
Gili

/Kaiduan

-Ekr

Gili

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

---

From: Kristian Kielhofner <[email-masked]>
Date: Tue, 5 Nov 2013 09:00:34 -0500

You might be interested in my updated analysis here:

http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html

SIP "enhancements" indeed!

On Monday, November 4, 2013, Richard Shockey wrote:

> From: [email-masked] <javascript:;> [mailto:
> [email-masked] <javascript:;>] On Behalf Of
> Ralph Giles
> To: [email-masked] <javascript:;>
> [email-masked] <javascript:;>
> [email-masked] <javascript:;>

-- 
Sent from mobile device

---

From: Randell Jesup <[email-masked]>
Date: Tue, 05 Nov 2013 06:58:08 -0800

On 11/5/2013 12:55 AM, Mo Zanaty (mzanaty) wrote:
> I'm serious. Name a device in mass production that is relevant to 
> rtcweb but does not have H.264 hardware.

Plenty have hardware is out there that might not be optimized (or 
usable) for the types of arbitrary-sized, realtime simultaneous h.264 
encode/decode.  Even just handling streaming decode on Android via OMX 
has been a year of pain for one of our engineers, because (especially 
before JB) the interfaces were unsupported, randomly 
modified/incompatible, and with lots of restrictions on what actually is 
supported.  Even with "perfect" API layers exposing them, the hardware 
layers (especially encoders) may not have the low-latency and other 
realtime characteristics needed, or knobs to tell them about things like 
packet loss reports that require IDR generation.  How many does this 
affect? who knows - and the API layers on top are inconsistent enough 
(or non-existent at the present) that it's especially hard to tell.

And many of them can handle only a single stream at a time; which makes 
"hangout"/simulcast cases more fun (need to run HW and SW in parallel, 
or drop to SW only - makes capability signaling fun too; the LCD of the 
SW and HW codecs needs to be what you offer probably, unless you want 
real pain).

>
> Your second point is valid; hardware is useless without supporting 
> software. OS APIs to access codecs (both hardware and software, 
> real-time and buffered) is an important issue. Android is the dominant 
> OS on the planet. If you are not happy with its OS APIs, just change 
> them; it's open source like VP8 right?

Not really.  You can't modify the underlying OS provided by the 
manufacturer (no rooting of phones to run webrtc should be required...)  
and even custom roms are going to get much harder or virtually 
impossible  with kitkat.  And witness my comments about the pain of 
platform decoders on Android today.

    Randell

> encoding/decoding of H.264 video streams? If so, which API is it? I 
> took a quick look but couldn't find it.
>
> Thanksm
> Gili
>

-- 
Randell Jesup
[email-masked]

---

From: Justin Uberti <[email-masked]>
Date: Tue, 5 Nov 2013 14:57:56 -0800

On Tue, Nov 5, 2013 at 6:58 AM, Randell Jesup <[email-masked]>wrote:

> Plenty have hardware is out there that might not be optimized (or usable)
> for the types of arbitrary-sized, realtime simultaneous h.264
> encode/decode.  Even just handling streaming decode on Android via OMX has
> been a year of pain for one of our engineers, because (especially before
> JB) the interfaces were unsupported, randomly modified/incompatible, and
> with lots of restrictions on what actually is supported.  Even with
> "perfect" API layers exposing them, the hardware layers (especially
> encoders) may not have the low-latency and other realtime characteristics
> needed, or knobs to tell them about things like packet loss reports that
> require IDR generation.  How many does this affect? who knows - and the API
> layers on top are inconsistent enough (or non-existent at the present) that
> it's especially hard to tell.
>
> "hangout"/simulcast cases more fun (need to run HW and SW in parallel, or
> drop to SW only - makes capability signaling fun too; the LCD of the SW and
> HW codecs needs to be what you offer probably, unless you want real pain).
>

Exactly. Name a 3rd-party software application in wide use on any of
today's popular platforms that uses a H.264 HW encoder for rtcweb scenarios.

> software. OS APIs to access codecs (both hardware and software, real-time
> and buffered) is an important issue. Android is the dominant OS on the
> planet. If you are not happy with its OS APIs, just change them; it’s open
> source like VP8 right?
>
>
> and even custom roms are going to get much harder or virtually impossible
> with kitkat.  And witness my comments about the pain of platform decoders
> on Android today.
>
>    Randell
>
>
>
>  Mo
>
>
>   On 11/5/13, 1:10 AM, cowwoc <[email-masked]> wrote:
>
>
> encoding/decoding of H.264 video streams? If so, which API is it? I took a
> quick look but couldn't find it.
>
> Thanksm
> Gili
>
>   On 11/2/13, 7:41 PM, Kaiduan Xie <[email-masked]> wrote:
>
>>> plan to integrate WebRTC into a non-browser application, especially on iOS,
> Randell [email-masked]
>
>

---

From: Dave Taht <[email-masked]>
Date: Tue, 5 Nov 2013 15:20:26 -0800

> SIP "enhancements" indeed!

Oh that was excellent thank you! All the evidence to date on
videoconferencing points towards a smaller than 1500 quantum default for fq
codel.
>> Reverse engineering isn't necessary to establish this, although it's
nice to

---

From: Gustavo Garcia <[email-masked]>
Date: Tue, 5 Nov 2013 16:23:09 -0800

+1

H.264 licensing as introduced by Cisco is great because it opens the door
to truly present H.264 as a viable alternative codec for broad
implementation in WebRTC endpoints, but Cisco’s proposal as it stands is
not enough to warrant H.264 being adopted as an MTI for WebRTC.

>From TokBox’s point of view, WebRTC needs to be able to solve two needs if
true adoption is intended:  1) supporting interoperability with legacy
end-points and 2) enabling novel and innovative real-world use-cases on a
broad range of software-powered end-points (mobile included, not just
browsers)

The option as proposed with H.264 is not really viable in mobile native
applications (specifically iOS devices as the situation stands today),
whether both endpoints are mobile native or one is browser-based. At
TokBox, we are already seeing a wide range of very interesting applications
being built on top of WebRTC using native mobile apps as one of the
endpoints, and the standard must do the right thing by not preventing these
scenarios from playing out.

As far as MTI codecs go, we still believe VP8 is the right option and
believe H.264 should be embraced as an optional alternative video codec.The
purpose of the WebRTC is not to create a browser compatible with existing
solutions (many of which are closed systems) but rather to bring the best
possible experience to application developers, extending the capabilities
of the web for real-time communication. (More of our views here:
http://www.tokbox.com/blog/is-webrtc-ready-for-h-264/)

---

From: <[email-masked]>
Date: Wed, 6 Nov 2013 00:24:58 +0000

Hi,

I agree there is definitely a need to improve the access to the H.264  “HW” codecs so they would be realistically usable for WebRTC or other interactive video apps. But that still seems to me as the best way forward compared to the other options. I know improvements are coming at least to Windows Phone and Windows RT.

Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Justin Uberti
Sent: 06 November, 2013 00:58
To: Randell Jesup
Cc: [email-masked]
Subject: Re: [rtcweb] Platforms that support H264

On Tue, Nov 5, 2013 at 6:58 AM, Randell Jesup <[email-masked]<mailto:[email-masked]>> wrote:
On 11/5/2013 12:55 AM, Mo Zanaty (mzanaty) wrote:
I’m serious. Name a device in mass production that is relevant to rtcweb but does not have H.264 hardware.

Plenty have hardware is out there that might not be optimized (or usable) for the types of arbitrary-sized, realtime simultaneous h.264 encode/decode.  Even just handling streaming decode on Android via OMX has been a year of pain for one of our engineers, because (especially before JB) the interfaces were unsupported, randomly modified/incompatible, and with lots of restrictions on what actually is supported.  Even with "perfect" API layers exposing them, the hardware layers (especially encoders) may not have the low-latency and other realtime characteristics needed, or knobs to tell them about things like packet loss reports that require IDR generation.  How many does this affect? who knows - and the API layers on top are inconsistent enough (or non-existent at the present) that it's especially hard to tell.

And many of them can handle only a single stream at a time; which makes "hangout"/simulcast cases more fun (need to run HW and SW in parallel, or drop to SW only - makes capability signaling fun too; the LCD of the SW and HW codecs needs to be what you offer probably, unless you want real pain).

Exactly. Name a 3rd-party software application in wide use on any of today's popular platforms that uses a H.264 HW encoder for rtcweb scenarios.

Not really.  You can't modify the underlying OS provided by the manufacturer (no rooting of phones to run webrtc should be required...)  and even custom roms are going to get much harder or virtually impossible  with kitkat.  And witness my comments about the pain of platform decoders on Android today.

   Randell

Mo

Thanksm
Gili

/Kaiduan

-Ekr

Gili

--

Randell Jesup

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

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 6 Nov 2013 05:20:20 +0000

Note that fixing the OS API issues helps all codecs. We should all be supportive of that, not using the issues as an excuse to ignore hardware benefits or abandon good engineering design. The Google Nexus 5 can encode and decode 1080p60 H.264 or VP8 fully in hardware. Why should Chrome, Hangouts or other Google apps not take advantage of a Google hardware codec on a Google phone/OS?

Forget H.264 vs. VP8 for a moment. If you have codec X available at 1080p60 in hardware, why fallback to software?

Randell, I feel your pain on getting hardware access to work reliably and universally. We have gone through this for several apps and platforms, and it is indeed a pain, and sometimes you still need software fallback. But it is better than giving up and always relying on software fallback. I applaud Firefox for wrestling with Android APIs, and encourage you and others to continue doing so for all hardware codecs. (We will get more than H.264 or VP8 in next year’s silicon, so this will pay off even more.)

Mo

On 11/5/13, 7:24 PM, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Markus

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Justin Uberti
Sent: 06 November, 2013 00:58
To: Randell Jesup
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Platforms that support H264

   Randell

Mo

Thanksm
Gili

/Kaiduan

-Ekr

Gili

--

Randell Jesup

---

From: David Singer <[email-masked]>
Date: Thu, 07 Nov 2013 15:09:55 +0900

On Nov 2, 2013, at 19:34 , Emil Ivov <[email-masked]> wrote:

> Compared to VP8, H.264 baseline is only marginally better than H.263. This makes it hard to justify the inconvenience of post-installation additions.

Baseline is better than VP8, I think.  But I don't think this debate is about the codec quality, as previously noted (within reason).

David Singer

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 7 Nov 2013 07:19:47 +0100

Re performance, and just so that silence isn't taken as me agreeing with
David Singer on this topic:

I haven't wanted to distract from the debate at hand by tossing more
numbers around, but we do think VP8 is significantly better than Baseline.
The exchanges with Ericsson have shown that we need to be meticulously
clear in defining what we mean by that and how we measure it, so I won't
post more numbers until I feel that our description is precise enough.

Harald

On Thu, Nov 7, 2013 at 7:09 AM, David Singer <[email-masked]> wrote:

> > Compared to VP8, H.264 baseline is only marginally better than H.263.
> This makes it hard to justify the inconvenience of post-installation
> additions.
>
> Baseline is better than VP8, I think.  But I don't think this debate is
> about the codec quality, as previously noted (within reason).
>
> David Singer

---

From: David Singer <[email-masked]>
Date: Thu, 07 Nov 2013 15:35:57 +0900

On Nov 7, 2013, at 15:19 , Harald Alvestrand <[email-masked]> wrote:

> Re performance, and just so that silence isn't taken as me agreeing with David Singer on this topic:
> 
> I haven't wanted to distract from the debate at hand by tossing more numbers around, but we do think VP8 is significantly better than Baseline. The exchanges with Ericsson have shown that we need to be meticulously clear in defining what we mean by that and how we measure it, so I won't post more numbers until I feel that our description is precise enough.

I also would like to see some tests which tell us where we really are.  A lot of us are engineers who like having facts, even if, as many of us realize, the comparative performance is a minor part of the debate.

I welcome Ericsson's efforts to get clarity in this area; they seem to have been working very hard to get a level playing field measure, and if you can help that effort, this would be all to the good.

David Singer

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 07 Nov 2013 07:43:42 +0100

> I welcome Ericsson's efforts to get clarity in this area; they seem to have been working very hard to get a level playing field measure, and if you can help that effort, this would be all to the go…

Yes, agreeing on what the word "level" means seems to be a difficult
undertaking!

The code we're working from lives on this repository:

http://git.chromium.org/webm/vpx_codec_comparison.git

Ericsson's fork has been posted to the list back in July.

-- 
Surveillance is pervasive. Go Dark.

---

From: Gregory Maxwell <[email-masked]>
Date: Thu, 7 Nov 2013 01:47:00 -0800

> I welcome Ericsson's efforts to get clarity in this area; they seem to have been working very hard to get a level playing field measure, and if you can help that effort, this would be all to the go…

Hm.  Maybe I'm confused: I thought slide 9 from the H.264 "joint
presentation" in Atlanta (
http://tools.ietf.org/agenda/85/slides/slides-85-rtcweb-10.pdf )
showed baseline needing 16% more bitrate than VP8 at the same quality,
and the debate was more over high profile and the magnitude of VP8's
lead wrt baseline.

(And, also in agreement: quality isn't the thing to debate in
excruciating detail, but I did think at least this point wasn't
controversial. Did I miss a post?)

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 7 Nov 2013 16:40:15 +0000

The previous comparisons used poor x264 settings and different rate
controls.
The latest comparisons used better x264 settings:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09064.html
...and then more similar rate controls:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09126.html

In the end, it is a draw, with or without rate control. Which was expected
since the actual coding tools are virtually identical. We could have saved
a lot of time and posturing if the codec experts on both sides would have
just admitted this. Performance is a wash (when ignoring high profile).

Mo

On 11/7/13, 4:47 AM, Gregory Maxwell <[email-masked]> wrote:

On Wed, Nov 6, 2013 at 10:35 PM, David Singer <[email-masked]> wrote:
>>numbers around, but we do think VP8 is significantly better than
>>Baseline. The exchanges with Ericsson have shown that we need to be
>>meticulously clear in defining what we mean by that and how we measure
>>it, so I won't post more numbers until I feel that our description is
>>precise enough.
>
> I also would like to see some tests which tell us where we really are.
>A lot of us are engineers who like having facts, even if, as many of us
>realize, the comparative performance is a minor part of the debate.
>
> I welcome Ericsson's efforts to get clarity in this area; they seem to
>have been working very hard to get a level playing field measure, and if
>you can help that effort, this would be all to the good.

---

From: Bo Burman <[email-masked]>
Date: Thu, 7 Nov 2013 17:12:56 +0000

Agree.

Some previous tests between VP8 and H.264, like the one from the Atlanta presentation, have included a rate controller which does something similar to QP-toggling for VP8 but not for H.264. About two weeks ago we sent out a modified test where both codecs are allowed to QP-toggle, and that resulted in no difference between H.264 baseline and VP8 (http://www.ietf.org/mail-archive/web/rtcweb/current/msg09126.html). A more detailed analysis on the problems of previous tests can be found in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09064.html. The result of no difference between H.264 baseline and VP8 is also consistent with the fixed QP test results we had published earlier (http://www.ietf.org/mail-archive/web/rtcweb/current/msg08052.html). We have long argued that compression efficiency tests are best made this way, i.e., without a rate controller, since small changes in the rate control parameters can have a huge impact on the end result, as the example of QP-toggling shows. 

But I fully agree to that quality isn't the thing to debate at the moment.

/Bo Burman

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mo Zanaty (mzanaty)
> Sent: den 7 november 2013 08:40
> To: Gregory Maxwell; David Singer
> Cc: Harald Alvestrand; [email-masked]
> Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8
> 
> The previous comparisons used poor x264 settings and different rate controls.
> In the end, it is a draw, with or without rate control. Which was expected since the actual coding tools are virtually
> identical. We could have saved a lot of time and posturing if the codec experts on both sides would have just admitted
> this. Performance is a wash (when ignoring high profile).
> 
> Mo
> 
> 
> >have been working very hard to get a level playing field measure, and
> >if you can help that effort, this would be all to the good.
> 
> Hm.  Maybe I'm confused: I thought slide 9 from the H.264 "joint presentation" in Atlanta (
> http://tools.ietf.org/agenda/85/slides/slides-85-rtcweb-10.pdf ) showed baseline needing 16% more bitrate than VP8 at
> the same quality, and the debate was more over high profile and the magnitude of VP8's lead wrt baseline.
> 
> (And, also in agreement: quality isn't the thing to debate in excruciating detail, but I did think at least this point wasn't
> controversial. Did I miss a post?) _______________________________________________
> rtcweb mailing list
> [email-masked]

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 7 Nov 2013 20:33:40 +0000

The blog makes a good point I would like to highlight and address:
"If you want us to get 100% serious about H.264 for WebRTC, why not just make it free?  MPEG-LA, you’ll get our attention if you declare software implementations of H.264 codecs for WebRTC free and clear of royalties."

Many (of the ~30) member companies in the MPEG-LA AVC pool agree with this point and pushed for amendments to the license to make constrained baseline profile royalty-free. There were a few objections. So the supporting members took this point directly to MPEG itself (all >200 members), to have a new royalty-free standard called WebVC that is H.264 AVC CBP. This has progressed in MPEG to DIS (Draft Intl Std) status, when IPR declarations are typically made.

In short, most MPEG members are not evil, and want the same thing as the open source and broader communities, including royalty-free licensing.

The Cisco announcement is to remove the dependencies on these MPEG and MPEG-LA efforts (which would, however, remove the redistribution restrictions that people have rightfully criticized).

Mo

On 11/5/13, 7:23 PM, Gustavo Garcia <[email-masked]<mailto:[email-masked]>> wrote:

+1

H.264 licensing as introduced by Cisco is great because it opens the door to truly present H.264 as a viable alternative codec for broad implementation in WebRTC endpoints, but Cisco’s proposal as it stands is not enough to warrant H.264 being adopted as an MTI for WebRTC.

>From TokBox’s point of view, WebRTC needs to be able to solve two needs if true adoption is intended:  1) supporting interoperability with legacy end-points and 2) enabling novel and innovative real-world use-cases on a broad range of software-powered end-points (mobile included, not just browsers)

The option as proposed with H.264 is not really viable in mobile native applications (specifically iOS devices as the situation stands today), whether both endpoints are mobile native or one is browser-based. At TokBox, we are already seeing a wide range of very interesting applications being built on top of WebRTC using native mobile apps as one of the endpoints, and the standard must do the right thing by not preventing these scenarios from playing out.

As far as MTI codecs go, we still believe VP8 is the right option and believe H.264 should be embraced as an optional alternative video codec.The purpose of the WebRTC is not to create a browser compatible with existing solutions (many of which are closed systems) but rather to bring the best possible experience to application developers, extending the capabilities of the web for real-time communication. (More of our views here: http://www.tokbox.com/blog/is-webrtc-ready-for-h-264/)

On Thu, Oct 31, 2013 at 11:47 AM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Monty Montgomery <[email-masked]>
Date: Thu, 7 Nov 2013 15:36:40 -0500

> In short, most MPEG members are not evil, and want the same thing as the
> open source and broader communities, including royalty-free licensing.

I agree, but the structure of the MPEG is such that it only takes one
(or a handful).  We've heard promises of RF baselines stretching back
almost 20 years.

I agree this would be a wholly positive development, but frankly...
call us when it's done.

Monty

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 7 Nov 2013 21:59:43 +0100

The list of declarations made against the proposed baseline document is
available at the bottom of this page:

http://www.iso.org/iso/home/standards_development/governance_of_technical_work/patents.htm

For declarations against the MPEG baseline proposal, look for the number
14496-29.

For some of the declarations, the spreadsheet will tell you whether it's a
Type 1 (royalty free) or Type 2 (royalty bearing) declaration. For the 3
most recent declarations in the spreadsheet, you will even find a link to
the declaration itself.

Draw your own conclusions.

---

From: Krasimir Kolarov <[email-masked]>
Date: Thu, 07 Nov 2013 13:10:19 -0800

One interesting observation from the database is that one of the most recent Type 2 (royalty bearing) declarations on the list is from a major proponent of Royalty Free coding - Motorola Mobility (which is now fully owned by Google).

It looks like a compelling strategy - to offer technology that you support for Royalty Free adoption, while blocking a competing technology with a Type 2 declaration.

Krasimir

On Nov 7, 2013, at 12:59 PM, Harald Alvestrand <[email-masked]> wrote:

> The list of declarations made against the proposed baseline document is available at the bottom of this page:
> 
> For declarations against the MPEG baseline proposal, look for the number 14496-29.
> 
> For some of the declarations, the spreadsheet will tell you whether it's a Type 1 (royalty free) or Type 2 (royalty bearing) declaration. For the 3 most recent declarations in the spreadsheet, you will even find a link to the declaration itself.
>

---

From: cowwoc <[email-masked]>
Date: Thu, 07 Nov 2013 16:13:43 -0500

Are you implying that Google made this move *after* purchasing 
Motorola? If not, your statement sounds factually incorrect.

Gili

On 07/11/2013 4:10 PM, Krasimir Kolarov wrote:
> One interesting observation from the database is that one of the most 
> recent Type 2 (royalty bearing) declarations on the list is from a 
> major proponent of Royalty Free coding - Motorola Mobility (which is 
> now fully owned by Google).
>
> It looks like a compelling strategy - to offer technology that you 
> support for Royalty Free adoption, while blocking a competing 
> technology with a Type 2 declaration.
>
> Krasimir
>
> On Nov 7, 2013, at 12:59 PM, Harald Alvestrand <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> For some of the declarations, the spreadsheet will tell you whether 
>> it's a Type 1 (royalty free) or Type 2 (royalty bearing) declaration. 
>> For the 3 most recent declarations in the spreadsheet, you will even 
>> find a link to the declaration itself.
>>
>> On Thu, Nov 7, 2013 at 9:36 PM, Monty Montgomery <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>

---

From: Krasimir Kolarov <[email-masked]>
Date: Thu, 07 Nov 2013 13:16:06 -0800

The date of the declaration can be seen clearly in the database - August 5, 2013

On Nov 7, 2013, at 1:13 PM, cowwoc <[email-masked]> wrote:

> 
>     Are you implying that Google made this move *after* purchasing Motorola? If not, your statement sounds factually incorrect.
> 
> Gili
>

---

From: cowwoc <[email-masked]>
Date: Thu, 07 Nov 2013 16:17:01 -0500

I stand corrected. Thanks for pointing this out.

Gili

On 07/11/2013 4:16 PM, Krasimir Kolarov wrote:
> On Nov 7, 2013, at 1:13 PM, cowwoc <[email-masked] 
>>> One interesting observation from the database is that one of the 
>>> most recent Type 2 (royalty bearing) declarations on the list is 
>>> from a major proponent of Royalty Free coding - Motorola Mobility 
>>> (which is now fully owned by Google).
>>>
>>>> The list of declarations made against the proposed baseline 
>>>> document is available at the bottom of this page:
>>>>
>>>> it's a Type 1 (royalty free) or Type 2 (royalty bearing) 
>>>> declaration. For the 3 most recent declarations in the spreadsheet, 
>>>> you will even find a link to the declaration itself.
>>>>
>>>> On Thu, Nov 7, 2013 at 9:36 PM, Monty Montgomery 
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 7 Nov 2013 22:27:52 +0100

Krasimir, if you want to discuss licenses with the Motorola Mobility
lawyers, the contact details are in the filing.

My impression when I asked them to file something was that the status of
that project didn't even enter into consideration when they decided how to
respond - but I'm not going to speak for them. If you want to know, call
them.

On Thu, Nov 7, 2013 at 10:10 PM, Krasimir Kolarov <[email-masked]> wrote:

> recent Type 2 (royalty bearing) declarations on the list is from a major
> proponent of Royalty Free coding - Motorola Mobility (which is now fully
> owned by Google).
>
> It looks like a compelling strategy - to offer technology that you support
> for Royalty Free adoption, while blocking a competing technology with a
> Type 2 declaration.
>
> Krasimir
>
> On Thu, Nov 7, 2013 at 9:36 PM, Monty Montgomery <[email-masked]>wrote:
>

---

From: David Singer <[email-masked]>
Date: Fri, 08 Nov 2013 09:18:37 +0900

On Nov 8, 2013, at 6:27 , Harald Alvestrand <[email-masked]> wrote:

> Krasimir, if you want to discuss licenses with the Motorola Mobility lawyers, the contact details are in the filing.

Is there anything ambiguous or unclear that would warrant discussion?  The statement seems fairly straightforward.  And generally, in the standards bodies we work on what is formally said, not what we might learn in hypothetical side-conversations.

> My impression when I asked them to file something was that the status of that project didn't even enter into consideration when they decided how to respond - but I'm not going to speak for them. If you want to know, call them.

It's not Krasimir who wants to know, it's all of us.  The public statement is presumed to be your public statement.

David Singer