Subject: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85

From: Matthew Kaufman <[email-masked]>
Date: Sat, 20 Oct 2012 10:23:20 -0700

Can we just save a bunch of time and have a show of hands at the 
beginning for:

A) People who WILL NOT implement H.264 in their product and cannot be 
swayed by any presentation

B) People who WILL NOT implement VP8 in their product and cannot be 
swayed by any presentation

C) People who are still undecided enough that they want to hear the 
presentations

It is quite possible that once we get that out of the way, the rest of 
the presentations will be irrelevant and we can get back to discussing 
important things like who is going to write down the particulars for the 
"SDP profile" we're using as an API surface.

Matthew Kaufman

________________________________________

From: [email-masked] <mailto:[email-masked]> 
[[email-masked]] on behalf of Cullen Jennings (fluffy) 
[[email-masked]]

Sent: Friday, October 19, 2012 11:59 AM

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

Subject: [rtcweb] Draft agenda for RTCWeb session 2 at IETF85

We have two WebRTC session at the next IETF. We have not worked out the 
agenda for the first session yet but our current plan is to dedicate the 
second session to the MTI video codec question.

The draft agenda for this season is:

Admin issues (5 min)

IPR at the IETF ( 10 min )

- this is a reminder of IETF rules and guidelines around IPR

Presentations ( 80 min )

- a 20 minute presentation from each of the following drafts

draft-alvestrand-rtcweb-vp8-00

draft-burman-rtcweb-h264-proposal-00

draft-dbenham-webrtc-videomti-00

draft-marjou-rtcweb-video-codec-00

- If the authors of drafts recommending the same codec can consult with 
each other to avoid overlap, or even merge presentations, the recovered 
time would be given to the general discussion.

General discussion (30 min )

- general time for everyone to speak at the mic to express information 
important for the decision

Call the question of which mandatory to implement video codec to select( 
5 min )

Next steps ( 20 min )

Cullen, Magnus, and Ted <RTCWeb Chairs>

_______________________________________________

rtcweb mailing list

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

https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Stefan Hakansson LK <[email-masked]>
Date: Sun, 21 Oct 2012 16:44:13 +0200

> C) People who are still undecided enough that they want to hear the

I think something like this makes sense. We could alternative do a show 
of hand for preference of either alternative, if it seems we're far away 
from any (rough) consensus then we could move on to discuss if we should 
abandon an MTI video codec, or select an alternative decision process.

And hopefully save a lot of time for SDP discussion.
> [email-masked]

---

From: Ron <[email-masked]>
Date: Mon, 22 Oct 2012 07:31:47 +1030

On Sat, Oct 20, 2012 at 10:23:20AM -0700, Matthew Kaufman wrote:
> A) People who WILL NOT implement H.264 in their product and cannot
> be swayed by any presentation

Are there actually people saying they *will not* implement H.264?

I can't say that I've seen that here.  The problem being repeatedly
voiced is that under its current licencing regime they simply *CANNOT*
implement and/or distribute it with their products.

> swayed by any presentation

That constraint does not apply to VP8, so turning this into a tug of
war between the WILL NOTs and the CANNOTs, doesn't seem to really
address the actual problem we have before us.

> C) People who are still undecided enough that they want to hear the

Unless the presentations are going to announce new perpetual RF
licencing conditions for H.264, I don't really see what new facts
might be presented that can change the reality of:

"People invested in H.264 licences or owning its IPR prefer H.264
 and the exclusivity and revenue streams it brings them."

"People who don't qualify for H.264 licences will be screwed unless
 we pick VP8 as the baseline - and will need to either fork RTCWeb,
 or adopt or create an alternative to it."

This isn't a coin toss between choices of equivalent merit.
Framing the question as one of Wills completely ignores the salient
technical point of which choice would give RTCWeb relevance to the
broadest range of possible developers, adopters and users.

I don't want to see discussion of people's real concerns suppressed,
so I think I agree that it would be a great idea for people to begin
their presentations here and now, with the aim of distilling that to
some final brief summations by the time of the meeting.

So far as I can see this is a technical no-brainer.  But not because
I have any deep set preference for one or the other, or an inability
to be swayed.  Simply because H.264 would be *impossible* for many
users to deploy.  That's very different to VP8 being undesirable to
deploy by people who have a competing interest in other codecs.

