Subject: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"

From: Mike Linksvayer <[email-masked]>
Date: Tue, 12 Nov 2013 13:53:04 -0800

Hi all,

I was one of the remote attendees last Thursday. Long-time
read-list-via-archives lurker. Interest/excitement because seems
to me WebRTC is the most significant addition to the web in terms
of supporting new types of applications since Ajax, at least. And
specifically the video codec MTI debate, as FLOSS being second class is
a huge burden to projects I'm involved in, as well as being terrible
social policy.

I figured I was contributing by not repeating things that have already
been said many times. :) But it was apparent from the meeting that
posting to the list is valued...

I strongly support VP8 for MTI, and oppose H.264. Undecided on which
of both, either, or neither would be second best. My reason is simply
that FLOSS (and any entity for which users downloading a binary from
Cisco next year is unworkable) is second class at best in the H.264
case, while VP8 is demonstrably acceptable.

I think I appreciate the arguments for H.264, which all (including
those about legal risk) boil down to H.264 having a longer history
and greater adoption in other applications. Those don't flip me,
because, again, FLOSS is my baseline requirement. I realize that some
large companies have different baselines. Frankly, I don't care if the
legal risk to large companies is slightly different for either codec:
if trolls come out after mass implementation of WebRTC, the relevant
companies have resources to fight them, and more incentive to fix the
troll situation and/or end software patents in the interim, the better.

Speaking of now, the interim, and longer term, I was struck by two
brief statements in the meeting.

Jonathan Rosenberg, about 22 minutes into
http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF88_RTCWEB_II&chapter=part_4
> I would love it if all patents evaporated, if all the stuff was
> open  source in ways that we could  use, and we didn’t have to
> deal with any of this mess.

(In the middle of explaining why he thinks H.264 is the best choice
now, given this patent mess.)

Harald Alvestrand, about 48 minutes into
http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF88_RTCWEB_II&chapter=part_9
> Development of codecs has been massively hampered and held back by
> the  fact that it has been done in a fashion that has served to
> maximize the  patent encumbrances on codecs. Sooner or later, we
> should see a way  forward to abandon the dependence on encumbered
> codecs also for video  software. My question, at this juncture,
> is if not now, when?

I didn't hear an answer, but would love to hear one. It is conceivable
I could be convinced of a compromise now, if it were obvious those
individuals and businesses pushing for H.264 were also unambiguously
helping fix the problem in the medium and longer term by helping
next- VP9 and and next-next-generation Daala, and lobbying for the
elimination of software patents.

Mike

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Tue, 12 Nov 2013 17:14:24 -0500

> Hi all,
<snip>
> troll situation and/or end software patents in the interim, the better.
<snip>
> Mike

For brevity, I snipped the pieces that I thought didn't need repeating
above.  I, for one, simply wanted to say I was thinking of writing
something similar, for basically the same reasons.

By not standing for freedom and openness now, if I may use those terms,
we are becoming complicit in prolonging the stranglehold that the
current patent quagmire that exists today.  By giving in, we are
basically admitting a win.  When even the proponents of the
patent-encumbered format bemoan the problems of the system, we have to
wonder, if their cries are sincere, why they won't also join the FLOSS
folks.

The thing is, there is absolutely nothing that can be done if H.264 is
the standard that cannot be done with VP8, but such a thing is not true
the other way around due to the obvious requirements of licensing needed
for H.264.

And, in fact, there already exists a strong installed based supporting
VP8, so it's not like choosing VP8 will kill the standard.

We cannot change the patent landscape of H.264 as long MPEG-LA and it's
partners operate the way they always have.  However, I would like to
know what, if anything, is stopping the providers that want to use H.264
from choosing VP8, and if we can work toward a solution that way.

The problem is, this involves sincerity from those participating, and we
have no way of guaranteeing that.

I apologize I don't have a solution here, but I know one exists.  We
just haven't found one yet.

-- 
Libre Video
http://librevideo.org

---

From: David Singer <[email-masked]>
Date: Wed, 13 Nov 2013 11:59:19 +0800

> elimination of software patents.

MPEG has not one, not two, but three tracks for developing unencumbered or RF-only encumbered video, as an experiment.  I think there are a few people at MPEG who think that this optimization direction -- for cost of license -- is clearly applicable to some cases, and should be followed.

The need or bandwidth-saving at any cost -- the old optimization direction -- is slackening, IMHO.  Sometimes you want to optimize battery life (complexity), sometimes license cost, and so on.

There are not enough people, in my opinion, working on this at MPEG.  Getting involved, helping, would be good.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Tim Panton <[email-masked]>
Date: Wed, 13 Nov 2013 10:34:48 +0000

Since the MTI video codec discussion I've been mulling over the h264 plugin kindly offered by cisco.

I think that there are many places where it will be useful, and I thank cisco for that.

I've come up with some problems which will need to addressed for it to meet the needs of rtcweb.

1) Appstores: No program that is destined to be sold or distributed in an app store will be able to use it.
As far as I can tell the Mac, win8, ios and android app stores all specifically ban the use of downloaded
plugins. 
This means that no 3rd party browser can use it - except those browsers that have their own distribution channel.
Like it or not, the appstore model is taking over the world. Many people don't feel comfortable (or just can't)
install apps that don't come from the official app stores.

This also means that no native app can include webRTC compatible video functionality using the plugin, if it wants 
to be sold/distributed via an app store.

2) Secure platforms: Platforms that only run authorised, signed code, (eg OSX by default) may have trouble running this, depending
on exactly how the install-and-download-plugin sequence works.  

