Subject: [rtcweb] Proposal for H.263 baseline codec

From: Dean Willis <[email-masked]>
Date: Thu, 29 Mar 2012 14:15:35 +0200

In today's meeting I made a plea for a mandatory baseline codec that is
approachable to the small developer without the cost and IPR risks of
either H.264 or VP8.

I believe that some sort of baseline codec is required to jump start the
protocol. It's OK if this isn't the best possible codec. Market forces will
assure that commercial implementations converge on a higher quality when
the market requires it.

While I proposed today that H.261 could serve as a baseline, we know this
would be "extremely basic". In other words, it might not pass the "good
enough to use" test required for a successful launch.

Stephane and several others suggested H.263 as an alternative during the
after-meeting chat. While it is not as IPR-safe a choice as H.261, it is
relatively mature and the known challenges have generally failed.
Implementations are reasonably available and should make it possible for
smaller implementers, students, and hobbyists to play ball. It's not all
that network efficient and is outright piggy at higher resolutions, but it
probably works "well enough to use."

So I propose we set H.263 as the baseline ( I expect a bit of profiling may
be necessary to further qualify the baseline) and run with that for now. If
the situation changes, we can always replace it before final publication.
--
Dean

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 29 Mar 2012 14:29:28 +0200

+1

Lorenzo

Il giorno Thu, 29 Mar 2012 14:15:35 +0200
Dean Willis <[email-masked]> ha scritto:

> In today's meeting I made a plea for a mandatory baseline codec that
> is approachable to the small developer without the cost and IPR risks
> of either H.264 or VP8.
> 
> I believe that some sort of baseline codec is required to jump start
> the protocol. It's OK if this isn't the best possible codec. Market
> forces will assure that commercial implementations converge on a
> higher quality when the market requires it.
> 
> While I proposed today that H.261 could serve as a baseline, we know
> this would be "extremely basic". In other words, it might not pass
> the "good enough to use" test required for a successful launch.
> 
> Stephane and several others suggested H.263 as an alternative during
> the after-meeting chat. While it is not as IPR-safe a choice as
> H.261, it is relatively mature and the known challenges have
> generally failed. Implementations are reasonably available and should
> make it possible for smaller implementers, students, and hobbyists to
> play ball. It's not all that network efficient and is outright piggy
> at higher resolutions, but it probably works "well enough to use."
> 
> So I propose we set H.263 as the baseline ( I expect a bit of
> profiling may be necessary to further qualify the baseline) and run
> with that for now. If the situation changes, we can always replace it
> before final publication. --
> Dean

-- 
Lorenzo Miniero, COB

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

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 12:30:50 +0000

Hi,

I support Dean's proposal to make H.263 as the mandatory-to-implement codec. I'm not expert on profiles, but someone mentioned H.263 profile 0 as something suitable for our needs (smallest IPR risk).

I also believe that even making H.261 as the mandatory-to-implement would be better than going for the forced pseudo-random selection between H.264 or VP8.

Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Dean Willis
Sent: 29 March, 2012 15:16
To: [email-masked]
Subject: [rtcweb] Proposal for H.263 baseline codec

In today's meeting I made a plea for a mandatory baseline codec that is approachable to the small developer without the cost and IPR risks of either H.264 or VP8.

I believe that some sort of baseline codec is required to jump start the protocol. It's OK if this isn't the best possible codec. Market forces will assure that commercial implementations converge on a higher quality when the market requires it.

While I proposed today that H.261 could serve as a baseline, we know this would be "extremely basic". In other words, it might not pass the "good enough to use" test required for a successful launch.

Stephane and several others suggested H.263 as an alternative during the after-meeting chat. While it is not as IPR-safe a choice as H.261, it is relatively mature and the known challenges have generally failed. Implementations are reasonably available and should make it possible for smaller implementers, students, and hobbyists to play ball. It's not all that network efficient and is outright piggy at higher resolutions, but it probably works "well enough to use."

