Re: [rtcweb] Alternative decision process in RTCWeb

David Singer <singer@apple.com> Wed, 04 December 2013 01:26 UTC

Return-Path: <singer@apple.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 5DAC01ADFFD; Tue, 3 Dec 2013 17:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 tZvuX1UMfPHz; Tue, 3 Dec 2013 17:26:16 -0800 (PST)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id EC9381ADFC8; Tue, 3 Dec 2013 17:26:15 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset="windows-1252"
Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MX900361DACO991@mail-out.apple.com>; Tue, 03 Dec 2013 17:25:24 -0800 (PST)
X-AuditID: 11807157-b7ff46d000001540-e8-529e84840f99
Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id A6.91.05440.4848E925; Tue, 03 Dec 2013 17:25:24 -0800 (PST)
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MX900G7HDACRM50@spicerack.apple.com>; Tue, 03 Dec 2013 17:25:24 -0800 (PST)
From: David Singer <singer@apple.com>
In-reply-to: <CEC277EC.AB897%stewe@stewe.org>
Date: Tue, 03 Dec 2013 17:25:24 -0800
Content-transfer-encoding: quoted-printable
Message-id: <65ECB9F5-49F1-492A-A5DC-A4EE02C37092@apple.com>
References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <D4D5920A-E041-42E8-BB1C-1CB24FBEE3F4@nominum.com> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <CAMm+LwhUB+Ppj8QXNA+=2thi0ZTgymc1G7=XH9jd+agEEAvwHA@mail.gmail.com> <242q99176qj0e4t7as5lu3e7rosd8grn1v@hive.bjoern.hoehrmann.de> <CEC277EC.AB897%stewe@stewe.org>
To: Stephan Wenger <stewe@stewe.org>
X-Mailer: Apple Mail (2.1822)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUi2FCsodvSMi/I4NVvbYtnG+ezWKz9187u wOSxZMlPpgDGKC6blNSczLLUIn27BK6MpdcuMRZ0c1VMX7WFvYGxhaOLkZNDQsBE4sGK08wQ tpjEhXvr2boYuTiEBCYzSfRPvsAI4UxnkrjVP5Gli5GDg1lAT+L+RS2QBl4g81bzfbBmYQEb iS+zv7GA2GwCqhIP5hxjBLE5BXQlDr9fB2azAMXPTV7DDDKTWWA2o8ShUwtYQRLMAtoST95d YIUYaiOx9VY/C8TiyywSp/4cB+sWEVCROHTzBwvEqbISu59/Z57AKDAL4aZZSG6ahWTsAkbm VYwCRak5iZUmeokFBTmpesn5uZsYwUFYGL6D8d8yq0OMAhyMSjy8CZzzgoRYE8uKK3MPMUpw MCuJ8NqUAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzOoQBpQTSE0tSs1NTC1KLYLJMHJxSDYzX r9cIVs/3nddx0NTv5rEtSy6uy2EpN1kp1XlHlLf06r6HZt+nRjivEczs8Tg/Q38t36c69i1p 3dwGGuEHJta/PH17Zeoiq5a0hZ0X5wmnPFepmOlzSFJp86G1rceUdX+fVbR8KKUyWVrgzJ6X HI5Pi/s1lMp6bJb9EKtKa7rDtnwn0+EQualKLMUZiYZazEXFiQArEF3iPgIAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, Phillip Hallam-Baker <hallam@gmail.com>, IETF Discussion <ietf@ietf.org>
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
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, 04 Dec 2013 01:26:17 -0000

On Dec 2, 2013, at 18:36 , Stephan Wenger <stewe@stewe.org> wrote:

> 1. A reasonably well tuned H.261 codec (including pre/post filters etc.)
> will under almost any circumstance produce a better picture than MJPEG.
> The intra coding tools of H.261 have a lot in common with JPEG, and H.261
> offers inter picture prediction on top of that.

That may be true, but everyone has a JPEG implementation, its status is clear, and it does convey pictures.  The RTP carriage is trivial, error resilience is excellent (all I pictures).  Yes, you get low frame rates or small pictures, but it’s a fallback.

Motion JPEG is not as bad a choice as all that.  Anyone could implement it, and we could terminate this endless discussion with a decision that could, in fact, be respected by implementations.

I still doubt whether people would consider it worthwhile spending engineer time and so on, on developing an H.261 solution, whereas JPEG (as a codec) is still in heavy use elsewhere.

Nonetheless, I still think H.263 deserves a more careful look.  I know Stephan is negative, but so far, he’s the only one.  For those who DON’T currently implement H.263, could/would you?


David Singer
Multimedia and Software Standards, Apple Inc.