3) Cloud platforms: A common usage in cloud land is to build a server image, and then boot multiple clones
of that image as service demand rises, then deleting them as load falls. Now consider a cloud video service that uses
the plugin as part of it's code. If I understand it correctly, each image boot
would need to separately download and install the plugin or risk breaching the license terms. This breaks the 
easy scalability model of having pre-pickeled images ready to roll.

4) Dark installs: It is common practice in some environments to require an install that can be made entirely from a DVD.
This won't be possible with the plugin.

Sure there are possible work arounds for some of these issues, but all are somewhat unsatisfactory, and highlight the extent to which
the h264 plugin puts engineering decisions into the hands of lawyers.

Tim.

---

From: John Leslie <[email-masked]>
Date: Wed, 13 Nov 2013 11:55:26 -0500

Mike Linksvayer <[email-masked]> wrote:
> of both, either, or neither would be second best.

   I'm _very_ glad you care which is "second best!"

   I went into last week's session quite prepared to accept either, both
or neither. I came out unwilling to support _either_ as MTI.

   This is mostly because I came to understand the "cisco" postition.

   (Please excuse me for assigning names to the two main positions, but
it will make the discussion _much_ simpler.)

   The "cisco" position is:

- look at all the H.264 hardware out there: we must make use of it;
- if VP8 is MTI, we'll get sued and our customers will get hassled.

   The "linux" position is:

- look at all the VP8 software out there: we must make use of it;
- if H.264 is MTI, we'll get sued and our customers will get hassled.

   And, alas, they're both right.

   What I didn't understand before the presentations was why Cisco
believes they'll get sued over VP8, but not H.264.

   Basically H.264 has quite a consortium to slap down the likes of
Nokia in court should they sue anyone in the consortium. This greatly
reduces the chance of Nokia's lawyer suing.

   But this consortium won't lift a finger if Nokia sues Cisco over
VP8. Cisco is a _very_ attractive target over VP8.

   Thus, Cisco management would _very_much_ prefer that VP8 _not_ be
MTI. They probably won't implement it.

   Conversely, of course, "linux" management would _very_much_ prefer
that H.264 not be MTI. They probably won't implement it.

   Understanding this, I now strongly recommend against making either
H.264 or VP8 MTI. (And I will not consent to a RFC 3929 process limited
to choosing between them.)

   This issue has dragged on long enough already. We need to start
reading the riot act to the folks who claim we "need" either of these
as MTI in order to have "satisfied" users.

   Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
IMHO, will achieve consensus for "MUST implement" status. Yes, this
is a sorry state to find ourselves in. But the marketplace has
sorted out much worse problems in my memory.

   And I claim that both camps are actually more likely to implement
(or allow extensions for) the other side's codec if it is _not_ MTI,
simply because they can back out at the first sign of lawyers.

   I will not go into any details about how VP8 endpoints might talk
to H.264 endpoints, but I'm _very_ confident ways will be found if
we actually _publish_ an RFC saying both are "SHOULD implement".

   (Surely I'm not the _only_ person who'd like to see _both_ H.264
and VP8 legacy devices using our standard...)

--
John Leslie <[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Nov 2013 09:43:48 -0800

On 13 November 2013 02:34, Tim Panton <[email-masked]> wrote:
> 3) Cloud platforms:

At least for the Microsoft cloud, I don't see this being an issue.
It's pretty standard to have a setup step once an image is deployed.

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Nov 2013 10:18:32 -0800

On Nov 13, 2013, at 8:55, John Leslie <[email-masked]> wrote:

> VP8 legacy devices

Aside from Firefox and Chrome, what did you have in mind here?

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Nov 2013 21:02:34 +0100

> we actually _publish_ an RFC saying both are "SHOULD implement".

I don't know if many noticed it, but one reason for my fiddling with
devices to show Hangouts working on stage at the meeting was to show
that transcoding is in fact working in real services that people are
using on a day-to-day basis.

Sure, it's not optimal. In fact, it hurts. But it's not the end of the
world either.

-- 
Surveillance is pervasive. Go Dark.

---

From: Ron <[email-masked]>
Date: Thu, 14 Nov 2013 06:58:52 +1030

> MTI. They probably won't implement it.

I don't understand your logic here?  They've said they are all for future
codecs like Daala that will surely have the same FUD spread about them by
the same few belligerent actors.  How is that any different to the current
status of VP8?

Also: http://www.cisco.com/en/US/prod/collateral/video/ps9901/ps10631/data_sheet_c78-565206_ps12130_Products_Data_Sheet.html

... says it supports WebM.

So "probably won't" looks more like "already have" here.

> that H.264 not be MTI. They probably won't implement it.

There is a critical difference between "would prefer" and "cannot licence".

The symmetry you seem to suggest here isn't grounded in reality.
"Don't want to" is not even approximately the same as "have no licence to".

  Ron

---

From: cowwoc <[email-masked]>
Date: Wed, 13 Nov 2013 15:46:40 -0500

> Sure, it's not optimal. In fact, it hurts. But it's not the end of the

So... we're throwing P2P out of WebRTC?

If you mandate H.261 as MTI, big business can still do transcoding and 
the rest of us can use H.261. Small business shouldn't have to choose 
between transcoding and dropping the call.

Gili

---

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

Hi John,

First, thanks for summarize the positions brought up in the meeting.

A few weeks ago I advocated making both H.264 and VP8 MTI with the 
reasoning that if an implementer gets sued they can simply drop the 
codec, notify the community, and have that codec removed en-mass from 
the specification. A few months later we would replace it with another 
MTI codec. According to what you wrote above, Cisco is under the 
impression that once a codec is MTI they cannot drop it even if they get 
sued.

