Subject: [rtcweb] H.261

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 22 Nov 2013 05:17:45 +0000

On 11/21/13 12:48, Basil Mohamed Gohar <[email-masked]<mailto:[email-masked]>> wrote:
Has anyone actually objected to H.261 being the one MTI codec [...] ?

Assume this wins and all obey. Chrome does H.261+VP8, Firefox does H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. According to various (incredibly extrapolated, possibly inaccurate and sometimes conflicting) sources [1] on who uses what browser, the chance of H.261 fallback is a whopping 30% [2]. Not the minor insignificant case some had assumed.

How will these users react to H.261 QCIF/CIF compared to what they use today, say Skype for example? "This web shit really sucks. I’m going back to Skype and never trying it again." Is that the first (and perhaps last) impression we want from users that try webrtc? Those arguing crappy video is better than no video are ignoring the critical importance of first impressions. While some may accept crappy video as usable, many more may be permanently turned off and tune out even faster than if they got only (good) audio. It’s not as if webrtc is the only game in town. Users have options, so it needs to be competitive with competitive technology which has already set the bar.

We previously narrowed the options down to H.264 and VP8 for good reasons over the course of this excruciatingly long decision. Reopening discarded tangents like H.261 does not move us forward as a workgroup, and certainly does not move webrtc forward as a technology.

Mo

[1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
[2] H.261 fallback % = 2 x VP8-only% x H.264-only% = 2 x Chrome% x (IE% + Safari%)

---

From: Leon Geyser <[email-masked]>
Date: Fri, 22 Nov 2013 07:41:01 +0200

>>How will these users react to H.261 QCIF/CIF compared to what they use
today, say Skype for example? "This web shit >>really sucks. I’m going back
to Skype and never trying it again."
How different is this from: "This WebRTC thing is crap, because it doesn't
even show basic video."
What option do you suggest?

>>We previously narrowed the options down to H.264 and VP8 for good reasons
over the course of this excruciatingly long >>decision. Reopening discarded
tangents like H.261 does not move us forward as a workgroup, and certainly
does not move >>webrtc forward as a technology.

No consensus was reached between H.264 and VP8. All that is left now is
H.261, Theora and maybe MPEG 1 Part 2.

On 22 November 2013 07:17, Mo Zanaty (mzanaty) <[email-masked]> wrote:

>  On 11/21/13 12:48, Basil Mohamed Gohar <[email-masked]> wrote:
>
>  Assume this wins and all obey. Chrome does H.261+VP8, Firefox does
> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. According to
> various (incredibly extrapolated, possibly inaccurate and sometimes
> conflicting) sources [1] on who uses what browser, the chance of H.261
> fallback is a whopping 30% [2]. Not the minor insignificant case some had
> assumed.
>
>  How will these users react to H.261 QCIF/CIF compared to what they use
> today, say Skype for example? "This web shit really sucks. I’m going back
> to Skype and never trying it again." Is that the first (and perhaps last)
> impression we want from users that try webrtc? Those arguing crappy video
> is better than no video are ignoring the critical importance of first
> impressions. While some may accept crappy video as usable, many more may be
> permanently turned off and tune out even faster than if they got only
> (good) audio. It’s not as if webrtc is the only game in town. Users have
> options, so it needs to be competitive with competitive technology which
> has already set the bar.
>
>  We previously narrowed the options down to H.264 and VP8 for good
> reasons over the course of this excruciatingly long decision. Reopening
> discarded tangents like H.261 does not move us forward as a workgroup, and
> certainly does not move webrtc forward as a technology.
>
>  Mo
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Steve Kann <[email-masked]>
Date: Thu, 21 Nov 2013 22:11:48 -0800

Mo,

I think we all agree that choosing H.264 or VP8 would be better, but it is
clear that neither option today has consensus.    Circumstances could change
in the future, but it seems that OpenH264 was not enough to change that
circumstance.

I think that where your scenario might go astray is that users won¹t
associate their poor experience with ³WebRTC², or ³that web stuff² ‹ they
will associate it with the brand of the service which they are using at the
time.

So, for example, if Facebook builds video chat using WebRTC, and they do no
transcoding, 30% of users might associate their poor video with Facebook,
but most of them won¹t call it ³that web shit² ‹ they would say Facebook
video sucks.

Of course, Facebook could decide to transcode 30% of the time, in which case
the user would have a different experience.

Facebook obviously just being used as an example service which might
implement WebRTC video.

-SteveK

From:  "Mo Zanaty (mzanaty)" <[email-masked]>
Date:  Thursday, November 21, 2013 at 9:17 PM
To:  Basil Mohamed Gohar <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  [rtcweb] H.261

> How will these users react to H.261 QCIF/CIF compared to what they use today,
> say Skype for example? "This web shit really sucks. I¹m going back to Skype
> and never trying it again." Is that the first (and perhaps last) impression we
> want from users that try webrtc? Those arguing crappy video is better than no
> video are ignoring the critical importance of first impressions. While some
> may accept crappy video as usable, many more may be permanently turned off and
> tune out even faster than if they got only (good) audio. It¹s not as if webrtc
> is the only game in town. Users have options, so it needs to be competitive
> with competitive technology which has already set the bar.
> 
> We previously narrowed the options down to H.264 and VP8 for good reasons over
> the course of this excruciatingly long decision. Reopening discarded tangents
> like H.261 does not move us forward as a workgroup, and certainly does not
> move webrtc forward as a technology.
> 
> Mo
> 
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: [email-masked]
Date: Fri, 22 Nov 2013 04:47:55 -0800

Lots of uses will be 1:1 calls, and maybe 30% fallback applies in this
case.  My use of WebRTC involves 1:many group calls in the browser with an
MCU.  For 1:many, the options are 1) fallback to common codec and 2)
transcode.  So, for 1:many we can say that the chance of using the fallback
codec is 100%.  Assuming IE and Safari actually ship WebRTC.

On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann <[email-masked]> wrote:

> clear that neither option today has consensus.    Circumstances could
> change in the future, but it seems that OpenH264 was not enough to change
> that circumstance.
>
> I think that where your scenario might go astray is that users won’t
> associate their poor experience with “WebRTC”, or “that web stuff” — they
> So, for example, if Facebook builds video chat using WebRTC, and they do
> no transcoding, 30% of users might associate their poor video with
> Facebook, but most of them won’t call it “that web shit” — they would say
> Facebook video sucks.
>
> Of course, Facebook could decide to transcode 30% of the time, in which
> case the user would have a different experience.
>
> over the course of this excruciatingly long decision. Reopening discarded
> does not move webrtc forward as a technology.
>
> Mo
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 22 Nov 2013 08:53:23 -0800

For 1:many with MCU, I don't understand why you wouldn't do #2, i.e.
transcode. As stated earlier, the bandwidth costs of using an inefficient
codec (which any MCU service will incur) exceed the CPU cost of transcode.

On Fri, Nov 22, 2013 at 4:47 AM, <[email-masked]> wrote:

>> I think we all agree that choosing H.264 or VP8 would be better, but it
>> is clear that neither option today has consensus.    Circumstances could

---

From: Maik Merten <[email-masked]>
Date: Fri, 22 Nov 2013 18:06:13 +0100

The best way to not run into bandwidth problems is *not* to go for 
transcoding. After all, all those video calls need to go through your 
transcoding infrastructure, directing all the traffic your way.

In P2P scenarios there's a much much higher chance of traffic finding a 
nice and direct route.

And talking about H.261: We're talking about video in the range of 0.2 
to 0.8 Mbps. Compression efficiency per-pixel certainly leaves much to 
be desired, but we're talking CIF resolution here.

Maik

