Subject: RTCWeb proposal

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Dec 2013 08:53:49 -0500

I propose the following as a way out of the current RTCWeb MTI issue.

* The MTI codec is motion JPEG.
* From 2018 on, the MPEG2 codec is also MTI.

The rationale for this is as follows:

* There is no decision process that can arrive at a choice between H.264
and AV8.

Parties that have already purchased access to H.264 are not going to
purchase access for a second codec simply to enable other parties to gain
access to a codec for free. Using AV8 without purchasing access to the
necessary patents would open them up to a major litigation risk and
potential damages awards in the billions of dollars and/or having their
products subject to injunctions without any benefit to themselves.

* The proposed vote is manifestly unfair and subject to legal challenge in
a jurisdiction of the plaintiff's choice.

Taking a vote in the IETF is not going to settle the matter and would only
expose the IETF itself to the risk of litigation. It would not surprise me
if one or more parties applied for a court injunction to prevent a vote.
The eligibility criteria for participating in the vote were only revealed
after the ability to become eligible had passed. Whatever the justification
the ADs and WG chairs might imagine for this approach it is not one that
the courts are likely to be impressed with. With several billion dollars in
potential damages at risk and a certainty of tens of millions of dollars in
legal fees fighting additional IP claims, litigation against the IETF is
certain.

* The WG does not have the right to make decisions for the IETF

The criteria for adopting standards is IETF consensus, not WG consensus.
The proposed mechanism excludes the majority of the IETF membership from
the decision which will inevitably be appealed. So the ultimate decision
body inside the IETF is the IAB.

* The proposed MTI codecs are widely implemented and require minimal or no
additional implementation effort in a Web application.

* The proposed MTI codecs are good enough to permit applications to
interoperate.

* Development of an alternative codec is impractical since any effort would
take much longer than the expiry of the remaining MPEG2 patents and the
resulting specification would be vulnerable to IP claims regardless of the
effort taken to avoid encumbered techniques. There is simply too much
encumbered art. Prior art is only a defense against damages, it does not
protect against the costs of defending a case.

The only codec work which might be of value is to look at the patent pool
and see if a subset of the MPEG2 standard could be defined with a shorter
encumbrance period. I note that one of the longest patent expiries is for a
tagging scheme providing for backward compatibility with MPEG1. But I don't
read patents unless I am being paid to do so and I doubt anyone else does
for fun.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Dec 2013 09:41:55 -0500

On Wed, Dec 4, 2013 at 9:08 AM, Yoav Nir <[email-masked]> wrote:

> I would first ask the potential implementers what they would do if two
> endpoints negotiated down to motion JPEG, which according to Wikipedia,
> means 320x240 at 12 FPS using up over 1 Mbps, which is more than the
> upstream capacity in many places.
>
> Would they show the user this barely-usable video stream, or would they
> show a message that video couldn't be made to work?
>

I am on several fat pipes here and I get those messages all the time on
Skype etc. etc. So I don't see that this would be introducing a completely
new concern.

The endpoints are only going to select motion JPEG if they have no better
shared codec available. So this is only going to occur in a case where the
applications would otherwise be unable to communicate.

The only essential criteria I have for MTI is that it stands a chance of
being implemented universally which in this case means that it has to be
definitively unencumbered. Microsoft is not going to risk a billion dollar
damages award to let Mozilla get the codec of their choice. Nor are they
likely to buy a second license to the necessary IP. Mozilla is not going to
pay for a H.264 license. No decision made in the IETF is going to change
the position on either side.

So making AV8 MTI is not going to increase interoperability, nor is making
H.264 MTI. Whatever the intentions of the inventors, there are numerous
patent holders that might make a claim.

The other option that appears to meet the definitively unencumbered
criteria is H.261.

Yes, the lowest common denominator is going to be markedly less efficient
than the encumbered codecs. That is not an argument for creating a new
process that allows a group of people who don't bear the costs of the
decision to decide a winner.

-- 
Website: http://hallambaker.com/

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 4 Dec 2013 16:45:32 +0000

Why MPEG-2?  MPEG-2 video is MPEG-1 video plus interlace support.  Do we want interlace?  More to the point, do we want to burden our decoders to implement interlace support (which is non-trivial) when no sane encoder would send interlace in a PC or mobile environment, even if the bitstream format would allow for it?
Stephan

From: Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 4 December, 2013 at 05:53
To: IETF Discussion Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: RTCWeb proposal

* There is no decision process that can arrive at a choice between H.264 and AV8.

Parties that have already purchased access to H.264 are not going to purchase access for a second codec simply to enable other parties to gain access to a codec for free. Using AV8 without purchasing access to the necessary patents would open them up to a major litigation risk and potential damages awards in the billions of dollars and/or having their products subject to injunctions without any benefit to themselves.