Practically speaking, is that really true? I mean, if the specification 
requires everyone to implement both VP8 and H.264 and one implementer 
temporarily drops one of the codecs, shouldn't things keep on working 
until the lawsuit is over (codec returns) or the community replaces the 
codec with another?

Thanks,
Gili

On 13/11/2013 11:55 AM, John Leslie wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Kaiduan Xie <[email-masked]>
Date: Wed, 13 Nov 2013 16:57:14 -0500

"if an implementer gets sued they can simply drop the codec"

Thing is not that simple as "simply drop the codec", for some case you
still have to pay a lot of money.

/Kaiduan

On Wed, Nov 13, 2013 at 3:54 PM, cowwoc <[email-masked]> wrote:

> reasoning that if an implementer gets sued they can simply drop the codec,
> notify the community, and have that codec removed en-mass from the
> specification. A few months later we would replace it with another MTI
> codec. According to what you wrote above, Cisco is under the impression
> that once a codec is MTI they cannot drop it even if they get sued.
>
> temporarily drops one of the codecs, shouldn't things keep on working until
> the lawsuit is over (codec returns) or the community replaces the codec
> with another?
>
> Thanks,
> Gili
>
>

---

From: cowwoc <[email-masked]>
Date: Wed, 13 Nov 2013 17:32:17 -0500

I agree. I'm just pointing out that John's argument (quoted below) 
doesn't make any sense. Choosing "no MTI" doesn't make Cisco any more 
likely to implement VP8.

If we choose "No MTI" we will end up with transcoding, plain and simple. 
One crowd will only implement H.264. The other crowd will only implement 
VP8. All the useless middlemen will rejoice, having killed a technology 
that puts them out of business.

Providing "video chat without a plugin" is not revolutionary. Flash is 
already installed on 95% of the market. That's more people than WebRTC 
can reach today, so we're not "liberating" those people from anything.

The real revolution is P2P: massive cost savings, ease of deployment and 
most importantly: cutting out the middle man. The status quo (H.264 over 
Flash) does not do this.

P2P cannot work unless 95% of clients can agree on a common codec. I say 
again: start with H.261 and upgrade to VP8 or H.264. This way everyone 
can be happy:

  * The VP8 crowd can use VP8
  * The H264 crowd can use H264
  * The enterprise crowd can transcode
  * If all of the above fails, we can fallback on H.261.

Yes, this carries the burden of implementing H.261 but this is a 
solved-problem. There are plenty of free implementations and is a much 
easier problem to solve than getting the H.264 and VP8 crowd to agree to 
implement each other's codec.

Start with H.261 and replace it the moment you find something better. 
Forcing us to transcode or drop video calls is not a solution.

Gili

---

From: Michael Thornburgh <[email-masked]>
Date: Wed, 13 Nov 2013 15:32:58 -0800

> The real revolution is P2P: massive cost savings, ease of deployment and most importantly: cutting out the middle man. The status quo (H.264 over Flash) does not do this.

note: Flash has had P2P for real time communication since 2009.

-michael thornburgh

From: [email-masked] [mailto:[email-masked]] On Behalf Of cowwoc
Sent: Wednesday, November 13, 2013 2:32 PM
To: Kaiduan Xie
Cc: [email-masked]
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"

I agree. I'm just pointing out that John's argument (quoted below) doesn't make any sense. Choosing "no MTI" doesn't make Cisco any more likely to implement VP8.

If we choose "No MTI" we will end up with transcoding, plain and simple. One crowd will only implement H.264. The other crowd will only implement VP8. All the useless middlemen will rejoice, having killed a technology that puts them out of business.

Providing "video chat without a plugin" is not revolutionary. Flash is already installed on 95% of the market. That's more people than WebRTC can reach today, so we're not "liberating" those people from anything.

The real revolution is P2P: massive cost savings, ease of deployment and most importantly: cutting out the middle man. The status quo (H.264 over Flash) does not do this.

P2P cannot work unless 95% of clients can agree on a common codec. I say again: start with H.261 and upgrade to VP8 or H.264. This way everyone can be happy:

Yes, this carries the burden of implementing H.261 but this is a solved-problem. There are plenty of free implementations and is a much easier problem to solve than getting the H.264 and VP8 crowd to agree to implement each other's codec.

Start with H.261 and replace it the moment you find something better. Forcing us to transcode or drop video calls is not a solution.

Gili

Thing is not that simple as "simply drop the codec", for some case you still have to pay a lot of money.

/Kaiduan

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 13 Nov 2013 23:54:28 +0000

On Nov 13, 2013, at 9:55 AM, John Leslie <[email-masked]> wrote:

>  Both H.264 and VP8 deserve "SHOULD implement" status.

Just out of curiosity, could you say a bit more about what you see as the difference between MAY, SHOULD, and MUST in this context?

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 14 Nov 2013 08:04:11 +0800

> reduces the chance of Nokia's lawyer suing.

What makes you think that? I am not aware of a requirement on MPEG-LA
to get involved in any lawsuit that involves a company suing somebody
over a patent that is part of the H.264 pool.

On the contrary: if you get sued over VP8, you will likely find that
Google has an interest to support you.

Silvia.

---

From: Ron <[email-masked]>
Date: Thu, 14 Nov 2013 11:06:08 +1030

> Start with H.261 and replace it the moment you find something better.