Am 22.11.2013 17:53, schrieb Justin Uberti:
> transcode. As stated earlier, the bandwidth costs of using an
> inefficient codec (which any MCU service will incur) exceed the CPU cost
> of transcode.
>
>
> On Fri, Nov 22, 2013 at 4:47 AM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Lots of uses will be 1:1 calls, and maybe 30% fallback applies in
>     this case.  My use of WebRTC involves 1:many group calls in the
>     browser with an MCU.  For 1:many, the options are 1) fallback to
>     common codec and 2) transcode.  So, for 1:many we can say that the
>     chance of using the fallback codec is 100%.  Assuming IE and Safari
>     actually ship WebRTC.
>
>
>
>     On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>         Mo,
>
>         I think we all agree that choosing H.264 or VP8 would be better,
>         but it is clear that neither option today has consensus.
>           Circumstances could change in the future, but it seems that
>         OpenH264 was not enough to change that circumstance.
>
>         I think that where your scenario might go astray is that users
>         won’t associate their poor experience with “WebRTC”, or “that
>         web stuff” — they will associate it with the brand of the
>         service which they are using at the time.
>
>         So, for example, if Facebook builds video chat using WebRTC, and
>         they do no transcoding, 30% of users might associate their poor
>         video with Facebook, but most of them won’t call it “that web
>         shit” — they would say Facebook video sucks.
>
>         Of course, Facebook could decide to transcode 30% of the time,
>         in which case the user would have a different experience.
>
>         Facebook obviously just being used as an example service which
>         might implement WebRTC video.
>
>         -SteveK
>
>
>
>         From: "Mo Zanaty (mzanaty)" <[email-masked]
>         <mailto:[email-masked]>>
>         To: Basil Mohamed Gohar <[email-masked]
>         <mailto:[email-masked]>>
>         Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>
>         Subject: [rtcweb] H.261
>
>             On 11/21/13 12:48, Basil Mohamed Gohar
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>             Assume this wins and all obey. Chrome does H.261+VP8,
>             Firefox does H.261+H.264+VP8, IE does H.261+H.264, Safari
>             does H.261+H.264. According to various (incredibly
>             extrapolated, possibly inaccurate and sometimes conflicting)
>             sources [1] on who uses what browser, the chance of H.261
>             fallback is a whopping 30% [2]. Not the minor insignificant
>             case some had assumed.
>
>             How will these users react to H.261 QCIF/CIF compared to
>             what they use today, say Skype for example? "This web shit
>             really sucks. I’m going back to Skype and never trying it
>             again." Is that the first (and perhaps last) impression we
>             want from users that try webrtc? Those arguing crappy video
>             is better than no video are ignoring the critical importance
>             of first impressions. While some may accept crappy video as
>             usable, many more may be permanently turned off and tune out
>             even faster than if they got only (good) audio. It’s not as
>             if webrtc is the only game in town. Users have options, so
>             it needs to be competitive with competitive technology which
>             has already set the bar.
>
>             We previously narrowed the options down to H.264 and VP8 for
>             good reasons over the course of this excruciatingly long
>             decision. Reopening discarded tangents like H.261 does not
>             move us forward as a workgroup, and certainly does not move
>             webrtc forward as a technology.
>
>             Mo
>
>             _______________________________________________ rtcweb
>             mailing list [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Fri, 22 Nov 2013 09:06:39 -0800

The point that I was making (perhaps not very clearly) is that in many use
cases, the common codec is much more important than that 30% number would
suggest.  My priority is having an efficient common video codec.  I would
transcode as a last resort.

Also, my concern with transcoding is not cost, but scalability.  I can find
a dedicated server for a couple hundred dollars per month that would give
me 100TB of bandwidth.  If I had to transcode, then I would run out of cpu
cycles long before I ran out of bandwidth.  If I only have to route packets
and transcrypt, then the balance between cpu and bandwidth allows much more
efficient resource utilization.

Perhaps the math on cpu vs bandwidth cost that you are referring to was
based on AWS -- I use dedicated hardware.

---

From: Ron <[email-masked]>
Date: Sat, 23 Nov 2013 03:40:20 +1030

On Fri, Nov 22, 2013 at 05:17:45AM +0000, Mo Zanaty (mzanaty) wrote:
> How will these users react to H.261 QCIF/CIF compared to what they use today ...

You seem to be forgetting that WebRTC is a communication protocol
for PEOPLE, not some one-sided push technology that gives them
take it or leave it choices decided by self-interested vendors.

So I would assume they'll react the same way they already do.
Something along the lines of:

  "D00d!!  Y U use that crap browser!??!111"

And then they'll use the amazing text capabilities to paste
a download link for firefox or something.

  2 minutes later, problem solved.

And they'll be watching each other's cats do fun things in full
hi-res glory.

It's not some accident of fate that the vendor browsers have the
poor level of mindshare that they do, even given the solid advantage
of incumbency they should otherwise enjoy.

If the only way they think they can compete is via lock in and
exclusivity using codec patents, then that alone speaks for the
irrelevancy of those opinions about what is best for making this
standard become ubiquitous.

We need to guarantee interoperability between things that claim to
implement the standard.  Quality of implementation is something
that users will judge for themselves, and their mindshare will
again gravitate accordingly between the available options.

I'd still much prefer a better codec than H.261 as our baseline,
but if the proprietary patent holders refuse to let us have that,
then we need to work with the technology that is available to us.

It doesn't take a doctorate in formal logic to connect those dots.

This is our next best option for "making the patents evaporate",
are people really now saying they didn't really want that to
actually happen after all, despite what they said previously?

  Ron

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 11:23:02 -0600

You are not going to avoid patent issues with H.261.  Even if all patents associated with the H.261 specification have expired you are going to run into generic video patents around motion estimation or rate distortion and many, many other areas that have not.  At the end of the day, if a patent troll sees you have money, they are going to find a way to sue you.

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Ron
Sent: Friday, November 22, 2013 9:10 AM
To: [email-masked]
Subject: Re: [rtcweb] H.261

On Fri, Nov 22, 2013 at 05:17:45AM +0000, Mo Zanaty (mzanaty) wrote:
> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. 
> According to various (incredibly extrapolated, possibly inaccurate and 
> sometimes
> fallback is a whopping 30% [2]. Not the minor insignificant case some 
> had assumed.
> 

You seem to be forgetting that WebRTC is a communication protocol for PEOPLE, not some one-sided push technology that gives them take it or leave it choices decided by self-interested vendors.

And then they'll use the amazing text capabilities to paste a download link for firefox or something.

And they'll be watching each other's cats do fun things in full hi-res glory.

It's not some accident of fate that the vendor browsers have the poor level of mindshare that they do, even given the solid advantage of incumbency they should otherwise enjoy.

If the only way they think they can compete is via lock in and exclusivity using codec patents, then that alone speaks for the irrelevancy of those opinions about what is best for making this standard become ubiquitous.

We need to guarantee interoperability between things that claim to implement the standard.  Quality of implementation is something that users will judge for themselves, and their mindshare will again gravitate accordingly between the available options.

I'd still much prefer a better codec than H.261 as our baseline, but if the proprietary patent holders refuse to let us have that, then we need to work with the technology that is available to us.

This is our next best option for "making the patents evaporate", are people really now saying they didn't really want that to actually happen after all, despite what they said previously?

  Ron

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Nov 2013 09:43:56 -0800

> codec (which any MCU service will incur) exceed the CPU cost of transcode.

That ignores the engineering and latency costs.  Not to say that it
isn't an option, but that's picking the holes in the wrong part of
Mo's argument.

---

From: Maik Merten <[email-masked]>
Date: Fri, 22 Nov 2013 19:08:45 +0100

Disclaimer: IANAL

You can get *sued* for anything from anyone at any time. Trolls are not 
in the business of making sound claims on technology, they're in the 
business of getting paid to leave you alone.

However, you will have as good a defense as you can get if you can point 
to a 25 years old reference implementation. Such an old reference 
implementation (including an encoder) exists for H.261, meaning a set of 
encoder techniques should be identifiable that is "as safe as it can 
be". Of course, if your encoder introduces encoding techniques beyond 
that you're not automatically "safe" anymore. However, the existence of 
spec-compliant H.261 encoders in the late 1980ies clearly means that old 
techniques exist that are useful for creating valid H.261 streams.

In a nutshell: Doing really old stuff *should* actually improve your 
standing regarding IPR claims.

Of course, a troll might have a nice patent like "Method and apparatus 
for doing real-time bible lessons over a digital network in the context 
of hypertext-enabled applications" which might or might not read on any 
WebRTC implementation, no matter what the codec. The fix for that: Don't 
implement anything, ever.

Maik

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 12:27:43 -0600

The whole argument around H.261 came up as a way around potential patent issues.  My argument is that it is literally impossible and thus we should not have that factor into our decision on what technology to use.

Your last point is the most critical, if you're worried about litigation from patent trolls don't do anything or if you do, don't be successful at it.

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Maik Merten
Sent: Friday, November 22, 2013 10:09 AM
To: [email-masked]
Subject: Re: [rtcweb] H.261

Disclaimer: IANAL

You can get *sued* for anything from anyone at any time. Trolls are not in the business of making sound claims on technology, they're in the business of getting paid to leave you alone.

However, you will have as good a defense as you can get if you can point to a 25 years old reference implementation. Such an old reference implementation (including an encoder) exists for H.261, meaning a set of encoder techniques should be identifiable that is "as safe as it can be". Of course, if your encoder introduces encoding techniques beyond that you're not automatically "safe" anymore. However, the existence of spec-compliant H.261 encoders in the late 1980ies clearly means that old techniques exist that are useful for creating valid H.261 streams.

In a nutshell: Doing really old stuff *should* actually improve your standing regarding IPR claims.

Of course, a troll might have a nice patent like "Method and apparatus for doing real-time bible lessons over a digital network in the context of hypertext-enabled applications" which might or might not read on any WebRTC implementation, no matter what the codec. The fix for that: Don't implement anything, ever.

Maik

Am 22.11.2013 18:23, schrieb Stefan Slivinski:
>> According to various (incredibly extrapolated, possibly inaccurate 
>> and sometimes
>> conflicting) sources [1] on who uses what browser, the chance of 
>> H.261 fallback is a whopping 30% [2]. Not the minor insignificant 
>> case some had assumed.
>>

---

From: Maik Merten <[email-masked]>
Date: Fri, 22 Nov 2013 20:04:08 +0100

While it is indeed impossible to reach absolute safety, there are 
low-risk scenarios. H.261 enables you to go down a "lowest possible 
risk" route. Given that the codec discussion was mostly centered around 
whether certain formats are connected to acceptable risks or not, this 
has value.

Maik

---

From: Ron <[email-masked]>
Date: Sat, 23 Nov 2013 05:56:41 +1030

On Fri, Nov 22, 2013 at 11:23:02AM -0600, Stefan Slivinski wrote:
> You are not going to avoid patent issues with H.261.  Even if all patents
> associated with the H.261 specification have expired you are going to run
> into generic video patents around motion estimation or rate distortion and
> many, many other areas that have not.  At the end of the day, if a patent
> troll sees you have money, they are going to find a way to sue you.

You keep repeating this, but it's not clear to me what you are actually
arguing here?

Are you saying that the concerns of the VP8 objectors are irrelevant
since the only confirmed relevant IP is freely licenced (just like H.261
now is), and that we should use it instead?

For the people who can't use H.264, the problem is intractable, unless
the holders of its patents revise their licence terms, or until they
also expire.

For the people who say they can't use VP8, the problem is much as you
describe, "maybe some mugger will spring out of the hedges", despite
the protections provided by its licencing.

There seems to be general agreement that the patent risk of H.261 is
no greater than for *any* other technology that will go into this
standard (will you be allowed to establish a connection with one click?)
and that its age provides a certain amount of shelter an implementor
could cower under should that be their best choice.

When was the last time you heard Stephan agree that some technology was
fairly sure to be unencumbered ;?   I rest my case ...

The interesting question that remains is do we have consensus that the
patent risk of MPEG1 is equally minimal (or will be by the time there
are implementations of WebRTC using it out in the wild and/or this
standard is ratified).

If we do, then it remains an option for the MTI video codec.

If there is consensus that the fear of it is too great to expose people
to, then we only have one "safe" choice left for us to consider that
addresses the concerns of those objecting to VP8, and has none of the
problems of H.264.

As I said right after the last meeting, I think we're still a long way
from having exhausted the normal IETF consensus procedures on this
question - though we do seem to be at the point where most people now
realise their most preferred codec option is going to be steadfastly
prevented from achieving consensus by the objections of others.

And so we again basically only have 2 options:

 - Those objections are rejected as vexatious by the chairs and we
   find that we do have consensus on one of the original preferences. [1]

 - Those objections are upheld as valid consensus blockers by the
   chairs, and we need to look at other solutions which address them.

The latter is what the people proposing H.261 are directly addressing.
I'm not sure which part of that you find confusing.

  Ron

[1] - which would seem to be difficult, assuming they both like their
      role in the IETF and like it to remain uncontroversial, and like
      the job they have with their present employers :)

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 13:30:34 -0600

No, this is taking things to extremes.  This codec hasn't been used in any industry for 15 years.  The entire video conferencing industry uses H.264, the broadcast industry uses H.264, the streaming video industry uses H.264, facetime, skype both use H.264.  The list goes on and on.  There is not a single company is existence today using H.261 over H.264 because of patent fears.  It is asinine that this is even being discussed.

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Maik Merten
Sent: Friday, November 22, 2013 11:04 AM
To: [email-masked]
Subject: Re: [rtcweb] H.261

While it is indeed impossible to reach absolute safety, there are low-risk scenarios. H.261 enables you to go down a "lowest possible risk" route. Given that the codec discussion was mostly centered around whether certain formats are connected to acceptable risks or not, this has value.

Maik

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Nov 2013 11:51:02 -0800

On 22 November 2013 11:30, Stefan Slivinski <[email-masked]> wrote:
> It is asinine that this is even being discussed.

+1

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Fri, 22 Nov 2013 20:59:27 +0100

> No, this is taking things to extremes.  This codec hasn't been used in any industry for 15 years.  The entire video conferencing industry uses H.264, the broadcast industry uses H.264, the streamin…

You misunderstood the issue. h264 has already an incompatible licensing 
policy for many situations, especially towards open source. Not using 
h264 is not about fears of new patents, but because of the conditions 
imposed by exiting patents.

The vp8 vs h261 is actually the case when today none of them has a 
known/final incompatible license, but of course, the future is not 
known. Against vp8 there are some claims, but none with a final decision 
in court (some already dismissed in early stages).

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

---

From: David Singer <[email-masked]>
Date: Fri, 22 Nov 2013 12:08:17 -0800

Um

> the protections provided by its licencing.

It’s much worse than that.  The IETF has a formal “will not license” on the table, and there are active lawsuits.  For most standards bodies, a “will not license” statement requires an analysis, and removal of technology as needed.  Now, it may be that the analysis and lawsuits end up revealing that the patents do not, in fact, read.  But we cannot just assume that.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Ron <[email-masked]>
Date: Sat, 23 Nov 2013 06:42:28 +1030

On Fri, Nov 22, 2013 at 01:30:34PM -0600, Stefan Slivinski wrote:
> No, this is taking things to extremes.  This codec hasn't been used in any
> industry for 15 years.  The entire video conferencing industry uses H.264,
> the broadcast industry uses H.264, the streaming video industry uses H.264,
> facetime, skype both use H.264.  The list goes on and on.

And this working group exists precisely _because_ the other solutions in
existence today all have obvious failings.

A solution that depended on technology with a restrictive licence that
prevented many potential implementors from being able to deploy it would
just be a very long winded way of adding one to the number of failed
solutions in this space.

So we _can't_ choose H.264 which has exactly that problem.

We're also told we can't choose VP8 "because patent fears".

One of those problems has a potential solution available to us.

> There is not a single company is existence today using H.261 over H.264
> because of patent fears.  It is asinine that this is even being discussed.

I especially like the irony that obstinate fearmongering of unknown
VP8 patents are exactly why we're now resigned to discussing it.

  Thanks for the giggle.  Hee Haw,
  Ron

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 14:11:00 -0600

As I'm sure everyone in this group is aware, Cisco has provided an open source implementation of H.264 and they will cover the patent licensing fees.  Seems like this would be a good option for the little guys worried about dealing with the mpeg-la

-----Original Message-----
From: Daniel-Constantin Mierla [mailto:[email-masked]] 
Sent: Friday, November 22, 2013 11:59 AM
To: Stefan Slivinski; Maik Merten; [email-masked]
Subject: Re: [rtcweb] H.261

> No, this is taking things to extremes.  This codec hasn't been used in any industry for 15 years.  The entire video conferencing industry uses H.264, the broadcast industry uses H.264, the streamin…

You misunderstood the issue. h264 has already an incompatible licensing policy for many situations, especially towards open source. Not using
h264 is not about fears of new patents, but because of the conditions imposed by exiting patents.

The vp8 vs h261 is actually the case when today none of them has a known/final incompatible license, but of course, the future is not known. Against vp8 there are some claims, but none with a final decision in court (some already dismissed in early stages).

Daniel

--
Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Nov 2013 12:17:25 -0800

> existence today all have obvious failings.

Well, all technologies have failings--generally obvious ones--but it's
certainly
not correct that RTCWEB exists because of failings in the media codecs
used by previous solutions.

-Ekr

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 22 Nov 2013 15:19:15 -0500

Stefan,

I am not trying to be condescending or put down your comments, but
actually, a lot of what you are bringing up now has been discussed on
this list earlier, and we still arrived where we're at.

The Cisco offer, if and when it actual reaches fruition, solves some but
not all problems with using H.264 as an MTI codec.  It definitely widens
the audience that can use H.264 in some cases, but there are definitely
use cases it does not cover, because H.264 *itself* is not licensed in a
way that is usable.  I'd like to point you to this posting [1] I made
years ago after a long interview process with a representative from
MPEG-LA, which reaches some interesting conclusions.

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

-- 
Libre Video
http://librevideo.org

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Fri, 22 Nov 2013 21:22:43 +0100

> As I'm sure everyone in this group is aware, Cisco has provided an open source implementation of H.264 and they will cover the patent licensing fees.  Seems like this would be a good option for the…
Maybe you haven't understood the Cisco deal either -- they are not 
covering the license for the open source version, only for the binary 
version that one has to always download from cisco. They plan to release 
the sources under BSD, but who wants to use them directly, they have to 
deal with mpeg-la.

I am sure if you go back to archive and read the discussion, you will 
find all these (and even more) aspects that makes Cisco offer unfeasible 
in many situations.

Daniel

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 14:44:39 -0600

Thank you for the link.

The point I'm trying to make is H.261 will harm the proliferation of webrtc far more than it will help.  This is purely a technical argument speaking to quality and error resiliency.

Has anyone listed the concerns surrounding H.264 and have these been raised with mpeg-la to see if they can make adjustments to the license agreement.  They have certainly done so in the past.

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Basil Mohamed Gohar
Sent: Friday, November 22, 2013 12:19 PM
To: [email-masked]
Subject: Re: [rtcweb] H.261

Stefan,

I am not trying to be condescending or put down your comments, but actually, a lot of what you are bringing up now has been discussed on this list earlier, and we still arrived where we're at.

The Cisco offer, if and when it actual reaches fruition, solves some but not all problems with using H.264 as an MTI codec.  It definitely widens the audience that can use H.264 in some cases, but there are definitely use cases it does not cover, because H.264 *itself* is not licensed in a way that is usable.  I'd like to point you to this posting [1] I made years ago after a long interview process with a representative from MPEG-LA, which reaches some interesting conclusions.

[1]

On 11/22/2013 03:11 PM, Stefan Slivinski wrote:
> As I'm sure everyone in this group is aware, Cisco has provided an 
> open source implementation of H.264 and they will cover the patent 
> licensing fees.  Seems like this would be a good option for the little 
> guys worried about dealing with the mpeg-la
> 
> You misunderstood the issue. h264 has already an incompatible 
> licensing policy for many situations, especially towards open source. 
> Not using

---

From: Maik Merten <[email-masked]>
Date: Fri, 22 Nov 2013 21:54:47 +0100

Numerous parties have elaborated on why they cannot deploy H.264 due to 
its licensing terms. In short: Some business or operating models simply 
cannot be aligned with H.264's licensing terms. It's all in the mailing 
list archive.

And again, H.261 is only considered as fallback option to establish 
basic video interoperability as no single high-performance video codec 
can be agreed on. It would only kick into action in situations when the 
alternative would be "no video at all". This fallback option has to be 
implementable without relevant restrictions.

Of course, if consensus can be reached that more modern codecs such as 
MPEG-1 Part 2 or H.263 can be implemented and deployed with acceptable 
risk and without restrictions that would be preferable.

Maik

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 22 Nov 2013 15:56:51 -0500

> Has anyone listed the concerns surrounding H.264 and have these been raised with mpeg-la to see if they can make adjustments to the license agreement.  They have certainly done so in the past.

Believe it or not, the MPEG-LA is currently trying to establish a
royalty-free subset of H.264 called "Constrained Baseline Profile",
which is very similar to the most commonly-used subset of H.264 features
out there.

The problem is, it's not done yet, and there's no indication whether or
not it will be successful or not.  This would require all existing
stakeholders in H.264 licensing to agree to this royalty-free variant
for it to matter.

There's another effort to do the same with one using MPEG-1 as a base.

The problem is, none of these formally exist in royalty-free forms as of
yet.  Everything else we've discussed, though, does, including H.261.

And, for what it's worth, I disagree about H.261.  Yes, H.264 and/or VP8
(and a whole list of other codecs) will look *better*, but I think being
able to communicate via video over H.261 is better than not being able
to all.

And we are at a point where "not at all" is going to happen because the
WG is effectively split over using VP8 and H.264.

-- 
Libre Video
http://librevideo.org

---

From: Ron <[email-masked]>
Date: Sat, 23 Nov 2013 07:31:13 +1030

On Fri, Nov 22, 2013 at 12:08:17PM -0800, David Singer wrote:
> It’s much worse than that.  The IETF has a formal “will not license” on the
> table, and there are active lawsuits.  For most standards bodies, a “will not
> license” statement requires an analysis, and removal of technology as needed.
> Now, it may be that the analysis and lawsuits end up revealing that the
> patents do not, in fact, read.  But we cannot just assume that.

As you said yourself just a few minutes ago:

> I’m not sure I’d call that a detailed analysis;  a detailed analysis would
> include, for example, opening up the 31/34 patent statements for each codec,
> identifying the patents, and seeing whether they had yet expired.

except s/had yet expired/were even remotely relevant/

It is indeed most unfortunate that the IETF disclosure policy allows anyone
to make even the most blatantly bogus claim and places no onus on them to
correct or retract it even once proven so.

I'm yet to see anyone take down their existing support for VP8, or point
to a particular section of code that any of that IPR core dump is relevant
to in any way.  At least one claim has already been dismissed by the court
that heard it.  And the MTI audio codec has similar bogus claims made for
it too (that have since been conclusively refuted but are still up).

The timing of the particular mugger you refer to springing from the hedges
here will in itself be an interesting point for historians of the future.
And maybe for anti-trust lawyers too.

I'd also note those patents *still* aren't declared against H.264, despite
that being their origin, and that neither the Cisco offer, nor MPEG LA, do
licence them.  The deafening silence on this is itself a notable concern.

People are actively trying to find a workable solution to the concerns
that you profess here.  Mounting a bipolar argument about which side of
the question the onus of proof belongs to depending on what you are
arguing for or against makes it a bit tricky to take that professed
concern seriously and address it as anything more than simple sophistry.

I'm pretty sure that if you can point to which part of the VP8 technology
concerns you, people would be very interested in examining that and as
you say, removing or reimplementing it as needed.  There's surely more
scope for fixing it than for fixing H.263 where the patents were designed
into it from the outset.

Unless you show us the proof where it does, we can only address your
claimed concerns as the generic handwaving that they are - with a
generically 'accepted as safe' solution.

And if we accept that handwaving, then we really can't accept the
"implement any 2" solution either.  Since that would still have the
risk of of the sets becoming disjoint should your vague fear actually
ever really play out.

  Woof,
  Ron

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 15:14:05 -0600

Why don't we add the "must support both H.264 and VP8 decode and must support at least one of H.264 or VP8 encode" to the list of options and ask for a show of hands as to what people are in favor of.  This would be non-binding, simply a status check.  Maybe no one is in favor of H.261 except for a vocal minority in which case we're wasting time arguing about it.

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Basil Mohamed Gohar
Sent: Friday, November 22, 2013 12:57 PM
To: [email-masked]
Subject: Re: [rtcweb] H.261

> Has anyone listed the concerns surrounding H.264 and have these been raised with mpeg-la to see if they can make adjustments to the license agreement.  They have certainly done so in the past.

Believe it or not, the MPEG-LA is currently trying to establish a royalty-free subset of H.264 called "Constrained Baseline Profile", which is very similar to the most commonly-used subset of H.264 features out there.

The problem is, it's not done yet, and there's no indication whether or not it will be successful or not.  This would require all existing stakeholders in H.264 licensing to agree to this royalty-free variant for it to matter.

The problem is, none of these formally exist in royalty-free forms as of yet.  Everything else we've discussed, though, does, including H.261.

And, for what it's worth, I disagree about H.261.  Yes, H.264 and/or VP8 (and a whole list of other codecs) will look *better*, but I think being able to communicate via video over H.261 is better than not being able to all.

And we are at a point where "not at all" is going to happen because the WG is effectively split over using VP8 and H.264.

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 Nov 2013 16:01:13 -0600

On 11/22/13 14:22, Daniel-Constantin Mierla wrote:
> They plan to release the sources under BSD, but who wants to use them 
> directly, they have to deal with mpeg-la. 

Every time this kind of statement is made without also including "if 
they distribute more than 100,000 copies a year", it's a bald 
misrepresentation of the situation.

I'm not saying the 100,000-copy exemption is a silver bullet. But it 
sure does cut down the number of people who have to deal with MPEG-LA, 
and completely addresses the "what if I want to have a enterprise disk 
image?" question. And ignoring it to exaggerate your case doesn't do 
anyone any favors.

/a

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 22 Nov 2013 17:44:46 -0500

> image?" question. And ignoring it to exaggerate your case doesn't do

Free software projects do not have a reliable mechanism by which to
count their distribution, since it is sent out through many means, not
the least of which can include direct downloads, SCM code checks (e.g.,
Github), GNU/Linux and *BSD distibutions (which can easily exceed
100,000 for the most popular ones), to name a few.

Where does the liability for counting lie in each of these cases?  The
licensing restrictions that MPEG-LA has placed on H.264 is very
free-software unfriendly for any cases where you want rights to be
transitive - which is a key, fundamental aspect of software freedom.

-- 
Libre Video
http://librevideo.org

---

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

On Fri, Nov 22, 2013 at 04:01:13PM -0600, Adam Roach wrote:
> >They plan to release the sources under BSD, but who wants to use
> >them directly, they have to deal with mpeg-la.
> 
> 
> sure does cut down the number of people who have to deal with
> MPEG-LA, and completely addresses the "what if I want to have a
> enterprise disk image?" question. And ignoring it to exaggerate your
> case doesn't do anyone any favors.

So to put this into perspective ...

If you wrote a piece of software, and made it Free (as in libre) and
it got picked up by one or more of the (even moderately popular) distros,
then you'd quite likely blow your 100,000 copy limit within just a few
days of mirror pushes.

Even before anyone may have actually used it at all.

And before you deal with the non-MPEG-LA patent holders.

Understating the degree to which this is a problem does nobody any
favours either.

  Ron

---

From: David Singer <[email-masked]>
Date: Fri, 22 Nov 2013 15:42:24 -0800

On Nov 22, 2013, at 12:54 , Maik Merten <[email-masked]> wrote:

> And again, H.261 is only considered as fallback option to establish basic video interoperability as no single high-performance video codec can be agreed on. It would only kick into action in situations when the alternative would be "no video at all". This fallback option has to be implementable without relevant restrictions.

I rather suspect that many, given a choice between:
a) deliver crappy video using H.261, with the unstated implication to the users at the two ends that they really need to find something that will interoperate on something better
and
b) tell the users directly that they don’t have a video codec in common, and to get video they need to find something that will interoperate

