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

Daniel-Constantin Mierla <> Thu, 31 October 2013 21:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5328C21F9E3B for <>; Thu, 31 Oct 2013 14:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7yYbWEi7lP9H for <>; Thu, 31 Oct 2013 14:40:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c00::236]) by (Postfix) with ESMTP id 9090521F9EF2 for <>; Thu, 31 Oct 2013 14:40:20 -0700 (PDT)
Received: by with SMTP id c50so1002615eek.13 for <>; Thu, 31 Oct 2013 14:40:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=0YIn02QmbK01WSlcM87af065gu1mzrTa/eCqa7zd8JM=; b=sMD3C6x1uFCy89MGs4DOHwxZI188U9dIPECZ5IQ5p0IU7FA5pM227c/otzLX7Jbtz+ VM1/l6a3csS/V2+k07NQ8jnrzkzAlZ8aMA0mR16+KAX8uyrvDqYJFrHQgnNF5YLP1lzW 8SDXW/vrVjk/PN5f+l1SCtlO7Jn/Ussb5ZK5K0sjCNlfRPlwjmVEgKlgmEtmt5eKGIPM mrbD7shbfT/3GTSjVYXrFnxODHoviIu4qgolsYV8kvxPGLXGBTmPkwab6bInjdIphZRW XZDb7Ne0Gt9rc3qOIoVqQykgBAnmlx8rfwe+hnQ3HP205lggVBuVOm4GQDMiDOCtcSRk jTYA==
X-Received: by with SMTP id l4mr98842eep.37.1383255619615; Thu, 31 Oct 2013 14:40:19 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j7sm14363935eeo.15.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 14:40:18 -0700 (PDT)
Message-ID: <>
Date: Thu, 31 Oct 2013 22:40:16 +0100
From: Daniel-Constantin Mierla <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Eric Rescorla <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------050100080701070303070509"
Cc: "" <>, Neil Stratford <>
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: Thu, 31 Oct 2013 21:40:26 -0000

On 10/31/13 10:27 PM, Eric Rescorla wrote:
> On Thu, Oct 31, 2013 at 2: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.
> Solely on the security question...
> I'm not sure what you mean by "rather complex". What I would expect is 
> to have signed
> binaries. This addresses the question of attack from the network and 
> is how we
> intend to handle things in Firefox.
> Note that any product that auto-updates (like Firefox and Chrome) 
> already need
> to have some mechanism for verifying that the things they download are 
> correct.

Typically the updates you mentioned are done from the project's sites, 
so that is easier to handle. Now there is a third party involved, 
requiring some sync'ing between Cisco and browser's sites. It's like a 
menage-a-trios, pretty dirty affair. I wonder why flash plugin was not 
loaded this way, it was always free -- but had to be 
downloaded/installed explicitly by users.

>     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 don't see why this would be needed. The containing program (e.g., the
> browser) doesn't compile, it just does signature verification.
> Obviously, this only addresses the question of attack from the network,
> not malicious binaries constructed by Cisco. I expect that to be addressed
> by third parties doing verified builds and comparing the binaries. 
> Presumably,
> one could invent some countersignature mechanism to allow clients to
> verify that a specific third party had verified a build.
If we get to 'one could invent some ...' and wait for that, better wait 
for a pure open source video codec. Mozilla is working in that direction 


Daniel-Constantin Mierla -!/miconda -
Kamailio Advanced Trainings - Berlin, Nov 25-28
   - more details about Kamailio trainings at -