Except this would essentially be an RFC 6919 MUST (BUT WE KNOW YOU WON"T)
recommendation, since nobody is going to spend development effort on a
thing that gives thumbnail video that wasn't even acceptable for users
in the 80's.

> Forcing us to transcode or drop video calls is not a solution.

... which means you'll still have exactly this problem - no solution.

If MTI video is important, the selected codec does need to be better
than the equivalent of mandating morse as the MTI audio channel.

Either we mandate something that is of good quality and has a licence
that allows anyone to use it - or we accept that the people trying to
hijack the potential ubiquity of this standard have succeeded in that.

Seems like a pretty simple choice to me.

  Ron

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 14 Nov 2013 10:38:48 +0900

> thing that gives thumbnail video that wasn't even acceptable for users

Is there some place (ideally a Web site) that shows (potentially 
simulated) H.261 side-by-side with H.264 baseline or V8 or both with the 
same bandwidth, so that it's easy to compare?

Regards,   Martin.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 13 Nov 2013 17:43:06 -0800

On Wed, Nov 13, 2013 at 12:46 PM, cowwoc <[email-masked]> wrote:

> If you mandate H.261 as MTI, big business can still do transcoding and the
> rest of us can use H.261. Small business shouldn't have to choose between
> transcoding and dropping the call.
>
>
Regarding H.261: Consider the following clip, encoded at 256 kbps using
H.261.
http://www-mobile.ecs.soton.ac.uk/peter/h261/missa.norm.h261.mpg

Do you think this quality (QCIF, grayscale, PSNR of 38) is acceptable for
your users?

---

From: cowwoc <[email-masked]>
Date: Thu, 14 Nov 2013 00:20:48 -0500

Really? I've never seen a single P2P video chat app in Flash. What 
specifically does "P2P for real time communication" actually mean?

Gili

On 13/11/2013 6:32 PM, Michael Thornburgh wrote:
>
> > The real revolution is P2P: massive cost savings, ease of deployment 
> and most importantly: cutting out the middle man. The status quo 
> (H.264 over Flash) does not do this.
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *cowwoc
> *Sent:* Wednesday, November 13, 2013 2:32 PM
> *To:* Kaiduan Xie
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] ~"I'd love it if patents evaporated...If not 
> now, when"
>
>
> If we choose "No MTI" we will end up with transcoding, plain and 
> simple. One crowd will only implement H.264. The other crowd will only 
> implement VP8. All the useless middlemen will rejoice, having killed a 
> technology that puts them out of business.
>
> The real revolution is P2P: massive cost savings, ease of deployment 
> and most importantly: cutting out the middle man. The status quo 
> (H.264 over Flash) does not do this.
>
> P2P cannot work unless 95% of clients can agree on a common codec. I 
> say again: start with H.261 and upgrade to VP8 or H.264. This way 
> everyone can be happy:
>
> easier problem to solve than getting the H.264 and VP8 crowd to agree 
> to implement each other's codec.
>

---

From: cowwoc <[email-masked]>
Date: Thu, 14 Nov 2013 00:22:14 -0500

> thing that gives thumbnail video that wasn't even acceptable for users

How realistic is that statement? Today I think I can get 720p (or was it 
1080p, I forget) using VP8 in 1.5Mbps.

How much bandwidth would you need to do the same in H.261? What 
resolution would get you for 1.5Mbps? We need some reasonable comparisons.

> Seems like a pretty simple choice to me.

I think you're exaggerating how bad H.261 is and it's also misleading to 
imply that the vast majority of users would be forced to use H.261. We 
are talking about H.261 as a fallback (if upgrading to VP8 or H.264 
fails). In the 5-10% of cases this happens, I am advocating we get using 
H.261 instead of dropping the call.

Gili

---

From: cowwoc <[email-masked]>
Date: Thu, 14 Nov 2013 00:22:20 -0500

On 13/11/2013 8:43 PM, Justin Uberti wrote:
> Regarding H.261: Consider the following clip, encoded at 256 kbps 
> using H.261.
> Do you think this quality (QCIF, grayscale, PSNR of 38) is acceptable 
> for your users?

That is hardly a scientific comparison.

And again, it is misleading to imply that I am advocating the mass-use 
of H.261. I am only advocating the use of this codec in the 5-10% of 
cases where the clients fail to agree on a common upgrade path (to VP8 
or H.264). In those cases, I'd happily accept H.261 instead of dropping 
the call. You can still transcode, if you so wish.

Gili

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 14 Nov 2013 06:41:00 +0100

> Really? I've never seen a single P2P video chat app in Flash.

You missed chatroulette and it's clones?

>  What specifically does "P2P for real time communication" actually mean?

See the slides from the 2009 MAX presentation.
http://assets.max.adobe.com/files/307/P2P%20on%20the%20Flash%20Platform%20with%20RTMFP.pdf

RTMFP was and is in many ways alot more advanced than webrtc.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 14 Nov 2013 05:51:21 +0000

Chatroulette (the top trending search term for 2010 and featured on The Daily Show) used Flash and RTMFP to do peer-to-peer video chat. The original Tokbox and their original API was also based on Flash with RTMFP for P2P communications. I'm sure there's others.

Matthew Kaufman

From: [email-masked] [mailto:[email-masked]] On Behalf Of cowwoc
Sent: Wednesday, November 13, 2013 9:21 PM
To: Michael Thornburgh
Cc: [email-masked]
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"

Really? I've never seen a single P2P video chat app in Flash. What specifically does "P2P for real time communication" actually mean?

Gili

-michael thornburgh

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of cowwoc
Sent: Wednesday, November 13, 2013 2:32 PM
To: Kaiduan Xie
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"

Gili

/Kaiduan

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 14 Nov 2013 06:02:51 +0000

We're clearly off topic here, but:

