Re: [rtcweb] JS friendly codec compromise?

Bjoern Hoehrmann <> Tue, 01 April 2014 23:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 269481A0020 for <>; Tue, 1 Apr 2014 16:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.563
X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dLqCkyVMa74l for <>; Tue, 1 Apr 2014 16:40:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 79D631A0011 for <>; Tue, 1 Apr 2014 16:40:17 -0700 (PDT)
Received: from netb ([]) by (mrgmx102) with ESMTPSA (Nemesis) id 0LrqNe-1XBZIt3SZS-013fPL; Wed, 02 Apr 2014 01:40:12 +0200
From: Bjoern Hoehrmann <>
Date: Wed, 02 Apr 2014 01:40:10 +0200
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:5Uso8TG/HB46Ls42GSmbCv5KhkOiApP0lUy7lhyfgcnpdhYbfMH U079vYGSMbe/AgJpHYMJRWVSPRhe420vbI0HzaDry5qg+qetg4JUGgiCeSTujnOVIIH0b9d 0sR1ZpRa/J688f31eUZtwTi4rJZgvAbt7FmScQHSRo1aqto/I4R/OzYZQyB2pD4/fPmkEzc yAiB/ZNaTTPN6pBEOB+3A==
Subject: Re: [rtcweb] JS friendly codec compromise?
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: Tue, 01 Apr 2014 23:40:19 -0000

* Zach Lym wrote:
>> Which aspect of "performance" do you mean here, and could you share some
>> references to support the claim? References to a legal analysis would be
>> helpful aswell.
>ORBX claims performance on par with H.264.  We all know that's probably
>marketing hype, but it's hard to imagine not being able to outperform
>H.261.  Even if the working group chose to hack together a custom codec
>which is worse than H.261, an upgradeable client means we can update the
>spec as performance improvements are made by the browser vendors.

I meant performance characteristics like, say, battery life per second
of decoded video at H.261 resolutions and GPRS bitrates, to throw in a
couple of metrics. Or something like "ORBX needs more CPU but produces
smaller files at the same quality level". Maybe ORBX is cheap to decode
but expensive to encode, while with H.261 both is cheap? Comparisons
along those lines supported by references would be useful.
Björn Höhrmann · ·
Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·