Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

From: David Singer <[email-masked]>
Date: Wed, 03 Dec 2014 10:33:04 -0800

As I understand it, the recent face to face meeting decided to draft the requirement that WebRTC browsers be required to implement both VP8 and H.264, and get feedback on this, on the list.

This is some feedback.

I’d like to point out that this could easily place companies in an impossible position.

Consider: it is not uncommon for IPR owners to grant a license (often free) only to ‘conforming implementations’. (A common rationale is that they want to use their IPR to bring convergence and interoperability to the industry).  Let’s hypothesize that this happens, now or in future, from Company X, for some IPR in the WebRTC specifications.

Consider also: we have an “unwilling to license” statement from Nokia on VP8, on the formal record (and including a long list of patents).

Consider finally: a small company for whom WebRTC is important.

Let’s look at the choices:

1.  Follow the mandate, implement VP8, and risk a ruinous lawsuit from Nokia.

2.  Reject the mandate, do not implement VP8, and be formally therefore not conformant and therefore not in receipt of a license from company X; risk a ruinous lawsuit from X.

3.  Do not implement WebRTC, and risk a ruinous loss of relevance.

I do not think that the IETF should be placing anyone into the position of having three extremely unpalatable choices.

(Yes, I am aware that #2 is ‘unlikely’, but one day someone will decide that the “only to conformant implementations” clause needs to be real and enforced, and will do this; our hypothetical small company might prefer not to be the example case.)

(I use a small company as the example, because for them the risk is bankruptcy, but of course no-one likes to step into the path of trouble even if they have the resources to weather it.)

Dave Singer

[email-masked]

David Singer
Manager, Software Standards, Apple Inc.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 03 Dec 2014 20:12:40 +0100

> Consider: it is not uncommon for IPR owners to grant a license (often free) only to ‘conforming implementations’. (A common rationale is that they want to use their IPR to bring convergence and int…

I'm having trouble following the logic here. What technology are you 
imagining that Company X will put IPR claims on, and what conformance do 
you imagine that it would require?

(We could also consider the case of someone, call it Company G, claiming 
IPR on some non-codec part of WebRTC technology and refusing to license 
it at all. We can discuss the relative chances of the two things happening.)

> I do not think that the IETF should be placing anyone into the position of having three extremely unpalatable choices.
If Company G does its thing, both 1 and 2 risk a ruinous lawsuit from 
Company G.
> (I use a small company as the example, because for them the risk is bankruptcy, but of course no-one likes to step into the path of trouble even if they have the resources to weather it.)

My impression from the meeting was that the people speaking in favour of 
the proposed solution had evaluated the risks, and were ready to make a 
decision based on their evaluation.

YMMV.

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 03 Dec 2014 20:28:12 +0100

A copy of this email should be placed directly in the wikipedia 
definition of FUD..

Best regards
Sergio

---

From: David Singer <[email-masked]>
Date: Wed, 03 Dec 2014 13:07:41 -0800

> On Dec 3, 2014, at 11:28 , Sergio Garcia Murillo <[email-masked]> wrote:
> 
> A copy of this email should be placed directly in the wikipedia definition of FUD..

There is plenty of F here.  But there is little U and little D. The Nokia statement exists and license grants of the type I cite are common. Heck, the license given to MPEG-4 *reference software* says this:

"ISO/IEC gives users of MPEG-4 free license to this
software module or modifications thereof for use in hardware 
or software products claiming conformance to MPEG-4.”

You want to put yourself at risk, go right ahead.  Please don’t ask that the IETF mandate that others put themselves at risk.

Dave Singer

[email-masked]

David Singer

---

From: David Singer <[email-masked]>
Date: Wed, 03 Dec 2014 13:07:54 -0800

> On Dec 3, 2014, at 11:12 , Harald Alvestrand <[email-masked]> wrote:
> 
> I'm having trouble following the logic here. What technology are you imagining that Company X will put IPR claims on, and what conformance do you imagine that it would require?

I am imagining the common case that company X has IPR on some aspect of the WebRTC spec. (some other aspect than the codec), and they offer the fairly-common “license is free to conforming implementations of WebRTC”.  

> 
> (We could also consider the case of someone, call it Company G, claiming IPR on some non-codec part of WebRTC technology and refusing to license it at all. We can discuss the relative chances of the two things happening.)

No, I am not interested in discussing trolls here.  I am pursuing much more normal circumstances.

> If Company G does its thing, both 1 and 2 risk a ruinous lawsuit from Company G.
>> 
> My impression from the meeting was that the people speaking in favour of the proposed solution had evaluated the risks, and were ready to make a decision based on their evaluation.

Well, this is exactly that:  for the ‘vanilla’ company, mandating VP8 means mandating a violation of Nokia’s statement, which puts them at risk;  or forcing people to abrogate a ‘must’ clause, which also may put them at risk.  Or not do WebRTC.

Dave Singer

[email-masked]

David Singer

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Wed, 3 Dec 2014 23:32:40 +0000

Hello,

Here are some other feedbacks.

a) How can the group composed by a vast majority of non-browser vendors force a decision on browser vendors against their statements? 
- Apple and Microsoft have stated that they have no plans to implement VP8
- Google has stated they intend to implement the spec (assuming the two codecs)but they have not decided yet when and how
- Mozilla is the only browser vendor that has a clear commitment.
How will the specification be relevant if MTI functions are specified while knowing they will likely not be implemented?
Does the proposed text give us interoperability other than on paper?

b)I don't think there was enough discussion on "non-browser" entities. I believe the two topics (browser/non-browser) should have been separated. There was quite a few objections on a non-browser having to implement both codecs, at the meeting and on the list prior to the meeting. There was some comments as well about the state of WebRTC implementations preventing to deploy applications, the codec was not an issue. Most applications needs to interact with themselves on other platforms or via browsers. For that purpose they can chose the codec they want. Can we leave the non-browser alone (aka not mandating a codec) or asking that they support only one?

Can we separate the two topics to reach agreement on each of them independently?

c) codec versus decoder
I guess the discussion was very limited despite multiple comments that decoder(s) only should be mandated. I did not find any reasoning for mandating the two encoders in the audio archive feed, nor in the slides. Was that a lack of time? Can we discuss that point?

d)Cost increase
Cost does not only equal to patent license.
Cost also include implementation, testing, maintenance, providing APIs. By multiplying codecs, the cost is mechanically increased. Can this be taken in account in the revisiting note?

licensing and RF statement.
It seems there will be further discussion on the proposed revisiting note. When? How? 
Nokia's type 3 declaration has been pointed out many times as a serious concern. 
Another concern is the following: It was stated that Google is "working from the assumption that VP8 is RF and that anyone that challenges that assumption will be proven wrong. that proof may take time and lawyers but we are working from that assumption."
Microsoft, Dolby and Ericsson have made a type 2 declaration and possibly quite a few more can be expected.
It seems that no one knows, as of today, the actual licensing price of VP8; nor how long it will take to resolve that question.

Why does it sound reasonable to the group to impose unknown fees to WebRTC endpoints and actors? 
Is the goal to alleviate the codec fees to only part of the WebRTC ecosystem (aka gateways? App developers)? 
Can this be clarified?

thanks
Gaëlle

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of David Singer
Sent: Wednesday, December 03, 2014 4:08 PM
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Dave Singer

[email-masked]

David Singer

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 03 Dec 2014 16:21:56 -0800

Gaelle Martin-Cocher wrote:
> b)I don't think there was enough discussion on "non-browser" entities. I believe the two topics (browser/non-browser) should have been separated. There was quite a few objections on a non-browser having to implement both codecs, at the meeting and on the list prior to the meeting.

Let me see if I can follow the logic here. There was a "vast majority of 
non-browser vendors" making this decision, but the overwhelming 
consensus achieved in the hum in Honolulu does not demonstrate that 
objections from non-browser vendors are "in the rough".

---

From: Andrew Allen <[email-masked]>
Date: Thu, 4 Dec 2014 01:10:56 +0000

Harald

I think it could be also characterized less of. Those in favor of the solution had evaluates the risks and were reedy to make the decision based on that evaluation to instead. Many of those now in favor had defined  a way forward where their implementations didn't need to expose them to the risks thus minimizing the voice of those that would have to take the risk!

Andrew
H
Sent from my BlackBerry 10 smartphone.
From: Harald Alvestrand
Sent: Wednesday, December 3, 2014 13:13
To: [email-masked]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

YMMV.

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 4 Dec 2014 12:25:47 +1100

> 3.  Do not implement WebRTC, and risk a ruinous loss of relevance.

I don't see the risk of 1. having changed because of the IETF's
statement. Plenty of small companies are already doing 1. and have had
to risk getting sued by Nokia at this point in time already. In fact,
it's a risk that small companies always have to deal with since there
is so much patented technology around that you invariable will step on
something. I doubt very much that the IETF's decision has any impact
on small business' risk in that space at all.

> I do not think that the IETF should be placing anyone into the position of having three extremely unpalatable choices.

For a small company in the WebRTC space, 3. is a non-choice. 2. Is
more of a business decision than an IP decision - which market are you
trying to address? Are you trying to be interoperable with (current)
browsers - then implement VP8. Are you trying to be interoperable with
legacy devices - then implement H.264 (and probably even H.263).

If you are trying to argue for a large company, the situation changes.
However, as a large company, you tend to have an existing portfolio of
patents. You're already playing the game of patents. As long as your
hypothetical "IPR owners to grant a license only to ‘conforming
implementations’" doesn't happen, you are free to choose 2. and avoid
Nokia.

As for the threat in your option 2. - I can only see Google with IPR
around VP8. Now, Google's IPR statement on WebM codecs, which includes
VP8 and VP9 currently states: "Google hereby grants to you a
perpetual, worldwide, non-exclusive, no-charge, royalty-free,
irrevocable (except as stated in this section) patent license"
http://www.webmproject.org/license/additional/
The word "perpetual" implies (to my non-lawyer eyes) that they can't
suddenly change this to mean "only if you are conformant to the
standard". So you can't be referring to such a risk associated with
VP8 being created by Google. I don't know which other company you
would want to be afraid of for your hypothetical threat in 2. Could
you clarify?

Best Regards,
Silvia.

---

From: Andrew Allen <[email-masked]>
Date: Thu, 4 Dec 2014 01:42:19 +0000

Silvia

It  is not usually the small companies that get sued in patent cases. Its companies with assets and significant revenues that get the lawsuits.

Nobody sues the  penniless! - thats like suing the homeless!

Andrew

Sent from my BlackBerry 10 smartphone.
From: Silvia Pfeiffer
Sent: Wednesday, December 3, 2014 19:28
To: David Singer
Cc: [email-masked]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Best Regards,
Silvia.

---

From: David Singer <[email-masked]>
Date: Wed, 03 Dec 2014 18:08:11 -0800

You're missing something. I am considering a company that has ipr in *other* aspects of webrtc, that gives a license to that only to conformant implementations. Not the codec.

What do you do? Defy the Nokia declaration, defy the 'must' and not do vp8 and be non-conformant, or not do webrtc at all? None are good choices.

Sent from my iPad

> On Dec 3, 2014, at 5:25 PM, Silvia Pfeiffer <[email-masked]> wrote:
>

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Thu, 4 Dec 2014 02:10:47 +0000

There was a single hum for the three categories (browser, non-browser, compatible endpoints), right?

That makes a lot of sense for non-browser entities that are in fact WebRTC-compatible enpoints (apps, or gateways or else) to push the burden on the browser vendors as those entities will need to interact with browsers.  Hence "hum"...

I think it would make a lot of sense to have different "hums" or questions for the two different categories.
That will bring clarity on what the "non-browser" yet WebRTC endpoint is, versus what the WebRTC-compatible endpoint is (let aside gateways).
It is not clear to me that we would have had the same results for each category if there was two (or three) different questions.

Gaëlle

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Timothy B. Terriberry
Sent: Wednesday, December 03, 2014 7:22 PM
To: [email-masked]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

> b)I don't think there was enough discussion on "non-browser" entities. I believe the two topics (browser/non-browser) should have been separated. There was quite a few objections on a non-browser h…

Let me see if I can follow the logic here. There was a "vast majority of non-browser vendors" making this decision, but the overwhelming consensus achieved in the hum in Honolulu does not demonstrate that objections from non-browser vendors are "in the rough".

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 03 Dec 2014 19:20:45 -0700

On 11/25/14, 4:33 PM, Adam Roach wrote:
> I've updated the draft-ietf-rtcweb-video based on the minutes from
> Hawaii. Now that we have a clear path to success, I'd like to get the
> document finalized and published as quickly as possible. This means I
> need your feedback on the remaining open issues (1, 4, and 5, below). If
> you are CCed on this mail, it's because you took an action item in
> Hawaii, and I'm waiting to hear back from you.
>
> New version: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/
> Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-03.txt