So I propose we set H.263 as the baseline ( I expect a bit of profiling may be necessary to further qualify the baseline) and run with that for now. If the situation changes, we can always replace it before final publication.
--
Dean

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 29 Mar 2012 14:47:59 +0200

+1

On Mar 29, 2012, at 14:29, "Lorenzo Miniero" <[email-masked]> wrote:

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

---

From: Piers O'Hanlon <[email-masked]>
Date: Thu, 29 Mar 2012 14:48:35 +0200

On 29 Mar 2012, at 14:30, <[email-masked]> wrote:

> Hi,
>  
> I support Dean’s proposal to make H.263 as the mandatory-to-implement codec. I’m not expert on profiles, but someone mentioned H.263 profile 0 as something suitable for our needs (smallest IPR risk).
>  
One of the key limitations with H.261 is it's small range of available supported resolutions (QCIF, Max:CIF(352x288)) - so if there is a low IPR risk for an H.263(+?) configuration then it would be preferable. 

The whole issue of which Profile and levels one might support for these codecs is another issue as I think they lead to differing IPR dependencies.

Piers.

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 29 Mar 2012 09:19:31 -0400

On 03/29/2012 08:15 AM, Dean Willis wrote:
> this would be "extremely basic". In other words, it might not pass the
> "good enough to use" test required for a successful launch.
>
> the after-meeting chat. While it is not as IPR-safe a choice as H.261,
> it is relatively mature and the known challenges have generally
> failed. Implementations are reasonably available and should make it
> possible for smaller implementers, students, and hobbyists to play
> ball. It's not all that network efficient and is outright piggy at
> higher resolutions, but it probably works "well enough to use."
>
Claiming that VP8 is riskier than a known IPR-enforced format is a
specious claim considering its already widely implemented usage across
the web on numerous sites and in hardware.  Additionally, a patent pool
was called for over a year ago, and nothing has been made public about this.

No technology can be completely free from the specter of patent trolls
and spurious software patents, so these arguments that VP8 is not
suitable based on this could be applied to anyone.  The fact of the
matter is that the only known patents on VP8 are owned now by Google and
they have been licensed in a way compatible with all appropriate uses of
the technology, including WebRTC.

While I appreciate the sentiment of this suggestion, I am of the opinion
that choosing a known-restricted format over VP8 will be
counter-productive to the adoption of the WebRTC standard and will, in
fact, restrict possible implementations.

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 29 Mar 2012 13:47:54 +0000

Hi,

A few random data points about H.263.

I write this as someone who sat through the meetings which defined H.263+ and H.263++ and with a vague recollection who proposed what.  I'm leaning myself fairly far out of the window here, so let me emphasize that this is not a formal risk analysis, no legal advice, and that it is instead today's snapshot of what I would think is a sensible position for a risk-averse implementer, which may be very different tomorrow.  As usual, you and your legal folks will have to perform your own risk analysis.  For those unfamiliar with the ITU tool set, the ITU patent database can be found here http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS and can be searched for Recommendation H.263.  The content of this database probably needs to be interpreted in the context of the then valid policies, disclosure and declaration requirements, and practices in the ITU, which were IMO and at the time, considerably less strict than the disclosure requirements observed in the IETF today.

H.263 is not "profiled" in the sense the MPEG video codecs are.  There is an Annex X defining profiles and levels, but this Annex was added several years after the first revision of H.263, almost as an afterthought.  The profiles defined therein are not necessarily the mode combinations that are (or have been) in practical use.

Compared to modern video codecs, H.263 is trivial to implement.  I would suggest that the availability or non-availability of certain modes and options in today's software base (be it open source or proprietary) should not the key driver in profiling H.263.  Compared to the implementation effort of the rest of the rtcweb stack, an H.263 implementation is cheap to have.