Reducing that to a question of WILLs is a gross oversimplification
that isn't really very helpful to making a Good decision here or to
showing the careful reasoning behind it.

  Simply,
  Ron

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 21 Oct 2012 17:21:46 -0600

On Oct 21, 2012, at 8:44 AM, Stefan Hakansson LK <[email-masked]> wrote:

> I think something like this makes sense. We could alternative do a show of hand for preference of either alternative, if it seems we're far away from any (rough) consensus then we could move on to discuss if we should abandon an MTI video codec, or select an alternative decision process.

I'd like to point out that rough show of hands was done at a previous meeting and it seemed like getting to agreement on a MTI video codec was possible. 

On the question proposed, I don't think this is the right question. The right questions would be of the people that want present information one way or the other, how many of them think nothing they say will change the opinions of anyone in the room. If they feel this way, I'm sure the presentations will be short and no one will line up at the mic to discuss it. My best guess is that the will be people at the front of the room, and at the mic, that feel they have something to say on the topic. 

Keep in mind this approach was discussed at the last meeting an there seemed to an awful lot of people that felt this was important. We have spent an incredible amount of WG meeting time trying to get to the point were we can make have a meeting where we try and come to consensus on this.

---

From: Matthew Kaufman <[email-masked]>
Date: Sun, 21 Oct 2012 20:50:11 -0700

>   or adopt or create an alternative to it."

If only it were this simple. My employer spends more on H.264 licensing 
than it receives in return, and it isn't about "exclusivity" or "revenue 
streams" ( 
http://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx 
)

John Leslie said:

"The actual decisions will
be made by folks [who] won't be in the room.

    Those decisions won't be driven by which codec is better: they'll
be driven by what _risks_ are taken by implementing one or the other."

And this is a much more accurate way of saying it... and why, for anyone 
in the room actually on the "implementation" side, there's not much 
point in continuing to debate the potential merits unless the landscape 
is *significantly* changed from its current state (for example, RF 
licenses for H.264 or total indemnification provided by VP8's owner.)

Matthew Kaufman

---

From: Ron <[email-masked]>
Date: Tue, 23 Oct 2012 09:18:57 +1030

On Sun, Oct 21, 2012 at 08:50:11PM -0700, Matthew Kaufman wrote:
> If only it were this simple. My employer spends more on H.264
> licensing than it receives in return, and it isn't about
> "exclusivity" or "revenue streams"

It is fairly normal to need to pay for exclusivity :)

It certainly means that I could not ship a Free RTCWeb implementation
with H.264 as MTI to the same volume of users that your employer might.
If the cost of simply tracking all those users didn't bankrupt me all
by itself, then the licence fees certainly would try to finish the job.

That sounds like exclusivity to me.  If not a little Deja Vu of the
good old days of the First Browser Wars ...