would actually prefer (b).  It’s less work, more direct, and more honest.

David Singer

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 22 Nov 2013 18:44:26 -0500

> Multimedia and Software Standards, Apple Inc.

Then we need to restate one of the goals of this WG if we're not going
to have an MTI.  However, I personally disagree with that change.

-- 
Libre Video
http://librevideo.org

---

From: David Singer <[email-masked]>
Date: Fri, 22 Nov 2013 15:45:02 -0800

> transitive - which is a key, fundamental aspect of software freedom.

Curiously, I think that the position is that if you distribute source (e.g. of FFMPeg, X264) then the person who compiles it is making the final product, so if everyone builds it themselves, they are in a product distribution group size of 1.

Don’t rely on me, IANAL.

David Singer

---

From: David Singer <[email-masked]>
Date: Fri, 22 Nov 2013 15:46:14 -0800

> to have an MTI.  However, I personally disagree with that change.

No, I think we all want an MTI codec.  But not at any price in terms of quality degradation, and H.261 may be simply off the bottom end.

David Singer

---

From: Ron <[email-masked]>
Date: Sat, 23 Nov 2013 11:05:48 +1030

On Fri, Nov 22, 2013 at 03:45:02PM -0800, David Singer wrote:
> Curiously, I think that the position is that if you distribute source (e.g.
> of FFMPeg, X264) then the person who compiles it is making the final product,
> so if everyone builds it themselves, they are in a product distribution group
> size of 1.

The whole point of many distros is to supply binaries, often built
many times for many different system architectures.  So even when
source copies are also distributed there's a large multiplier for
binaries, which is then multiplied again by uncountable tiers of
(both public and private) distribution mirrors.

And many projects available as source also produce binary releases,
in particular for systems where people aren't used to building
binaries for themselves (like Windows and OSX).  These also are
often mirrored by other services that specialise in this (but
provide no auditable account of downloads) - often without the
knowledge of, and almost always without asking the permission of,
the original binary creator, as is their right for any freely
licenced software.

Then maybe you've heard of this newfangled thing called CDN ...

The problem is quite simply intractable without a major change to
the H.264 licencing scheme.

No amount of saying "well my homepage never gets 100k hits", and
"my appstore app only had 20 downloads" is really going to change
that a 100,000 download limit is effectively the same as a Zero
download limit on an internet that wasn't designed to count every
copy of every thing made by every user.

Once you publish it anywhere you have no idea how short a time it
will take to exceed that.  And you can't even take it back down
again, even if you wanted to.  And if somebody claims you have made
X copies, based on some fuzzy math, you have no way to dispute that
except with more fuzzy guesswork.

If H.264 is really this important to you, for reasons other than
vendor exclusivity and lock-in, then do what Google did, go and
buy out the licence holders and put it under a useable licence.
If "nobody is making any money out of this" as they all claim,
then it should even be pretty cheap, right?

People might actually Really Genuinely thank you for that :)

  Ron

---

From: Lorenzo Miniero <[email-masked]>
Date: Sat, 23 Nov 2013 01:39:35 +0100

On Fri, 22 Nov 2013 16:01:13 -0600

> image?" question. And ignoring it to exaggerate your case doesn't do 

This 100k again... Apart from the fact that, even for the free 100k units, you still have to track them, which apparently is an all but simple task: as I asked repeatedly on the list (without ever getting an answer), what makes a unit? what counts in the famous 100k list? if I install a transcoding mixer application on a server, does that count as 1 unit? or do I have to count a unit each time I attach a user to the mixer, i.e., whenever I allocate an encoder/decoder? or anything else? any answer, which I still haven't received, would put that 100k in a different perspective. The only info I could find around was related to an even more obscure subscription vs. title-by-title distinction that confused me even more.

Lorenzo

-- 
Lorenzo Miniero, COB

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 23 Nov 2013 01:45:10 +0100

* David Singer wrote:
>Curiously, I think that the position is that if you distribute source 
>(e.g. of FFMPeg, X264) then the person who compiles it is making the 
>final product, so if everyone builds it themselves, they are in a 
>product distribution group size of 1.

I trust MPEG-LA just HATES this one weird trick...
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Steve Kann <[email-masked]>
Date: Fri, 22 Nov 2013 20:09:40 -0500

We keep tailing about this 100k cap as if there are no additional obligations on folks:

- they still need to define what units mean and count them (problem well described in recent posts)
- even in the situation below (compile by user, etc) In order to be covered by the 100k minimum, you still need to count and also submit to a quarterly reporting requirement.

So this sounds great:  
- you distribute your product in source form. 
- you ask your users to compile it on their own ( I'm guessing automating this might be problematic)
- you ask your users to request and complete paperwork with MPEG-LA, and submit to quarterly reporting requirements. 

Sounds fantastic for those guys. Imagine that this was required for tcp-Reno?

Anyway, I think we should establish a consensus call requesting we don't talk about h.264-only or vp8-only MTI options. I think we can find consensus that unless something significant changes (and Cisco's openh264 action was significant but insufficient), that we will not get consensus there.   I don't know how procedure works, but I think we all just need to accept and move on. 

-Sent from an iOS mobile device

> On Nov 22, 2013, at 7:45 PM, Bjoern Hoehrmann <[email-masked]> wrote:
> 
> * David Singer wrote:

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 Nov 2013 19:36:59 -0600

On 11/22/13 18:35, Ron wrote:
> many times for many different system architectures.

And the overwhelming majority of these do so by including a list of 
repositories from which the binaries can be downloaded.

I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, 
and whatever else is needed for these distros, targeting whatever 
platforms are required. Now, whether we can get the distro maintainers 
to add a single line to their list of repos -- because that's all it 
would take -- is a different issue. But at that point, it's just a 
matter of the distro maintainers being intransigent rather than any real 
technical or legal barrier.

/a

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 19:42:45 -0600

Just for fun, let's play out the H.261 scenario as the great savior of webrtc that some claim it is:

Let's say through some divine miracle we manage to all agree to make H.261 the one and only MTI codec.  The rationale being of course that no one will ever use it because it is of course terrible, but we need it to get around those pesky patent/license terms with VP8/H.264 respectively.

Alright fast forward, Chrome adds H.261 but continues to use VP8.  IE uses H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261, H.264 and VP8.  So far so good.  Chrome can talk using VP8 to Firefox, Safari can talk H.264 to IE, Firefox can either H.264 or VP8 to everyone.  As long as Chrome users don't try to call IE or Safari, we're in good shape, otherwise we need to transcode using some undefined cloud based transcoder service or just use H.261.

So we're still in good shape.  Now let's consider the multiway case.  I heard a use case at the conference on Tuesday where a university was using webrtc to enable video online classes.  So let's assume there are 20 people in the class.  19 people in the class love Chrome, so they join the class from chrome and are all sending each other VP8.  But of course there's always one person that has to be difficult and they decide they prefer IE.  So what now?   Well the IE person doesn't understand any of the 19 VP8 streams and the 19 chrome users don't understand the 1 H.264 stream.  So we can now utilize that same undefined cloud transcoding service to convert each of the 19 VP8 streams to H.264 and the 1 H.264 stream to VP8....or we can use H.261.

My guess is H.261 is going to get used a lot more than anyone thinks.

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Friday, November 22, 2013 5:37 PM
To: Ron; [email-masked]
Subject: Re: [rtcweb] H.261

> many times for many different system architectures.

And the overwhelming majority of these do so by including a list of repositories from which the binaries can be downloaded.

I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, and whatever else is needed for these distros, targeting whatever platforms are required. Now, whether we can get the distro maintainers to add a single line to their list of repos -- because that's all it would take -- is a different issue. But at that point, it's just a matter of the distro maintainers being intransigent rather than any real technical or legal barrier.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 Nov 2013 19:49:20 -0600

On 11/22/13 18:39, Lorenzo Miniero wrote:
> as I asked repeatedly on the list (without ever getting an answer), what makes a unit?

Of course you're not getting an answer from the list. We're not the 
right people to answer that question. I think the address you want is 
<[email-masked]>.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 Nov 2013 20:15:55 -0600

On 11/22/13 19:42, Stefan Slivinski wrote:
> Just for fun, let's play out the H.261 scenario as the great savior of webrtc that some claim it is...
>
> ...
> I'm 100% confident that we could convince Cisco to serve up RPMs...

Stefan: This is the second completely non-sequitur response you've sent 
to my emails over the course of five minutes. I'm not sure what you're 
trying to accomplish, but I don't think it's productive.

/a

---

From: Ron <[email-masked]>
Date: Sat, 23 Nov 2013 12:57:50 +1030

On Fri, Nov 22, 2013 at 07:36:59PM -0600, Adam Roach wrote:
> I'm 100% confident that we could convince Cisco to serve up RPMs,
> DPKGs, and whatever else is needed for these distros, targeting
> whatever platforms are required. Now, whether we can get the distro
> maintainers to add a single line to their list of repos -- because
> that's all it would take -- is a different issue. But at that point,
> it's just a matter of the distro maintainers being intransigent
> rather than any real technical or legal barrier.

So, now you want people to give Cisco not only the ability to
install binary blobs on their machine -- but a root shell to do
it as well?  What could possibly go wrong.

I'd laugh but my intransigence gland doesn't appear to be
secreting the necessary humors ...

  Moving along, nothing technical or legal to see here,
  just a mirror, a single line, and a razor blade ...

  Snort,
  Ron

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 20:40:11 -0600

This isn't specifically in response to anything you have said, this thread is about H.261, I'm simply addressing arguments made in favor of H.261 as the single MTI and the problems that will arise

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Friday, November 22, 2013 6:16 PM
To: Stefan Slivinski; [email-masked]
Subject: Re: [rtcweb] H.261

> I'm 100% confident that we could convince Cisco to serve up RPMs...

Stefan: This is the second completely non-sequitur response you've sent to my emails over the course of five minutes. I'm not sure what you're trying to accomplish, but I don't think it's productive.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 Nov 2013 21:38:12 -0600

> it as well?  What could possibly go wrong.

It's... uh... um... I'm a bit incredulous.

Look, it's *Cisco*. If they *wanted* to attack you, this would be 
possibly the least worrisome vector.

/a

---

From: Stefan Slivinski <[email-masked]>
Date: Fri, 22 Nov 2013 21:58:39 -0600

yes, it appears I missed that....Byran Donnovan's point is exactly in line with my comment here, even a small sized multiway conferences has a high likelihood of dissimilar browsers and will either require a transcoding MCU or they will be forced down to a common codec.

-----Original Message-----
From: Hervé W. [mailto:[email-masked]] 
Sent: Friday, November 22, 2013 7:12 PM
To: Stefan Slivinski; [email-masked]
Subject: RE: [rtcweb] H.261

----------------------------------------
> From: [email-masked]

> Let's say through some divine miracle we manage to all agree to make H.261 the one and only MTI codec. The rationale being of course that no one will ever use it because it is of course terrible, b…

Either you need the fallback codec or no one will ever use it. They can't both be right. I realise that you're illustrating that exact point below, but you're misrepresenting the rationale behind h.261, I think.

> So we're still in good shape. Now let's consider the multiway case. I heard a use case at the conference on Tuesday where a university was using webrtc to enable video online classes. So let's assu…

Yes, they can offer an extra H.261 stream to that IE user and receive a H.261 stream from them. And then watch H.261 play about as well as the 18 other P2P streams, while they clog up their Wifi and overheat their laptops ?
I think you've found a scenario that might benefit from No MTI; audio only or no streams to/from the IE user can't hurt network performance.

> My guess is H.261 is going to get used a lot more than anyone thinks.

related to that: http://www.ietf.org/mail-archive/web/rtcweb/current/msg10058.html

- Hervé

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Nov 2013 20:23:32 -0800

On Fri, Nov 22, 2013 at 7:38 PM, Adam Roach <[email-masked]> wrote:

> Look, it's *Cisco*. If they *wanted* to attack you, this would be possibly
> the least worrisome vector.

And of course the binaries would be digitally signed and one could do
verifiable builds.

-Ekr

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Sat, 23 Nov 2013 04:45:26 +0000

All major distros including Debian already include x264, ffmpeg, etc.
http://packages.debian.org/wheezy/x264

Those packages offer no patent license at all. What is the perceived
unique risk of Cisco¹s H.264? It attempts to license the patents legally
instead of leaving users bare naked. If the FOSS community sees this as
worse than the current situation, and feels its users are better off
naked, it would be good to understand why.

Mo

On 11/22/13, 8:36 PM, Adam Roach <[email-masked]> wrote:

/a

---

From: cowwoc <[email-masked]>
Date: Sat, 23 Nov 2013 01:59:35 -0500

This post is not meant to target Stefan specifically. It is a general 
statement based on what I've noticed over the past 200+ posts on this topic.