My 2008 MAX presentation is actually more applicable to what RTCWEB can now do, and (if you watch the video) includes a demo of widely-deployed browser-to-browser peer-to-peer video, 5 years ago. Somewhat ahead of its time, I'm afraid.

http://tv.adobe.com/en/watch/max-2008-develop/future-of-communication-with-rtmfp-by-matthew-kaufman/ is a link to the video... the demo of building and running a peer-to-peer video chat is at 30 minutes in.

Matthew Kaufman

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Philipp Hancke
> Sent: Wednesday, November 13, 2013 9:41 PM
> To: [email-masked]

---

From: Justin Uberti <[email-masked]>
Date: Wed, 13 Nov 2013 22:07:32 -0800

On Wed, Nov 13, 2013 at 9:22 PM, cowwoc <[email-masked]> wrote:

> And again, it is misleading to imply that I am advocating the mass-use of
> H.261. I am only advocating the use of this codec in the 5-10% of cases
> where the clients fail to agree on a common upgrade path (to VP8 or H.264).
> In those cases, I'd happily accept H.261 instead of dropping the call. You
> can still transcode, if you so wish.
>
> It is a single example, but I think it illustrates the limits on what you
can achieve with a 25-year-old (really!) coding technology. The page at
http://www-mobile.ecs.soton.ac.uk/peter/h261/ claims that the compression
ratio for the above file is 25:1, with PSNR of 38. Modern codecs achieve
compression ratios of at least 150:1 for similar PSNR with a similar
talking head scene, i.e. H.261 requires at least 6x the bits for the same
quality.

Implementing H.261 in WebRTC has a nontrivial cost. If you think H.261 is a
realistic option, I think you need to show data that indicates it can
deliver decent quality at typical internet bitrates.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 14 Nov 2013 15:25:19 +0900

>> http://www-mobile.ecs.soton.ac.uk/peter/h261/missa.norm.h261.mpg

Thanks for the pointer to the sample.

> That is hardly a scientific comparison.

True, but that's not what I asked about.

> the call. You can still transcode, if you so wish.

Having had a look at the sample, I'd say "it depends".

If the video were used to discuss e.g. some details of a new physical 
product, higher resolution and color may be rather important, and H261 
insufficient.

If it's just to get a quick impression of the person at the other end of 
the call, I guess it would be okay, but in that use case, there's a high 
chance I'd overlay it with some other document even if the video quality 
was much better.

If it's one of many videos of participants in a conference call, 
grayscale may be disappointing but better than nothing, the size may be 
just about right, and the (relatively speaking) high bandwidth may not 
be noticed.

Regards,   Martin.

---

From: cowwoc <[email-masked]>
Date: Thu, 14 Nov 2013 01:46:02 -0500

Okay, so I stand corrected (thank you for pointing this out).

So, I guess my new argument is: WebRTC shouldn't support any less than 
Flash ;)

Gili

---

From: cowwoc <[email-masked]>
Date: Thu, 14 Nov 2013 02:00:49 -0500

On 14/11/2013 1:07 AM, Justin Uberti wrote:
>
> On Wed, Nov 13, 2013 at 9:22 PM, cowwoc <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         Regarding H.261: Consider the following clip, encoded at 256
>         kbps using H.261.
>         Do you think this quality (QCIF, grayscale, PSNR of 38) is
>         acceptable for your users?
>
>
>     And again, it is misleading to imply that I am advocating the
>     mass-use of H.261. I am only advocating the use of this codec in
>     the 5-10% of cases where the clients fail to agree on a common
>     upgrade path (to VP8 or H.264). In those cases, I'd happily accept
>     H.261 instead of dropping the call. You can still transcode, if
>     you so wish.
>
> It is a single example, but I think it illustrates the limits on what 
> you can achieve with a 25-year-old (really!) coding technology. The 
> page at http://www-mobile.ecs.soton.ac.uk/peter/h261/ claims that the 
> compression ratio for the above file is 25:1, with PSNR of 38. Modern 
> codecs achieve compression ratios of at least 150:1 for similar PSNR 
> with a similar talking head scene, i.e. H.261 requires at least 6x the 
> bits for the same quality.
>
> Implementing H.261 in WebRTC has a nontrivial cost. If you think H.261 
> is a realistic option, I think you need to show data that indicates it 
> can deliver decent quality at typical internet bitrates.
>

Okay, that's reasonable, though my point remains: how do we want to 
handle the 5-10% of cases where the clients can't agree on a common 
codec? For some businesses, it might very well be preferable to fallback 
to a lower-resolution H.261 feed than to drop the call or use 
transcoding. I don't believe we should make this decision on behalf of 
the client.

Is it fair to assume that a H.261 feed using the same bandwidth as VP8 
would stream roughly 6x less pixels? So say 720p would drop down to 
funky resolution of 404x303? This is definitely not great, but it's 
certainly useable depending on your use-case. Anyway, my argument is 
that this decision is best left up to the developer. There plenty of 
cases (gaming comes to mind) where using H.261 would be "good enough" 
and preferable to dropping the call or transcoding.

Gili

---

From: cowwoc <[email-masked]>
Date: Thu, 14 Nov 2013 02:04:08 -0500

On 14/11/2013 1:25 AM, "Martin J. Dürst" wrote:
> If it's just to get a quick impression of the person at the other end 
> of the call, I guess it would be okay, but in that use case, there's a 
> high chance I'd overlay it with some other document even if the video 
> quality was much better.
>
> grayscale may be disappointing but better than nothing, the size may 
> be just about right, and the (relatively speaking) high bandwidth may 
> not be noticed.
>
> Regards,   Martin.

