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

<Markus.Isomaki@nokia.com> Mon, 25 November 2013 20:23 UTC

Return-Path: <Markus.Isomaki@nokia.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 2ECF11AE01F for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 12:23:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 PzN_04pGGucf for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 12:23:48 -0800 (PST)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 80C2C1ADFC8 for <rtcweb@ietf.org>; Mon, 25 Nov 2013 12:23:48 -0800 (PST)
Received: from smtp.mgd.nokia.com ([65.54.30.58]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rAPKEm1H001593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 25 Nov 2013 22:14:49 +0200
Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.177]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.03.0158.002; Mon, 25 Nov 2013 20:14:48 +0000
From: Markus.Isomaki@nokia.com
To: stewe@stewe.org, rtcweb@ietf.org
Thread-Topic: H.263 Baseline vs. H.261? (Was: H.263 licensing situation)
Thread-Index: Ac7qF/g0TVuw5j/ATR+VbdFvC7rEOQ==
Date: Mon, 25 Nov 2013 20:14:47 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A134094@008-AM1MPN1-041.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only;
x-titus-version: 3.5.9.3
x-headerinfofordlp:
x-tituslabs-classificationhash-30: /l7IPXixAhc7RTUH/zCwpm2SDxFGrd9DcC9axWnwtNqyJi1p2pwdLI0jWuwM+IFxp1IDPfCvVpLGJBB81NXr9vDqN7YiYd/swCg2uwHtgwA95XftqYAjyRiKuaA1H/3L4aUm/9GOFQrgFXuVAcDdmHW6SSonaOZQcwVyig8ZIMnJ60c4OsjLVAEcPXckKGkan5p/IMKxuORjEJE2yavQkWTRLIqpcrLd5WyuTHSRxOqDr15ZFbdL8eMltvSxkQ4+
x-originating-ip: [10.163.30.186]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: [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:23:51 -0000

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