I am ... concerned ... by the apparently attempt by certain individuals 
to have options removed ahead of a possible vote. It is one thing to 
explain your opinion in order to encourage/discourage people from voting 
for it. It is another matter to imply that an option is a "waste of 
time" because only a "vocal minority" seems to care about it or that 
"given the choice between what you are proposing and X, most developers 
would prefer X". If no one is in favor of H.261 "except for a vocal 
minority" or "most developers would prefer X" then you have nothing to 
worry about. Let the community vote and see where the chips land. I 
don't think it's safe to rely on "vocal minorities" to gauge what the 
community at large prefers. The only way to find out is to ask them (and 
that's what the vote is all about).

Everyone should be free to express their opinion for/against an option, 
but no option should be removed ahead of a vote.

Just my 2 cents.

Gili

---

From: cowwoc <[email-masked]>
Date: Sat, 23 Nov 2013 02:23:23 -0500

Stefan,

At the conference, they mentioned that you cannot implement online video 
classes (with 20+ participants) unless you reduce the resolution and 
frame rate of non-speakering participants. Meaning, even without having 
to do any transcoding (they use VP8 across the board) there is 
insufficient bandwidth and CPU to handle 20 incoming video streams at HD 
resolutions. So what you do is host non-speakers at tiny resolutions and 
3 fps.

H.261 could handle those non-speakers just fine (in fact, it would be 
preferable as it reduces CPU usage). Furthermore, if you chose to 
transcode, you'd be dealing with tiny resolutions and 3fps. In both 
cases, the use of H.261 or transcoding is not the bottleneck.

Gili

---

From: Lorenzo Miniero <[email-masked]>
Date: Sat, 23 Nov 2013 12:08:16 +0100

On Fri, 22 Nov 2013 19:49:20 -0600

> <[email-masked]>.

If no one has a clue either, then, why make the 100k point in the first place? Because as I said, a different answer can describe a completely different scenario, and have your 100k units potentially consumed by a single app.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 23 Nov 2013 06:59:14 -0800

Gili,

I would like to push back on this a bit. Say that we had general consensus
that Theora was strictly better than H.261. I think it would be OK to remove
H.261. Obviously, if there's any significant dissent, we shouldn't, but I'm
already pretty sad about all the options, and I don't think it's bad to
winnow
the field if there is near-unanimity on something....

-Ekr

On Fri, Nov 22, 2013 at 10:59 PM, cowwoc <[email-masked]> wrote:

> I am ... concerned ... by the apparently attempt by certain individuals to
> have options removed ahead of a possible vote. It is one thing to explain
> your opinion in order to encourage/discourage people from voting for it. It
> is another matter to imply that an option is a "waste of time" because only
> a "vocal minority" seems to care about it or that "given the choice between
> what you are proposing and X, most developers would prefer X". If no one is
> in favor of H.261 "except for a vocal minority" or "most developers would
> prefer X" then you have nothing to worry about. Let the community vote and
> see where the chips land. I don't think it's safe to rely on "vocal
> minorities" to gauge what the community at large prefers. The only way to
> find out is to ask them (and that's what the vote is all about).
>
>> Why don't we add the "must support both H.264 and VP8 decode and must
>> support at least one of H.264 or VP8 encode" to the list of options and ask
>> for a show of hands as to what people are in favor of.  This would be
>> non-binding, simply a status check.  Maybe no one is in favor of H.261
>> except for a vocal minority in which case we're wasting time arguing about
>> it.
>>
>>> The point I'm trying to make is H.261 will harm the proliferation of
>>> webrtc far more than it will help.  This is purely a technical argument
>>> speaking to quality and error resiliency.
>>>
>>> Has anyone listed the concerns surrounding H.264 and have these been
>>> raised with mpeg-la to see if they can make adjustments to the license
>>> agreement.  They have certainly done so in the past.
>>>
>> royalty-free subset of H.264 called "Constrained Baseline Profile", which
>> is very similar to the most commonly-used subset of H.264 features out
>> there.
>>
>> stakeholders in H.264 licensing to agree to this royalty-free variant for
>> it to matter.
>>
>> able to communicate via video over H.261 is better than not being able to
>> all.
>>

---

From: [email-masked]
Date: Sat, 23 Nov 2013 07:00:46 -0800

Gili,

Large group conferences, classes, seminars, etc., typically have 1 person
sending and N persons receiving -- at least where my product is concerned.
 This is 1:N, not mesh conferencing.  My original point, the one that
Stefan said he was agreeing with, was to do with the fact that you would
always be using the common codec when you have multiple people receiving
the same video stream on different browsers, unless you wanted to transcode
the video.  Granted, this would be 1 transcode for each sending stream, not
1 transcode for each receiver, so the cost is not terrible.

On Fri, Nov 22, 2013 at 11:23 PM, cowwoc <[email-masked]> wrote:

> classes (with 20+ participants) unless you reduce the resolution and frame
> rate of non-speakering participants. Meaning, even without having to do any
> transcoding (they use VP8 across the board) there is insufficient bandwidth
> and CPU to handle 20 incoming video streams at HD resolutions. So what you
> do is host non-speakers at tiny resolutions and 3 fps.
>
> transcode, you'd be dealing with tiny resolutions and 3fps. In both cases,
> the use of H.261 or transcoding is not the bottleneck.
>
> Gili
>
>
>> Let's say through some divine miracle we manage to all agree to make
>> H.261 the one and only MTI codec.  The rationale being of course that no
>> one will ever use it because it is of course terrible, but we need it to
>> get around those pesky patent/license terms with VP8/H.264 respectively.
>>
>> Alright fast forward, Chrome adds H.261 but continues to use VP8.  IE
>> uses H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261,
>> H.264 and VP8.  So far so good.  Chrome can talk using VP8 to Firefox,
>> Safari can talk H.264 to IE, Firefox can either H.264 or VP8 to everyone.
>>  As long as Chrome users don't try to call IE or Safari, we're in good
>> shape, otherwise we need to transcode using some undefined cloud based
>> transcoder service or just use H.261.
>>
>> So we're still in good shape.  Now let's consider the multiway case.  I
>> heard a use case at the conference on Tuesday where a university was using
>> webrtc to enable video online classes.  So let's assume there are 20 people
>> in the class.  19 people in the class love Chrome, so they join the class
>> from chrome and are all sending each other VP8.  But of course there's
>> always one person that has to be difficult and they decide they prefer IE.
>>  So what now?   Well the IE person doesn't understand any of the 19 VP8
>> streams and the 19 chrome users don't understand the 1 H.264 stream.  So we
>> can now utilize that same undefined cloud transcoding service to convert
>> each of the 19 VP8 streams to H.264 and the 1 H.264 stream to VP8....or we
>> can use H.261.
>>
>> and whatever else is needed for these distros, targeting whatever platforms
>> are required. Now, whether we can get the distro maintainers to add a
>> single line to their list of repos -- because that's all it would take --
>> is a different issue. But at that point, it's just a matter of the distro
>> maintainers being intransigent rather than any real technical or legal
>> barrier.
>>
>> /a

---

From: Stefan Slivinski <[email-masked]>
Date: Sat, 23 Nov 2013 10:50:02 -0600

As an individual with a deep background in video compress and someone who works for a company that builds products across a wide variety of architectures that do indeed incorporate H.261, I am in a good position to voice my technical knowledge as it relates to H.261.  I have nothing personal against H.261, it was a great technology when it was ratified and for many years after but it is no longer.  I don't think anyone wants H.261, they are simply pushing for it out of frustration about the lack of consensus regarding H.264/VP8.  

The reality is the concerns raise over the license terms with H.264 are valid, some people might be taking things to the extreme but regardless they need to be addressed.  There is IMO a lot of FUD floating around here, most of it is probably unintentional but in any event we need more accurate information.  I have setup a meeting with our patent attorney's to get their perspective on some of the licensing concerns raise as they relate to H.264 in the hopes of getting a more accurate analysis.

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of cowwoc
Sent: Friday, November 22, 2013 11:00 PM
To: [email-masked]
Subject: [rtcweb] Opinions are fine, bypassing a vote is not (was: H.261)

This post is not meant to target Stefan specifically. It is a general statement based on what I've noticed over the past 200+ posts on this topic.

I am ... concerned ... by the apparently attempt by certain individuals to have options removed ahead of a possible vote. It is one thing to explain your opinion in order to encourage/discourage people from voting for it. It is another matter to imply that an option is a "waste of time" because only a "vocal minority" seems to care about it or that "given the choice between what you are proposing and X, most developers would prefer X". If no one is in favor of H.261 "except for a vocal minority" or "most developers would prefer X" then you have nothing to worry about. Let the community vote and see where the chips land. I don't think it's safe to rely on "vocal minorities" to gauge what the community at large prefers. The only way to find out is to ask them (and that's what the vote is all about).

Everyone should be free to express their opinion for/against an option, but no option should be removed ahead of a vote.

Just my 2 cents.

Gili

---

From: Ron <[email-masked]>
Date: Sun, 24 Nov 2013 05:19:34 +1030

> naked, it would be good to understand why.

That's not a package which I maintain, or have had anything to do with,
so if you're looking for an explanation of what the people who do might
be thinking, then I'll have to disappoint you, sorry. [1]

If you're looking for legal advice, then I'm doubly not your man, I'm
just a software guy, you'll want to address that to the role address
that Debian has for such things, [email-masked].

  Ron

[1] - So I shouldn't need to clarify this here, of all places, but since
there's talk of voting, ramming through a mandate for things which have
strong objections and a single unguaranteed supplier, cabbages and kings,
and other clear nonsense like having unknown and unaccountable sysadmins
at random companies install "DPKGs" on everyone's machines - and people
making summaries that talk about "Debian's opinion", I guess I need to
restate the obvious ...  if only for the people who actually know nothing
at all about what Debian is and how it works.

I do not, and indeed cannot, speak _for_ Debian.  I don't hide my
significant affiliations, but since I'm not a Chair or AD, or hold
any other role in the IETF, I can only, ever, speak solely as an
individual contributor.  And only ever have.

There have been people here who have sought to express "their employer's
opinion", but since that's just obviously irrelevant extra baggage here,
that's not a hammer I've ever swung in any working group.

Debian as an organisation, is actually similar to the IETF in many ways.
Aside from a small handful of people endowed with delegations for various
tasks (of which I'm not one), contributors are all volunteer individuals,
who are essentially responsible for only their own contributions.

If you want the "Opinion of Debian", you're going to need to have a shit
fight on another list, to draft a position statement (or several dozen
options for one), and then hold a General Resolution, where 1000-odd
people will vote to see if we can 'agree' on any of them.  And there
you'll again face many people who (like me), think voting is a useless
way to determine anything more important than whether our logo should
be the chicken or the swirl - and from past experience know that trying
this for actually significant contentious issues, is typically intensely
damaging and divisive, leaving scars that take years to heal, if they
ever finally do.

I would strongly, as an individual, recommend the Chairs of this WG
learn from our mistakes there and not seek to repeat them here too. [2]
Whatever the result of the vote may be, it _will_ escalate through
every level of protest available, and possibly invent several new
ones too.  People who wanted nothing more than for this group to
fail spectacularly, will laugh their asses off at the havoc wreaked
beyond their wildest imagination.

[2] - Since as every pilot knows, you won't live long enough to make
      them all yourself :)

---

From: Ron <[email-masked]>
Date: Sun, 24 Nov 2013 05:34:57 +1030

On Sat, Nov 23, 2013 at 06:59:14AM -0800, Eric Rescorla wrote:
> that Theora was strictly better than H.261.

Do you think that such a consensus might actually exist?

It seems fairly obvious to me that Theora would be a better choice than
H.261, but I haven't seen any indication that it wouldn't be subject to
exactly the same FUD that VP8 has.  Is my impression wrong about that?

If it's not, then H.261 _does_ have the advantage of its IPR and licencing
situation being far less controversial - dare I say near to irrefutable?

I'd be willing to entertain a consensus call on the idea that Theora was
considered _strictly_ better than H.261 here.  And happy to be proven
wrong in this case.

> I'm already pretty sad about all the options

amen.

> and I don't think it's bad to winnow the field if there is near-unanimity
> on something....

I agree.  I'm likewise disappointed that your repeated hints about the
troubles of voting for a field filled with many questionable options
seems to have been lost in the noise.

  Ron

---

From: Adam Roach <[email-masked]>
Date: Sat, 23 Nov 2013 13:39:17 -0600

On 11/23/13 05:08, Lorenzo Miniero wrote:
> If no one has a clue either, then, why make the 100k point in the first place?

Because the situation you're describing is applicable to only a tiny 
sliver of the people involved in this space. If you have a question 
about the corner cases, you need to ask experts. I'm sorry we can't 
optimize your corner cases to the detriment of the normal ones, but 
that's just good engineering practice.

/a

---

From: Lorenzo Miniero <[email-masked]>
Date: Sat, 23 Nov 2013 21:53:00 +0100

On Sat, 23 Nov 2013 13:39:17 -0600

> that's just good engineering practice.

The example I made, maybe, not the applicability of the question. The same could apply to a browser, mobile app or whatever: am I consuming a unit installing the browser which includes an encoder/decoder, or each time I start a call? Too bad I have no lawyer or expert to ask to.

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Sat, 23 Nov 2013 22:05:54 +0100

> that's just good engineering practice.
Why is open source distributing model a corner case? Or can you detail 
who are you counting in this tiny sliver?

Afaik, you are now working for Mozilla Foundation, thus Firefox, the 
open source browser. Without a call home (or to Cisco in this case), 
would you be able to count how many copies of Firefox are distributed 
out there?

For sake of clarification, 100 000 or higher/lower makes no difference 
from my point of view, it is exposing everything to more troubles that 
what it solves. It keeps all the things trapped, so if something is 
getting popular or competing with cisco (or mpeg-la), it can be screwed 
easily. And this can go beyond the financial matter.

Daniel

---

From: Adam Roach <[email-masked]>
Date: Sat, 23 Nov 2013 15:07:52 -0600

> who are you counting in this tiny sliver? 

Conference mixers.

/a

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Sat, 23 Nov 2013 22:11:30 +0100

> Curiously, I think that the position is that if you distribute source (e.g. of FFMPeg, X264) then the person who compiles it is making the final product, so if everyone builds it themselves, they a…
That would require to have also smart phones shipped with a compiler and 
all build dependencies/libraries. Anyhow, most of distros ship binary 
packages.

Daniel

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 23 Nov 2013 13:12:19 -0800

On Sat, Nov 23, 2013 at 12:53 PM, Lorenzo Miniero <[email-masked]>wrote:

> The example I made, maybe, not the applicability of the question. The same
> could apply to a browser, mobile app or whatever: am I consuming a unit
> installing the browser which includes an encoder/decoder, or each time I
> start a call? Too bad I have no lawyer or expert to ask to.

Seriously? May I ask whether you have read the summary terms at:
http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf

They seem relatively clear on this point:
"(a decoder, encoder, or product consisting of one decoder and one encoder
= “unit”)"

More importantly, do you seriously think anyone would license H.264 for
a product if you had to pay $.10 every time the product started up.

-Ekr

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Sat, 23 Nov 2013 22:14:45 +0100

> No, I think we all want an MTI codec.  But not at any price in terms of quality degradation, and H.261 may be simply off the bottom end.
This is the last resort if one doesn't have a better alternative. I 
doubt people that really like wide band audio codecs don't use mobile 
phones on 2G/GSM which is quite poor audio experience, but when you are 
on top of mountains or remote locations is the only option.

Daniel

---

From: Ron <[email-masked]>
Date: Sun, 24 Nov 2013 12:04:00 +1030

On Sat, Nov 23, 2013 at 10:14:45PM +0100, Daniel-Constantin Mierla wrote:
> > No, I think we all want an MTI codec.  But not at any price in terms
> > of quality degradation, and H.261 may be simply off the bottom end.
>
> doubt people that really like wide band audio codecs don't use
> mobile phones on 2G/GSM which is quite poor audio experience, but
> when you are on top of mountains or remote locations is the only
> option.

Actually, it's much more than that.  This is going to be the codec
of last resort "forever".  Think about that.  Think hard.  I'll wait.

Unless we are going to resign ourselves to this whole standard being
a bad joke, that will be discarded in a few short years time, with
all the work that has gone into it needing to be repeated *again*,
then this specification is going to vastly outlive any codec that
happens to be flavour of the month today.

Which means long after H.264 has fallen out of favour and stopped
being included in hardware and "legacy devices", and possibly during
that fun period where people screw up the royalty rates hard to get
people to move on to H.265 or whatever the next revenue raiser will
be, implementations of this standard would still need to carry that
dead baggage.  Forever.

Let's take a quick look at how that might compare:

 For the RM8 implementation of H.261:

  p64dir$ sloccount .
  Total Physical Source Lines of Code (SLOC) = 6,707

 For x264 (from git a few minutes ago):

  x264$ sloccount .
  Total Physical Source Lines of Code (SLOC) = 89,663

One of these has been 'stable' since 1995.  The other is still fixing
several bugs a month, even as we speak.

One of these will still be a standard applicable to the PSTN for as
long as it continues to be around (just like G.711).  The other will
be consigned to the dusts of history with H.262 and H.263, probably
well before vinyl records are.

H.265 is already out.  VP9 is nearly already out.  Daala is going
to kick all of their asses like Opus did ...

These are the codecs that people are _actually_ going to use by the
time this standard is actually completed and well established.

So remind me again why we want to take all of the obvious pain today
to mandate a codec that will also be orders of magnitude more pain
in perpetuity?  Who wants to still be fixing security bugs in H.264
in 2020?  When people have long since stopped actually using or
testing it.

Yes, H.261 is not quite as trivial as G.711, but compared to H.264
it's near enough.  It was designed to run on 'computers' made of
snot and matchsticks and rubber bands.  If we are going to burden
ourselves with having to carry an obsolete codec forever, whatever
we do -- then maybe there actually is a genuine argument that H.261
is not just a compromise we'll all hate, but it could in fact be,
when all things are considered, a clearly superior choice in its
own right for the MTI fallback of last resort.

Shocking I know.

But I guess that's what happens when you take a step back from
short sighted, short term, "best for me today" considerations
and look at the big picture here.

I cordially invite everyone else to do the same :)

  Ron

---

From: Martin Thomson <[email-masked]>
Date: Sat, 23 Nov 2013 20:12:22 -0800

On 23 November 2013 17:34, Ron <[email-masked]> wrote:
> Forever.

Just like DVI4 [RFC3551].  Oh wait [RFC7007].

---

From: Stefan Slivinski <[email-masked]>
Date: Sat, 23 Nov 2013 22:29:39 -0600

I don't want to make any assumptions as to why their particular use case failed at 20+ participants.  Maybe it was bandwidth related, maybe it was because intel quicksync doesn't support VP8.  I don't know and I'm not going to speculate.  What I do know is intel quicksync is capable of decoding H.264 at 4K without breaking a sweat.  4K is more than 80x (yes, eighty times) the resolution of H.261.  So H.261 isn't likely to have helped them here.

What few seem to acknowledge is that companies like intel, TI, qualcomm, broadcom (just to name a few) have spent hundreds of millions (if not billions) of dollars adding hardware accelerate for H.264 to their chips.  Purpose designed hardware will always be faster and require less power than software implementations and no one is spending anything supporting H.261 hardware acceleration.  

H.261 does not have any technical advantage whether it be bitrate, performance, power consumption or otherwise over H.264 on any modern media processor

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of cowwoc
Sent: Friday, November 22, 2013 11:23 PM
To: [email-masked]
Subject: Re: [rtcweb] H.261

Stefan,

At the conference, they mentioned that you cannot implement online video classes (with 20+ participants) unless you reduce the resolution and frame rate of non-speakering participants. Meaning, even without having to do any transcoding (they use VP8 across the board) there is insufficient bandwidth and CPU to handle 20 incoming video streams at HD resolutions. So what you do is host non-speakers at tiny resolutions and
3 fps.

H.261 could handle those non-speakers just fine (in fact, it would be preferable as it reduces CPU usage). Furthermore, if you chose to transcode, you'd be dealing with tiny resolutions and 3fps. In both cases, the use of H.261 or transcoding is not the bottleneck.

Gili

---

From: Ron <[email-masked]>
Date: Sun, 24 Nov 2013 16:31:28 +1030

> Just like DVI4 [RFC3551].  Oh wait [RFC7007].

Are you suggesting that two interoperable implementations of H.264
will not be found, or just confusing the difference between recommended
and mandatory to implement?

If H.264 and/or VP8 and anything else that people fancy are simply given
SHOULD or MAY status "Just like DVI4", then we can indeed update the
recommendations in the spec at a later date easily just like this.

That's _exactly_ what I'm suggesting.

That we seriously consider the future burden that MANDATORY will impose.
Since changing that will break the interoperability guarantee.

Choosing something that actually is trivial to maintain over that sort
of timespan is a decision that people in the (not too distant) future
might actually look back on as having some forethought.

If you'd like to think about it a bit more, I'll keep waiting ;p

  Ron

---

From: Leon Geyser <[email-masked]>
Date: Sun, 24 Nov 2013 08:02:36 +0200

If we fallback to a software H.261 encoder/decoder then will it really use
so much CPU that devices will be unusable or the battery will deplete
early? I didn't know that H.261 was so CPU intensive...
I also agree with Ron that we shouldn't make a codec like H.264 mandatory
that will anyway be obsoleted by the next best thing in the future.

On 24 November 2013 06:29, Stefan Slivinski <[email-masked]> wrote:

> I don't want to make any assumptions as to why their particular use case
> failed at 20+ participants.  Maybe it was bandwidth related, maybe it was
> because intel quicksync doesn't support VP8.  I don't know and I'm not
> going to speculate.  What I do know is intel quicksync is capable of
> decoding H.264 at 4K without breaking a sweat.  4K is more than 80x (yes,
> eighty times) the resolution of H.261.  So H.261 isn't likely to have
> helped them here.
>
> What few seem to acknowledge is that companies like intel, TI, qualcomm,
> broadcom (just to name a few) have spent hundreds of millions (if not
> billions) of dollars adding hardware accelerate for H.264 to their chips.
>  Purpose designed hardware will always be faster and require less power
> than software implementations and no one is spending anything supporting
> H.261 hardware acceleration.
>
> H.261 does not have any technical advantage whether it be bitrate,
> performance, power consumption or otherwise over H.264 on any modern media
> processor
>

---

From: Ron <[email-masked]>
Date: Sun, 24 Nov 2013 17:10:11 +1030

On Sun, Nov 24, 2013 at 08:02:36AM +0200, Leon Geyser wrote:
> early?

No, it won't.  You're pretty much certain to get better battery life
doing software H.261 than hardware H.264 on all but the most retarded
of architectures (ie. something with _no_ powersaving ability at all).
And both of them pale into insignificance against the power your
display will use.

http://www.yosefk.com/blog/its-done-in-hardware-so-its-cheap.html

tldr;  something that take 100x more operations to perform _still_
takes ~100x more operations to perform, and about the same amount of
power, regardless of whether it's run on a "custom processor" (aka
'hardware acceleration') or a general purpose processor (aka CPU).

