Re: [rtcweb] Performance of H.264...

Stephan Wenger <stewe@stewe.org> Wed, 20 November 2013 22:14 UTC

Return-Path: <stewe@stewe.org>
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 07DF31AE084 for <rtcweb@ietfa.amsl.com>; Wed, 20 Nov 2013 14:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 3W9G-q-vGK4g for <rtcweb@ietfa.amsl.com>; Wed, 20 Nov 2013 14:14:22 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id B65131AE01C for <rtcweb@ietf.org>; Wed, 20 Nov 2013 14:14:21 -0800 (PST)
Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB361.namprd07.prod.outlook.com (10.141.75.19) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 20 Nov 2013 22:14:09 +0000
Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.99]) with mapi id 15.00.0820.005; Wed, 20 Nov 2013 22:14:08 +0000
From: Stephan Wenger <stewe@stewe.org>
To: Basil Mohamed Gohar <basilgohar@librevideo.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Performance of H.264...
Thread-Index: AQHO5hk+oT4X9Wzm8UyORPNQmBT585oue4QAgAAE7QCAACk3gIAAARyA//9+kYA=
Date: Wed, 20 Nov 2013 22:14:07 +0000
Message-ID: <CEB29C9F.AA960%stewe@stewe.org>
In-Reply-To: <528D303F.6010302@librevideo.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [160.79.220.22]
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(479174003)(24454002)(189002)(199002)(51704005)(83322001)(36756003)(19580395003)(19580405001)(49866001)(56776001)(54316002)(81686001)(69226001)(56816003)(76176001)(51856001)(47736001)(74876001)(81342001)(83072001)(47976001)(80976001)(46102001)(50986001)(79102001)(77096001)(81816001)(47446002)(76796001)(4396001)(16601075003)(87936001)(76786001)(77982001)(74366001)(80022001)(31966008)(2656002)(74502001)(65816001)(53806001)(87266001)(74662001)(85306002)(63696002)(66066001)(76482001)(74706001)(59766001)(81542001)(54356001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB361; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:160.79.220.22; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0B059A5D084FBF469FDE492D0B01E40C@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] Performance of H.264...
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: Wed, 20 Nov 2013 22:14:24 -0000

Hi,
I believe you can indeed include an H.261 *de*coder without running
unmanageable risk, for pretty much every value of unmanageable.  The
*en*coder is much trickier, as you would have to ensure that your
non-standardized mechanisms are also not covered by enforceable patents.
H.261 *En*coders have never been standardized.
You could in theory implement, without deviation, RM8 (the final H.261
test model), published around the same time as H.261.
Stephan

On 11.20.2013, 16:57 , "Basil Mohamed Gohar" <basilgohar@librevideo.org>;
wrote:

>On 11/20/2013 04:53 PM, Thomas Reisinger wrote:
>> From my opinion we should stick with h.263 even the minimal risk or
>>licences for the implementer. H261 is a no go for me.
>> 
>> Thomas Reisinger
>
>Thomas,
>
>The point of choosing something aside from VP8 and H.264, which are both
>superior to H.263, is to *completely* avoid all raised and known
>licensing concerns in the mandatory part of the spec.
>
>This is where H.261 has any value at all in this discussion, even more
>so than any alleged quality tweaks and performance.  It is because any
>rtcweb implementation can include a standards-compliant H.261 en/decoder
>without worrying at all about patent risks.
>
>If we're willing to accept even a small degree of patent risk, then that
>opens up the door to formats far superior to H.261 and even H.263,
>several of which have already been presented.
>
>-- 
>Libre Video
>http://librevideo.org
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb