Re: [rtcweb] On video codec for rtcweb

Basil Mohamed Gohar <> Fri, 23 March 2012 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D534A21F866D for <>; Fri, 23 Mar 2012 12:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hA67pMQIVdth for <>; Fri, 23 Mar 2012 12:01:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3F01021F8698 for <>; Fri, 23 Mar 2012 12:01:02 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 8ADC96524DC for <>; Fri, 23 Mar 2012 15:01:01 -0400 (EDT)
Message-ID: <>
Date: Fri, 23 Mar 2012 15:00:58 -0400
From: Basil Mohamed Gohar <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
OpenPGP: id=5AF4B362
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] On video codec for rtcweb
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, 23 Mar 2012 19:01:06 -0000

On 03/23/2012 12:48 PM, Roman Shpount wrote:
> On Fri, Mar 23, 2012 at 8:34 AM, Timothy B. Terriberry
> < <>> wrote:
>     With a direct browser-to-browser connection, there is nothing
>     sitting between them to do the transcoding. In the DTLS-SRTP case
>     with identity verification, which I think a number of people here
>     view as highly important, you are in fact _guaranteeing_ that
>     nothing but the browser can encode or decode the video.
> This is not technically correct. You can still build a system that
> implements a media proxy that does nothing but handling ICE,
> encryption, and identity verification without ever transcoding the
> content. The cost of re-encrypting the media is low (ie single E5 Xeon
> CPU can probably do about 10GB/s), but the cost of transcoding video,
> or even audio is huge in comparison. Because of this, supporting a
> comprehensive set of codecs is highly desirable.
While perhaps technically desirable for those already knee-deep in the
existing telecommunications, it will serve to lock-out any WebRTC
implementations that either choose to or cannot implement an encumbered
format, such as free/open source software developers and companies.  As
of right now, there *are* no official complete WebRTC implementations to
inconvenience by choosing a mandatory-to-implement codec.  It would be
only an inconvenience to existing infrastructure, but because of the
free and open nature of the proposed format, adding support for it in
software would be a minimal effort, especially as it would standardized.

The reference implementation of VP8 (libvpx) is also licensed in such as
a way as to be equally available to all types of software.