If you want it to actually go faster too, that will generally use
MORE power, not less.  Ye cannae change the laws o' physics.

Nobody who has actually measured this, or understands anything about
the details of it peddles this kind of snake oil about hardware accel.

> I didn't know that H.261 was so CPU intensive...

It's so CPU intensive that it ran on phones from 25 years ago ...

So I guess we can add "power saving and longer battery life" to
the list of pros for H.261, and reasons someone might deliberately
choose to use it, even if other options are available!

If we keep thinking, the list just keeps growing :)

  Ron

---

From: Stefan Slivinski <[email-masked]>
Date: Sun, 24 Nov 2013 02:10:30 -0600

I'm not suggesting H.261 in software is going to consume less power than H.264 720p in hardware but apples to apples in terms of resolution it's unlikely software is going to come out ahead in very many architectures.

It's not about changing the laws of physics, it's about cutting out what you don't need.  General purpose instruction sets don't necessarily map well to every algorithm, not to mention these hardware acceleration engines can put lots of on chip memory to limit how often they need to go to external memory, and generally speaking hardware acceleration engines run at much lower clock speeds than their host processors.

But don't take my word for it, intel and apple seem to think they saved power:

Comparison on hardware codec vs software codec
http://software.intel.com/en-us/articles/power-benefits-using-intel-quick-sync-video-h264-codec-with-sorenson-squeeze

apple:
see: 'Fourth, there's battery life'  http://www.apple.com/hotnews/thoughts-on-flash/

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Ron
Sent: Saturday, November 23, 2013 10:40 PM
To: [email-masked]
Subject: Re: [rtcweb] H.261

On Sun, Nov 24, 2013 at 08:02:36AM +0200, Leon Geyser wrote:
> If we fallback to a software H.261 encoder/decoder then will it really 
> use so much CPU that devices will be unusable or the battery will 
> deplete early?

No, it won't.  You're pretty much certain to get better battery life doing software H.261 than hardware H.264 on all but the most retarded of architectures (ie. something with _no_ powersaving ability at all).
And both of them pale into insignificance against the power your display will use.

tldr;  something that take 100x more operations to perform _still_ takes ~100x more operations to perform, and about the same amount of power, regardless of whether it's run on a "custom processor" (aka 'hardware acceleration') or a general purpose processor (aka CPU).

If you want it to actually go faster too, that will generally use MORE power, not less.  Ye cannae change the laws o' physics.

Nobody who has actually measured this, or understands anything about the details of it peddles this kind of snake oil about hardware accel.

So I guess we can add "power saving and longer battery life" to the list of pros for H.261, and reasons someone might deliberately choose to use it, even if other options are available!

  Ron

---

From: Maik Merten <[email-masked]>
Date: Sun, 24 Nov 2013 10:12:37 +0100

> What few seem to acknowledge is that companies like intel, TI, qualcomm, broadcom (just to name a few) have spent hundreds of millions (if not billions) of dollars adding hardware accelerate for H.…

It appears that these hardware accelerators are usually not accessible 
to 3rd-party applications on mobile platforms (as has been discussed 
before). Even if they are they may not be consistent regarding available 
settings and performance. Can hardware accelerators, e.g., decode 
several incoming streams in parallel (honest question, I really don't 
know)? How does bitrate control of the embedded encoders behave? Do they 
offer options for error resilience etc. etc.?

IIRC it has been confirmed on this list that Skype deploys H.264 in 
software across all platforms for such reasons. So clearly, the 
theoretical advantages of H.264 hardware support (which works nicely in 
media playback, no doubt) do clearly not transfer quite easily to 
real-time communication on consumer devices. Given that older codecs 
currently in discussion are much more frugal in terms of overall 
computation, deployments in software don't look especially intimidating.

Maik

---

From: Florian Weimer <[email-masked]>
Date: Sun, 24 Nov 2013 17:46:59 +0100

* Stefan Slivinski:

> Alright fast forward, Chrome adds H.261 but continues to use VP8.
> IE uses H.261 and H.264, Safari uses H.261 and H.264 and Firefox
> does H.261, H.264 and VP8.  So far so good.  Chrome can talk using
> VP8 to Firefox, Safari can talk H.264 to IE, Firefox can either
> H.264 or VP8 to everyone.  As long as Chrome users don't try to call
> IE or Safari, we're in good shape, otherwise we need to transcode
> using some undefined cloud based transcoder service or just use
> H.261.

Or use a WebRTC implementation which is written in Actionscript and
thus has access to Chrome's existing H.264 support:

<http://www.adobe.com/devnet/adobe-media-server/articles/encoding-live-video-h264.html>

