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 >
- [rtcweb] H.263 Baseline vs. H.261? (Was: H.263 li… Markus.Isomaki
- Re: [rtcweb] H.263 Baseline vs. H.261? (Was: H.26… Leon Geyser