Re: [rtcweb] Alternative decision process in RTCWeb

David Singer <> Wed, 04 December 2013 01:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5DAC01ADFFD; Tue, 3 Dec 2013 17:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.903
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tZvuX1UMfPHz; Tue, 3 Dec 2013 17:26:16 -0800 (PST)
Received: from ( []) by (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 ([]) by (Oracle Communications Messaging Server 7u4-23.01 ( 64bit (built Aug 10 2011)) with ESMTP id <>; Tue, 03 Dec 2013 17:25:24 -0800 (PST)
X-AuditID: 11807157-b7ff46d000001540-e8-529e84840f99
Received: from ( []) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by (Apple SCV relay) with SMTP id A6.91.05440.4848E925; Tue, 03 Dec 2013 17:25:24 -0800 (PST)
Received: from ( []) by (Oracle Communications Messaging Server 7u4-24.01( 64bit (built Nov 17 2011)) with ESMTPSA id <>; Tue, 03 Dec 2013 17:25:24 -0800 (PST)
From: David Singer <>
In-reply-to: <>
Date: Tue, 03 Dec 2013 17:25:24 -0800
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <> <> <> <> <> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <> <> <> <>
To: Stephan Wenger <>
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: "" <>, Bjoern Hoehrmann <>, Phillip Hallam-Baker <>, IETF Discussion <>
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Dec 2013 01:26:17 -0000

On Dec 2, 2013, at 18:36 , Stephan Wenger <> 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.