Precisely my point. It depends. There are plenty of cases where dropping 
down to H.261 is "good enough" and preferable to dropping the call 
altogether. And again, we're only talking about a minority of cases that 
will ever have to drop down to H.261.

(Note, I'm using H.261 as a placeholder. Are there other candidate 
codecs we should consider?)

Gili

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 14 Nov 2013 08:05:42 +0100

> Okay, so I stand corrected (thank you for pointing this out).

heh, I'm always surprised by how many people are completly unaware that 
the innovations webrtc brings aren't new at all.

> So, I guess my new argument is: WebRTC shouldn't support any less than

That's a long list of advanced features. I'd leave things like building 
an optimized overlay to the application layer however. Hopefully a 
specification of the RTMFP groups stuff will appear as an internet draft 
so people don't start reinventing that wheel, too.

---

From: Tim Panton <[email-masked]>
Date: Thu, 14 Nov 2013 08:49:10 +0000

> and VP8 legacy devices using our standard...)

I'm coming around to this POV. With the possible slight variant that we should clarify
that this applies to _browsers_ not rtcweb compatible endpoints.

Ideally we'd see browsers implementing both VP8 and H264 - but single purpose 
endpoints (doorbells, prison video phones, baby alarms, smart-fashion mirrors, video mixers etc) using whichever
codec suits their hardware/legal/usecase needs best, and exchanging rtcweb media with
a browser at the far end. 

Non browser endpoints need to be confident they can talk to any browser and browsers need to
be able to talk to anything.

I think that's what is behind the option #4 in Gonzalo's proposal. 
>  4. Browsers MUST support both H.264 and VP8

- What this highlights is that we've created a media protocol that will be used by things that aren't browsers,
we need to address that requirement, without just seeing it as legacy support.

Tim.

Tip of the Hat to @nstratford for helping clarify my thinking on this.

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 14 Nov 2013 18:08:07 +0800

On Thu, Nov 14, 2013 at 3:05 PM, Philipp Hancke
<[email-masked]> wrote:
> heh, I'm always surprised by how many people are completly unaware that the
> innovations webrtc brings aren't new at all.

Right. HTML is just another word processing format, too. :-)
Silvia.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Nov 2013 14:41:52 -0500

An important drawback of H.261 as MTI is interop with existing installed
base. Very old conferencing systems and products may still have it since
its easier to keep the code than delete it, but new platforms in the last
few years will not have H.261.

I also disagree with the assertion that H.261 video is better than audio
only. Video quality matters and I believe the higher quality we've been
able to achieve in recent years due to the combo of better tech (ala H.264)
along with faster networks is a material factor in the acceptance of video
by end users. I think folks writing the apps should decide whether lousy
video is good enough, and for business usage the answer is no.

Finally, don't overestimate the typical upstream bandwidth that is
available to users across the Internet. Many of us here on this list
probably have nice speedy high speed connections (I have fiber with 85/35
service) and that is not the norm for the rest of the world.

On Thu, Nov 14, 2013 at 5:08 AM, Silvia Pfeiffer
<[email-masked]>wrote:

> the

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

---

From: Gili <[email-masked]>
Date: Thu, 14 Nov 2013 14:52:11 -0500

Hi,

On 14/11/2013 2:41 PM, Jonathan Rosenberg wrote:
> An important drawback of H.261 as MTI is interop with existing 
> installed base. Very old conferencing systems and products may still 
> have it since its easier to keep the code than delete it, but new 
> platforms in the last few years will not have H.261.

If older platforms had working implementations, it could always be added 
back in. Meaning, there should be plenty of mature implementation out in 
the wild.

> I also disagree with the assertion that H.261 video is better than 
> audio only. Video quality matters and I believe the higher quality 
> we've been able to achieve in recent years due to the combo of better 
> tech (ala H.264) along with faster networks is a material factor in 
> the acceptance of video by end users. I think folks writing the apps 
> should decide whether lousy video is good enough, and for business 
> usage the answer is no.

I don't think that's for the specification to say. Let the developer 
decide which is better. I provided plenty of examples where a 
lower-resolution H.261 feed is preferable to audio-only (e.g. video 
games). The specification should give developers the option to choose.

Furthermore, I'll repeat again, we're not choosing between H.264 and 
H.261. We're choosing between H.261 and no video, for only the 5-10% of 
calls where there is no agreement on a higher-end codec (VP8 or H.264).

> probably have nice speedy high speed connections (I have fiber with 
> 85/35 service) and that is not the norm for the rest of the world.

Again, this is up to the developers to choose. I don't necessarily need 
a high-resolution video for gaming.

Gili

---

From: Maik Merten <[email-masked]>
Date: Thu, 14 Nov 2013 21:20:25 +0100

Am 14.11.2013 20:41, schrieb Jonathan Rosenberg:
> able to achieve in recent years due to the combo of better tech (ala
> H.264) along with faster networks is a material factor in the acceptance
> of video by end users. I think folks writing the apps should decide
> whether lousy video is good enough, and for business usage the answer is no.

Well, as long as there is a MTI video codec, even if it is H.261 or 
MPEG-1, users at least have a *choice* if the transferred video content 
suits their needs. There can always be a "mute video" option for 
situations where the video content is not useful, no matter what the reason.

Also codecs such as H.261/MPEG-1 would only be chosen during negotiation 
if everything else has failed. IMO they at least cover the "talking 
head" scenario quite decently, even with bitrates in the region of 
256-384 kbit/s. For me, this is "G.711, but for video" and often more 
useful than "no video at all" - albeit not always (e.g., in your 
business use case).

