Re: [rtcweb] On video codec for rtcweb

Gregory Maxwell <gmaxwell@juniper.net> Sat, 24 March 2012 00:49 UTC

Return-Path: <gmaxwell@juniper.net>
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 DA53321E8034 for <rtcweb@ietfa.amsl.com>; Fri, 23 Mar 2012 17:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 lklWAvg6w+Wy for <rtcweb@ietfa.amsl.com>; Fri, 23 Mar 2012 17:49:32 -0700 (PDT)
Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDB621E800F for <rtcweb@ietf.org>; Fri, 23 Mar 2012 17:49:32 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT20aGdbyyV6JNtxbfyZA+NkViQF2tAd4@postini.com; Fri, 23 Mar 2012 17:49:32 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 23 Mar 2012 17:48:40 -0700
From: Gregory Maxwell <gmaxwell@juniper.net>
To: Roman Shpount <roman@telurix.com>, Basil Mohamed Gohar <abu_hurayrah@hidayahonline.org>
Date: Fri, 23 Mar 2012 17:48:38 -0700
Thread-Topic: [rtcweb] On video codec for rtcweb
Thread-Index: Ac0JS89Y14yGlRY2QXCagWy79vAi7AACdKwM
Message-ID: <BCB3F026FAC4C145A4A3330806FEFDA94086731AF2@EMBX01-HQ.jnpr.net>
References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com> <E44893DD4E290745BB608EB23FDDB76219E813@008-AM1MPN1-041.mgdnok.nokia.com> <4F6C6DC1.7020606@mozilla.com> <CAD5OKxu3Q45wASxLUhOR5kyPUZZb=81ybvZrpkbFuyqomsRH9Q@mail.gmail.com> <4F6CC86A.3090107@hidayahonline.org>, <CAD5OKxu_668CbS1sPYzfK-Je9XGvDstsGMCmK_6-UbOMFZ2DUQ@mail.gmail.com>
In-Reply-To: <CAD5OKxu_668CbS1sPYzfK-Je9XGvDstsGMCmK_6-UbOMFZ2DUQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <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: Sat, 24 Mar 2012 00:49:34 -0000

Roman Shpount wrote:
> I am not arguing for making H.264 a base codec. I would actually prefer 
> VP8. All I was saying that despite lack of interoperability on 
> encryption, ICE, and identity, there are still significant benefits of 
> supporting the same codecs when communicating with legacy equipment, 

This is all true, but there won't always be a gateway or SBC in the media
path and users may not want one even if all it did was transcode. The case
with no media gateway can _only_ work reliably by virtue of compatibility
being baked into the specification— in the other cases interoperability
is 'simply' a matter of different tradeoffs.

An interesting observation on the cost of transcoding: a number of
mobile providers are now transparently transcoding their users' http
video downloads on the fly, not for the purposes of changing the codec,
but solely to make them smaller. This can do terrible things to the video
quality (beyond just the reduction in bitrate: MP4 wasn't designed to
stream from a live source). Perhaps this is an argument for more pervasive
end-to-end encryption— but the point remains that CPU power, especially
CPU power in high density data-centers, is still relatively cheap.