I have concerns about the future-oriented text:

       To promote the use of non-royalty bearing video codecs,
       participants in the RTCWEB working group, and any successor
       working groups in the IETF, intend to monitor the evolving
       licensing landscape as it pertains to the two mandatory-to-
       implement codecs.  If compelling evidence arises that one of the
       codecs is available for use on a royalty-free basis, the working
       group plans to revisit the question of which codecs are required
       for Non-Browsers, with the intention being that the royalty-free
       codec will remain mandatory to implement, and the other will
       become optional.

The if-clause in the last sentence establishes a trigger for revisiting 
the combination of VP8 and H.264 as MTI video codecs. But is that the 
only possible trigger? If so, I think the document is misguided.

The ideal solution to the video codec problem would be for the IETF 
community to create a truly unencumbered video codec, as it has already 
done for audio with the Opus codec. If the IETF (or some other standards 
development organization) were to develop such a codec, then I think 
that would be a sufficient trigger for revisiting the recommendations in 
this document, no matter what happens with the royalty-free status of 
VP8 and H.264.

I would strongly prefer that the document contain text recognizing that 
possibility.

Furthermore, this text about WebRTC Browsers sends the wrong message, I 
think:

       These provisions apply to WebRTC Non-Browsers only.  There is no
       plan to revisit the codecs required for WebRTC Browsers.

Certainly there is no active plan at this time to revisit the MTI codec 
issue (after all, we're still *visiting* the issue for the first time), 
but that's immaterial to the question of when it might be appropriate to 
do so. The current text reads as if there are no conditions under which 
the MTI codec issue would ever be revisited, and that's just wrong.

(A smaller but not insignificant issue is that the document talks about 
"the RTCWEB working group", "any successor working groups in the IETF", 
and "the working group" interchangeably. Yet can this document establish 
plans for successor working groups, or even future incarnations of the 
RTCWEB working group? Any plans related to future efforts will be set by 
WG consensus or IETF consensus, not for all time by this document.)

IMHO we need to either pull out the future-oriented text entirely (which 
has its own problems) or significantly improve it. I would be happy to 
propose text for the latter.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Justin Uberti <[email-masked]>
Date: Wed, 3 Dec 2014 18:25:00 -0800

Many companies, of various market capitalizations, are shipping VP8 today,
indicating the amount of concern they have for the Nokia declaration.

But as I said during the meeting, if you really are concerned about this,
we would be happy to give you a VP8 binary of some sort.

On Wed, Dec 3, 2014 at 6:08 PM, David Singer <[email-masked]> wrote:

> You're missing something. I am considering a company that has ipr in
> *other* aspects of webrtc, that gives a license to that only to conformant
> implementations. Not the codec.
>
> What do you do? Defy the Nokia declaration, defy the 'must' and not do vp8
> and be non-conformant, or not do webrtc at all? None are good choices.
>
> Sent from my iPad
>
> >> As I understand it, the recent face to face meeting decided to draft
> the requirement that WebRTC browsers be required to implement both VP8 and
> H.264, and get feedback on this, on the list.
> >>
> >> This is some feedback.
> >>
> >>
> >>
> >> Consider: it is not uncommon for IPR owners to grant a license (often
> free) only to ‘conforming implementations’. (A common rationale is that
> they want to use their IPR to bring convergence and interoperability to the
> industry).  Let’s hypothesize that this happens, now or in future, from
> Company X, for some IPR in the WebRTC specifications.
> >>
> >> Consider also: we have an “unwilling to license” statement from Nokia
> on VP8, on the formal record (and including a long list of patents).
> >>
> >> 2.  Reject the mandate, do not implement VP8, and be formally therefore
> not conformant and therefore not in receipt of a license from company X;
> risk a ruinous lawsuit from X.
> >>
> >> I do not think that the IETF should be placing anyone into the position
> of having three extremely unpalatable choices.
> >
> >> (Yes, I am aware that #2 is ‘unlikely’, but one day someone will decide
> that the “only to conformant implementations” clause needs to be real and
> enforced, and will do this; our hypothetical small company might prefer not
> to be the example case.)
> >>
> >> (I use a small company as the example, because for them the risk is
> bankruptcy, but of course no-one likes to step into the path of trouble
> even if they have the resources to weather it.)
> >>
> >> Dave Singer
> >>
> >> [email-masked]
> >>
> >> David Singer

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Dec 2014 19:22:36 -0800

> a) How can the group composed by a vast majority of non-browser vendors force a decision on browser vendors against their statements? 

[BA]  The basic gist is "don't dual MTI him, don't dual MTI me, dual MTI the fellow behind the tree".  No mobile application or device maker will pay attention to the dual MTI requirement, nor should they - it adds overhead and potential liability/fees with little benefit.  For codec implementers, the timing couldn't be worse - with next generation codecs now appearing in products (e.g. H.265 and VP9), making an argument for diverting resources away into work on previous generation codecs is difficult at best.

There is a difference between suggesting a compromise that many people dislike but can live with versus one that is only palatable if it applies to someone else.

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 4 Dec 2014 16:16:43 +1100

Indeed, that's why I said point 1. in David's list doesn't make sense,
since he's talking about a small company getting sued by Nokia.
S.

On Thu, Dec 4, 2014 at 12:42 PM, Andrew Allen <[email-masked]> wrote:

>   Silvia
>
>  It  is not usually the small companies that get sued in patent cases.
> Its companies with assets and significant revenues that get the lawsuits.
>
>    *From: *Silvia Pfeiffer
> *Sent: *Wednesday, December 3, 2014 19:28
> *To: *David Singer
> *Cc: [email-masked]
> *Subject: *Re: [rtcweb] Finishing up the Video Codec document, MTI
> (again, still, sorry)
>
> > As I understand it, the recent face to face meeting decided to draft the
> requirement that WebRTC browsers be required to implement both VP8 and
> > Consider also: we have an “unwilling to license” statement from Nokia on
> VP8, on the formal record (and including a long list of patents).
> >

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 04 Dec 2014 13:26:15 +0100

> It is not clear to me that we would have had the same results for each category if there was two (or three) different questions.

It is not clear that the questions are independent.

In fact, it is pretty clear to me that some participants who were 
willing to go with this package deal were quite unwilling to commit to 
all the pieces of the package if they were presented one at a time, and 
they had to answer the question not knowing how all the other pieces 
came out.

I think this is a textbook case of a "package deal".

---

From: Ron <[email-masked]>
Date: Fri, 5 Dec 2014 01:21:38 +1030

> 3.  Do not implement WebRTC, and risk a ruinous loss of relevance.

This seems more like a hypothetical small strawman than a situation
that any *real* small company has expressed to this group.

Your concern for small operators is heartwarming, but I think if you
consult the list archives to see what such people have actually said
for themselves, the only ruinous legal barrier that Nokia appears to
have them worried about is the IPR it holds on H.264 that is outside
the pool MPEG-LA operates, with no clear guarantee of its terms.

And we *still* don't have an IPR statement from them about this.
How many times should we need to ask them to respect the IETF process?

Fear of VP8 here would appear to be directly proportional to something
much simpler than what you claim.

If someone would like to graph "Number of H.264 patents held" vs
"Fear of VP8 being MTI", I think you'll find the real correlation
that you're grasping for here to be fairly obvious.

  hth!
  Ron

---

From: Ron <[email-masked]>
Date: Fri, 5 Dec 2014 01:30:41 +1030

Hi Peter,

On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet wrote:
> The if-clause in the last sentence establishes a trigger for revisiting the
> combination of VP8 and H.264 as MTI video codecs. But is that the only
> possible trigger? If so, I think the document is misguided.
> 
> community to create a truly unencumbered video codec, as it has already done
> for audio with the Opus codec. If the IETF (or some other standards
> development organization) were to develop such a codec, then I think that
> would be a sufficient trigger for revisiting the recommendations in this
> document, no matter what happens with the royalty-free status of VP8 and
> H.264.
> 
> issue (after all, we're still *visiting* the issue for the first time), but
> that's immaterial to the question of when it might be appropriate to do so.
> The current text reads as if there are no conditions under which the MTI
> codec issue would ever be revisited, and that's just wrong.
> 
> (A smaller but not insignificant issue is that the document talks about "the
> RTCWEB working group", "any successor working groups in the IETF", and "the
> working group" interchangeably. Yet can this document establish plans for
> successor working groups, or even future incarnations of the RTCWEB working
> group? Any plans related to future efforts will be set by WG consensus or
> IETF consensus, not for all time by this document.)
> 
> IMHO we need to either pull out the future-oriented text entirely (which has
> its own problems) or significantly improve it. I would be happy to propose
> text for the latter.

I'd definitely be interested in seeing proposals from you to improve
upon these things.  It seemed premature to explore this until we had
some sense of whether this kind of compromise could fly at all, but
now that it seems it can, I think these are important details for us
to clarify as best we can.

  Thanks!
  Ron

---

From: Andrew Allen <[email-masked]>
Date: Thu, 4 Dec 2014 15:43:28 +0000

Silvia

I think the risk for small companies is if they suddenly have a successful product and have revenue that they then become a target. Plenty of cash flow to go after without the experience and resources to fight off the lawsuit.

My point was the fact that small companies may have implemented VP8 without yet becoming engaged in a lawsuit does not prove  that VP8 is RF.

Andrew

Sent from my BlackBerry 10 smartphone.
From: Silvia Pfeiffer
Sent: Wednesday, December 3, 2014 23:17
To: Andrew Allen
Cc: David Singer; [email-masked]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Indeed, that's why I said point 1. in David's list doesn't make sense, since he's talking about a small company getting sued by Nokia.
S.

On Thu, Dec 4, 2014 at 12:42 PM, Andrew Allen <[email-masked]<mailto:[email-masked]>> wrote:
Silvia

Andrew

Sent from my BlackBerry 10 smartphone.
From: Silvia Pfeiffer
Sent: Wednesday, December 3, 2014 19:28
To: David Singer
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Best Regards,
Silvia.

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

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 04 Dec 2014 08:45:28 -0700

> to clarify as best we can.

OK, I'll get to work. :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: cowwoc <[email-masked]>
Date: Thu, 04 Dec 2014 10:49:40 -0500

Andrew,

This discussion is kind of silly. We should be investing as much energy 
into disproving Nokia's IP claim as they have invested into proving it 
is valid: none at all. The fact that they haven't provided a shred of 
evidence after repeated public inquiries will be used against them in a 
court of law, should it ever come up.

Gili

On 04/12/2014 10:43 AM, Andrew Allen wrote:
> Silvia
>
> I think the risk for small companies is if they suddenly have a 
> successful product and have revenue that they then become a target. 
> Plenty of cash flow to go after without the experience and resources 
> to fight off the lawsuit.
>
> My point was the fact that small companies may have implemented VP8 
> without yet becoming engaged in a lawsuit does not prove  that VP8 is RF.
>
> Andrew
>
> *Sent: *Wednesday, December 3, 2014 23:17
> *To: *Andrew Allen
> *Cc: *David Singer; [email-masked]
>     It  is not usually the small companies that get sued in patent
>     cases. Its companies with assets and significant revenues that get
>     the lawsuits.
>
>     *Cc: [email-masked] <mailto:[email-masked]>
>     > As I understand it, the recent face to face meeting decided to
>     draft the requirement that WebRTC browsers be required to
>     implement both VP8 and H.264, and get feedback on this, on the list.
>     >
>     > This is some feedback.
>     >
>     >
>     >
>     > Consider: it is not uncommon for IPR owners to grant a license
>     (often free) only to ‘conforming implementations’. (A common
>     rationale is that they want to use their IPR to bring convergence
>     and interoperability to the industry).  Let’s hypothesize that
>     this happens, now or in future, from Company X, for some IPR in
>     the WebRTC specifications.
>     >
>     > Consider also: we have an “unwilling to license” statement from
>     Nokia on VP8, on the formal record (and including a long list of
>     patents).
>     >
>     > 2.  Reject the mandate, do not implement VP8, and be formally
>     therefore not conformant and therefore not in receipt of a license
>     from company X; risk a ruinous lawsuit from X.
>     >
>     > I do not think that the IETF should be placing anyone into the
>     position of having three extremely unpalatable choices.
>
>     > (Yes, I am aware that #2 is ‘unlikely’, but one day someone will
>     decide that the “only to conformant implementations” clause needs
>     to be real and enforced, and will do this; our hypothetical small
>     company might prefer not to be the example case.)
>     >
>     > (I use a small company as the example, because for them the risk
>     is bankruptcy, but of course no-one likes to step into the path of
>     trouble even if they have the resources to weather it.)
>     >
>     > Dave Singer
>     >
>     > [email-masked] <mailto:[email-masked]>
>     >
>     > David Singer
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 4 Dec 2014 16:50:36 +0100

On Thu, 4 Dec 2014 15:43:28 +0000

> to fight off the lawsuit.

Forcing H.264 only on small fishes like us instead will remove the risk
of having a successful product entirely, as we wouldn't be able to
afford it. I guess we should be grateful.

L.

> Indeed, that's why I said point 1. in David's list doesn't make
> sense, since he's talking about a small company getting sued by
> Nokia. S.
> 
> On Thu, Dec 4, 2014 at 12:42 PM, Andrew Allen
> <[email-masked]<mailto:[email-masked]>> wrote: Silvia
> 
> On Thu, Dec 4, 2014 at 5:33 AM, David Singer
> <[email-masked]<mailto:[email-masked]>> wrote:
> > draft the requirement that WebRTC browsers be required to implement
> > both VP8 and H.264, and get feedback on this, on the list.
> >
> > This is some feedback.
> >
> >
> >
> > and interoperability to the industry).  Let’s hypothesize that this
> > happens, now or in future, from Company X, for some IPR in the
> > WebRTC specifications.
> >
> > bankruptcy, but of course no-one likes to step into the path of