I don't think availability of licensed H.264 implementations is a
problem.  It's just that the MPEG LA licensing conditions date back to
the early 2000s and it's totally unclear how they'll translate to
WebRTC application developers and commercial end users.  (If you don't
believe me, go and read Adobe's Flash Player 11 licensing agreement.)

---

From: Florian Weimer <[email-masked]>
Date: Sun, 24 Nov 2013 18:04:43 +0100

> a product if you had to pay $.10 every time the product started up.

It's unclear if a WebRTC application that is distributed on demand
would fall into that category if it is capable of using H.264.  The
MPEG LA licensing scheme was devised when this kind of use was not
common.  Also note the lack of reference to mobile devices.

It's also not clear what kind of license commercial use of H.264-based
WebRTC applications by end users would need.  They don't fall into
either of the top-level category.

(The fact that MPEG LA is apparently not structured in a way that
enables it to grant clearcut licenses to commercial users of
videoconferencing solutions doesn't mean they are exempted from
obtaining licenses.)

---

From: cowwoc <[email-masked]>
Date: Sun, 24 Nov 2013 14:23:37 -0500

While I am in favor of most of your arguments, I disagree that anything 
we mandate should be forever. It might make sense to maintain backwards 
compatibility for 5 years or so, but past that point all bets are off 
(I'd drop the deprecated codecs). Backwards-compatibility should not 
last forever, especially now that most applications auto-update themselves.

Practically speaking that means that WebRTC 2.0 would be backwards 
compatible with 1.0, but 3.0 would not be.

Gili

---

From: cowwoc <[email-masked]>
Date: Sun, 24 Nov 2013 14:31:30 -0500

Eric,

Just so there is no confusion: if you manage to convince us that X is 
"strictly better" than H.261 then I'd jump on board. I was trying to 
explain that many people are trying to remove H.261 as an option by 
explaining how bad it is. Going down this road won't change our minds 
because we already agree that it is a shitty codec.

The only way to convince us that X is "strictly better" than H.261 is to 
talk about X (not H.261) and demonstrate that it meets our IPR 
requirements. Do that, and you will have my vote (and probably that of 
others).

Kind regards,
Gili

---

From: cowwoc <[email-masked]>
Date: Sun, 24 Nov 2013 14:42:43 -0500

Stefan,

You are beating a dead horse. No one is arguing that H.261 is 
technically superior to H.264. I'll repeat what I just posted on another 
thread:

Gili

---

From: David Singer <[email-masked]>
Date: Sun, 24 Nov 2013 15:28:39 -0800

On Nov 23, 2013, at 13:11 , Daniel-Constantin Mierla <[email-masked]> wrote:

> That would require to have also smart phones shipped with a compiler and all build dependencies/libraries. Anyhow, most of distros ship binary packages.
> 

If you want a binary package, then Cisco is supplying.  If you want to compile it yourself, you’re not required by any license I know to compile on the same platform as use…and as you note, that would be unusual for some platforms.

David Singer

---

From: Ron <[email-masked]>
Date: Mon, 25 Nov 2013 11:14:54 +1030

On Sun, Nov 24, 2013 at 02:23:37PM -0500, cowwoc wrote:
> While I am in favor of most of your arguments, I disagree that
> anything we mandate should be forever.

I'm not arguing that it _should_ be.

I'm explaining that, empirically, unless this standard is a complete
and utter failure, it absolutely _will_ be.

Successful standards are forever.  RFC 791 is a diamond.

It occasionally gets polished, but never deliberately thrown away
or broken.  For people who invested in it a long time ago, their
investment is still valuable today.

> It might make sense to maintain backwards compatibility for 5 years
> or so, but past that point all bets are off

That would guarantee the failure of this standard.
Who is going to invest all that effort in something doomed to be
obsolete before they've even finished debugging it?  Before it
ever even has a chance to become, as we hope, ubiquitous.

> Backwards-compatibility should not last forever, especially now that
> most applications auto-update themselves.

The PSTN is perfectly capable of carrying full-band Opus in the 64kbs
timeslots that carry G.711.

Yet we mandated G.711 here as important for interop with it, because
nobody realistically expects that successful standard is going to
change.  No matter how crappy or ancient its MTI codec may be.

> compatible with 1.0, but 3.0 would not be.

... only if we completely fail to get the foundations correct.

I have no objection to varying the recommended codecs over time as
better recommendations become available and apparent.  This is what
codec negotiation is for.  This is exactly why those codecs should
be no stronger than recommended, if even that strong.

But the MANDATORY aspects of this standard are its cornerstones.
If you remove those, you no longer have the structure called WebRTC,
you have a collapsed pile of rubble, that _maybe_ you can build some
other thing out of from scratch, with a huge amount of new effort.

And maybe, if you're lucky, that new thing will get adopted not long
after IPv6 actually becomes widely usable and ubiquitous ...
but don't hold your breath for it.

We're not defining a widget library, or toy scripting language here,
where it's ok to tell everybody their old stuff won't work anymore
next year and they'll need to completely rewrite it.

We're proposing a new internet standard.  If people see that it has
no enduring or expected lifetime, they're just going to ignore it
and we're completely wasting our time.  In that case we might as
well just let Google and Mozilla work it out between themselves.
That would be a lot less work and get it deployed a whole lot quicker.

  Ron

---

From: cowwoc <[email-masked]>
Date: Sun, 24 Nov 2013 20:50:48 -0500

On 24/11/2013 7:44 PM, Ron wrote:
> next year and they'll need to completely rewrite it. We're proposing a 
> new internet standard. If people see that it has no enduring or 
> expected lifetime, they're just going to ignore it and we're 
> completely wasting our time.

i think you are being a bit over-dramatic. Say one day we discover that 
codec X is strictly-better than H.261 and decide to replace it. We would 
add X as MTI, alongside H.261 as part of WebRTC 2.0 and announce that 
H.261 is deprecated. Fast forward a few years, and WebRTC 3.0 is about 
to roll out. If we find that 95% [1] of users are using WebRTC 2.0 and 
higher then we can safely remove H.261 as MTI from version 3.0. I see no 
benefit in supporting deprecated features forever, nor do I see how 
removing them will cause WebRTC to fail.

Take a look at http://developer.android.com/about/dashboards/index.html 
... Will Android lose value if they drop support for version 2.2? I 
think not. It has 1.7% market share in spite of the fact it was released 
3.5 years ago.

Mobile platforms and auto-updating applications make it easier and 
easier to drop deprecated features.

[1] 95% is an arbitrary figure, you can use 99% if it makes you happier.

Gili

---

From: Stefan Slivinski <[email-masked]>
Date: Sun, 24 Nov 2013 20:04:54 -0600

Every time I think the horse is dead, it gets back up

-----Original Message-----
From: cowwoc [mailto:[email-masked]] 
Sent: Sunday, November 24, 2013 11:43 AM
To: Stefan Slivinski; [email-masked]
Subject: Re: [rtcweb] H.261

Stefan,

You are beating a dead horse. No one is arguing that H.261 is technically superior to H.264. I'll repeat what I just posted on another
thread:

Just so there is no confusion: if you manage to convince us that X is "strictly better" than H.261 then I'd jump on board. I was trying to explain that many people are trying to remove H.261 as an option by explaining how bad it is. Going down this road won't change our minds because we already agree that it is a shitty codec.

The only way to convince us that X is "strictly better" than H.261 is to talk about X (not H.261) and demonstrate that it meets our IPR requirements. Do that, and you will have my vote (and probably that of others).

Gili

On 23/11/2013 11:29 PM, Stefan Slivinski wrote:
> performance, power consumption or otherwise over H.264 on any modern 
> media processor
>
> At the conference, they mentioned that you cannot implement online 
> video classes (with 20+ participants) unless you reduce the resolution 
> and frame rate of non-speakering participants. Meaning, even without 
> having to do any transcoding (they use VP8 across the board) there is 
> insufficient bandwidth and CPU to handle 20 incoming video streams at 
> HD resolutions. So what you do is host non-speakers at tiny 
> resolutions and
> 3 fps.
>

---

From: Stefan Slivinski <[email-masked]>
Date: Sun, 24 Nov 2013 20:21:46 -0600

All good points.  3rd party support is inconsistent, there are platforms that play nice and others that don't.  It's definitely a problem but in theory everyone could support exposing an API to hardware acceleration.  Typically error resiliency is half-hearted, generally these engines were designed for playing movies or recording videos where packet loss is impossible.  Most of the time issues can be fixed with a firmware upgrade.  As for decoding several streams in parallel, the short answer is no.  some architectures have multiple hardware acceleration engines (TI omap as an example) where this is possible, otherwise it's serial but if you are decoding say 720p30 on a hardware acceleration engine that can do up to 4Kp30 then you can do 9 720p30 streams by decoding one frame for each stream as they arrive.  Managing all the 9 independent streams will usually have some hit to performance in order to page context information in/out of memory so maybe 8 streams is more realistic.

I don't know about skype on every platform, I know one of our products supports skype and we do all the encode/decode in hardware but that's just once example.  But one thing skype didn't do was use H.261.

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Maik Merten
Sent: Sunday, November 24, 2013 1:13 AM
To: [email-masked]
Subject: Re: [rtcweb] H.261

> What few seem to acknowledge is that companies like intel, TI, qualcomm, broadcom (just to name a few) have spent hundreds of millions (if not billions) of dollars adding hardware accelerate for H.…

It appears that these hardware accelerators are usually not accessible to 3rd-party applications on mobile platforms (as has been discussed before). Even if they are they may not be consistent regarding available settings and performance. Can hardware accelerators, e.g., decode several incoming streams in parallel (honest question, I really don't know)? How does bitrate control of the embedded encoders behave? Do they offer options for error resilience etc. etc.?

IIRC it has been confirmed on this list that Skype deploys H.264 in software across all platforms for such reasons. So clearly, the theoretical advantages of H.264 hardware support (which works nicely in media playback, no doubt) do clearly not transfer quite easily to real-time communication on consumer devices. Given that older codecs currently in discussion are much more frugal in terms of overall computation, deployments in software don't look especially intimidating.

Maik

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 27 Nov 2013 03:30:44 +0000

> I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, and whatever else is needed for these distros, targeting whatever platforms are required. Now, whether we can get the distro…

+1 adam and to add a bit more … and also at the same time making sure the source is available so people can compute their own signatures and verify the binary matches the open source and the open source does not contain any malware. 

For distributions that distribute source like debian, they can just keep doing what they are doing now in distributing the source. They can distribute openh264 or x264 or both depending on what is needed and what licenses they like. For the same reason they can currently distribute x264, they can distribute the BSD source.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 27 Nov 2013 03:30:55 +0000

When I go to http://www.librevideo.org, the top headline is "Google Chrome dropping support for H.264, will support only open web codecs in the future" which seem, ah, a little out of date. I think the http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/ article is also a bit confused about the current state of MPEG LA license terms for 264 AVC pool. I do get they MPEG LA terms can be confusing at times but lots of people have figured it out. If people have questions about specific use case I'm glad to try and get them answers.

---

From: cowwoc <[email-masked]>
Date: Tue, 26 Nov 2013 22:40:49 -0500

> When I go to http://www.librevideo.org, the top headline is "Google Chrome dropping support for H.264, will support only open web codecs in the future" which seem, ah, a little out of date. I think…

Sure:

 1. If I recall correctly, someone asked for a more concrete definition
    of a licensing "unit".
 2. On a related note, if my application is downloaded once but
    installed 5 times by the same end-user, how many units is that?
 3. I asked for the ability to license multiple units at a time so we
    deploy images and applications without a separate plugin/download
    process.

Thanks,
Gili

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 27 Nov 2013 05:07:13 +0000

Inline below, with the caveat that I do not represent MPEG-LA; I'm only a guy who works for a company that is both an MPEG-LA licensee and licensor, and therefore have some very limited insight in their thinking process.
Stephan

From: cowwoc <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 26 November, 2013 at 19:40
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] H.261

Sure:

  1.  If I recall correctly, someone asked for a more concrete definition of a licensing "unit".

StW: I do not recall the context, but MPEG-LA licenses (in addition to content, which is not at issue here) a thing called "codec", which is defined as one encoder, one decoder, or one encoder and one decoder. /StW

2. On a related note, if my application is downloaded once but installed 5 times by the same end-user, how many units is that?

StW: I believe the correct answer would be 5.  However, there is a provision that allows you to distribute "disabled" copies of a "codec", and in that case the license fee only becomes due upon the enabling of the copy, for example at the first use.  People use this in conjunction with software activation mechanisms.  /StW

3. I asked for the ability to license multiple units at a time so we deploy images and applications without a separate plugin/download process.

StW: if this is related to MPEG-LA (and not to the Cisco download mechanism) the answer is simple.  You, as an MPEG-LA sublicensee, are responsible for the correct accounting of the number of codecs you "sell" (where "sell" includes things like free download etc.).  MPEG-LA has the right to audit you, and if they do  and you are found cheating, then there are provisions for penalties. /StW

Thanks,
Gili

---

From: cowwoc <[email-masked]>
Date: Wed, 27 Nov 2013 00:26:34 -0500

On 27/11/2013 12:07 AM, Stephan Wenger wrote:
> If I recall correctly, someone asked for a more concrete definition of 
> a licensing "unit".
> StW: I do not recall the context, but MPEG-LA licenses (in addition to 
> content, which is not at issue here) a thing called "codec", which is 
> defined as one encoder, one decoder, or one encoder and one decoder. /StW

I don't think that answers the question. It was my understanding they 
were asking what constitutes one unit (out of the 100k free units we are 
allowed per year). For example, should we be counting the number of 
installs? Or number of concurrent users (e.g. what happens when a user 
installs the software on 5 machines but only runs one at a time?)? Or 
number of downloads? What happens if the same user downloads the app 100 
times? When users uninstall the app, do we get a unit back? The point 
is, we need a very concrete definition of how to count units.

> StW: I believe the correct answer would be 5.  However, there is a 
> provision that allows you to distribute "disabled" copies of a 
> "codec", and in that case the license fee only becomes due upon the 
> enabling of the copy, for example at the first use.  People use this 
> in conjunction with software activation mechanisms.  /StW

(Folded into the above question)

> StW: if this is related to MPEG-LA (and not to the Cisco download 
> mechanism) the answer is simple.  You, as an MPEG-LA sublicensee, are 
> responsible for the correct accounting of the number of codecs you 
> "sell" (where "sell" includes things like free download etc.). 
>  MPEG-LA has the right to audit you, and if they do  and you are found 
> cheating, then there are provisions for penalties. /StW

Good point. I guess I am asking about Cisco's mechanism, since it is the 
one that we will be bound by. I guess this would be much simpler if 
Cisco hit the licensing upper limit, because then we wouldn't need to 
keep on counting.

Gili

---

From: Adam Roach <[email-masked]>
Date: Tue, 26 Nov 2013 23:53:20 -0600

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

> I guess I am asking about Cisco's mechanism, since it is the one that we will be bound by. I guess this would be much simpler if Cisco hit the licensing upper limit, because then we wouldn't need to keep on counting.

If you use Cisco's binary, you don't have to count. Cisco takes care if that for you. As far as I understand, they are paying the cap, but that fact doesn't make any difference to you one way or another. The important thing is that Cisco is distributing the codec, and Cisco is bearing the costs for making sure that anything it distributes is properly licensed. 

/a

---

From: Hrishikesh Kulkarni <[email-masked]>
Date: Wed, 27 Nov 2013 12:09:09 +0530

> codec (which any MCU service will incur) exceed the CPU cost of transcode.

Good point on bandwidth costs. But you need to transcode if the decoding
endpoints/browsers dont support the codec or the bitrate of the source.
This applies to audio and video. If the source video is 720p@800kbps which
could then "transrated" into multiple bitrates at 500kbps or downsized to
480p@300kbps. We did this for audio when Chrome was on isac and Firefox was
on opus.

---

From: Leon Geyser <[email-masked]>
Date: Wed, 27 Nov 2013 08:55:26 +0200

Why not just run the codec at the same bitrates that the other codecs would
of been using anyway? That wouldn't increase the costs of bandwidth.

On 27 November 2013 08:39, Hrishikesh Kulkarni <[email-masked]> wrote:

> On Fri, Nov 22, 2013 at 10:23 PM, Justin Uberti <[email-masked]>wrote:
>
> This applies to audio and video. If the source video is 720p@800kbpswhich could then "transrated" into multiple bitrates at 500kbps or
> downsized to 480p@300kbps. We did this for audio when Chrome was on isac
> and Firefox was on opus.
>
>
>>
>>
>>>> So, for example, if Facebook builds video chat using WebRTC, and they
>>>> do no transcoding, 30% of users might associate their poor video with

---

From: Hrishikesh Kulkarni <[email-masked]>
Date: Wed, 27 Nov 2013 12:56:53 +0530

In that case the source endpoint/browser needs the bandwidth/compute to
produce many encode streams (different codecs/bitrate). I would rather the
MCU handle the transcoding/transrating.

On Wed, Nov 27, 2013 at 12:25 PM, Leon Geyser <[email-masked]> wrote:

> Why not just run the codec at the same bitrates that the other codecs
> would of been using anyway? That wouldn't increase the costs of bandwidth.
>
>
> On 27 November 2013 08:39, Hrishikesh Kulkarni <[email-masked]>wrote:
>
>>>>> I think we all agree that choosing H.264 or VP8 would be better, but
>>>>> it is clear that neither option today has consensus.    Circumstances could
>>>>> Of course, Facebook could decide to transcode 30% of the time, in
>>>>> which case the user would have a different experience.
>>>>>

---

From: cowwoc <[email-masked]>
Date: Wed, 27 Nov 2013 03:00:40 -0500

> If you use Cisco's binary, you don't have to count. Cisco takes care if that for you. As far as I understand, they are paying the cap, but that fact doesn't make any difference to you one way or an…
Hi Adam,

We still need to count. If that weren't the case, Cisco would let us 
bundle their binary as part of our installers. The reason they force us 
to download the binary after-the-fact is so that they can keep track of 
the count.

Gili

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 27 Nov 2013 15:23:49 +0000

On Nov 26, 2013, at 10:26 PM, cowwoc <[email-masked]> wrote:

>> StW: if this is related to MPEG-LA (and not to the Cisco download mechanism) the answer is simple.  You, as an MPEG-LA sublicensee, are responsible for the correct accounting of the number of codecs you “sell” (where “sell” includes things like free download etc.).  MPEG-LA has the right to audit you, and if they do  and you are found cheating, then there are provisions for penalties. /StW
> 
> Good point. I guess I am asking about Cisco's mechanism, since it is the one that we will be bound by. I guess this would be much simpler if Cisco hit the licensing upper limit, because then we wouldn't need to keep on counting.
> 
> Gili

Cisco is going to pay the cap - not because we think counting is hard (even CDNs allow easy counting) - but because we believe that the Firefox usage alone will greatly exceed the cap.

---

From: tim panton <[email-masked]>
Date: Wed, 27 Nov 2013 16:03:33 +0000

On 27 Nov 2013, at 05:26, cowwoc <[email-masked]> wrote:

>> If I recall correctly, someone asked for a more concrete definition of a licensing "unit".
>> StW: I do not recall the context, but MPEG-LA licenses (in addition to content, which is not at issue here) a thing called “codec”, which is defined as one encoder, one decoder, or one encoder and one decoder. /StW
> 
> I don't think that answers the question. It was my understanding they were asking what constitutes one unit (out of the 100k free units we are allowed per year). For example, should we be counting the number of installs? Or number of concurrent users (e.g. what happens when a user installs the software on 5 machines but only runs one at a time?)? Or number of downloads? What happens if the same user downloads the app 100 times? When users uninstall the app, do we get a unit back? The point is, we need a very concrete definition of how to count units.

Or even more fun, if you install an update of the app, say once a month, that’s 12 units per year per user - Or am I misunderstanding the ‘unit’ thing?

T.

---

From: tim panton <[email-masked]>
Date: Wed, 27 Nov 2013 16:05:46 +0000

> If you use Cisco's binary, you don't have to count. Cisco takes care if that for you. As far as I understand, they are paying the cap, but that fact doesn't make any difference to you one way or an…

Unless or until one of your users uses your app for a purpose that isn’t covered by Cisco’s license grant,
at which point you’d better be able to count users by usage type _really_ fast.

T.

---

From: Ron <[email-masked]>
Date: Thu, 28 Nov 2013 02:55:52 +1030

On Wed, Nov 27, 2013 at 03:30:55AM +0000, Cullen Jennings (fluffy) wrote:
> I do get they MPEG LA terms can be confusing at times
> but lots of people have figured it out.

I can only assume that you mean this in the same sense that "lots of people"
have "figured out" those click through EULA conditions that don't actually
allow them to do the things they'll be doing but obviously aren't intended
to be read since a 50 page document is presented in a 4 line scroll box with
no button that says "click here to send this to your lawyer". [1]

Like the ones that say your TV can report everything that's ever watched on
it to the manufacturer, even after you click the Don't Do That button. [2]

Or in the same sense that they drive their motor vehicles without complying
with their legal obligation to keep a bale of hay in the trunk or have some
person walk in front at all times waving a flag.

A licence that says "we'll take your money, but we can't actually grant you
the rights to use this since we don't own or control them - we'll just sort
of promise that WE won't drag you through the courts, in exchange for being
able to track exactly how profitable your business is" -- isn't a licence at
all.  It's a protection racket.  With a dash of industrial espionage thrown
in for good measure.

This isn't something we should be booby trapping IETF standards with.

The IETF has disclosure rules that are aimed at avoiding, so much as is
possible, this sort of Don't ask Don't tell nonsense.  And yet we *still*
don't have disclosures from the H.264 IPR holders that *are* present here
for the use of H.264 in this standard.  Despite them having core dumped
their IPR restrictions on alternative proposals.

How can we possibly take mandating that technology seriously in this light?

That alone should already rule this out from consideration.

> If people have questions about specific use case I'm glad to try and get
> them answers. 

The specific question about how the Cisco offer resolves the problem of
MPEG LA not being the only holder of IPR that would need to be licenced
has so far met with deafening silence.

Glad answers to that would certainly be nice.

People keep making claims about that offer "solving everything", which
can't possibly be true unless you pretend those other licence holders
don't exist.

By comparison, Google at least has shown that it is *very* willing to
do whatever is necessary to ensure that the licence and IPR of VP8 is
very unambiguously exactly as they claim it to be.

That seems a lot more reassuring than the state of denial that has
surrounded promoting H.264.  First pretending the IPR wasn't a problem,
then pretending they could buy us all free tickets, then claiming they
"really wished there was a solution with no IPR burden", then rejecting
that solution when it was actually presented as a compromise.

Then pushing for getting the IETF to vote ...

The number of dimensions in which we'd have to disconnect from reality
to make this proposal acceptable makes even string theory start to look
well grounded.

  Ron

[1] http://i.imgur.com/m0sQKZI.jpg

[2] http://www.bbc.co.uk/news/technology-25042563

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 27 Nov 2013 16:41:32 +0000

Hi,

On 11.27.2013, 08:03 , "tim panton" <[email-masked]> wrote:

>>>content, which is not at issue here) a thing called ³codec², which is
>Or even more fun, if you install an update of the app, say once a month,
>that¹s 12 units per year per user - Or am I misunderstanding the Œunit¹
>thing?

You guys are discussing MPEG-LA FAQ and agreement interpretations.
Therein, there is no such thing as a ³unit² in the context you use it.
When discussing hypothetical interpretations of an agreement text most of
you obviously have never seen, let¹s at least try to stick with
terminology that is known to exist in the agreement.

Broader point:

I doubt very much that you will get an authoritive answer to the those
broad interpretation questions from MPEG-LA, even if they were formulated
in a precise and concise way (which, currently, they certainly are not).
MPEG-LA commonly doesn't want to go public with their own interpretation
of the agreement, and prefer to do so only with consent of the licensor
group, which is harder to obtain than herding cats because of the very
diverse nature of the licensor community.  One motivation of this silence
may be the fear of weakening the license by making public statements about
its interpretation that may provide openings for sharp company lawyers to
cheat out of their licensing obligations.  It¹s a common theme in the
legal community: say as little as possible.

What can be done, and is (so I understand) not uncommon, is that a company
(a prospective licensee, but not a ³community²) contacts MPEG-LA directly,
explains their business model, and asks how that fits within the agreement
language.  This process can result in a side letter that includes an
interpretation of the agreement language tailored to the business model of
the company.  Those side letters are confidential.  The agreement itself
is AFAIK take it or leave it.

Stephan

---

From: tim panton <[email-masked]>
Date: Wed, 27 Nov 2013 17:02:35 +0000

> terminology that is known to exist in the agreement.

My example was lifted from the direct experience of a startup I know who
were indeed charged license fees for every upgrade by the MPEG-LA. 
They ended up shipping partial patches that re-used old binaries to
avoid this issue.

But you are correct I have not read the license.

> is AFAIK take it or leave it.

This is the kind of restrictive thinking that was common place before the web.
Back in the day, if you wanted to use the Nortel SDK, you had to apply to use it, handing over a
detailed app description and business model  to them, which might or might not be 
‘accepted’. 

Tim.

---

From: cowwoc <[email-masked]>
Date: Wed, 27 Nov 2013 13:53:45 -0500

> Cisco is going to pay the cap - not because we think counting is hard (even CDNs allow easy counting) - but because we believe that the Firefox usage alone will greatly exceed the cap.

So why can't we bundle the H.264 codec again? If you are already hitting 
the cap, I don't see a reason to force us to download the codec 
after-the-fact.

Gili

---

From: cowwoc <[email-masked]>
Date: Wed, 27 Nov 2013 13:53:54 -0500

+1. There seems to be a lot of hand waving when it comes to H.264. Some 
very concrete questions are going unanswered.

Gili

---

From: cowwoc <[email-masked]>
Date: Wed, 27 Nov 2013 13:56:00 -0500

This interpretation leaves me very uncomfortable at the thought of using 
H.264 in my own products. How can we base our business on a technology 
when the owner refuses to issue public answers (i.e. commitments) 
regarding its own licensing terms?

This might work for companies with deep pockets for lawyers, but I don't 
think it makes sense for the rest of all. And don't tell me that we're 
safe so long as we use less than "100k units" when the very definition 
of a unit is unknown.

Gili

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Nov 2013 11:22:24 -0800

On Wed, Nov 27, 2013 at 10:53 AM, cowwoc <[email-masked]> wrote:
>>>> deploy images and applications without a separate plugin/download process.
>>>>
>>>> responsible for the correct accounting of the number of codecs you “sell”
>>>> (where “sell” includes things like free download etc.).  MPEG-LA has the
>>>> right to audit you, and if they do  and you are found cheating, then there
>>>> are provisions for penalties. /StW
>>>
>>> one that we will be bound by. I guess this would be much simpler if Cisco
>>> hit the licensing upper limit, because then we wouldn't need to keep on
>>> counting.
>>>
>>> Gili
>>
>> Cisco is going to pay the cap - not because we think counting is hard
>> (even CDNs allow easy counting) - but because we believe that the Firefox
>> usage alone will greatly exceed the cap.
>
>
> So why can't we bundle the H.264 codec again? If you are already hitting the
> cap, I don't see a reason to force us to download the codec after-the-fact.

Because Cisco distributing the copies is what makes them, not you,
responsible for the license fee.

-Ekr

---

From: tim panton <[email-masked]>
Date: Wed, 27 Nov 2013 19:50:52 +0000

> responsible for the license fee.

If (and only if) you and your users meet some as-yet-to-be-defined criteria.
Unless Cisco is indemnifying all possible uses of the downloadable blob?

T.

---

From: cowwoc <[email-masked]>
Date: Wed, 27 Nov 2013 15:39:57 -0500

> responsible for the license fee.

Either you misunderstood my question or I am misunderstanding your 
answer. I'm asking what prevents us from bundling Cisco's binary as part 
of our installer or image? Originally we were told we could not bundle 
their binary in-line because Cisco had to count how many license units 
they were giving out, but now that they say they will hit the cap what 
is the point of counting?

Gili

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Nov 2013 12:42:25 -0800

On Wed, Nov 27, 2013 at 12:39 PM, cowwoc <[email-masked]> wrote:
>>>>>> “sell”
>>>>> Cisco
>>> the
> Either you misunderstood my question or I am misunderstanding your answer.
> I'm asking what prevents us from bundling Cisco's binary as part of our
> installer or image?

What makes it a Cisco product is that it comes from Cisco, not that you
make a bunch of copies and send it to people.

> Originally we were told we could not bundle their binary
> in-line because Cisco had to count how many license units they were giving
> out, but now that they say they will hit the cap what is the point of
> counting?

I don't recall anyone saying that they had to count. What I recall them
saying was that licensing restrictions required them to distribute the
binary directly to end users.

-Ekr

---

From: cowwoc <[email-masked]>
Date: Wed, 27 Nov 2013 15:48:38 -0500

> binary directly to end users.

Makes sense, though if that's the case, what the heck was I discussing 
with Cullen on Wednesday night? :) Remember, we were talking about 
licensing a block of units at a time. Cullen, can you please shed some 
light on this?