* The proposed vote is manifestly unfair and subject to legal challenge in a jurisdiction of the plaintiff's choice.

Taking a vote in the IETF is not going to settle the matter and would only expose the IETF itself to the risk of litigation. It would not surprise me if one or more parties applied for a court injunction to prevent a vote. The eligibility criteria for participating in the vote were only revealed after the ability to become eligible had passed. Whatever the justification the ADs and WG chairs might imagine for this approach it is not one that the courts are likely to be impressed with. With several billion dollars in potential damages at risk and a certainty of tens of millions of dollars in legal fees fighting additional IP claims, litigation against the IETF is certain.

The criteria for adopting standards is IETF consensus, not WG consensus. The proposed mechanism excludes the majority of the IETF membership from the decision which will inevitably be appealed. So the ultimate decision body inside the IETF is the IAB.

* The proposed MTI codecs are widely implemented and require minimal or no additional implementation effort in a Web application.

* The proposed MTI codecs are good enough to permit applications to interoperate.

* Development of an alternative codec is impractical since any effort would take much longer than the expiry of the remaining MPEG2 patents and the resulting specification would be vulnerable to IP claims regardless of the effort taken to avoid encumbered techniques. There is simply too much encumbered art. Prior art is only a defense against damages, it does not protect against the costs of defending a case.

The only codec work which might be of value is to look at the patent pool and see if a subset of the MPEG2 standard could be defined with a shorter encumbrance period. I note that one of the longest patent expiries is for a tagging scheme providing for backward compatibility with MPEG1. But I don't read patents unless I am being paid to do so and I doubt anyone else does for fun.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Dec 2013 12:11:45 -0500

On Wed, Dec 4, 2013 at 11:45 AM, Stephan Wenger <[email-masked]> wrote:

>  Why MPEG-2?  MPEG-2 video is MPEG-1 video plus interlace support.  Do we
> want interlace?  More to the point, do we want to burden our decoders to
> implement interlace support (which is non-trivial) when no sane encoder
> would send interlace in a PC or mobile environment, even if the bitstream
> format would allow for it?
> Stephan
>

As I said in a previous message, the actual choice of encoding does not
really matter so much as the criteria.

The group is unable to come to agreement between the two choices. This is
because both choices are de facto encumbered even if there may be dispute
about the validity of the claims.

What I thought was a settled principle in the IETF is that the IETF does
not choose a encumbered technology as MTI if there is a viable unencumbered
alternative.

H.264 is obviously encumbered so that is excluded from consideration.
Anyone with deep pockets who attempts to use AV8 is likely to be sued and
suffer substantial expense regardless of the merits of the case. Ergo AV8
is effectively encumbered.

MPEG-1 was published in near complete form in 1991 (according to Wikipedia)
and is thus likely to be unencumbered and would meet the criteria.

If there is sufficient code support for MPEG-1 then it would seem to make
an excellent choice since it is definitively unencumbered.

My objective in making the proposal was to try to get the area ADs and WG
chairs to withdraw the silly proposal to have a vote so the matter can be
referred back to their committee and an appropriate choice made from the
eligible candidates. The same point could have been made by suggesting use
of animated GIF.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 05 Dec 2013 13:12:25 +0100

On 12/04/2013 06:11 PM, Phillip Hallam-Baker wrote:
> On Wed, Dec 4, 2013 at 11:45 AM, Stephan Wenger <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Why MPEG-2?  MPEG-2 video is MPEG-1 video plus interlace support.
>      Do we want interlace?  More to the point, do we want to burden
>     our decoders to implement interlace support (which is non-trivial)
>     when no sane encoder would send interlace in a PC or mobile
>     environment, even if the bitstream format would allow for it?
>     Stephan
>
>
> As I said in a previous message, the actual choice of encoding does 
> not really matter so much as the criteria.
>
> The group is unable to come to agreement between the two choices. This 
> is because both choices are de facto encumbered even if there may be 
> dispute about the validity of the claims.
>
> What I thought was a settled principle in the IETF is that the IETF 
> does not choose a encumbered technology as MTI if there is a viable 
> unencumbered alternative.
>
> Anyone with deep pockets who attempts to use AV8 is likely to be sued 
> and suffer substantial expense regardless of the merits of the case. 
> Ergo AV8 is effectively encumbered.

Phil, if you can't even get the name of VP8 right, I think you are 
demonstrating a basic lack of knowledge about the area.