---

From: Adam Roach <[email-masked]>
Date: Thu, 04 Dec 2014 08:08:57 -0800

> OK, I'll get to work. :-)

Awesome, thanks. I've always found your prose to be clearer and easier 
to read than mine anyway. :)

When you draft your text, keep in mind that what we're trying to do is 
capture the essence of the agreement that we've formed a critical mass 
around. The less formal (i.e., not really document-ready) version of 
this is:

> "WebRTC devices MUST implement both VP8 and H.264. If compelling 
> evidence arises that one of the codecs is available for use on a 
> royalty-free basis, such as all IPR declarations known for the codec 
> being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change 
> this normative statement to indicate that only that codec is required. 
> For absolute, crystal clarity, this provision is only applicable to 
> WebRTC devices, and not to WebRTC User Agents."

There's nuance to be added there, for sure, but I'd encourage you not to 
color way outside those lines. Expanding scope to discuss issues such as 
*other* circumstances that may cause revisiting the MTI, for example, 
are far more likely to weaken consensus than they are to strengthen it.

/a

---

From: David Singer <[email-masked]>
Date: Thu, 04 Dec 2014 11:17:21 -0800

> On Dec 4, 2014, at 6:51 , Ron <[email-masked]> wrote:
> 

I’m sorry, is H.264 a specification in progress at the IETF? You will find declarations from them at ISO, IEC, and ITU, I think. They state (as I recall) RAND.  (Not “unwilling to license”.)

David Singer

---

From: David Singer <[email-masked]>
Date: Thu, 04 Dec 2014 11:25:48 -0800

> On Dec 3, 2014, at 21:16 , Silvia Pfeiffer <[email-masked]> wrote:
> 

So, your conclusion to my question is “Ship VP8, most of you probably won’t get sued. Good luck.  Try not to be too successful or your luck may change.”

It is an answer; I don’t think it’s a good one, myself.

David Singer

---

From: Silvia Pfeiffer <[email-masked]>
Date: Fri, 5 Dec 2014 07:10:08 +1100

There is no difference to h.264 in that respect. I still don't understand
the fascination of big companies with perceived problems of small
companies. What are you really trying to say?

Best Regards,
Silvia.
On 5 Dec 2014 02:43, "Andrew Allen" <[email-masked]> wrote:

> successful product and have revenue that they then become a target. Plenty
> of cash flow to go after without the experience and resources to fight off
> the lawsuit.
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 4 Dec 2014 15:15:21 -0500

David,

The other answer is "Ship H.264. Most of you are going to get sued. Good
luck settling." The risk associated with licensing H.264 is very high for
any company who is not already part of this quagmire. There are enough
problems there to hire an IPR law firm the second you look at H.264 and
hope that they are professional enough and there is enough money to
settle.  I do understand that companies who are already stuck with H.264
would not want to be exposed to any additional IPR claims. There is also a
little problem that if they implement VP8, they cannot sue any other VP8
implementers, or risk losing the VP8 IPR license.

Being a small company, we had to go through patent law suite/settlement
process several times already. Being small is not a defense against getting
sued. Some IPR holders prefer to start with going after smaller players to
create a large precedent base before going after larger targets. As far as
possibility of being sued is concerned, the free VP8 license actually looks
safer for us then the paid H.264 license. Neither offers indemnity, but, at
least, VP8 license offers reciprocity.

I do think that the current solution is the only one currently possible. If
everyone implements both, then everyone would be forced to deal with the
same problems. Hopefully, as a result, some sort of collective resolution
would be found. I doubt anybody is happy with this decision. There are a
parties who are affected by this decision who can make the situation better
for everybody. If they think this decision is so bad, they know exactly
what is required to make other options acceptable.

_____________
Roman Shpount

On Thu, Dec 4, 2014 at 2:25 PM, David Singer <[email-masked]> wrote:

> So, your conclusion to my question is “Ship VP8, most of you probably
> won’t get sued. Good luck.  Try not to be too successful or your luck may
> change.”
>

---

From: Silvia Pfeiffer <[email-masked]>
Date: Fri, 5 Dec 2014 07:20:11 +1100

Yes and it's the same answer as for h.264 and h.265 for that matter. Only
add to that the extra licence fee you heavy to pay, which is a certainty -
the risk of getting sued is uncertain and frankly quite small compared to
other risks that you take as a small company.

It would be nice to remove those risks, too, yes, but it's not a show
stopper and no different between the codecs.

Regards,
Silvia.

---

From: David Singer <[email-masked]>
Date: Thu, 04 Dec 2014 12:29:20 -0800

> On Dec 4, 2014, at 12:15 , Roman Shpount <[email-masked]> wrote:
> 
> David,
> 
> The other answer is "Ship H.264. Most of you are going to get sued. Good luck settling." The risk associated with licensing H.264 is very high for any company who is not already part of this quagmire.

I beg to disagree.  I am unaware of any problem from any company that has not made clear RAND declarations to the appropriate bodies, and most of those are members of MPEG-LA, so though it’s not quite a one-stop shop, it’s close.

Not only is there a formal “unwilling to license” on the table for VP8, it was not developed by the companies active in this area, and with significant portfolios, and (as Nokia shows) they may not find themselves under  formal or moral obligation to license at all.

> There are enough problems there to hire an IPR law firm the second you look at H.264 and hope that they are professional enough and there is enough money to settle.  I do understand that companies who are already stuck with H.264 would not want to be exposed to any additional IPR claims. There is also a little problem that if they implement VP8, they cannot sue any other VP8 implementers, or risk losing the VP8 IPR license.

True, we would get some protection from practicing entities.

> 
> Being a small company, we had to go through patent law suite/settlement process several times already. Being small is not a defense against getting sued.

Not what Silvia was hoping to hear.

> Some IPR holders prefer to start with going after smaller players to create a large precedent base before going after larger targets. As far as possibility of being sued is concerned, the free VP8 license actually looks safer for us then the paid H.264 license. Neither offers indemnity, but, at least, VP8 license offers reciprocity.

I think there is also some defensive suspension in the H.264 licenses, but I would have to check.

> 
> I do think that the current solution is the only one currently possible. If everyone implements both, then everyone would be forced to deal with the same problems.

“We may as well all drown together” — it’s not very cheery, is it?

> Hopefully, as a result, some sort of collective resolution would be found. I doubt anybody is happy with this decision. There are a parties who are affected by this decision who can make the situation better for everybody. If they think this decision is so bad, they know exactly what is required to make other options acceptable.

I wish.

David Singer

---

From: David Singer <[email-masked]>
Date: Thu, 04 Dec 2014 12:30:50 -0800

> On Dec 4, 2014, at 12:20 , Silvia Pfeiffer <[email-masked]> wrote:
> 
> 
> Yes and it's the same answer as for h.264 and h.265 for that matter.

It is not at all.  Where are the “unwilling to license” statements for H.264?  Where is the VP8 license coverage from the larger players not in the MPEG-LA agreement?

> Only add to that the extra licence fee you heavy to pay, which is a certainty - the risk of getting sued is uncertain and frankly quite small compared to other risks that you take as a small company.

See the other thread…

David Singer

---

From: cowwoc <[email-masked]>
Date: Thu, 04 Dec 2014 15:33:53 -0500

A formal "unwilling to license" without any factual information to back 
it up is practically meaningless.

What is the legal difference between a company that does that and a 
company who sues using a previously-undeclared H.264 IPR?

Gili

---

From: Silvia Pfeiffer <[email-masked]>
Date: Fri, 5 Dec 2014 07:40:51 +1100

> > > > Indeed, that's why I said point 1. in David's list doesn't make
sense, since he's talking about a small company getting sued by Nokia.
> It is not at all.  Where are the “unwilling to license” statements for
H.264?  Where is the VP8 license coverage from the larger players not in
the MPEG-LA agreement?
>
> > Only add to that the extra licence fee you heavy to pay, which is a
certainty - the risk of getting sued is uncertain and frankly quite small
compared to other risks that you take as a small company.

That can very nicely be construed as anticompetitive behaviour I would
think in my layman knowledge. It certainly doesn't look like playing fair.

> See the other thread…

Indeed, Roman certainly has more experience with law suits and still shares
my position.

Regards,
Silvia.

> David Singer
> Manager, Software Standards, Apple

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 4 Dec 2014 20:43:46 +0000

As a tangent to this discussion, I'd note that pretty much every codec implementor will be subject to additional IPR risk. This is because pretty much all the standards specifications of codecs only specify the decoder (VP8 included). Therefore any IPR claims and licences tied to the specification will only have relevance to the decoder.

Unless you have a viable application that only needs the decoder, you will have zero visibility in the standards IPR databases of what IPR claims might exist against your coder implementation.

Everyone who uses the term "codec" in association with "royalty free" or "IPR free" is misleading the world. What they mean is the decoder only.

Regards

Keith

> Sent: 04 December 2014 20:31
> To: Silvia Pfieffer
> Cc: [email-masked]
> > > > Indeed, that's why I said point 1. in David's list 
> doesn't make sense, since he's talking about a small company 
> getting sued by Nokia.
> > >
> > > So, your conclusion to my question is "Ship VP8, most of 
> you probably won't get sued. Good luck.  Try not to be too 
> successful or your luck may change."
> > 
> It is not at all.  Where are the "unwilling to license" 
> statements for H.264?  Where is the VP8 license coverage from 
> the larger players not in the MPEG-LA agreement?
> 
> > Only add to that the extra licence fee you heavy to pay, 
> which is a certainty - the risk of getting sued is uncertain 
> and frankly quite small compared to other risks that you take 
> as a small company.
> 
> See the other thread...
> 
> David Singer

---

From: David Singer <[email-masked]>
Date: Thu, 04 Dec 2014 12:52:42 -0800

> On Dec 4, 2014, at 12:40 , Silvia Pfeiffer <[email-masked]> wrote:
> 
> 
> That can very nicely be construed as anticompetitive behaviour I would think in my layman knowledge. It certainly doesn't look like playing fair.

Sorry, I can’t work out what you say is not playing fair?  Using someone else’s patents and assuming that they will give everyone a license?

David Singer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 4 Dec 2014 16:04:32 -0500

