Re: [rtcweb] JS friendly codec compromise?

[Zach Lym <[e-mail]>]

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.