Re: [rtcweb] On video codec for rtcweb

Roman Shpount <roman@telurix.com> Fri, 23 March 2012 16:48 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8238C21F85A0 for <rtcweb@ietfa.amsl.com>; Fri, 23 Mar 2012 09:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level:
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH6xzaFA9nUa for <rtcweb@ietfa.amsl.com>; Fri, 23 Mar 2012 09:48:34 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EDC4521F8597 for <rtcweb@ietf.org>; Fri, 23 Mar 2012 09:48:33 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so3249959ggm.31 for <rtcweb@ietf.org>; Fri, 23 Mar 2012 09:48:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=YjQ6huDF80gS9aUdbozeNaCRYUSickGIdWl5CYBvOUs=; b=HFjLGjLZh84fujPSqX7FDfhDi7/OTNmaZsEI7/HG6nHSwwT5nOhawSrTozfFz435+K xipENmyexzJZw+K183DFpkIo79s7MWQ1arEqdjIT0nwA2hbaV6oHn6eNN/h+ULP9a1VZ bdTGYUfFd6URV1wFv+qaTLmiXftBMQrdt/VCxFyAAU5bLdky4GG0UpcPo4pIxP/pxc6R tuHQIez/8IRCnbSivqRZPX1lAZ8h4+U1b6jifq3wLVSbooxheXg974lToAnBond2010q QyNrxbsW6IwqlNMZKuTOBh0B8ksBGagz3kKsXIKgtYQcNOCheFI8rqUnag561moNUjOV 8EWw==
Received: by 10.236.156.34 with SMTP id l22mr12793697yhk.118.1332521313251; Fri, 23 Mar 2012 09:48:33 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id g7sm22757632yhm.5.2012.03.23.09.48.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 09:48:32 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so3217626yhk.31 for <rtcweb@ietf.org>; Fri, 23 Mar 2012 09:48:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.132.99 with SMTP id ot3mr30303527pbb.160.1332521310949; Fri, 23 Mar 2012 09:48:30 -0700 (PDT)
Received: by 10.68.6.67 with HTTP; Fri, 23 Mar 2012 09:48:30 -0700 (PDT)
In-Reply-To: <4F6C6DC1.7020606@mozilla.com>
References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <E44893DD4E290745BB608EB23FDDB76219E813@008-AM1MPN1-041.mgdnok.nokia.com> <4F6C6DC1.7020606@mozilla.com>
Date: Fri, 23 Mar 2012 12:48:30 -0400
Message-ID: <CAD5OKxu3Q45wASxLUhOR5kyPUZZb=81ybvZrpkbFuyqomsRH9Q@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: "Timothy B. Terriberry" <tterriberry@mozilla.com>
Content-Type: multipart/alternative; boundary="047d7b15a68b6510fe04bbebcb04"
X-Gm-Message-State: ALoCoQlpWE7MyHf2D0TSO2oHMsa5OxRPvxMRjFiiN5kZA6p4ibih0UhefQbzoT3MH606Mmc/KEw2
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] On video codec for rtcweb
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Fri, 23 Mar 2012 16:48:34 -0000

On Fri, Mar 23, 2012 at 8:34 AM, Timothy B. Terriberry <
tterriberry@mozilla.com> 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.
_____________
Roman Shpount