Re: [rtcweb] On the topic of MTI video codecs

cowwoc <> Fri, 01 November 2013 00:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD4C021E8087 for <>; Thu, 31 Oct 2013 17:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.057
X-Spam-Status: No, score=-5.057 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lQEc3b5zjxg1 for <>; Thu, 31 Oct 2013 17:54:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 166CB21E809D for <>; Thu, 31 Oct 2013 17:54:42 -0700 (PDT)
Received: by with SMTP id n7so2154961qcx.27 for <>; Thu, 31 Oct 2013 17:54:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=T4I0gIJopDcHNEMv5HdRpgFheZqKfQBq7TU/R4/sLOk=; b=UaM9NTbfQzU5TI0FIX0rlQ28oPwYkRn16d0xxVztQUc4STyfjOkeAt/7vOJaQQlXVj MvP2o5vR7J9oRd7L6QBPmv24cJxzdn9mcs8mBs2FZYC4TBWyaLiLbkNddYXZBKtHPj/E t9KY0g1nzGYen/ycS0mcG3ATBGbMjFA5zmD0mn93PRXuphy9Ql4YuOspo+Yctkb9+o7X 3s33NIA2wxzTRkkby7c0nNk38S7iep5K+nQfJray6zQrfugNY8/nlXLHWU+9ywxnNOvM 1ISPPgTTOYyw7oBQkqKnH+N9Yg34q0stUawKVUHOgzpXNM9XG1KNVkqufuCatspor7wH jwQw==
X-Gm-Message-State: ALoCoQnJwhWhR7urUaJvNF25PF1GOsJo+lbtZzS6Z+msAX/ajoeDFjHXz/H3juhr9aLhXdcsfyqY
X-Received: by with SMTP id b10mr625019qan.6.1383267282367; Thu, 31 Oct 2013 17:54:42 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id h9sm15312076qaq.9.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 17:54:41 -0700 (PDT)
Message-ID: <>
Date: Thu, 31 Oct 2013 20:54:37 -0400
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-Mailman-Version: 2.1.12
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: Fri, 01 Nov 2013 00:54:51 -0000

     Everyone seems to be fixated on web browsers. What happens to those 
of us who wish to integrate WebRTC as a library into non-browser 
applications? What about standalone (client) applications? What about 
(auditing) web servers? Are we expected to download the binary module 
once per user? Or does our build machine download it once and deploy it 
to a million users?

     VP8 is far more attractive from a security and deployment point of 


On 31/10/2013 5:08 PM, Daniel-Constantin Mierla wrote:
> On 10/31/13 4:10 PM, Olle E. Johansson wrote:
>> On 31 Oct 2013, at 10:02, Neil Stratford <> wrote:
>>> On 30 Oct 2013, at 17:55, Adam Roach <> wrote:
>>>> As Jonathan mentioned earlier, this morning Cisco announced that it 
>>>> will be open sourcing an H.264 implementation as well as gratis 
>>>> binary modules compiled from that source and hosted by Cisco for 
>>>> download. Mozilla will be modifying Firefox to support H.264 by 
>>>> downloading Cisco's binary module.
>>> It seems like most of the groundwork is being done here for a real 
>>> codec plugin API which would obviate the need for any particular 
>>> codec to be selected as MTI.
>>> Can we encourage this new codec plugin API to be developed in an 
>>> open way as part of the standards process and therefore be supported 
>>> in all browsers? (Enabling for example the addition of VP8 to a 
>>> browser that may not natively ship with it.)
>> I don't agree. The idea was to create a realtime web platform without 
>> the need for any plugins or downloadable modules. We've had that for 
>> ages and it is not a good solution.
>> I am still for a MTI codec or set of codecs so we always can set up 
>> video calls, regardless of implementation and if it's possible to 
>> download by policy or network conditions a specific binary.
> Downloading a binary opens doors for tons of risks, knowing that lot 
> of carriers do caching or interpose themselves (e.g., it happens very 
> commonly for dns to redirect you to some adds page when typing an 
> invalid domain), thus is easy to replace the original source, so a 
> rather complex security mechanism has to be put in place.
> Even the argument that the code can be compiled and signatures 
> compared is not really feasible - simply it cannot be done by mobile 
> devices - they don't have the sdk installed.
> I can't see an impediment for Cisco to grant the main web browsers 
> (e.g., Mozilla, ...) to simply have the codec built in, using the BSD 
> open sourced codec. If the webrtc is going to the masses, then the 
> yearly fee cap will be reached anyhow.
> For the sake of clarification, I am not in a favor of a particular 
> video codec, but the one to be selected has to be embedded directly in 
> all browsers, specially in those open source, for full transparency. 
> Otherwise, better as Neil said, make it a plugin API so there can be 
> many providers - with binary blob download, there has to be an API 
> anyhow, make that the standard.
> Daniel