The reference implementation for H.263+ was maintained by the University of British Columbia and later by UB Video, and access to it for the public was removed around 1999.  UB Video also sold a close-to-real-time (on the machines of the time) H.263+ encoder and decoder library.  On today's machines, I would expect this software, after some optimization reflecting "modern" instructions sets, to handle 720p encoding and decoding on most machines.  UB Video was acquired by Scientific Atlanta, which in turn was acquired by Cisco.  AFAIK, today, Cisco owns the rights to all this software.  I could likely establish contacts to those people inside Cisco who may still have a copy of the software, if I were approached by Cisco folks not so fortunate.

Personally, I would not expect an IPR risk to go up significantly (compared to H.263 baseline 1996) when using the PLUSPTYPE header, which would (among other things) allow for flexible picture sizes.  The same is IMHO true for some of the optional modes of H.263+ that are "bug fixes" to the 1996 version of the spec, for example Annexes I (advanced intra), J (deblocking filter), K (slices), and S (VLC bug fix) , as well as 1996 Annex D (unrestricted motion).  Annex I helps for Intra pictures, J is good for subjective quality and not such a computational complexity bear as Annex F (overlapped block motion compensation), you want slices for MTU size matching if your picture size goes beyond CIF, and S is a bug fix.

The majority of the above coding tools do not require tricky encoder mode decision steps; the are simply alternate or additional syntax for baseline tools and functionalities.

Regards,
Stephan

From: Piers O'Hanlon <[email-masked]<mailto:[email-masked]>>
Date: Thu, 29 Mar 2012 14:48:35 +0200
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Proposal for H.263 baseline codec

On 29 Mar 2012, at 14:30, <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Piers.

Markus

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Dean Willis
Sent: 29 March, 2012 15:16
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] Proposal for H.263 baseline codec

So I propose we set H.263 as the baseline ( I expect a bit of profiling may be necessary to further qualify the baseline) and run with that for now. If the situation changes, we can always replace it before final publication.
--
Dean
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

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

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 29 Mar 2012 14:20:10 +0000

Please see inline.
Stephan

On 3.29.2012 15:19 , "Basil Mohamed Gohar"
<[email-masked]> wrote:

>>[Š]

These things take time.  The formation of the MPEG-2 patent pool took 4+
years, the formation of the H.264 pool almost as long.  VP8 may be a
particularly hard-to-deal-with technology, because it is not a formal
standard, which may provide rightholders options to enforce their patents
in ways not available if they would have been involved in a standards
setting process (see below), which can make the negotiation of the pool
more complex (can't re-use previous pool agreements as templates, may have
to check for antitrust compliance, and so on).

The most commonly cited timeline for a widely in use technology to be
"save" from a patent viewpoint, based on equitable defenses such as laches
(in the US) is six years.  In some countries of significant size, this
time is longer, and in others, equitable defenses do not exist.  (Very
briefly, and perhaps incorrectly put, those equitable defenses allow a
defendant to argue successfully that a patent cannot be enforced as the
right holder knew that the patent claim was likely being infringed, and
did not enforce the patent.).

>the technology, including WebRTC.

The second part of your sentence may or may not be true, depending on your
relationship with google, your willingness to use the webm implementation
in unchanged form, and other factors.  Please see the webm license
conditions, which AFAIK can be found here:
http://www.webmproject.org/license/additional/

In addition, as I pointed out in the meeting, the use of a video codec
created by a body such as MPEG or ITU-T SG16 has the advantage of that the
patents of all participating players are available at least under
Reasonable and Non Discriminatory (RAND) terms.  This may sound like a Bad
Thing if you operate under a business model that prevents you to pay
anything for patent licenses, but it is surely a Good Thing if you are
willing to dish out a moderate amount of money for a license.  RAND
recently has gotten teeth, not so much in terms of the monetary
compensation aspect, but in terms of difficulty (if not unavailability) to
obtain injunctive relive, among others.  H.26x and the MPEG standards
benefit from RAND commitments, VP8, AFAIK, does not.

Stephan

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 29 Mar 2012 10:24:55 -0400

Correct.  I think you are referring to this part, explicitly:
> If you or your agent or exclusive licensee institute or order or agree
> to the institution of patent litigation against any entity (including
> a cross-claim or counterclaim in a lawsuit) alleging that this
> implementation of VP8 or any code incorporated within this
> implementation of VP8 constitutes direct or contributory patent
> infringement, or inducement of patent infringement, then any patent
> rights granted to you under this License for this implementation of
> VP8 shall terminate as of the date such litigation is filed.
Perhaps I assumed that that is a very reasonable part of the license. 
That is, if you are suing someone alleging a patent infringement within
VP8, you are no longer granted the license to use VP8's patented
technologies that Google owns.

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 29 Mar 2012 14:53:03 +0000

>technologies that Google owns.

Yes, that's one issue.  Call it personal preference for different type of
reciprocity conditions :-)  (I could rant about it for hours, but let's
continue to pretend that this is mostly a technical mailing list)

The other issue, though (the fact that the license grant extends only to
the VP8 implementation as provided by google, and does not extent to
derivative works such as hardware implementations) should be moderately
alarming even for an open source person.  With respect to this clause, I
will note that I criticized the licensing conditions in private and in
public (IETF mike) several times, months ago, and nothing happened.
Suggests to me one of three things: (1) google is a large company and
decisions take time, or (2) google's legal is currently occupied with
other stuff, or (3) that the choice of language is intentional, and
intended to prevent forks.  Take your pick.
Stephan

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 29 Mar 2012 10:57:21 -0400

> intended to prevent forks.  Take your pick.
Stephan,

If the license wording is meant to limit the patent grant only to
software implementations, then I will raise this issue myself, because
that's a glaring hole and huge setback to the adoption of the format. 
If I find anything out about this, I'll report back here.  The fact that
there are already hardware implementations, though, seems to imply that
in reality, this is not the case.  Google has been open to changing the
licensing situation of VP8 in the past when issues like this were
brought up.

I do not, however, want this to be a point of FUD.  I would welcome
anyone from Google on this list authorized to speak about this to
clarify this ASAP.  A public statement like that should allow us to
discount this worry.

-- 
Libre Video
http://librevideo.org

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 29 Mar 2012 11:15:03 -0400

> clarify this ASAP.  A public statement like that should allow us to
A quicker follow-up than a requested, and by someone from outside of Google.

The first license you linked to appears to cover the libvpx
implementation itself.  It's solely a software implementation, obviously.

The VP8 bitstream is licensed separately, here:

http://www.webmproject.org/license/bitstream/

And that appears to make no distinction between software or hardware. 
It relates to the VP8 format (a.k.a., the bitstream) itself.  If I'm
wrong, hopefully someone can correct me.

-- 
Libre Video
http://librevideo.org

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 29 Mar 2012 10:12:52 -0700

Very interesting discussion. Out of personal curiosity, I have some
questions inline.

On Thu, Mar 29, 2012 at 7:20 AM, Stephan Wenger <[email-masked]> wrote:
> (in the US) is six years.

Very interesting to know the usually used limit on the number of
years. IIUC that would make Speex, Vorbis and Theora "save" codecs,
since they were released in 2003, 2000, and 2004 respectively?

> willing to dish out a moderate amount of money for a license.

So, what is the situation with H.263 and patent licensing? Is what
Larry wrote in 2003 in this email still valid?
http://lists.mpegif.org/pipermail/mp4-tech/2003-October/002771.html
My Web search hasn't turned up any more up-to-date information on
this, so it seems there are several patents associated that are still
valid for H.263 and there is no patent pool for it, thus requiring
every user of H.263 to come to separate license arrangements with each
patent holder?

Note: These are just questions of clarification - I am not implying
any codec preferences in this email.

Regards,
Silvia.