You are also proposing new solutions that seem to be minor variants of 
solutions already listed on the list of possible solutions ( 
http://tools.ietf.org/wg/rtcweb/trac/wiki) and doing so in a forum that 
is not the working group that has to come to consensus on any proposal.

One of the things this group does NOT suffer from is a lack of 
uninformed punditry.

Tell me again why you think you are contributing positively to the 
discussion?

              Harald

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 5 Dec 2013 16:44:21 +0000

To be fair, Philip did contribute a novel idea: decide *now* to a) require MJPEG as MTI starting immediately, and further b) require a second MTI codec (MPEG-2) later (2018, based on a undisclosed formula for patent safety, I suspect).
I'm personally not sure that binding ourselves on a future direction 4 years into said future is a particularly good idea.
Stephan

From: Harald Alvestrand <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 5 December, 2013 at 04:12
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: RTCWeb proposal

On 12/04/2013 06:11 PM, Phillip Hallam-Baker wrote:
On Wed, Dec 4, 2013 at 11:45 AM, Stephan Wenger <[email-masked]<mailto:[email-masked]>> wrote:
Why MPEG-2?  MPEG-2 video is MPEG-1 video plus interlace support.  Do we want interlace?  More to the point, do we want to burden our decoders to implement interlace support (which is non-trivial) when no sane encoder would send interlace in a PC or mobile environment, even if the bitstream format would allow for it?
Stephan

As I said in a previous message, the actual choice of encoding does not really matter so much as the criteria.

The group is unable to come to agreement between the two choices. This is because both choices are de facto encumbered even if there may be dispute about the validity of the claims.

What I thought was a settled principle in the IETF is that the IETF does not choose a encumbered technology as MTI if there is a viable unencumbered alternative.

H.264 is obviously encumbered so that is excluded from consideration. Anyone with deep pockets who attempts to use AV8 is likely to be sued and suffer substantial expense regardless of the merits of the case. Ergo AV8 is effectively encumbered.

Phil, if you can't even get the name of VP8 right, I think you are demonstrating a basic lack of knowledge about the area.

You are also proposing new solutions that seem to be minor variants of solutions already listed on the list of possible solutions ( http://tools.ietf.org/wg/rtcweb/trac/wiki) and doing so in a forum that is not the working group that has to come to consensus on any proposal.

One of the things this group does NOT suffer from is a lack of uninformed punditry.

Tell me again why you think you are contributing positively to the discussion?

             Harald

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Dec 2013 14:28:37 -0500

On Thu, Dec 5, 2013 at 7:12 AM, Harald Alvestrand <[email-masked]>wrote:

>>  Why MPEG-2?  MPEG-2 video is MPEG-1 video plus interlace support.  Do
>> we want interlace?  More to the point, do we want to burden our decoders to

Does it really matter what we call the codec if the issue that is blocking
adoption is a well founded concern that it may be subject to a purported
encumbrance?

I think the principle I was advancing was straightforward enough: Any
decision to decide this matter by a vote is a matter for the whole IETF and
not just the working group or the area ADs. And even if the IETF was to
arrive at a consensus the decision would have no effect on
interoperability.

As I told the ADs, I will stop discussing this matter on ietf.org as soon
as they confirm that they have abandoned their silly plan for a vote.

I don't pretend to be an expert in this area. But I do expect the WG chairs
and ADs to understand the procedural and business reasons that make their
proposal completely unworkable for this particular issue.

Pointing out that there is existing art that meets the minimal criteria for
interoperability seems completely reasonable to me. It is certainly
relevant to debunking the claim that there are only two acceptable
alternatives.

There are a lot of technical issues that could be put to a vote and are in
fact regularly decided that way, deciding to use JSON vs XML for example
could be decided by vote. Deciding an issue that will cause one set of
parties or another to spend several million dollars is not an issue that
can be sensibly put to a vote in any forum unless the parties who are
voting are the ones that will bear the cost.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 6 Dec 2013 14:45:30 +0000

On Dec 5, 2013, at 12:28 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> As I told the ADs, I will stop discussing this matter on ietf.org as soon as they confirm that they have abandoned their silly plan for a vote.
> 

Phil, as you insist on calling the chairs silly, I would strongly encourage you to fist actually understand what we did do and what we did not do before that. If you would like to phone me, I'd be happy to discuss with you. 

But in the mean time, I agree ietf@ietf is a fine place to discuss IETF process but if you wish to have any input to the actually choice of codecs in rtcweb, the advice I would give you is that the most appropriate list to discuss that at this point in time would be rtcweb@ietf.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 06 Dec 2013 16:11:02 +0100

On 12/05/2013 08:28 PM, Phillip Hallam-Baker wrote:
>
>
>
> On Thu, Dec 5, 2013 at 7:12 AM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>         Why MPEG-2?  MPEG-2 video is MPEG-1 video plus interlace
>>         support.  Do we want interlace?  More to the point, do we
>>         want to burden our decoders to implement interlace support
>>         (which is non-trivial) when no sane encoder would send
>>         interlace in a PC or mobile environment, even if the
>>         bitstream format would allow for it?
>>         Stephan
>>
>>
>>     As I said in a previous message, the actual choice of encoding
>>     does not really matter so much as the criteria.
>>
>>     The group is unable to come to agreement between the two choices.
>>     This is because both choices are de facto encumbered even if
>>     there may be dispute about the validity of the claims.
>>
>>     What I thought was a settled principle in the IETF is that the
>>     IETF does not choose a encumbered technology as MTI if there is a
>>     viable unencumbered alternative.
>>
>>     H.264 is obviously encumbered so that is excluded from
>>     consideration. Anyone with deep pockets who attempts to use AV8
>>     is likely to be sued and suffer substantial expense regardless of
>>     the merits of the case. Ergo AV8 is effectively encumbered.
>
>     You are also proposing new solutions that seem to be minor
>     variants of solutions already listed on the list of possible
>     solutions ( http://tools.ietf.org/wg/rtcweb/trac/wiki) and doing
>     so in a forum that is not the working group that has to come to
>     consensus on any proposal.
>
>
> Does it really matter what we call the codec if the issue that is 
> blocking adoption is a well founded concern that it may be subject to 
> a purported encumbrance?
>
> decision to decide this matter by a vote is a matter for the whole 
> IETF and not just the working group or the area ADs. And even if the 
> IETF was to arrive at a consensus the decision would have no effect on 
> interoperability.

Phil, if you had left it at that, i would not have reacted the way I did.

The specific reaction was to:

a) You suggesting that a codec was encumbered without bothering with 
enough fact-checking to get the name of the codec right.

b) You proposing specifically that MJPEG is a better solution to propose 
than the multiple maybe-royalty-free ones that have already been 
proposed in the WG (H.261, H.263 and Theora), without any justification 
for why you think this choice is either technically superior to or more 
IPR-proof than the others that have been proposed.