On Thu, Dec 4, 2014 at 3:43 PM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> As a tangent to this discussion, I'd note that pretty much every codec
> implementor will be subject to additional IPR risk. This is because pretty
> much all the standards specifications of codecs only specify the decoder
> (VP8 included). Therefore any IPR claims and licences tied to the
> specification will only have relevance to the decoder.
>
> Unless you have a viable application that only needs the decoder, you will
> have zero visibility in the standards IPR databases of what IPR claims
> might exist against your coder implementation.
>
> Everyone who uses the term "codec" in association with "royalty free" or
> "IPR free" is misleading the world. What they mean is the decoder only.
>
>
Actually Google does grant patent license to the implementation of WebM,
which includes both encoder and decoder (
http://www.webmproject.org/license/additional/). This is one of the reasons
we think VP8 license is better then H.264. (The other two are reciprocity
and no use restrictions on the produced media).
_____________
Roman Shpount

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 04 Dec 2014 13:15:30 -0800

Roman Shpount wrote:
> which includes both encoder and decoder
> (http://www.webmproject.org/license/additional/). This is one of the
> reasons we think VP8 license is better then H.264. (The other two are
> reciprocity and no use restrictions on the produced media).

Serge also confirmed on this list that that license applies to 
third-party implementations as well: 
https://www.ietf.org/mail-archive/web/rtcweb/current/msg04006.html

The Opus licenses similarly grant rights to patents that read on the 
reference implementation, including the encoder, even if used in a 
third-party implementation.

Now, it's certainly possible to infringe other people's IPR by 
implementing an encoder sufficiently different from the reference 
encoder. One must be very careful when doing that. But these reference 
implementations are production-grade. Anyone who merely wishes to deploy 
a codec has an implementation they can use with just as much assurance 
of the IPR safety of the encoder as they have of the decoder.

---

From: David Singer <[email-masked]>
Date: Thu, 04 Dec 2014 13:22:02 -0800

> On Dec 4, 2014, at 13:04 , Roman Shpount <[email-masked]> wrote:
> 
> On Thu, Dec 4, 2014 at 3:43 PM, DRAGE, Keith (Keith) <[email-masked]> wrote:
> Actually Google does grant patent license to the implementation of WebM, which includes both encoder and decoder (http://www.webmproject.org/license/additional/). This is one of the reasons we think VP8 license is better then H.264. (The other two are reciprocity and no use restrictions on the produced media).

It doesn’t take long to find the word “encoder” in the MPEG-LA summary:

"SUMMARY OF AVC/H.264 LICENSE TERMS1

The AVC Patent Portfolio License is divided into two principal parts (see Diagram): (a) sublicenses granting the right to manufacture and sell AVC encoders and decoders…”

That the specification only specifies the decoding process does not mean that the license only applies to decoding. Those granting licenses appear to grant them also for encoding, to my read. (IANAL).

MPEG has taken the position that as long as you produce decodable, conformant, bitstreams, you can encode how you like.  Given that this has resulted in substantial (I have heard 2X) performance improvements in the life of codecs (MPEG-2 and I think AVC) this seems goodness to me.

David Singer

---

From: Silvia Pfeiffer <[email-masked]>
Date: Fri, 5 Dec 2014 08:56:06 +1100

> Sorry, I can’t work out what you say is not playing fair?  Using someone else’s patents and assuming that they will give everyone a license?

"unwilling to license" doesn't seem like they even want to make money
with their patents. Since that is limited to patents that apply to one
codec and not to any other codec, I can only interpret that as playing
unfair. Note that this is my personal opinion and I don't think taking
this discussion any further is useful in any way. :-)

Silvia.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 4 Dec 2014 22:59:59 +0100

> As I understand it, the recent face to face meeting decided to draft the requirement that WebRTC browsers be required to implement both VP8 and H.264, and get feedback on this, on the list.

I've been searching in both the rtcweb and public-webrtc mailing
lists, and must say that it is VERY SAD that the only "contribution"
and "feedback" received from Apple are these regarding "MTI codecs",
nothing else.

I hope Apple has better things to do than sending FUD to working
groups in which they have no interest.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: David Singer <[email-masked]>
Date: Thu, 04 Dec 2014 14:01:46 -0800

> On Dec 4, 2014, at 13:56 , Silvia Pfeiffer <[email-masked]> wrote:
> 

Got you.  Notwithstanding that I agree that the discussion seems to be due to taper off, and noting that I have no idea what Nokia’s motivation is, I also note that sometimes people offer licenses only in some cases (e.g. for a specific international standard) as a way to try to bring interoperability and convergence to the industry.  “You can use my nice idea only if you implement X in an interoperable fashion”.  I actually think that this is one of the better uses of IPR, as it helps converge into interoperable playing fields.

Of course, when X is not free, this is then problematic for those who prefer free.  I recognize that.

David Singer

---

From: David Singer <[email-masked]>
Date: Thu, 04 Dec 2014 14:03:44 -0800

> On Dec 4, 2014, at 13:59 , Iñaki Baz Castillo <[email-masked]> wrote:
> 

I apologize for both the fact that you think this is FUD, and for the lack of other engagement.

Quite where you see the uncertainty and doubt in the “you MUST implement something which, it is stated, is subject to IPR which CANNOT be licensed”, I am less sure.  Fear, yes, I get that.

David Singer

---

From: David Singer <[email-masked]>
Date: Thu, 04 Dec 2014 14:21:48 -0800

> On Dec 4, 2014, at 12:33 , cowwoc <[email-masked]> wrote:
> 
> A formal "unwilling to license" without any factual information to back it up is practically meaningless.

They supply a (long) list of actual patents. That is quite a bit of factual information.  (Rather too much for some people, and not enough for others, I suspect; a lot of work to read them, and not specific reasons why they think those patents apply.  But you take what you can get, and the formal process only asks for the patent numbers.)

> What is the legal difference between a company that does that and a company who sues using a previously-undeclared H.264 IPR?

Well, in one case you were put on formal notice, and in the other, it was a situation you were previously unaware of. IANAL but I think this makes a difference.

David Singer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 4 Dec 2014 23:30:32 +0100

> Quite where you see the uncertainty and doubt in the “you MUST implement something which, it is stated, is subject to IPR which CANNOT be licensed”, I am less sure.  Fear, yes, I get that.

Just to clarify, I'm not in favor of mandating non 100% royalty-free
codecs in a W3C specification.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: David Singer <[email-masked]>
Date: Thu, 04 Dec 2014 14:36:18 -0800

> On Dec 4, 2014, at 14:30 , Iñaki Baz Castillo <[email-masked]> wrote:
> 

I understand and respect that.  I would also prefer not to mandate an RF codec; I just can’t find one.  I don’t like the situation at all.  

I just don’t see the current proposed wording as solving anything, and in fact, it makes the problem worse, not better.

David Singer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 4 Dec 2014 23:02:41 +0000

Both yours and David's responses to this are outside the IPR gathering exercise that forms part of the standards process.

The idea of the standards process is that a group of vendors etc write a standard, they are forced to declare their IPR involved in that standard. If the population is sufficiently large you stand a good chance of identifying all the worldwide IPR relating to that standard.

The bigger the standards organisation, with the greater coverage of all the vendors in that space, the better the process works.

So at that level, IPR knowledge for codecs is primarily on the decoder space and what IPR exists there.

What Tim is saying (and a somewhat parallel situation exists with MPEG LA) is that a limited set of organisations will limit your IPR problems and give you some help with the encoder IPR. For VP8 that is limited to Google's IPR and any background research they may have done. For MPEG LA it is limited to the members of the pool, which is only a subset of those involved in the parallel standards process. Yes it helps, but it does not have the degree of confidence of identifying all the existing IPR that the standards process would do.

Regards

Keith

> Sent: 04 December 2014 21:16
> To: [email-masked]
> > Actually Google does grant patent license to the implementation of 
> > WebM, which includes both encoder and decoder 
> Serge also confirmed on this list that that license applies 
> to third-party implementations as well: 
> The Opus licenses similarly grant rights to patents that read 
> on the reference implementation, including the encoder, even 
> if used in a third-party implementation.
> 
> Now, it's certainly possible to infringe other people's IPR 
> by implementing an encoder sufficiently different from the 
> reference encoder. One must be very careful when doing that. 
> But these reference implementations are production-grade. 
> Anyone who merely wishes to deploy a codec has an 
> implementation they can use with just as much assurance of 
> the IPR safety of the encoder as they have of the decoder.
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 4 Dec 2014 15:16:09 -0800

On Thu, Dec 4, 2014 at 2:03 PM, David Singer <[email-masked]> wrote:

> Quite where you see the uncertainty and doubt in the “you MUST implement
> something which, it is stated, is subject to IPR which CANNOT be licensed”,
> I am less sure.  Fear, yes, I get that.
>
>
I don't see others being deterred by the alleged uncertainty; there was
quite a broad consensus for this at IETF 91. But again, if this is a
particularly sensitive issue for your employer, I think there are many
potential solutions we can discuss.

---

From: David Singer <[email-masked]>
Date: Thu, 04 Dec 2014 16:23:17 -0800

> On Dec 4, 2014, at 14:36 , David Singer <[email-masked]> wrote:
> 
> 

I obviously meant a non-RF codec.  sorry

David Singer

---

From: Ron <[email-masked]>
Date: Fri, 5 Dec 2014 14:27:06 +1030

On Thu, Dec 04, 2014 at 02:03:44PM -0800, David Singer wrote:
> Quite where you see the uncertainty and doubt in the “you MUST
> implement something which, it is stated, is subject to IPR which
> CANNOT be licensed”, I am less sure.  Fear, yes, I get that.

Are you seriously suggesting that the due diligence which Google's
team did prior to the acquisition of On2 and the VP8 IP was so
completely incompetent that they "somehow missed" the barnload of
random claims that Nokia have belatedly asserted here as a last
scorched earth defence after all other lines of sophistry were
apparently failing dismally?

And/or that Google was also subsequently too incompetent to look
at those and make a few small changes to avoid any they really did?

I think you're right that there isn't actually much uncertainty
or doubt there, but a small group of H.264 patent holders sure is
still trying hard to project the idea that there ought to be some.
Their fear is showing yes.  But it doesn't really appear to be
rubbing off onto anyone else.

> “We may as well all drown together” — it’s not very cheery, is it?

I think the metaphor you were looking for here was "burn on the
platform together".

I don't think there's much uncertainty or doubt as to who the
arsonists are here.  If they want to self-immolate, that's fine,
but wanting to burn everyone else to the water line with them
isn't encouraging anyone to want to join them in that.

The current "compromise" is a direct response to attempts to game
the system to avoid the clear no-brainer outcome of adopting VP8,
which for all empirical measures is still as RF as Opus is, and
would be a near perfect fit as the sort of open to everyone
technology that the IETF prefers to endorse in its standards.

If you don't like the compromise, that's fine.  Lots of us don't
very much like it either.  But if you want to actually fix that,
you're flexing your muscles at the wrong group.  You ought to be
leaning on Nokia instead.  They are the ones who keep shoving a
sabot into the machinery here - though it's hard to think they'd
persist in that like they have without firm encouragement from
their peers.  It's not a good look for them.

The H.264 patent holder cartel holds all the cards to resolve this
one way or the other now.  This compromise explicitly hands them
the deck to shuffle and deal.  The sooner they understand that
they can't just bully or frighten the people who really need an
RF codec into giving up on having one, the sooner we can all get
on with the real game.

This compromise is a way of saying that you can't bully us into
total inaction and failure of this standard either.

I commend the people from both camps who have agreed to meet in
the middle, for all the work they have done trying to find real
ways to move this forward.

  Ron

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 05 Dec 2014 09:37:33 +0100

> They supply a (long) list of actual patents. That is quite a bit of factual information.  (Rather too much for some people, and not enough for others, I suspect; a lot of work to read them, and not…

Just to be precise:

The statement made by Nokia in MPEG does not cite patent numbers.
The statement made by Nokia in the IETF does cite patent numbers (thank 
you, Nokia!)
Neither statement explains which part of the VP8 specification the 
patents apply to.

And, of course, neither statement can compel anyone to come to the 
conclusion that the patent is a) valid, and b) applies to VP8 - that is 
a matter for each participant's legal analysis, which the industry 
participants have a long tradition of not sharing publicly (there are 
probably good reasons for that).

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 05 Dec 2014 09:40:49 +0100

On 12/05/2014 12:02 AM, DRAGE, Keith (Keith) wrote:
> What Tim is saying (and a somewhat parallel situation exists with MPEG LA) is that a limited set of organisations will limit your IPR problems and give you some help with the encoder IPR. For VP8 that is limited to Google's IPR and any background research they may have done.
And, of course, the IPR owned by signatories to the license agreement 
that Google has sublicensed through the WebM CCL: 
http://www.webm-ccl.org/vp8/agreement/

>   For MPEG LA it is limited to the members of the pool, which is only a subset of those involved in the parallel standards process. Yes it helps, but it does not have the degree of confidence of identifying all the existing IPR that the standards process would do.
>
> Regards
>
> Keith
>

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Fri, 5 Dec 2014 18:56:53 +0000

Hi Harald, 

Is that a google position or just an assumption?
I don't think anyone has an issue with WebRTC-Compatible endpoint. 
Assuming browsers have to implement both and that this question is out of the way.
The remaining point is the 'non-browser', which is already differentiated by the note, and it is acknowledged that (over time?) they may only have one codec to implement. 
I don't see why revisiting the  non-browser category is a problem.

Gaëlle

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Thursday, December 04, 2014 7:26 AM
To: [email-masked]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

In fact, it is pretty clear to me that some participants who were willing to go with this package deal were quite unwilling to commit to all the pieces of the package if they were presented one at a time, and they had to answer the question not knowing how all the other pieces came out.

---

From: David Singer <[email-masked]>
Date: Fri, 05 Dec 2014 11:11:30 -0800

> On Dec 4, 2014, at 19:57 , Ron <[email-masked]> wrote:
> 

I love your colorful language. I might think that it optimistic to think one could develop a motion-estimating, DCT-based, entropy-coded, codec — one that is in direct family from H.261 and MPEG-2 onwards — and avoid all the IPR. But your colorful language and happy faith in these engineers, and others’ skepticism, are both beside the point.

There is a formal notice from a company that they believe they hold IPR and they are unwilling to license. You and I can dislike the situation, dislike patent law, dislike the procedures, or anything else, as much as we wish, it doesn’t change them.

For the IETF to insert a MUST into a specification it is instructing companies, based on no visible analysis, and (unfortunately, since the German case closed without a clear answer) no formal judgment, to defy the claim and risk suit. That is clearly formally inappropriate.  The most we should do is to use a term from RFC 6919 (I’d suggest sections 1 or 6).

David Singer

---

From: Adam Roach <[email-masked]>
Date: Fri, 05 Dec 2014 11:13:38 -0800

> Is that a google position or just an assumption?

We speak as individuals.

> Assuming browsers have to implement both and that this question is out of the way.

I was about to make the same point that Harald did, but he beat me to 
it: the questions were asked together because the nature of the 
compromise was, for many people, "I'm okay with X if and only if Y". 
Characterizing this as an unconditional acceptance of one without the 
other is ridiculous.

/a

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Fri, 5 Dec 2014 19:24:53 +0000

The audio archive clearly showed that individual were talking on behalf of their company; but if you dismiss that, I am ok to have individuals answering.

I have not seen many email stating ""I'm okay with X if and only if Y". can you point that to me, in the context of this proposal with these categories?

I think what is ridiculous is to push more actors to be a webRTC-compatible endpoint, it is unclear they will just avoid one codec, they might remove much more from their apps/devices/browsers etc. 

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Friday, December 05, 2014 2:14 PM
To: Gaelle Martin-Cocher; Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

We speak as individuals.

I was about to make the same point that Harald did, but he beat me to
it: the questions were asked together because the nature of the compromise was, for many people, "I'm okay with X if and only if Y". 
Characterizing this as an unconditional acceptance of one without the other is ridiculous.

/a

---

From: Ted Hardie <[email-masked]>
Date: Fri, 5 Dec 2014 11:55:18 -0800

Hi David,

On Fri, Dec 5, 2014 at 11:11 AM, David Singer <[email-masked]> wrote:

> There is a formal notice from a company that they believe they hold IPR
> and they are unwilling to license. You and I can dislike the situation,
> dislike patent law, dislike the procedures, or anything else, as much as we
> wish, it doesn’t change them.
>
> For the IETF to insert a MUST into a specification it is instructing
> companies,

​This is fundamentally incorrect.  The IETF writes voluntary standards.  A
MUST in an IETF standard is not an instruction to a company; it is a
description of the expected behaviour of an interoperable implementation.
You are not required to implement the standard at all.  At most, it is a
description of what someone who claimed compliance to the standard is
expected to have done.

And note, "is expected" here has exactly no regulatory force; it is "is
expected" by other interoperable implementations.​

> based on no visible analysis, and (unfortunately, since the German case
> closed without a clear answer) no formal judgment, to defy the claim and
> risk suit.

​The IETF, as a body, does not undertake those analyses.  Working group
members may undertake them when deciding whether to implement the standard.​

> That is clearly formally inappropriate.  The most we should do is to use a
> term from RFC 6919 (I’d suggest sections 1 or 6).
>
>
​April 1 RFCs are an amusing lot, aren't they?  ​

​The proposed compromise contains multiple methods for handling the risk
you believe present:  choose not to implement the standard; choose a
different level compliance (endpoint); choose to accept the offer of a
binary solution provided by others (as have put forward by both Cisco and
Google).  The sense of the room (as I heard it as participant from the
floor) was that there were lots of people who could work with this
compromise, those methods, and their perception of the risk.

You are absolutely free to perform what risk analysis you like and to take
whatever risk avoidance​ steps you deem appropriate.  That might, sadly,
mean you remain on the sidelines as WebRTC moves forward.  Whatever your
choices there, please represent the IETF process correctly as you do so.

regards,

Ted Hardie
as an individual

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Fri, 5 Dec 2014 20:37:43 +0000

Harald, 

Would you mind clarifying if that VP8 WebM CCL agreement is up to date (copyright is 2010-2013) and if it covers all the declarations that are listed in https://tools.ietf.org/html/draft-benham-rtcweb-vp8litigation ?

Gaëlle

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Friday, December 05, 2014 3:41 AM
To: [email-masked]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

> What Tim is saying (and a somewhat parallel situation exists with MPEG LA) is that a limited set of organisations will limit your IPR problems and give you some help with the encoder IPR. For VP8 t…
And, of course, the IPR owned by signatories to the license agreement that Google has sublicensed through the WebM CCL: 
http://www.webm-ccl.org/vp8/agreement/

---

From: David Singer <[email-masked]>
Date: Fri, 05 Dec 2014 12:44:40 -0800

> On Dec 5, 2014, at 11:55 , Ted Hardie <[email-masked]> wrote:
> 
> Hi David,
> 
> For the IETF to insert a MUST into a specification it is instructing companies,
> 
> ​This is fundamentally incorrect.  The IETF writes voluntary standards.  A MUST in an IETF standard is not an instruction to a company; it is a description of the expected behaviour of an interoperable implementation.  You are not required to implement the standard at all.  At most, it is a description of what someone who claimed compliance to the standard is expected to have done.

OK, I apologize for the casual writing.  “If you claim to conform <this> definition in this RFC, then you MUST…” is effectively a conditional instruction.  Yes, of course you get to choose whether to implement at all (but you wouldn’t be here if you hadn’t chosen to implement), and also which definition you implement to (but see below).

> And note, "is expected" here has exactly no regulatory force; it is "is expected" by other interoperable implementations.​

It might not have regulatory force, but it might have consequences: notably any IPR grants that are conditioned on “conforming implementations”, as I pointed out before. If you deliberately don’t do a “must” (rather than, for example, having a bug), your claim of conformance may be suspect and your license therefore questionable.

> based on no visible analysis, and (unfortunately, since the German case closed without a clear answer) no formal judgment, to defy the claim and risk suit.
> 
> ​The IETF, as a body, does not undertake those analyses.  Working group members may undertake them when deciding whether to implement the standard.​
>  
> That is clearly formally inappropriate.  The most we should do is to use a term from RFC 6919 (I’d suggest sections 1 or 6).
> 
> 

Well, but that’s where we seem to be.  They are amusing precisely because they cut ‘close to the bone’.

> ​The proposed compromise contains multiple methods for handling the risk you believe present:  choose not to implement the standard; choose a different level compliance (endpoint);

This is where we stray into RFC 6919 territory.  You’re suggesting that an acceptable outcome is that some (many?) implementations of WebRTC in products that are called Browsers might NOT be, in fact, "WebRTC Browsers”?  This seems to both confuse the expectation — be contrary to a straightforward reading — and defeat the purpose (of interoperability). I was trying to treat the specification more straightforwardly than this, and go with obvious meanings and intentions.

If this is the expected outcome we might need a note saying roughly “Note that not every WebRTC implementation in a browser is a WebRTC Browser; some may be WebRTC Endpoints."

> choose to accept the offer of a binary solution provided by others (as have put forward by both Cisco and Google).  

I didn’t reply to this before: the point of the Cisco offer is not that it is binary, but that it carries a license.  The difficulty with VP8 is not, per se, in compiling the code, it’s the formal refusal to license.

> The sense of the room (as I heard it as participant from the floor) was that there were lots of people who could work with this compromise, those methods, and their perception of the risk.
> 
> You are absolutely free to perform what risk analysis you like and to take whatever risk avoidance​ steps you deem appropriate.  That might, sadly, mean you remain on the sidelines as WebRTC moves forward.  Whatever your choices there, please represent the IETF process correctly as you do so.

I will try to be as precise as I can.  My apologies for the casual writing.

best wishes

David Singer

---

From: Ted Hardie <[email-masked]>
Date: Fri, 5 Dec 2014 13:07:58 -0800

On Fri, Dec 5, 2014 at 12:44 PM, David Singer <[email-masked]> wrote:

>
> OK, I apologize for the casual writing.  “If you claim to conform <this>
> definition in this RFC, then you MUST…” is effectively a conditional
> instruction.  Yes, of course you get to choose whether to implement at all
> (but you wouldn’t be here if you hadn’t chosen to implement), and also
> which definition you implement to (but see below).
>

​May I take your presence in this discussion as an indication that you have
chosen to implement?​

While I certainly would welcome such good news, there may well be folks
here who are deciding whether and what to implement based on these
decisions. What I heard in the room was a lot of folks who were willing to
make this compromise to move forward, because it helped enable WebRTC as a
whole (this was the main thrust of JDR's comments, for example).  Speaking
personally, I hope that means that the breadth of implementors will
increase in the light of the options that will be available.

> It might not have regulatory force, but it might have consequences:
> notably any IPR grants that are conditioned on “conforming
> implementations”, as I pointed out before.

​You have pointed out that such IPR grants can exist.  I did not see you
point out​ any that applied to this case.  If I missed that pointer, I
would appreciate your sharing it again.

> If you deliberately don’t do a “must” (rather than, for example, having a
> bug), your claim of conformance may be suspect and your license therefore
> questionable.
>
> > That is clearly formally inappropriate.  The most we should do is to use
> a term from RFC 6919 (I’d suggest sections 1 or 6).
> >
> >
> different level compliance (endpoint);
>
> This is where we stray into RFC 6919 territory.  You’re suggesting that an
> acceptable outcome is that some (many?) implementations of WebRTC in
> products that are called Browsers

​No, I didn't say that.  I noted that someone who is building based on
WebRTC has options here.  The endpoint option may be workable for many
(especially in the Mobile App space).

While I am terribly fond of my browser colleagues, the real uptake here has
to be among those who write applications on the WebRTC platform--and making
that robust enough and varied enough for their needs is important.

Note as well that I, personally, have never advocated for having a single
codec available to an app or a browser; the methods for negotiating are a
key part of this infrastructure, and they will be key to it moving forward
as things progress.  We worked toward a mandatory-to-implement to avoid
interoperability failure.  This compromise gets a pretty good way toward
avoiding it​ and past what had been an impasse.  Am I thrilled?  No.  But
it works well enough to be going along with.

 .

>
> I didn’t reply to this before: the point of the Cisco offer is not that it
> is binary, but that it carries a license.  The difficulty with VP8 is not,
> per se, in compiling the code, it’s the formal refusal to license.
>
> OpenH264 notes that Cisco "will not pass on ... MPEG-LA licensing costs"
and, as far as I can see, pretty much stops there​.  Google is also not
passing on its costs in VP8, if there are any.  IF you believe that there
are other, unbundled rights you need in either, then you should behave
accordingly.  But the two are exactly parallel: they require the
participant to asses the available rights and risks.  Others' assessments
of those risks apparently differ from yours.

> > The sense of the room (as I heard it as participant from the floor) was
> that there were lots of people who could work with this compromise, those
> methods, and their perception of the risk.
> >
> > You are absolutely free to perform what risk analysis you like and to
> take whatever risk avoidance​ steps you deem appropriate.  That might,
> sadly, mean you remain on the sidelines as WebRTC moves forward.  Whatever
> your choices there, please represent the IETF process correctly as you do
> so.
>
​Thank you, and I will try to do the same.

regards,

Ted Hardie
as an individual​

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 5 Dec 2014 13:25:42 -0800

Ted Hardie said:

"What I heard in the room was a lot of folks who were willing to make this
compromise to move forward, because it helped enable WebRTC as a whole
(this was the main thrust of JDR's comments, for example). "

[BA] What I heard was quite different.  A lot of folks were in favor of
having *others* undertake a dual MTI obligation so they could benefit.  I
did not hear a lot of folks claim that *they themselves* were willing to
undertake the obligation for their own benefit or the benefit of WebRTC.
Big difference.

On Fri, Dec 5, 2014 at 1:07 PM, Ted Hardie <[email-masked]> wrote:

> ​May I take your presence in this discussion as an indication that you
> have chosen to implement?​
>
>> > That is clearly formally inappropriate.  The most we should do is to
>> use a term from RFC 6919 (I’d suggest sections 1 or 6).
>> >
>> >
>> > ​The proposed compromise contains multiple methods for handling the
>> risk you believe present:  choose not to implement the standard; choose a
>> This is where we stray into RFC 6919 territory.  You’re suggesting that
>> an acceptable outcome is that some (many?) implementations of WebRTC in
> While I am terribly fond of my browser colleagues, the real uptake here
> has to be among those who write applications on the WebRTC platform--and
> making that robust enough and varied enough for their needs is important.
>
>> I didn’t reply to this before: the point of the Cisco offer is not that
>> it is binary, but that it carries a license.  The difficulty with VP8 is
>> not, per se, in compiling the code, it’s the formal refusal to license.
>>

---

From: Mohammed Raad <[email-masked]>
Date: Fri, 5 Dec 2014 23:30:16 +0200

David,

What's missing from this thread is input from Nokia. I found it interesting
that the same list of patents submitted to the IETF was omitted from the
"unwilling to license" declaration made to ISO and IEC. My understanding of
the compromise made by the people at the meeting is that they either do not
believe that the declaration made is credible or that it is in some other
way irrelevant. It's interesting that you seem to be trying to "save" the
people who made this decision and their employers from it.

Mohammed

---

From: David Singer <[email-masked]>
Date: Fri, 05 Dec 2014 13:42:50 -0800

> On Dec 5, 2014, at 13:07 , Ted Hardie <[email-masked]> wrote:
> 
> ​May I take your presence in this discussion as an indication that you have chosen to implement?​  

Alas, no.  My job is to manage the standards landscape, and not products.  It’s another assumed conditional (!) “If my company (or indeed anyone) were to want to implement, could we/they, would we/they?"

> ​You have pointed out that such IPR grants can exist.  I did not see you point out​ any that applied to this case.  If I missed that pointer, I would appreciate your sharing it again.

If I find one, I will.  At this point, I merely point out that they are not unusual.

> This is where we stray into RFC 6919 territory.  You’re suggesting that an acceptable outcome is that some (many?) implementations of WebRTC in products that are called Browsers
> 
> ​No, I didn't say that.  I noted that someone who is building based on WebRTC has options here.  The endpoint option may be workable for many (especially in the Mobile App space). 

well, OK, but it does seem that if we went ahead with this text, you are saying that a browser would have a 4th option, over the three I already pointed out:

1) Implement VP8 and defy the “unwilling to license”
2) Don’t implement it, defy the “must” in the spec.
3) Don’t claim to do WebRTC at all