> And this is a much more accurate way of saying it... and why, for
> anyone in the room actually on the "implementation" side, there's
> not much point in continuing to debate the potential merits unless
> the landscape is *significantly* changed from its current state (for
> example, RF licenses for H.264 or total indemnification provided by
> VP8's owner.)

I don't really understand this repeated insistence that VP8 is somehow
more risky unless it comes with Total Indemnification?

H.264 certainly doesn't come with total indemnification, and MPEG-LA
is very clear that absolutely nothing which they licence comes with
even token indemnification from them or anyone else - or even with a
licence from all the people you might actually need a licence from.

This requirement is totally unprecedented, and such offers are near
to totally non-existent in the real world.  The landscape would most
certainly be changed if we woke up to find it covered in unicorns,
but I don't think anybody would take that seriously as a technical
prerequisite for some candidate technology.

The reality today is that H.264 is currently being prosecuted in the
courts over infringement claims -- while the only apparent threat to
VP8 is a mythical pool, that hasn't actually been formed, that hasn't
actually issued any licencing demands, and that the people who wanted
to form it have refused to say anything about for over a year, since
they last mumbled "yeah, some people responded.  really they did."

H.264 being released under an RF licence would indeed be a game-changer,
though even if that happened, on the evidence at hand today it is still
clearly the more patently risky (no pun intended) of the two unless you
happen to be one of its IPR holders (and even then, so it would seem).

If the current lawsuit against H.264 had instead been prosecuted against
a user of VP8, the prosecuting party would have lost their licence to
use VP8.  No such protection exists for me if I use H.264.

So the balance of both risk and protection would already seem tilted
in favour of VP8 too.  If anyone should be required to provide a total
indemnity, then surely H.264 is in more evident and urgent need of such
a thing, given the risk to it is already *known* to not be hypothetical.

What am I missing that means VP8 should need to jump over an even
higher bar for acceptance in this respect?  So far as I can see it
already has, hasn't it?

 Cheers,
 Ron

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Oct 2012 19:33:29 -0700

> by itself, then the licence fees certainly would try to finish the job.

[BA]  Pardon me if I'm obtuse, but I'd like to better understand the situation that is resulting in your being concerned about having to pay license fees and track users. 

Are you developing HTML5 applications?  f so, are you envisaging that as an HTML5 developer writing a WebRTC application for a browser that supports H.264 you would need to pay licensing fees? 

Are you working for a browser vendor?  If so, are you envisaging that you would need to pay licensing fees based on the number of users of your browser? 

Are you a developer of applications looking to interoperate with WebRTC?  If so, are you calling APIs that enable you to use the H.264 implementation in the OS platform, or accessing the hardware encode/decode functionality (available on most SoC platforms)?  If so, do you believe that you need to pay license fees? 

Or do you primarily develop on platforms without H.264 support in the OS, and on hardware with no H.264 encode/decode support?

---

From: Ron <[email-masked]>
Date: Wed, 24 Oct 2012 16:12:39 +1030

Hi Bernard,

On Mon, Oct 22, 2012 at 07:33:29PM -0700, Bernard Aboba wrote:
> [BA]  Pardon me if I'm obtuse, but I'd like to better understand the
> situation that is resulting in your being concerned about having to pay
> license fees and track users. 
> 
> Are you developing HTML5 applications?  f so, are you envisaging that as an
> HTML5 developer writing a WebRTC application for a browser that supports
> H.264 you would need to pay licensing fees? 
> 
> Are you working for a browser vendor?  If so, are you envisaging that you
> would need to pay licensing fees based on the number of users of your
> browser? 
> 
> Are you a developer of applications looking to interoperate with WebRTC?  If
> so, are you calling APIs that enable you to use the H.264 implementation in
> the OS platform, or accessing the hardware encode/decode functionality
> (available on most SoC platforms)?  If so, do you believe that you need to
> pay license fees? 
> 
> Or do you primarily develop on platforms without H.264 support in the OS, and
> on hardware with no H.264 encode/decode support?  

Yes, I see the distinction that you're aiming to point out there,
but I hadn't got the impression that anybody here actually was
confused by the difference between:

 "If a licenced implementation of H.264 is available, you can use it."

and 

 "RTCWeb can only be used on platforms with a licenced H.264 codec."

The former does not require H.264 to be MTI.  Like any other codec
it can always be negotiated when support for it exists at both ends.

The latter is a consequence of making H.264 MTI and would make this
standard useless to anyone who did not buy a licence to it themselves
or were not happy to restrict their userbase to platforms that had
purchased one for them in advance, whether they wanted it or not.

That doesn't seem like a good starting point for a standard that
likes to describe SIP as "legacy technology", and aims to become a
(if not The) ubiquitous communication technology for the future.

I don't see what is confusing about the idea that the baseline spec
should be RF, and open to as wide a field of users and developers
as possible -- with the ability to negotiate the optional use of
other (possibly royalty encumbered) technologies where some more
constrained demand or deployment or rationale for those also exists.

This would be consistent with the criteria applied for selection
of the MTI audio codec.

To return just briefly to the question of "risk" that was raised,
one other advantage to making VP8 the choice of MTI codec which
occurs to me is that since the known VP8 IPR comes with protective
conditions for its users in the form of the "poison pill" clauses
of its RF licence - then by making it MTI here, we'd also confer
that protection more broadly to RTCWeb users, since anyone suing
them for using VP8 would then also lose their own "licence" to
implement the RTCWeb standard too.

If RTCWeb is as successful at unifying communications as we all
hope it will be, that would certainly be a strong disincentive
to hostile action for anyone likely to actually hold patents on
any relevant communication technology.  That sounds like a much
stronger form of protection to me than "MPEG-LA can licence you
lots of, but not all of, the patents for H.264".  Doesn't it?

 Acutely,
 Ron

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 25 Oct 2012 15:26:31 -0700

Ok, so now that we've had one round of the usual debate that won't 
terminate, *how* much time on the agenda do we really want to spend 
debating the potential merits or flaws of codecs that some of us either 
will or will not use no matter what happens in the meeting?

I really think there's more important things to discuss and specify.

Matthew Kaufman

---

From: Ted Hardie <[email-masked]>
Date: Thu, 25 Oct 2012 16:14:18 -0700

On Thu, Oct 25, 2012 at 3:26 PM, Matthew Kaufman <[email-masked]> wrote:
> terminate, *how* much time on the agenda do we really want

The chairs are currently discussing how to compress the presentation
time, and we hope to have a query to the authors very soon.  That,
presuming it works out, will regain some time.  If there are short mic
lines after the presentations, we will also gain time.

We hope to have an update of the draft agenda that's currently update
by early next week.  Additional topics that you wish to see covered in
any time we make available would be welcome.

Ted

---

From: Ron <[email-masked]>
Date: Fri, 26 Oct 2012 10:45:42 +1030

On Thu, Oct 25, 2012 at 03:26:31PM -0700, Matthew Kaufman wrote:
> debating the potential merits or flaws of codecs that some of us
> either will or will not use no matter what happens in the meeting?

If you feel that the discussion has exhausted all the rationale
that you have to offer, perhaps you'd like to summarise what you
see as the potential merits and flaws of each candidate for us?

"I will not use it no matter what", isn't much of a technical
argument.

"I cannot use it because people are still fighting in the courts
 over who actually has a licence and how much one should cost",
is more than a technical problem, it's a real and present, and
apparently quite enduring danger haunting H.264, and not just for
the people otherwise ineligible to get a licence for it at all.

Am I forgetting one, or is it really now the most litigated codec
in the history of all codecs?

But perhaps you have some other list of pros and cons that
somehow changes that balance?  I'd certainly like to see a
concise summary of what I'm supposedly missing that means
VP8 isn't technically the no-brainer choice to make here, 
in pretty much every respect that has been discussed.

> I really think there's more important things to discuss and specify.

I agree.  But until we get past the question of MTI codecs that
will ensure interoperability, the risk remains that those things
will just be Rearranging The Deck Chairs.  Again.

So let's get some consensus on a summary of pros and cons for
each, that will give us some reasoned basis to back whatever
decision we do arrive at on this, and let us really move on.

 Double Hulled and Hopeful This Time,
 Ron

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 25 Oct 2012 17:25:44 -0700

> see as the potential merits and flaws of each candidate for us?

I think I made this clear in an earlier post. VP8 is not the product of 
a recognized standards body. This has negative technical implications 
and negative legal implications. I am not a lawyer, and this is an IETF 
list, so that's two reasons for me to not go into more detail on the latter.

My employer happens to be a major browser vendor, has published blog 
postings that I've previously referenced on this topic, and nothing 
substantive has changed since those were posted as far as I can tell.

As was pointed out by someone else, and quoted by me previously, the 
decision to include or not include a particular codec in a shipping 
product is not going to be made by any of the technical people on this 
list, and so discussing it here or at the meeting is pointless. And 
presenting *technical* arguments as to the superiority of one or another 
is likewise pointless.

Matthew Kaufman

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 26 Oct 2012 02:07:31 +0000

Hi Ron,
A few comments inline.

On 10.26.2012 08:15 , "Ron" <[email-masked]> wrote:

[...]
>in the history of all codecs?

Oh yes, you are forgetting MPEG-2.  Out of the top of my head, I can
recollect four high profile lawsuits regarding MPEG-2 video essential
claims.  I believe there have been several more, and enforcement is going
on even in the most recent past (the Nero antitrust dispute being the most
prominent one in the last three years).

Many of those MPEG-2 related lawsuits were the result of enforcement
action in an emerging licensing ecosystem that is based on royalties.  I'm
not aware of any video codec patent disputes, nor of any significant
royalty-bearing licensing deals in the video codec space, before the
advent of MPEG-2, formation of the related MPEG-LA pool, and the resulting
wave of litigation.

While there have been a few more, the single most prominent H.264 related
lawsuit today is the action brought by Motorola/google against a number of
companies that could be viewed as threatening the Android ecosystem.
(Most of the older stuff is straightforward enforcement in a settled
royalty-bearing ecosystem.)  The Motorola lawsuits are IMO strategic
disputes, and the use of video codec related patents is just a means to
achieve a higher goal: keep the Android system competitive.

Also, with respect to the Motorola lawsuits, it is my understanding that
the patent claims being litigated are related to interlace technologies
and, therefore, are not relevant to the practice of constrained baseline.
I'm not going to discuss this further; those interested may want to
consult the web or, much better, your trusted patent lawyer.

[...]

Stephan

---

From: Ron <[email-masked]>
Date: Fri, 26 Oct 2012 13:22:53 +1030

On Thu, Oct 25, 2012 at 05:25:44PM -0700, Matthew Kaufman wrote:
> I think I made this clear in an earlier post. VP8 is not the product
> of a recognized standards body. This has negative technical
> implications and negative legal implications. I am not a lawyer, and
> this is an IETF list, so that's two reasons for me to not go into
> more detail on the latter.
> 
> product is not going to be made by any of the technical people on
> this list, and so discussing it here or at the meeting is pointless.
> And presenting *technical* arguments as to the superiority of one or
> another is likewise pointless.

That's a pretty good summary of the problems I'm seeing with the
arguments against VP8 indeed.  And exactly why I asked to see a
more substantial summary of them.

In the one breath you are saying "not the product of an SDO == Bad"
is your only direct argument against it.

And then you immediately follow that with "we should ignore anything
this SDO has to say about it anyway".  And then wonder why I'm more
than a little bewildered about what exactly your argument is here?

The decision of which codec should be MTI for this proposed standard
not being the product of this recognised standards body, I completely
agree would have negative technical and legal implications for it.
Serious ones at that.

It is far less clear in practice how much harm this does to a codec
that was carefully designed by experts in that field though.  It is
clear that working within the IETF process did wonderful things for
Opus -- but it is much less clear that the same people working
together in the same way would have produced total crap if the
efforts to oppose formation of the CODEC WG had been "successful"
at that and they had done their work outside of an SDO instead.

Where is the offensive patent pool against Theora that we've been
hearing about for so many years?  Or the single lawsuit against a
user of it?  What about Vorbis?  Any problems it had were neither
technical nor legal.  Can nobody at all shed any light on the
status of the mythical pool that wanted to attack VP8 which seems
to have vanished in a whimper over a year ago?  Did anyone sue
Skype for SILK?  How does the success of those compare to OOXML?

I don't really see how your argument there is coherent with either
itself or the observable reality.  But you're insisting on it very
strongly so I'm hoping you can clue us in on the missing link that
makes it actually make some sense.

> substantive has changed since those were posted as far as I can

So that's the basis on which you think we should decide this?

There are two other major browser vendors contributing here,
and as I understand it, they both prefer VP8.  Since they have
the lion's share of users, why shouldn't their preference stand
if this logic is applied?

You say nothing substantive has changed since then.
The slope on this graph looks like pretty substantive change to me:
http://upload.wikimedia.org/wikipedia/commons/8/86/Usage_share_of_web_browsers_%28Source_StatCounter%29.svg

The numbers here look pretty substantive too:
http://www.w3schools.com/browsers/browsers_stats.asp

But personally I'd still much rather see us build consensus around
a clear list of agreed pros and cons, so that when people look back
and wonder "how did the RTCWeb WG make that decision" we will have
something a bit more substantive to show for it than "via a farce
where industry heavyweights had their preference rubber-stamped
without discussion or justification that held up to even the most
casual scrutiny."

I'm pretty sure this still is a technical standards group, and that
technical arguments to back up its decisions mostly aren't pointless.

  Unabashedly,
  Ron