Re: [rtcweb] Video codec selection - way forward

Maik Merten <maikmerten@googlemail.com> Thu, 21 November 2013 17:22 UTC

Return-Path: <maikmerten@googlemail.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 997F61AE1FB for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 09:22:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 2znfsgs2tQCw for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 09:22:13 -0800 (PST)
Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2711AE08D for <rtcweb@ietf.org>; Thu, 21 Nov 2013 09:22:13 -0800 (PST)
Received: by mail-ee0-f53.google.com with SMTP id b57so17734eek.40 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 09:22:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gAPihc6b1j/5fxufiHCx41eeGgcTinlqN/x0xLNid0w=; b=YiJDw+JaGxHf1ZmtGqKnBshufzYX87DmcYxPZzlCCAO27pUEtogLfmME3yPKBUw97n Si3YlLgrJsH67w/kDJCeVrlhHJ/gu1jOjkdjXZuyz2f+DPRnoYA9JlimSqJSLcGxcuJH zwP7WXZGi5jkUzRkONK412ewgRAD4qaIqwVI9nlwCyo+vFgIHa+dZ/Y4S6GhOUYn1zjQ hjHPlKpgn68EaWJSpFqMr/XmEL6AU6aTua44aOF5trx6Q2V6vuLHfh/avX+AcCy9Kjjs z5uLK5h0zAFG95AZvmn+AGEepzwGOIqV3k1XRhMX+Wpr9wIcUKrbW/aO8N6pL/CdoX7S G0Mw==
X-Received: by 10.14.94.199 with SMTP id n47mr58377eef.81.1385054526145; Thu, 21 Nov 2013 09:22:06 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id i1sm72040942eeg.0.2013.11.21.09.22.02 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 09:22:03 -0800 (PST)
Message-ID: <528E4139.3050808@googlemail.com>
Date: Thu, 21 Nov 2013 18:22:01 +0100
From: Maik Merten <maikmerten@googlemail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1@gbplmail03.genband.com> <52891EDB.2050607@googlemail.com> <D0698C9F-967F-4797-A9F3-E461B9DAE8EB@apple.com> <528B2ABE.4040701@googlemail.com> <BLU169-W24713EECAF0BE76A85E94B93E60@phx.gbl> <528C79AD.10608@googlemail.com> <BLU169-W19675CF49C4FAF3F889E4793E60@phx.gbl> <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com>
In-Reply-To: <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Video codec selection - way forward
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: Thu, 21 Nov 2013 17:22:15 -0000

Cleary H.263 is preferable from an engineering standpoint (as is, e.g., 
MPEG-1 Part 2): better performance, more deployments. The central 
question is, however, if those can actually be implemented without some 
sort of licensing.

If they can: Aweseome! However, this may not be determinable without a 
review by people who are knowledgeable in the field of IPR, i.e., 
"actual lawyers". I understand that H.263 is not yet old enough to 
automatically be considered "safe" (and neither is MPEG-1 Part 2, 
although it is closer).

Best regards,

Maik

Am 20.11.2013 20:42, schrieb David Singer:
> I think we should think hard about H.263 instead of H.261 as the third fallback.  Why?
>
> http://www.itu.int/rec/T-REC-H.263/
>
>
>
> H.263 was first published in March 1996, so it's 17 years old.  The restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more recent amendments deal with this (and a plethora of other issues), so we’d need to settle on which of those are mandatory (the usual profiling discussion).
>
> There are 34 records in the patent database against H.261, mostly from 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2 (reciprocity), as was one other I checked.
>
> Rather surprisingly, there are only 31 against H.263!  The most recent is 2011, and is also option 2.  Most are 1997-2001.
>
>
> On this quick glance, H.263 appears no worse than H.261. IANAL (as I am sure you have all noticed).
>
>
> H.263 is much more widely supported and mandated.  It has been mandated in the 3GPP specs for years (for lots of services, including videoconf), and is effectively the fallback codec today in the industry, as I understand.  It was ubiquitous in video telephony for years, and I suspect many of those systems still ship it.
>
> So, would “MUST implement at least two of (H.264, VP8, H.263)” work?
>
> (I am asking the question, not even answering on behalf of my company, yet.  Let’s get the issues on the table.)
>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>