and now 
4) Though being a browser and doing WebRTC, claim only to be a WebRTC Endpoint, not a WebRTC Browser.

I simply don’t see how this helps anything. It’s confusing and doesn’t advance interoperability at all.  We may as well delete the WebRTC Browser clause, and call everything an endpoint, if it’s a myth that browsers that implement WebRTC will be conformant to the WebRTC Browser requirements.  Or, as I said, put a 6919 clause 1 reference next to the MUST in the webrtc browser case. :-)

> While I am terribly fond of my browser colleagues, the real uptake here has to be among those who write applications on the WebRTC platform--and making that robust enough and varied enough for their needs is important.  

I thought the principle platform was envisaged to be the WebRTC browser — something that allows embedding of webrtc in arbitrary web pages?  Yes, we expect to interop with more focused endpoints. The applications don’t supply the codecs, do they (assuming by ‘application’ you mean the collection of HTML, JS, CSS and the like)?

> OpenH264 notes that Cisco "will not pass on ... MPEG-LA licensing costs" and, as far as I can see, pretty much stops there​.  Google is also not passing on its costs in VP8, if there are any.  IF you believe that there are other, unbundled rights you need in either, then you should behave accordingly.  But the two are exactly parallel: they require the participant to asses the available rights and risks.  Others' assessments of those risks apparently differ from yours.

It really is not similar.  Maybe there are licenses that one or other does not carry:  in the Cisco case, we are unaware of any “unwilling to license”, whereas for VP8 there is a clear statement that no license can be had.  Agreed, whether you actually need a license or not is a separate question.

David Singer

---

From: Adam Roach <[email-masked]>
Date: Fri, 05 Dec 2014 14:28:46 -0800

On 12/5/14 13:25, Bernard Aboba wrote:
> [BA] What I heard was quite different.  A lot of folks were in favor 
> of having *others* undertake a dual MTI obligation so they could 
> benefit.  I did not hear a lot of folks claim that *they themselves* 
> were willing to undertake the obligation for their own benefit or the 
> benefit of WebRTC.  Big difference.

Hi there.

/a

---

From: Ted Hardie <[email-masked]>
Date: Fri, 5 Dec 2014 14:32:28 -0800

Hi David,

On Fri, Dec 5, 2014 at 1:42 PM, David Singer <[email-masked]> wrote:

> ​
​(Much snipped)​

> I thought the principle platform was envisaged to be the WebRTC browser —
> something that allows embedding of webrtc in arbitrary web pages?

​That's certainly a model, and on platforms which provide robust access to
the necessary substrates, it may well be popular.  But it's not the only
model--a mobile app can be distributed with a  set of encoders and decoders
if the platform does not provide them (or, indeed, it could make up any
other deficits of the substrate in a particular OS).
​Because the Mah-jong ​application which substitutes player's faces for the
tile backs isn't expecting to handle arbitrary JS, or interoperate with
other applications other than browsers, the endpoint approach is valuable
for it.

>   Yes, we expect to interop with more focused endpoints. The applications
> don’t supply the codecs, do they (assuming by ‘application’ you mean the
> collection of HTML, JS, CSS and the like)?
>
> That's the "application" inside the browser or conforming mobile web
platform; it's not the only application type that might be doing WebRTC.​

> It really is not similar.  Maybe there are licenses that one or other does
> not carry:  in the Cisco case, we are unaware of any “unwilling to
> license”, whereas for VP8 there is a clear statement that no license can be
> had.

​In both cases, the participant needs to assess whether they know of all
the salient IPR, whether they have all the licenses for that IPR which they
need.   While I am not a lawyer, I imagine that in both cases that would
involve making a determination of the relevance of the claim as well as an
analysis of its license terms.  It also involves an assessment of the risk
that there are other claims which may later arise.

To my lay person's eyes, the two assessments do look pretty similar.  It
appears, honestly, that you disagree with the results' of others
assessments, rather than that the assessments do not need to take place in
both cases.  But I may be misunderstanding your point.

regards,

Ted Hardie
as an individual

> Agreed, whether you actually need a license or not is a separate question.
>
>
> David Singer

---

From: David Singer <[email-masked]>
Date: Fri, 05 Dec 2014 15:13:48 -0800

Hi Ted

> On Dec 5, 2014, at 14:32 , Ted Hardie <[email-masked]> wrote:
> 
> Hi David,
> 
>> It really is not similar.  Maybe there are licenses that one or other does not carry:  in the Cisco case, we are unaware of any “unwilling to license”, whereas for VP8 there is a clear statement that no license can be had. 
>> 
> ​In both cases, the participant needs to assess whether they know of all the salient IPR, whether they have all the licenses for that IPR which they need.   While I am not a lawyer, I imagine that in both cases that would involve making a determination of the relevance of the claim as well as an analysis of its license terms.  It also involves an assessment of the risk that there are other claims which may later arise.
> 
> To my lay person's eyes, the two assessments do look pretty similar.  It appears, honestly, that you disagree with the results' of others assessments, rather than that the assessments do not need to take place in both cases.  But I may be misunderstanding your point.

OK, let me see if I can persuade you of a qualitative difference.  For each ‘must’, what is the nature and availability of licenses that I might need from those claiming IPR?

* H.264: all those claiming IPR offer licenses, though most of them ask for payment
* VP8: almost all offer licenses that are either free or effectively so (pre-paid, in the case of the MPEG-LA), but there is one for which no license is available (and it’s not an insignificant company, or one not active in the field, or a small set of patents)

For me, that is a major difference.  Clearly for others (e.g. Ron who has said as much), the cost is more significant than the license availability.

I think inserting the ‘must’ here means that companies will either ignore it, or claim not to be a WebRTC Browser, neither of which advance the cause of interoperability at all.  If, in fact, we expect there to be a significant number of WebRTC Endpoints, and that we expect that they will be sometimes at both ends of a call, then this tentative agreement already has given up on ensuring interop, and I suggest we simply move to the webRTC Endpoint requirements and delete the webRTC Browser one.  (We could enhance it in various ways: add a ‘recommend both at least for decode’, for example.)

David Singer

---

From: Ted Hardie <[email-masked]>
Date: Fri, 5 Dec 2014 16:07:52 -0800

On Fri, Dec 5, 2014 at 3:13 PM, David Singer <[email-masked]> wrote:

>
> OK, let me see if I can persuade you of a qualitative difference.  For
> each ‘must’,
> ​​
> ​​
> what is the nature and availability of licenses that I might need from
> those claiming IPR?
>
>
​Is that the right question?  I think that " what is the nature and
availability of licenses that I might need from those whose IPR I believe I
must use?" might be closer, but, again, I am not a lawyer.  Seeking a
license for everything claimed is at best highly conservative; it might
even be expensive and unnecessary.

This is, in any case, exactly what I pointed out earlier:  each participant
must make this same assessment for each of the cases.

> * H.264: all those claiming IPR offer licenses, though most of them ask

​Note that this may be the case for common encoders and decoders, but
anyone coming up with their own code (especially on the encoder side) would
have ​to conduct the analysis for themselves.

* VP8: almost all offer licenses that are either free or effectively so
> (pre-paid, in the case of the MPEG-LA), but there is one for which no
> license is available (and it’s not an insignificant company, or one not
> active in the field, or a small set of patents)
>
> ​​There has been one assertion of non-licensable patents to be named later
(MPEG) and one set of patents (often asserted in multiple countries)  named
to the IETF in the following IPR declaration:
https://datatracker.ietf.org/ipr/2035/ . As noted above, I am not a lawyer,
but I invite folks to have their lawyers wade through that; it may be
shallower water than it first appears.

For me, that is a major difference.  Clearly for others (e.g. Ron who has
> said as much), the cost is more significant than the license availability.
>
> I think inserting the ‘must’ here means that companies will either ignore
> it

​I don't have a crystal ball myself, but I note at least two companies that
make browsers have said that they will comply if this the standard.  There
may be others that do not, of course, and if they had been intending to
consider it, it is obviously something that they would need to add to the
consideration.   But your conclusion is not the same as others', at least
according to my hearing or my reading of the work at Chrome and Firefox.​

​regards,

Ted Hardie
as an individual​

---

From: Ron <[email-masked]>
Date: Sat, 6 Dec 2014 14:49:05 +1030

On Fri, Dec 05, 2014 at 03:13:48PM -0800, David Singer wrote:
> > (Much snipped)
> > In both cases, the participant needs to assess whether they know of all the salient IPR, whether they have all the licenses for that IPR which they need.   While I am not a lawyer, I imagine that in both cases that would involve making a determination of the relevance of the claim as well as an analysis of its license terms.  It also involves an assessment of the risk that there are other claims which may later arise.
> > 
> each ‘must’, what is the nature and availability of licenses that I
> might need from those claiming IPR?
> 
> * H.264: all those claiming IPR offer licenses, though most of them
> ask for payment * VP8: almost all offer licenses that are either free
> or effectively so (pre-paid, in the case of the MPEG-LA), but there is
> one for which no license is available (and it’s not an insignificant
> company, or one not active in the field, or a small set of patents)

Ted was doing such a good job explaining this, that I was just going to
leave it to him.  But if you're going to call me out to be your champion,
to make your point here, then ...  ok :>

> For me, that is a major difference.  Clearly for others (e.g. Ron who
> has said as much), the cost is more significant than the license
> availability.

No.  You've clearly missed the point here, and you've missed it on the
order of Astronomical Units, not Barns.  You're going have to repeat
Free Software 101 I'm afraid.  I've never said anything of the sort.

Let me see if I can explain to you the qualitative difference ...

I'd gladly pay to be able to use VP8.  This isn't about money at all.
There simply is no amount of money that can remove the real crippling
costs of being burdened with or indentured to H.264 at present.

This is about Freedom.  The availability of a license for Freedom even.

The freedom to not have to count and track the users of my software.
The freedom to not have to ask permission to do what I need to do.
The freedom to not have to worry about anticompetitive patent abuse.
The freedom to interoperate with anyone else who values freedom.
The freedom to actually be able to get on with doing genuinely
interesting things instead of dealing with dinosaur legalese from
companies that no longer know how to do that.

I could go on, but that's probably enough for you to be able to
google the concept from there as your first homework assignment.

Do you want to know the really fun part about where I learned how
important these things were?  You're going to get a kick out of
this.  Go find a manual for an apple][ and turn to the back page!

When you're done studying its schematics and the source for its
ROM, we can get together for a beer and reminisce about where it
All Went So Sadly Wrong. :)

> I think inserting the ‘must’ here means that companies will either
> ignore it, or claim not to be a WebRTC Browser, neither of which
> advance the cause of interoperability at all.

So far we have something like 75% or more of the browser user market
share on board.  The only players in that game who aren't, are a
company that won't even tell us whether they plan to implement this
or not (which clearly makes their opinion vitally important!), and
another company who at some point at least seemed quite determined
to fork this effort and go off and do something completely different
all on their own.

That seems like a pretty good base to start from to me.

Maybe the holdouts will want to come play with us eventually, and
maybe they won't.  But we can't wait for them forever while they
learn to tie their shoelaces.  Enough people made that mistake
with SIP, let's not repeat it again here.

  Fiducially,
  Ron

---

From: Mohammed Raad <[email-masked]>
Date: Sat, 6 Dec 2014 06:24:14 +0200

Bravo!
On 6 Dec 2014 06:19, "Ron" <[email-masked]> wrote:

> > >> It really is not similar.  Maybe there are licenses that one or other
> does not carry:  in the Cisco case, we are unaware of any “unwilling to
> > > In both cases, the participant needs to assess whether they know of
> all the salient IPR, whether they have all the licenses for that IPR which
> they need.   While I am not a lawyer, I imagine that in both cases that
> would involve making a determination of the relevance of the claim as well
> as an analysis of its license terms.  It also involves an assessment of the
> risk that there are other claims which may later arise.
> > >
> > > To my lay person's eyes, the two assessments do look pretty similar.
> It appears, honestly, that you disagree with the results' of others

---

From: Andrew Allen <[email-masked]>
Date: Sat, 6 Dec 2014 05:40:18 +0000

As Harald already admitted this entire debate has been about companies business interests and not technical merits. There is ABSOLUTELY NO TECHNICAL REASON to have 2 MTI video codecs. This has been company business interest from the start.

Just about every comment I see in this thread is about what advances or disadvantages a particular company that the individual works for.

Sent from my BlackBerry 10 smartphone.
From: Adam Roach
Sent: Friday, December 5, 2014 14:14
To: Gaelle Martin-Cocher; Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

We speak as individuals.

/a

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Sat, 06 Dec 2014 19:14:48 -0700

> are far more likely to weaken consensus than they are to strengthen it.

I see two kinds of triggers:

1. A trigger that is specific to the alternatives we have been presented 
so far. That is: only H.264 or VP8 (or both) can be MTI. If we learn 
that one of them can be used royalty-free, then that codec will be the 
only MTI codec.

