Re: [rtcweb] JS friendly codec compromise?

Zach Lym <zachlym@indolering.com> Wed, 02 April 2014 01:40 UTC

Return-Path: <indolering@gmail.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 0E9011A005F for <rtcweb@ietfa.amsl.com>; Tue, 1 Apr 2014 18:40:11 -0700 (PDT)
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 qjwEXrIm6WSL for <rtcweb@ietfa.amsl.com>; Tue, 1 Apr 2014 18:40:09 -0700 (PDT)
Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 20EF91A005E for <rtcweb@ietf.org>; Tue, 1 Apr 2014 18:40:09 -0700 (PDT)
Received: by mail-pb0-f47.google.com with SMTP id up15so10723077pbc.20 for <rtcweb@ietf.org>; Tue, 01 Apr 2014 18:40:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=gHwHlWtPI7ESQno5WWWZynKXkbVosbHlTXo+4okSlsk=; b=s81FDmeAIMzScp0RcowLHTl5BW9iqXi1Vdi733vBsYxtsLaDFAdwD1jy7+GtBlNrAd xY/eRAUHuovAW3nGJoc11879/3y3EGeLMlpxnVMsy7CHPv9+vljiITANRZmbBrGqlloB CCXfiHBOFEqnbKwkpt003rFBK77T64stmYCgebcC6pCSi4Mfimi3MpDG2Bjih5X/29aH r56/Ek+j7hxR6i5E6OM5UJEXMUkBzgnW23RIrj7sZINxYhEUEagCpAiFdTjpB+1VD0pw b+ftYqRStTRy3TMVJ20sFNvUFCQ7R2fXhXfppoPoGAISi+FwckkwtXs6m8Vugs0GtvBV THcg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=indolering.com; s=google; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=gHwHlWtPI7ESQno5WWWZynKXkbVosbHlTXo+4okSlsk=; b=VFnn2r4rVXtUo7R6c1L/hlO9+NAoTktMlYXwmlQKue3lxdLuH8Nkr7WwPbORbTD8B4 ij1OyHHT3oFkQWWbzQHJo0grRap48mzKV3EQZI/vE7AgSFmSqYff/q7Opi2HfjX/wVam u8DfMVqNK00HFfu07YI6yubbESZjdKotI0w1I=
X-Received: by 10.69.2.2 with SMTP id bk2mr34442225pbd.75.1396402805496; Tue, 01 Apr 2014 18:40:05 -0700 (PDT)
Received: from mba-4.local (71-212-116-249.tukw.qwest.net. [71.212.116.249]) by mx.google.com with ESMTPSA id st4sm1735811pab.34.2014.04.01.18.40.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 18:40:03 -0700 (PDT)
Sender: Zach Lym <indolering@gmail.com>
Message-ID: <533B6A6E.7070208@indolering.com>
Date: Tue, 01 Apr 2014 18:39:58 -0700
From: Zach Lym <zachlym@indolering.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABWuLVey==ZNYog1iLkWiy3Ec6JkOASDPkjg-7BLLenvxf4q+w@mail.gmail.com> <j2fmj9tvssjfl8qa93q5t7to812vmjhjhh@hive.bjoern.hoehrmann.de> <533B48CF.1030705@indolering.com> <g2jmj9hvgq5ecgbru4fpd74uc9uvm6ssls@hive.bjoern.hoehrmann.de>
In-Reply-To: <g2jmj9hvgq5ecgbru4fpd74uc9uvm6ssls@hive.bjoern.hoehrmann.de>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hsw8K3Q7B2CPBvINm65I60jI22DPOWi9o"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bwmgsZsTHOaukW__HEJ0YcpzhVE
Cc: brendan@mozilla.org
Subject: Re: [rtcweb] JS friendly codec compromise?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: zachlym@indolering.com
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, 02 Apr 2014 01:40:11 -0000

I cannot find the exact analysis you appear to be looking for.  You can 
boot up some AMI instances and check for yourself, if you like.  
Brendan Eich apparently saw a demo of ORBX streaming to an iPhone 4s in 
Safari.

There is some discussion of performance on this thread:
https://brendaneich.com/2013/12/orbx-js-and-related-news/#div-comment-17627

And there is a whitepaper detailing ORBX2 here (although they have 
already moved on to ORBX3):
http://aws.otoy.com/docs/ORBX2_Whitepaper.pdf

However, the larger point Brendan Eich makes, and what I am trying to 
convey here, is that eschewing a fixed bit-stream format in favor of a 
living standard would make such comparisons moot.  Clients could even 
send the JS needed to decode their custom format to each other.  The 
web is based on specifying interfaces, think of this as an interface 
for codecs.

The only reason we are having this argument is because H.264 is etched 
into custom hardware.  The above stats show performance comparable with 
H.264 and they chalk it up to their ability to do everything on the 
GPU/WebGL, which you can't do with H.264 or VP8.  As long as we can 
offload to the GPU efficiently, there is no argument to be had.





On Tue Apr  1 16:40:10 2014, Bjoern Hoehrmann wrote:
> * 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.