(Personally, I'd even prefer ASCII-video over "no video forced onto the 
user in case of negotiation failure" - although I'd choose 
PETSCII-video, based on the character set of Commodore's 8-bit computers 
for added awesome. PETSCII has some well designed graphical symbols 
which may prove useful in a number of scenarios.)

Best regards,

Maik

---

From: Göran Eriksson AP <[email-masked]>
Date: Thu, 14 Nov 2013 20:21:17 +0000

14 nov 2013 kl. 20:42 skrev "Jonathan Rosenberg" <[email-masked]<mailto:[email-masked]>>:

An important drawback of H.261 as MTI is interop with existing installed base. Very old conferencing systems and products may still have it since its easier to keep the code than delete it, but new platforms in the last few years will not have H.261.

I also disagree with the assertion that H.261 video is better than audio only. Video quality matters and I believe the higher quality we've been able to achieve in recent years due to the combo of better tech (ala H.264) along with faster networks is a material factor in the acceptance of video by end users. I think folks writing the apps should decide whether lousy video is good enough, and for business usage the answer is no.

Finally, don't overestimate the typical upstream bandwidth that is available to users across the Internet. Many of us here on this list probably have nice speedy high speed connections (I have fiber with 85/35 service) and that is not the norm for the rest of the world.

And if we consider cellular access to Internet, upstream bandwidth may be even more limited. An MTI making mobile WEBRTC difficult is not easy to embrace wholeheartedly considering we already have it WEBRTC in some mobile browsers.

On Thu, Nov 14, 2013 at 5:08 AM, Silvia Pfeiffer <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Nov 14, 2013 at 3:05 PM, Philipp Hancke

Right. HTML is just another word processing format, too. :-)
Silvia.
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

--
Jonathan Rosenberg, Ph.D.
[email-masked]<mailto:[email-masked]>
http://www.jdrosen.net
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Leon Geyser <[email-masked]>
Date: Thu, 14 Nov 2013 22:30:24 +0200

>>And if we consider cellular access to Internet, upstream bandwidth may be
even more limited. An MTI making mobile WEBRTC difficult is >>not easy to
embrace wholeheartedly considering we already have it WEBRTC in some mobile
browsers.

Technically H.261 can work at as low as 64Kbps. I doubt the upstream will
be lower than that.

On 14 November 2013 22:21, Göran Eriksson AP <[email-masked]
> wrote:

>
>
> 14 nov 2013 kl. 20:42 skrev "Jonathan Rosenberg" <[email-masked]>:
>
> installed base. Very old conferencing systems and products may still have
> it since its easier to keep the code than delete it, but new platforms in
> the last few years will not have H.261.
>
>  And if we consider cellular access to Internet, upstream bandwidth may
> be even more limited. An MTI making mobile WEBRTC difficult is not easy to
> embrace wholeheartedly considering we already have it WEBRTC in some mobile
> browsers.
>
>
>
>
>
>
> On Thu, Nov 14, 2013 at 5:08 AM, Silvia Pfeiffer <
> [email-masked]> wrote:
>

---

From: Gili <[email-masked]>
Date: Thu, 14 Nov 2013 15:45:08 -0500

On 14/11/2013 3:21 PM, Göran Eriksson AP wrote:
> be even more limited. An MTI making mobile WEBRTC difficult is not 
> easy to embrace wholeheartedly considering we already have it WEBRTC 
> in some mobile browsers.

 1. The situation is only improving over time (meaning, the pipes are
    getting bigger).
 2. There should be enough bandwidth for the "talking head" scenario today.
 3. You still have the option of dropping to audio-only. At least you
    have the choice of using H.261 if it fits your use-case.

Gili

---

From: John Leslie <[email-masked]>
Date: Thu, 14 Nov 2013 15:47:06 -0500

Cullen Jennings (fluffy) <[email-masked]> wrote:
> Just out of curiosity, could you say a bit more about what you see
> as the difference between MAY, SHOULD, and MUST in this context?

   I'd be happy to (though I don't intend the slightest departure from
word-for-word RFC2119).

   MAY is simply a warning label -- that the authors expect some folks
to do this.

   SHOULD means it's intended as an integral part of the standard, but
the authors recognize that some implementations may not comply. The
chief difference from MAY is that anyone can hassle the implementors
which don't comply, demanding their reasons and publicly ridiculing
any reasons which are weak.

   MUST means if you don't implement it, you're not compliant with
the standard. Presumably you could be sued for false advertising if
you claim to comply to the standard but don't satisfy all the MUSTs.

---

From: John Leslie <[email-masked]>
Date: Thu, 14 Nov 2013 15:53:55 -0500

> over a patent that is part of the H.264 pool.

   I didn't mean to say the _consortium_ has a legal obligation to get
involved in a lawsuit against one of their members -- but they do have
an incentive to do so.

   In fact, I suspect it's other _members_ of the consortium which
will pay their lawyers to get involved.

   My point was that suing one member of the consortium looks less
attractive when other members are likely to support each other.

> Google has an interest to support you.

   I sincerely hope they would -- but there is nothing to convince Nokia
lawyers not to file suit in the first place.

---

From: Randell Jesup <[email-masked]>
Date: Thu, 14 Nov 2013 16:53:42 -0500

> It's pretty standard to have a setup step once an image is deployed.