Questions:

1a. Does this trigger fire as soon as one codec is learned to be usable 
royalty-free? So this is a first-past-the-post contest? (Let's say codec 
"c1" is learned to be usable RF and the next week or month or quarter 
"c2" is learned to be usable RF. What happens?)

1b. Text along the lines of "the IETF will change this normative 
statement" does not make it clear how that will happen. Is there an 
automatic trigger (i.e., it's built into this document)? Or does the 
IETF need to do something (e.g., publish an RFC that obsoletes this one)?

(There is some interaction between 1a and 1b. If some process is needed 
to declare "c1" the only MTI, then it's possible that we might learn 
that "c2" can also be used RF before the obsoleting RFC can be published.)

2. A trigger that is more general and future-proof. That is: someday 
(perhaps before too much longer on the standardization timescale) we 
will have other alternatives to consider: H.265, VP9, VP10, Daala, and 
who knows what.

Another question:

2a. There is some interaction between 1b and 2. Let's say it takes us 10 
years to learn that "c1" can be used RF. Hurray! But by that time, we 
might have "c3" and "c4" and "c5" to consider. Are we forbidden from 
considering anything but "c1" and "c2" at that time?

I *think* that the trigger you're talking about is #1. Personally I am 
much more interested in #2 because I don't think we'll really settle 
this issue in the medium term or long term until we have the video 
equivalent of Opus.

Because I think we're talking about different triggers for different 
purposes, my impression is that the text we have in mind would differ 
significantly (in particular, I feel no compulsion to "stay within the 
lines" because I think those lines are not useful, and indeed are 
positively harmful, in the long term).

Peter

-- 
Peter Saint-Andre
CTO @ &yet
https://andyet.com/

---

From: Ron <[email-masked]>
Date: Sun, 7 Dec 2014 14:50:41 +1030

On Sat, Dec 06, 2014 at 07:14:48PM -0700, Peter Saint-Andre - &yet wrote:
> 1. A trigger that is specific to the alternatives we have been presented so
> far. That is: only H.264 or VP8 (or both) can be MTI. If we learn that one
> of them can be used royalty-free, then that codec will be the only MTI
> codec.
> 
> Questions:
> 
> "c1" is learned to be usable RF and the next week or month or quarter "c2"
> is learned to be usable RF. What happens?)

This question was briefly picked at here:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg13506.html

> 1b. Text along the lines of "the IETF will change this normative statement"
> does not make it clear how that will happen. Is there an automatic trigger
> (i.e., it's built into this document)? Or does the IETF need to do something
> (e.g., publish an RFC that obsoletes this one)?
> 
> (There is some interaction between 1a and 1b. If some process is needed to
> declare "c1" the only MTI, then it's possible that we might learn that "c2"
> can also be used RF before the obsoleting RFC can be published.)

My impression was that this trigger is basically only relevant up until
the point where we actually publish an RFC specifying MTI video.  Since
after that it's essentially set in stone unless or until we publish some
superseding RFC.

There were one or two voices pushing for whatever decision we make now
to somehow irrevocably bind all future decisions, but personally I think
that is pure nonsense, we couldn't do that even if we wanted to.  Any
future RFC can say anything it likes, whether made by this same group
or any other.

If the facts on the ground change after we've published, sufficiently
for us to want to do something else, then I assume that something else
will need to run the gauntlet of IETF consensus again the same way as
any proposal normally would.

If I'm wrong about any of that, I'm happy to rethink my assumptions,
but that's the datum I've been surveying things from.

> (perhaps before too much longer on the standardization timescale) we will
> have other alternatives to consider: H.265, VP9, VP10, Daala, and who knows
> what.
> 
> Another question:
> 
> years to learn that "c1" can be used RF. Hurray! But by that time, we might
> have "c3" and "c4" and "c5" to consider. Are we forbidden from considering
> anything but "c1" and "c2" at that time?
> 
> I *think* that the trigger you're talking about is #1. Personally I am much
> more interested in #2 because I don't think we'll really settle this issue
> in the medium term or long term until we have the video equivalent of Opus.

I think this is where the hopes of most of the people who have been
facepalming at the idea of H.264 even being considered here, except
as some sort of sick in-joke, have moved to now.  With this compromise
essentially just being a way to avoid the work of this group collapsing
completely before the IETF can do for video what it did for audio with
Opus.

What should happen with this standard once it does, is much less clear
to me at this point in time.

The obvious first step Ted reiterated again most recently here:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg13722.html

 "Note as well that I, personally, have never advocated for having a
  single codec available to an app or a browser; the methods for
  negotiating are a key part of this infrastructure, and they will be
  key to it moving forward as things progress.  We worked toward a
  mandatory-to-implement to avoid interoperability failure."

So things which support a new codec will be able to negotiate it as
soon as it is available, as an essential part of this spec.

Whether we'll want to revisit making one or more of them MTI, and/or
dropping one or more of the existing MTI choices, seems like something
we can't really answer yet.

I do hope we'll have an IETF working group for video codec work soon,
how long before it completes that work and publishes is an open question
and how long after that happens before it reaches World Domination is
another.

Where RTCWEB will be at that time, I'm not sure anyone has a sufficiently
powerful crystal ball to really say.  (I mean, who would have guessed
that after all these years people are still dorking about trying to
*finish* HTML :)

I completely agree that this is the really interesting question now,
and it was one of the reasons some of us put forward the idea of having
H.261 as the MTI (if you're going to be stuck with a legacy MTI forever
it might as well be something lightweight) but that idea didn't really
get to critical mass either.

At this stage, I think we basically can only look at what options we
have and what facts we know up until the point where the video MTI
question goes to WGLC for publication of the RFC specifying it.

What happens after that is basically a clean slate again.  We can't be
constrained "normatively" by any previous decision, and it would be
stupid to want to be, since it's far more likely that things we don't
expect will change what we have to work with than things which we do.
(We might wake up tomorrow to find some company announcing that it has
essential patents on H.264 that it is refusing to licence, which could
change things we haven't specified actions for here too but that might
still spur us to action anyway)

All we can really do is work toward the world that we really want to
have, and make future decisions based on how successful we were at
that in the future.  I don't think anything we are talking about here
can or does rule out any of the interesting possibilities you're
seeing for the 'trigger 2' case though.

> lines" because I think those lines are not useful, and indeed are positively
> harmful, in the long term).

Unless I'm still missing (or wrong about) something, the worst case I
can see us painting ourselves into for the future is some people might
need to support whatever lands as MTI in this first iteration for a
bit longer than they otherwise would.  That Cisco folk wanted to kill
H.261 (which their devices already support) rather than make it MTI
here, seems to confirm that whatever lines we draw here today, aren't
really going to bind us forever.  If something we pick today becomes
more harmful than good in the future I don't think people are going
to feel bound to keeping it.

Video codecs are still far from being a Solved Problem, and I suspect
"both camps" can probably agree with the above.  If for no other
reason than the people who preferred VP8 are going to see better RF
alternative emerge, and the people who preferred H.264 are going to
have the patents that they hold expire eventually.

I don't mind if we explicitly say something to that effect, but it's
not clear to me that we need to for it to actually be in effect anyway.

  Cheers,
  Ron

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 07 Dec 2014 09:58:10 +0100

Personal opinions....

On 12/07/2014 03:14 AM, Peter Saint-Andre - &yet wrote:
> 1. A trigger that is specific to the alternatives we have been
> presented so far. That is: only H.264 or VP8 (or both) can be MTI. If
> we learn that one of them can be used royalty-free, then that codec
> will be the only MTI codec.
>
> Questions:
>
> 1a. Does this trigger fire as soon as one codec is learned to be
> usable royalty-free? So this is a first-past-the-post contest? (Let's
> say codec "c1" is learned to be usable RF and the next week or month
> or quarter "c2" is learned to be usable RF. What happens?)

I think it was Adam who said "that's a problem I'd love to have".......

> IETF need to do something (e.g., publish an RFC that obsoletes this one)?

When drafting this statement, it became abundantly clear that we
couldn't make a mechanistic trigger. Some human would have to decide
that the trigger conditions had been achieved.

So the IETF needs to do something - at minimum, a declaration by
somebody that the trigger conditions were achieved.

Publishing a new RFC obsoleting -video- would also be appropriate.

>
> (There is some interaction between 1a and 1b. If some process is
> needed to declare "c1" the only MTI, then it's possible that we might
> learn that "c2" can also be used RF before the obsoleting RFC can be
> published.)
>
> 2a. There is some interaction between 1b and 2. Let's say it takes us
> 10 years to learn that "c1" can be used RF. Hurray! But by that time,
> we might have "c3" and "c4" and "c5" to consider. Are we forbidden
> from considering anything but "c1" and "c2" at that time?

There are two variants of "consider c3 and c4 and c5": One is adding
c3/4/5 to the MTI set; the other one is removing c1/2 from the MTI set
and putting c3/4/5 into the MTI set instead.

The tendency for new codecs is that they are more complex than the old
ones. So the savings (in code lines or square millimeters of silicon) of
removing a codec from the MTI set is perhaps not so great.
My personal opinion is that removing things from the MTI set only makes
sense if it makes an IPR difference.

-- 
Surveillance is pervasive. Go Dark.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 07 Dec 2014 18:08:19 +0900

Hello Peter,

I agree with Ron and Harald that the details are difficult if not 
impossible to nail down. I see this as a broad statement of intent, with 
two purposes: 1) encourage better license conditions from those who have 
the power to make that happen, and 2) let the world know most of us 
(maybe even everybody?) would prefer to have only one MTI codec, RF and 
otherwise unencumbered of course.

The rest can only be decided in the future, not now.

Regards,   Martin.

---

From: Roman Shpount <[email-masked]>
Date: Sun, 7 Dec 2014 11:28:45 -0500

On Sat, Dec 6, 2014 at 12:40 AM, Andrew Allen <[email-masked]> wrote:

>
>  As Harald already admitted this entire debate has been about companies
> business interests and not technical merits. There is ABSOLUTELY NO
> TECHNICAL REASON to have 2 MTI video codecs. This has been company business
> interest from the start.
>

This is disingenuous at the very least: There is a great technical reason
to have 2 or more MTI video codecs -- interoperability.  If it weren't for
the IPR related issues, I would still vote for VP8 and H.264 as MTI, since
these are the two wide spread codecs that enable video calls of acceptable
quality.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Sun, 7 Dec 2014 11:40:40 -0500

There were a lot of arguments here about the Nokia IPR declaration
regarding VP8. IANAL, but typically there is a very simple way to determine
the validity of the IPR claim. It comes down to one simple question -- Have
the party claiming IPR violation filed the law suite? If not, their claims
most likely do not justify the court filing fees in their own eyes. Mozilla
and Google have been shipping browsers with VP8 codec support for several
years already and Nokia did not do a single thing to stop this. If Nokia is
serious about their IPR claims, they should take the alleged violators to
court. At least this way there is going to be a definitive decision
regarding the validity of these claims.

_____________
Roman Shpount

---

From: Andrew Allen <[email-masked]>
Date: Mon, 8 Dec 2014 05:15:44 +0000

Roman

We only need to agree on a single video MTI to ensure interoperability between RTCweb compliant entities. H.264 also gives you interoperability with much of the already established legacy video infrastructure base out there (Video over LTE, video conferencing, etc) as well.

Having two MTIs simply increases the complexity, cost and the litigation risk for everyone that actually has to implement both MTIs with little if any additional benefit.

Andrew

From: Roman Shpount [mailto:[email-masked]]
Sent: Sunday, December 07, 2014 11:29 AM
To: Andrew Allen
Cc: Adam Roach; Gaelle Martin-Cocher; Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

On Sat, Dec 6, 2014 at 12:40 AM, Andrew Allen <[email-masked]<mailto:[email-masked]>> wrote:

This is disingenuous at the very least: There is a great technical reason to have 2 or more MTI video codecs -- interoperability.  If it weren't for the IPR related issues, I would still vote for VP8 and H.264 as MTI, since these are the two wide spread codecs that enable video calls of acceptable quality.
_____________
Roman Shpount

---

From: Andrew Allen <[email-masked]>
Date: Mon, 8 Dec 2014 05:16:08 +0000

Roman

I don’t think that proves anything.

Any basic military doctrine on the tactics of ambush is going to state that you don’t go after the lead elements especially if they are the stronger armored elements that are most capable of beating back the attack – no you bide your time and wait until the follow on troops that are far less able to withstand the attack come along and then mount your assault – ripping them to shreads and thus leaving those more powerful lead elements cut off and surrounded with no path to retreat!

Andrew