Thanks,
Gili

---

From: Engel Nyst <[email-masked]>
Date: Wed, 27 Nov 2013 23:36:25 +0200

> is the point of counting?

MPEG-LA has not licensed the codec to anyone but Cisco, for an year if I 
understand correctly. Cisco pays the license fees for their 
distribution. Cisco's cap is for downloads from their site alone.

Anyone else doesn't have a license from MPEG-LA. No one else can offer 
for download or reuse the codec implementation in their applications, 
unless they strike another deal with MPEG-LA. (or have very small uses, 
of no interest)

It looks like essentially a trap, sorry to say.

-- 
~enyst

"Excuse me, Professor Lessig, but may I ask you to sign this CLA, so 
that we have legally your permission to distribute your CC-licensed words?"
   ~ Permission culture, take two.

---

From: Ron <[email-masked]>
Date: Thu, 28 Nov 2013 08:34:18 +1030

> make a bunch of copies and send it to people.

So, if I buy a video camera with H.264 support from some local store,
are you saying that it's the retailer responsible for purchasing the
licence?  Or maybe it's the sweat-shop fabricator that's responsible
for this?  Who did my camera "come from" in this case?

And are you by extension saying that I'm responsible for a 'unit'
every time that Cisco binary is copied from disk storage to RAM?
What if the disk it's on is in a NAS?

Juries in Texas are going to love this.

  Ron