Re: [rtcweb] Proposal for H.263 baseline codec

<Markus.Isomaki@nokia.com> Thu, 29 March 2012 12:31 UTC

Return-Path: <Markus.Isomaki@nokia.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417EA21F8ABD for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 05:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KQ+xeZUlkOo for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 05:31:00 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E3E8B21F8ABA for <rtcweb@ietf.org>; Thu, 29 Mar 2012 05:30:59 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2TCUWR2026470; Thu, 29 Mar 2012 15:30:54 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 15:30:51 +0300
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.245]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Thu, 29 Mar 2012 14:30:51 +0200
From: Markus.Isomaki@nokia.com
To: dean.willis@softarmor.com, rtcweb@ietf.org
Thread-Topic: [rtcweb] Proposal for H.263 baseline codec
Thread-Index: AQHNDaWpd/o/91jlJkKpwWEOtM2OV5aBMYzQ
Date: Thu, 29 Mar 2012 12:30:50 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7621AFB9A@008-AM1MPN1-042.mgdnok.nokia.com>
References: <CAOHm=4snSTbVKpGvuktC+wMYKBu1hvBkwippAQKbA9H1KdFo6w@mail.gmail.com>
In-Reply-To: <CAOHm=4snSTbVKpGvuktC+wMYKBu1hvBkwippAQKbA9H1KdFo6w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [93.158.44.126]
Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7621AFB9A008AM1MPN1042mgdn_"
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Mar 2012 12:30:51.0743 (UTC) FILETIME=[C743EEF0:01CD0DA7]
X-Nokia-AV: Clean
Subject: Re: [rtcweb] Proposal for H.263 baseline codec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Mar 2012 12:31:02 -0000

Hi,

I support Dean's proposal to make H.263 as the mandatory-to-implement codec. I'm not expert on profiles, but someone mentioned H.263 profile 0 as something suitable for our needs (smallest IPR risk).

I also believe that even making H.261 as the mandatory-to-implement would be better than going for the forced pseudo-random selection between H.264 or VP8.

Markus


From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Dean Willis
Sent: 29 March, 2012 15:16
To: rtcweb@ietf.org
Subject: [rtcweb] Proposal for H.263 baseline codec

In today's meeting I made a plea for a mandatory baseline codec that is approachable to the small developer without the cost and IPR risks of either H.264 or VP8.

I believe that some sort of baseline codec is required to jump start the protocol. It's OK if this isn't the best possible codec. Market forces will assure that commercial implementations converge on a higher quality when the market requires it.

While I proposed today that H.261 could serve as a baseline, we know this would be "extremely basic". In other words, it might not pass the "good enough to use" test required for a successful launch.

Stephane and several others suggested H.263 as an alternative during the after-meeting chat. While it is not as IPR-safe a choice as H.261, it is relatively mature and the known challenges have generally failed. Implementations are reasonably available and should make it possible for smaller implementers, students, and hobbyists to play ball. It's not all that network efficient and is outright piggy at higher resolutions, but it probably works "well enough to use."

So I propose we set H.263 as the baseline ( I expect a bit of profiling may be necessary to further qualify the baseline) and run with that for now. If the situation changes, we can always replace it before final publication.
--
Dean