Re: [rtcweb] H.263 Baseline vs. H.261? (Was: H.263 licensing situation)

Leon Geyser <lgeyser@gmail.com> Mon, 25 November 2013 20:54 UTC

Return-Path: <lgeyser@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EA31ADFF3 for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 12:54:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-2FYsZ7ZnX5 for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 12:54:25 -0800 (PST)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DC6E71ADFE6 for <rtcweb@ietf.org>; Mon, 25 Nov 2013 12:54:24 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id c11so3630394lbj.19 for <rtcweb@ietf.org>; Mon, 25 Nov 2013 12:54:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YghruF8G8xvU33/MOyZQrvhhCP5S5+fYOU5knd1D0ug=; b=PNB6yRRBjJ9A5nzc2l1Q7XWx2wlNcf8yQc3EVl6J25bqoJIAGWBuGQ1BsEeohbpN9D LWVrUo6MGMn7XGsTA67d6rcgFJAztRVFfD8NLLiWW15JWNI1IB/SUXPfap9wUItbMta9 kzoGQgblLjjo/cU9AtgVbU7apLw3kgfgqHuHET65WvoppXkRY3fXcwZP1iA/mJMvuRtX 9Uud4uM1tOqwbjhNJk8QAgnXY/iGMYJERK/zs0SPbCPmSSsBLEpmnJdAbTjUkbrqytpY DkqAKofJEAGxB/hQ/L/beGTtHkJ5lw+IasACAJjqTiHDHDsIYpHRxO6vWYZqfHRiTG1X 9nBw==
MIME-Version: 1.0
X-Received: by 10.152.219.133 with SMTP id po5mr2708060lac.34.1385412864278; Mon, 25 Nov 2013 12:54:24 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Mon, 25 Nov 2013 12:54:24 -0800 (PST)
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A134094@008-AM1MPN1-041.mgdnok.nokia.com>
References: <E44893DD4E290745BB608EB23FDDB7620A134094@008-AM1MPN1-041.mgdnok.nokia.com>
Date: Mon, 25 Nov 2013 22:54:24 +0200
Message-ID: <CAGgHUiReWzC3fkML240azihz91TEHKY2PpR0uwxMynhf=q-AUA@mail.gmail.com>
From: Leon Geyser <lgeyser@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary=001a113429c0a4857d04ec069170
Subject: Re: [rtcweb] H.263 Baseline vs. H.261? (Was: H.263 licensing situation)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Nov 2013 20:54:27 -0000

>>3.) People can live with the IPR risk. (I don't think we can conduct a
comprehensive study within the WG, but people need to >>draw their own
conclusions.)
H.263 sounds risky to me since it is only 17 years old. I would feel more
comfortable with H.261.
Even Theora feels less risky than H.263.


On 25 November 2013 22:14, <Markus.Isomaki@nokia.com>; wrote:

> Hi Stephan, all,
>
> Stephan Wenger wrote:
> >
> > H.263 baseline is insufficient for rtcweb¹s purposes, as it does not
> allow
> > arbitrary picture sizes.  You want to have at least the PLUSPTYPE picture
> > header extension which allows arbitrary picture sizes.  You also probably
> > want a few of the optional modes, especially the bug-fixes (improved VLC)
> > and the deblocking filter.  Patents related to this technologies are not
> > covered under the MPEG-LA MPEG-4 part 2 license.
> >
>
> How would you compare H.263 Baseline to H.261? Or H.263 Baseline with
> PLUSTYPE extension to H.261? Based on the list discussion it seems quite
> clear that none of the main browser vendors is really interested in
> including H.261, even if it was IPR-free. Would H.263 Baseline suck more or
> less? I have gotten an(other) educated opinion that the H.263 Baseline IPR
> risk was "virtually non-existent" already a few years back.
>
> In any case we need to define what "H.263" actually means within the
> alternatives. Does it stand for the H.263 Baseline, or do we want to add
> some of the features listed in Stephan's mail to make it usable?
>
> I'm currently thinking that "MUST implement any two of {VP8, H.264 CBP,
> H.263}" is the only sensible outcome for the WG apart from the "MUST
> implement either one of {VP8, H.264 CBP}, that I assume everyone will
> anyway be compliant with. But that would require:
> 1.) Define what exactly "H.263" is in this context: Baseline or Baseline
> plus a set of extensions
> 2.) People consider it better than H.261, and actually usable for WebRTC
> 3.) People can live with the IPR risk. (I don't think we can conduct a
> comprehensive study within the WG, but people need to draw their own
> conclusions.)
>
> Markus
>
>
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > Behalf Of ext Stephan Wenger
> > Sent: 18 November, 2013 18:36
> > To: rtcweb@ietf.org
> > Subject: [rtcweb] H.263 licensing situation
> >
> > Hi,
> >
> > Here is what I know or suspect regarding H.263 licensing:
> >
> > Know:
> >
> > Leon is correct, there are type 2 patent declarations in the ITU against
> H.263.
> >
> > Maik is also correct, H.263 baseline is a subset of MPEG-4 part 2.
>  MPEG-4
> > part 2 is generally considered royalty bearing and the license has been
> > enforced.  However, very few (no one?) is using strict H.263 baseline,
> and
> > even for an only slightly more advanced use of H.263 (no need to go to
> > H.263+, for example), the MPEG-4 portfolio license would not apply.
> >
> > H.263 has been the predominant codec in the video conferencing industry
> > for close to a decade (ca. 1996 through ca. 2005).  In all this time, I
> have heard
> > of one single instance of patent assertion by a non-troll against
> several of the
> > large video conferencing vendors.  However, since those vendors all used
> a
> > chip produced by the non-troll, they had enough commercial leverage to
> > fend off those assertions without the dispute ever going to trial and,
> so I
> > hear, without paying any premium for the use of
> > the patent.   The patent in question has now expired.
> >
> > H.263 baseline is insufficient for rtcweb¹s purposes, as it does not
> allow
> > arbitrary picture sizes.  You want to have at least the PLUSPTYPE picture
> > header extension which allows arbitrary picture sizes.  You also probably
> > want a few of the optional modes, especially the bug-fixes (improved VLC)
> > and the deblocking filter.  Patents related to this technologies are not
> > covered under the MPEG-LA MPEG-4 part 2 license.
> >
> > Suspect:
> >
> > Since we would most likely not use strict H.263 baseline, the war-chest
> of the
> > MPEG-LA pool cannot be used to enforce a patent against our hypothetical
> > H.263 implementation because it is not MPEG-4 part 2 compliant.  Which,
> in
> > turn, means that the MPEG-4 part 2 rightholders would be on their own in
> > asserting their patents.  Which, in turn, means that there is no
> difference
> > between H.263 and other non-pooled video codecs from an MPEG-LA
> > related risk assessment.
> >
> >
> > There have been patent assertions by trolls allegedly related to video
> > compression in general and H.263 in particular, but those happen all the
> time
> > and there is not much one can do about them.  Once you are a juicy enough
> > target (based on the troll¹s perception of relationship between your
> legal
> > competence versus your size) the troll will find you.
> > Technicalities such as whether the patent is actually infringed or
> related to
> > standards are secondary at best in the eye of a troll.  Their business,
> at least
> > when going against smaller companies, is to settle for a few hundreds of
> > thousands--an amount the alleged infringer can pay without excessive
> hurt--
> > thereby filling their war chest and then go to the next ³customer².  When
> > they meet determined opposition (based on a combination of legal and
> > technical competence), they often move on to greener pastures.
> >
> > As H.263 is fairly widely deployed, and I have not heard about patent
> > assertions except the cases mentioned above, the risk of a successful
> patent
> > assertion is probably manageable for almost everyone with sufficient
> legal
> > resources.  At least in countries that allow equitable defenses (implied
> > license, laches, estoppel).
> >
> > So is it worth evaluating H.263 further?  IMO, probably not.  It¹s
> doubtless
> > technically better than H.261, but the risk is inproportionally higher.
>  And the
> > whole idea of this substandard baseline codec has been to be essentially
> > without risk.
> >
> > Stephan
> >
> >
> > >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>