From: rtcweb [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Sunday, December 07, 2014 11:41 AM
To: [email-masked]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

There were a lot of arguments here about the Nokia IPR declaration regarding VP8. IANAL, but typically there is a very simple way to determine the validity of the IPR claim. It comes down to one simple question -- Have the party claiming IPR violation filed the law suite? If not, their claims most likely do not justify the court filing fees in their own eyes. Mozilla and Google have been shipping browsers with VP8 codec support for several years already and Nokia did not do a single thing to stop this. If Nokia is serious about their IPR claims, they should take the alleged violators to court. At least this way there is going to be a definitive decision regarding the validity of these claims.

_____________
Roman Shpount

---

From: Ron <[email-masked]>
Date: Mon, 8 Dec 2014 19:34:59 +1030

On Mon, Dec 08, 2014 at 05:16:08AM +0000, Andrew Allen wrote:
> > regarding VP8. IANAL, but typically there is a very simple way to
> > determine the validity of the IPR claim. It comes down to one simple
> > question -- Have the party claiming IPR violation filed the law suite?
> > If not, their claims most likely do not justify the court filing fees
> > in their own eyes. Mozilla and Google have been shipping browsers with
> > VP8 codec support for several years already and Nokia did not do a
> > single thing to stop this. If Nokia is serious about their IPR claims,
> > they should take the alleged violators to court. At least this way
> > there is going to be a definitive decision regarding the validity of
> > these claims.
> 
> Any basic military doctrine on the tactics of ambush is going to state
> that you don’t go after the lead elements especially if they are the
> stronger armored elements that are most capable of beating back the
> attack – no you bide your time and wait until the follow on troops
> that are far less able to withstand the attack come along and then
> mount your assault – ripping them to shreads and thus leaving those
> more powerful lead elements cut off and surrounded with no path to
> retreat!

While that's a very interesting analysis of the kind of panicked thought
processes going on among the rearguard participants from blackberry, it's
not clear to me exactly what relevance you think it has here.

Are you saying that Nokia is not only bad at business, bad at keeping
their talented staff, and bad at community relations - but that they
also suck at military strategy too?

Because they launched their attack, and got laughed out of court ...

http://blog.webmproject.org/2013/08/good-news-from-germany.html

Maybe you are suggesting that was just a clever ruse, and rather than
using their actually valid patent, they wasted all that money on lawyers
to simply feint with the weakest one they could find?

In which case I hope for their sake that they've kept their good lawyers
in reserve for when their shareholders come wanting to rip them to shreds!

  If ignorant both of your enemy and yourself,
  you are certain to be in peril.
    -- Sun Tzu

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 08 Dec 2014 17:00:29 +0100

Den 05. des. 2014 21:37, skrev Gaelle Martin-Cocher:
> Harald, 
> 
> Would you mind clarifying if that VP8 WebM CCL agreement is up to date (copyright is 2010-2013)

I believe it is.

> and if it covers all the declarations that are listed in https://tools.ietf.org/html/draft-benham-rtcweb-vp8litigation ?
> 

To the limits of my understanding:

It covers the IPR covered by Google's declarations listed in section 2.1
and 2.2 of that draft.

It also covers the IPR described by the declarations covered by Note 1
of section 2.2 of that draft.

But there are more declarations listed in those sections.
So the answer to your question, read literally, is "no".

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Mon, 8 Dec 2014 16:02:08 +0000

Ron, 

I don't think BlackBerry nor BlackBerry employees will ever make the statements you implied.
Our bottom line in this discussion is a balance between technical sense, QoS, interoperability and cost control.
Hence we have stated that we are OK with codecs that are already supported across various platforms (e.g. H.263, H.264). That solves both costs and interoperability concerns.
It takes far too long to remove a codec from a platform when it is once installed. (e.g. H261)
There is little reasons to create legacy services with VP8 as it is going to be soon obsoleted by VP9. There is even less reasons to mandate VP8 codec across platforms (soon obsolete, too long to remove from a platform, does not have much technical values over H.264).

I share the concerns from many in this list, that we may depend on browser vendors implementations of H.264 and VP8 and that we are not achieving consensus on this most critical category.

I am not against adding codecs to platforms/services/apps nor to specifications. 
It makes sense when it improves the quality of service (e.g. scalable, SEI etc) /compression ratio (e.g. H.265, VP9) or when it addressed a wider ecosystem that is currently not addressed. (e.g. opus).

In the current situation, I don't see VP8 as an answer to any of the above considerations.

Despite that, I have proposed an alternative solution that combined API availability and WebRTC categories. (no that was not discussed in this form before) I believe that proposal was/is the best way to introduce new codecs (VP8/H264 now; e.g. Dalaa VP9 and H265 later)in a reasonable manner and would have avoided upfront "no, we can't do this".

I hope this clarifies that the Type3 declaration from Nokia is far to be the only concern.
Finally, if VP8 is required, would RF help?
Yes, as it would reduce cost and as it is the main claim that proponent(s) intend(s) to deliver on. I see that as a possible advantage of VP8 over H.264 which, in my opinion, offers more flexibilities (profiles, functions etc). 

Gaëlle

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Ron
Sent: Monday, December 08, 2014 4:05 AM
To: [email-masked]
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

On Mon, Dec 08, 2014 at 05:16:08AM +0000, Andrew Allen wrote:
> > If not, their claims most likely do not justify the court filing 
> > fees in their own eyes. Mozilla and Google have been shipping 
> > browsers with
> > single thing to stop this. If Nokia is serious about their IPR 
> > claims, they should take the alleged violators to court. At least 
> > this way there is going to be a definitive decision regarding the 
> > validity of these claims.
> 

While that's a very interesting analysis of the kind of panicked thought processes going on among the rearguard participants from blackberry, it's not clear to me exactly what relevance you think it has here.

Are you saying that Nokia is not only bad at business, bad at keeping their talented staff, and bad at community relations - but that they also suck at military strategy too?

Maybe you are suggesting that was just a clever ruse, and rather than using their actually valid patent, they wasted all that money on lawyers to simply feint with the weakest one they could find?

In which case I hope for their sake that they've kept their good lawyers in reserve for when their shareholders come wanting to rip them to shreds!

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 8 Dec 2014 18:43:59 +0100

2014-12-05 20:55 GMT+01:00 Ted Hardie <[email-masked]>:
> This is fundamentally incorrect.  The IETF writes voluntary standards.  A

Let's imagine I want to build a new open-source browser from scratch
in my spare time. Basically (if I was smart enough) I could conform
with all the W3C specs... Really? can I safely include VP8 and H264
(existing libraries or my own implementation of both) into my
open-source browser and publish the project and its source code?

The "MUST implement VP8 and H264" is a break line in the W3C, meaning
that from now on just big vendors (those who can deal with licensing
stuff) can conform with the specifications. And that is no good at
all.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Dec 2014 09:49:39 -0800

> stuff) can conform with the specifications. And that is no good at

To the extent that this is true, it is true already.  If you want to
create a competitive browser, you need significant resources.  At any
one time, you need to have about this much work in flight, even once
you reach parity: https://status.modern.ie/

However, calling out codecs as being special is ridiculous.  Firefox
manages, therefore this hypothetical new player could do the same
thing.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 8 Dec 2014 18:55:19 +0100

> manages, therefore this hypothetical new player could do the same

I don't think Firefox "manages" H264 at all. When a website runs Flash
in my browser I don't say that "I manage Flash".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Dec 2014 10:17:43 -0800

> in my browser I don't say that "I manage Flash".

If that is your standard, I suggest that you might consider how
anything "manages" to happen at all.

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Mon, 08 Dec 2014 21:34:49 +0100

On 08/12/14 18:43, Iñaki Baz Castillo wrote:
> in my spare time.

You don't need to build one from scratch, but make a custom build of an
existing open source browser (e.g., from firefox, konqueror or
chromium), say for removing some unnecessary 'features' or tailor it for
special environment (e.g., remove/disable tcp to be sure it's on tls
always). This kind of 'forking' is legit, anyone can do it without
breaking exiting license and such variants already exist (ed).

Cheers,
Daniel
>  Basically (if I was smart enough) I could conform

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

---

From: John Leslie <[email-masked]>
Date: Fri, 12 Dec 2014 12:34:15 -0500

On Sat, 06 Dec 2014,
Peter Saint-Andre - &yet <[email-masked]> wrote:
>>>>> IMHO we need to either pull out the future-oriented text entirely
>>>>> (which has its own problems) or significantly improve it. I would
>>>>> be happy to propose text for the latter.

   I share Peter's concern: but not knowing what text is proposed, I'm
not ready to respond to specifics.

   Generally, we _cannot_ bind any future WG; and we _must_ avoid making
a WG statement about the validity of any IPR claims...

[Ron@debian responded:]

>>> OK, I'll get to work. :-)

[Adam Roach responded:]
>> around. The less formal (i.e., not really document-ready) version of

============================== Adam's text ==============================
>>> WebRTC devices, and not to WebRTC User Agents."
============================== Adam's text ==============================
>> are far more likely to weaken consensus than they are to strengthen it.

   (I don't know whether this is the text which Hawaii hummed for.)

   Actually, I have less problems with this text than with other versions
I have seen. It lists a specific condition of IPR declarations which is
not subject to on-list arguments (which is acceptable), but goes beyond
that with "such as" (which I find worrysome).

   Obviously, the condition it listed is wildly improbable except for
the "such as" language (which would enable on-list arguments). Further,
the pretense that this document could bind a future WG is ridiculous.

[Peter responded to Adam:]
> that "c2" can also be used RF before the obsoleting RFC can be published.)

   Peter is not being difficult here: no process is specified for the
IETF to "change this normative statement", and it could take many months
to do so.

> will have other alternatives to consider: H.265, VP9, VP10, Daala, and 

   (I'd be amazed if we didn't have at least one of these ready to use
before this document is published as an RFC.)

> considering anything but "c1" and "c2" at that time?

   Peter _is_ being difficult here: obviously nothing we could do would
bind us or any other WG that tightly.

> this issue in the medium term or long term until we have the video 

   IMHO, if we accept this text, we'll effectively bind future
implementations to implement both H.264 and VP8 for many years to come.
YMMV, of course...

> positively harmful, in the long term).

   +1

--
John Leslie <[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 12 Dec 2014 19:23:29 +0100

2014-11-26 18:09 GMT+01:00 Adam Roach <[email-masked]>:
> On 11/26/14 03:15, Daniel-Constantin Mierla wrote:
>>
>> IMO, mandatory codec revisiting has to be done for all webrtc entities.
>> Why not doing it for web browsers when one codec is proved to be royalty
>> free?
>
>
> The rationale here is browser accommodation for very constrained "WebRTC
> compatible" devices, which will most typically be concerned with browser
> interoperation. The example that's been tossed around in this space is the
> "WebRTC doorbell" -- when someone rings the bell, you navigate to its
> interface using WebRTC, and stream an image from a small, embedded camera.
> In these kinds of very-low-cost devices, you're going to likely see hardware
> video encoding (e.g. do a web search for NVS2200), which will likely be one
> codec or another, but not both.
>
> The goal is continued browser support for such devices in perpetuity.

So potential new open source browser vendors will have to deal with
H264 license/patent issues even within the next 6 years just because
the "goal is continued browser support for [old video devices] in
perpetuity". And that goal seems to be more important than making a
W3C/IETF standard 100% free of royalties and patents stuff.

May I know where in the WG chapter is that goal defined please?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ron <[email-masked]>
Date: Sat, 13 Dec 2014 05:13:00 +1030

On Fri, Dec 12, 2014 at 12:34:15PM -0500, John Leslie wrote:
> On Sat, 06 Dec 2014, Peter Saint-Andre - &yet <[email-masked]> wrote:
>

I hope I'll not be mistaken for hacking in to the pedantry game if I say
"that depends on how you define 'ready to use'" :)

In one sense you'd be correct, but "ready for this spec to use" is a bit
more elusive.

 - If H.264 is the 800 pound gorilla in the room, then H.265 has climbed
   to the top of the building with Fay Wray.  It's troublesome in all
   the same ways, but orders of magnitude more intensely.  And its
   licencing appears to have already responded to The Cisco Hack, making
   that a more difficult (or at least much more expensive) "solution"
   for anyone trying that sort of thing in future.

 - Both VP9 and H.265 are significantly more computationally expensive
   than the currently proposed MTI codecs.  It seems doubtful that just
   about any currently available hardware will be able to use them for
   real-time streaming.

 - VP10 and Daala are still WIP.  Despite holding a BoF in 2012, and
   there being continued interest, we don't actually have the WG for
   this established or chartered yet.  (and one of the objections to
   VP8 before "a dumptruck of Nokia IPR" became the excuse du jour
   was "but it's not a standard!!")

 - According to the charter of this group, the milestone for delivering
   this is ...  about 2 weeks away ...

It obviously won't be the first WG milestone where the whooshing noise
was heard by all and enjoyed by some, and I'm not sure what people
expect the time before it's delivered really will be now, but I'm kind
of doubtful we'll form another WG and complete its work before it does.

And other than happy news out of the ISO process for VP8, or something
other than coal in our stockings from the H.264 patent holders, that
really seems to be the only way we're likely to solve this once and
for all now.

I think the interesting question is whether or not we do want to say
something along those lines as part of a forward-looking rationale,
or whether people think it's still just a little too far over the
event horizon at this stage.

  Ron

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 13 Dec 2014 01:09:19 +0100

> before this document is published as an RFC.)

Too late.

-- 
Iñaki Baz Castillo
<[email-masked]>