It was these two statements that caused me to use the term "uninformed 
punditry" - which Dave, probably correctly, thought was not part of the 
terminology we should use in IETF discussion.

I listen carefully when you hold forth in a pundit-like fashion on 
topics where I know you have worked for a long time, and where I know 
you know the terminology and technology better than I do.

This was not one of those times.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Dec 2013 14:52:35 -0500

> enough fact-checking to get the name of the codec right.

I did check, I just got the name confused with something else in a couple
of posts.

What I said was not that VP8 was legitimately encumbered but that the
probability of a lawsuit is independent of the merits and is at or
approaching 1.

In one recent case I discovered prior art from the days when IBM still made
computers with vacuum tubes but the case is continuing. The situation is
terribly depressing. I would very much like to use EC encryption and I am
pretty certain that there are techniques that are unencumbered. But I can't
sell them to a customer because that would expose the customer to a serious
litigation risk.

And even if there was no litigation risk relating to VP8 the parties that
would have to come to agreement are currently locked in a mutual patent
litigation meltdown. Which means that the IETF would have to take sides to
come to a decision.

> than the multiple maybe-royalty-free ones that have already been proposed
> in the WG (H.261, H.263 and Theora), without any justification for why you
> think this choice is either technically superior to or more IPR-proof than
> the others that have been proposed.
>

I did not say that they were technically superior. In fact I said that
technical superiority was not essential. It probably isn't IPR proof
either. But given that every party that has a Web browser has already
implemented JPEG, the risk of additional IPR exposure for motion JPEG would
be minimal.

One of the ways to get people to agreement is to first exclude all the
proposals that are non-starters and then put an unpleasant option on the
table that does meet the necessary criteria. The participants can then
accept the unpleasant choice or they can come up with a less unpleasant
one. My original proposal was going to be animated GIF.

As far as the rest of the IETF is concerned, forcing RTCWEB to live with no
MTI codec or motion jpeg seems a lot less unpleasant than have a WG decide
to unilaterally set a precedent for future IPR issues.

I certainly can't see the issue being decidable by a vote in IETF, at best
that is going to be ignored, at worst it causes the IETF to lose it's
neutrality as the industry patent battles become increasingly nasty.

If there is going to be a vote it has to be taken by the parties that would
be bearing liability. My opinion on the encumbrance status of VP8 is
irrelevant and so is the opinion of the participants in RTCWEB. The only
opinions that would matter would be those of counsel for Microsoft, Apple,
Mozilla, HTC, etc. Perhaps at some point we will have established a
framework for settling IP disputes in the industry in a fashion that allows
those people to sit at the same table together. But that is not where I
think we are at today.