I'm not an expert on AWS/etc, but I imagine predictable and fast startup 
of instances is important.  With a plugin download (even from Cisco), it 
would seem to be worrisome for a cloud service developer to rely on this 
completing "quickly" and not having an error *ever* - and they can't 
host it themselves.  I think Cisco would have to say that (at least) 
certain versions of the binary (warts, bugs and all) MUST remain 
available for immediate download <long time>.  And anything (lawsuit) 
that for any reason forced Cisco to even temporarily stop distributing 
it would be disaster for them; so I think they'd need to bite the bullet 
and sign a license - which has costs even if you stay under 100K (and 
you have to reliably count uses, etc).

Also, if they're encoding videos in H.264 and charging money to see them 
(or for a service that includes them, and this might include even an 
answering-system I'm-away video message), they wouldn't fall into the 
Cisco-paid cap category (perhaps; IANAPL).

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 14 Nov 2013 22:16:20 +0000

You don¹t have to speculate. Motorola (now Google) sued Microsoft over
H.264 patents. No one intervened, so there is no obligation nor incentive
to do so. However, because this involved standards-essential patents, and
Motorola participated in the standards, it has FRAND obligations for those
SEPs, with a clear precedent for FRAND royalty rates established by MPEG
LA for that standard. The result was Microsoft has to pay half a cent in
royalties per product they ship containing an H.264 codec, but Motorola
must pay $15M for breaching SEP/FRAND obligations (by demanding $4B). If
Nokia sued anyone over H.264, a similar result is likely.

This is what people mean when they say H.264 IPR risk is low. Everyone
that participated in the standard is bound by SEP/FRAND obligations, and
can¹t demand much more than they would get if they were licensors in the
MPEG LA pool. For all the hate MPEG LA gets, here is an example where its
existence actually limits the extent anyone can leverage patents to demand
unreasonable royalties.

VP8 does not yet offer such SEP/FRAND protection. If it infringes any
patent, the patent holder may demand unreasonable royalties (or even no
license terms, in the case of Nokia).

Mo

On 11/14/13, 3:53 PM, John Leslie <[email-masked]> wrote:

---

From: Ron <[email-masked]>
Date: Fri, 15 Nov 2013 09:26:33 +1030

> Nokia sued anyone over H.264, a similar result is likely.

Except the proposed Cisco binary deal isn't licencing the Nokia patents,
or the Motorola patents, or any others, so they'd all still be free to
sue anyone using that.

How is this known and proven liability somehow less of a problem than the
absence of any such thing overshadowing VP8?

If we're giving credit to MPEG LA, we can also credit them for trying very
hard, and failing, to create a pool that reads on VP8.

If people are going to stand on that FUD, maybe a 25 year old codec is
the best answer here after all.

  Ron

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 15 Nov 2013 04:46:39 +0000

On 11/14/13, 5:56 PM, Ron <[email-masked]> wrote:

No licensor / licensee in the MPEG LA pool can sue anyone over H.264.
Google is a licensee, so Motorola can no longer sue anyone over H.264.
Nokia (like the old Motorola) is neither a licensor nor licensee, so it
can sue.
But Nokia has FRAND obligations for H.264 since it participated in the
standard,
while it has no such obligations for VP8. If it sues over H.264, it likely
can’t get
more than half a cent like Motorola. If it sues over VP8, and wins, it can
get
a permanent injunction.

Half a cent is less of a problem than a permanent injunction.

I never said it deserves credit, just that in one case it prevented
unreasonable royalties.

No FUD intended. If you want to help clear the FUD, help analyze the
patents.
http://www.groklaw.net/article.php?story=20130324162902177

I really hope we can do better than H.261. That would be a failure to me.

---

From: Marco Stura <[email-masked]>
Date: Fri, 15 Nov 2013 06:46:02 +0000

Are you thinking to use webrtc over 2g? AFAIK the minimum target mobile access should be 3g and a codec that technically could work at 64k is not a problem in uplink....

Sent from Huawei Mobile

Göran Eriksson AP <[email-masked]> wrote:

________________________________

The information in this email and any attachments thereto may contain information that is confidential, protected by intellectual property rights, and may be legally privileged. It is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. Any use, disclosure, copying, or distribution of the information contained herein by persons other than the designated addressee is unauthorized and may be unlawful. If you are not the intended recipient, you should delete the message immediately from your system. If you believe that you have received this email in error, please contact the sender. Any views expressed in this email and its attachments are those of the individual sender except where the sender expressly states them to be the views of Ooredoo.

---

From: Ron <[email-masked]>
Date: Fri, 15 Nov 2013 22:42:49 +1030

> Nokia (like the old Motorola) is neither a licensor nor licensee, so it

Ah, thanks for the clarification on that.

> > How is this known and proven liability somehow less of a problem than
> > the absence of any such thing overshadowing VP8?
> 

It's only half a cent after you've shelled out the 6+ figures for the
high powered lawyers though - and even then only if you 'win'.

And it still means that anyone wanting to take advantage of the Cisco
offer _is_ going to need to negotiate a separate licence from them.
So I still don't see how this changes the original problem (even if
we ignore the other remaining problems).

Half a cent for each of millions of unpaying users is still effectively
a permanent injunction (or worse) for many of the projects that would
otherwise deploy WebRTC.

I'll consider it a sad outcome if we are forced into choosing H.261 here
too, but if it's the only option that "makes the patents evaporate" in a
way that satisfies the objectors to VP8, then it's not worse than an
outcome which limits video (and compliant WebRTC implementation) to only
people that the H.264 patent holders approve of or turn a blind eye to.

  Ron

---

From: Kaiduan Xie <[email-masked]>
Date: Fri, 15 Nov 2013 09:51:01 -0500

For all the projects/products built upon webrtc, they better focus on more
how to grow their own business to become profitable and sustainable first.
If you get sued in the future, congratulations to you, your business has
become big enough.

/Kaiduan