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.
- Re: [rtcweb] On video codec for rtcweb Bernard Aboba
- Re: [rtcweb] On video codec for rtcweb Matthew Kaufman
- [rtcweb] On video codec for rtcweb Stefan Hakansson LK
- Re: [rtcweb] On video codec for rtcweb Timothy B. Terriberry
- Re: [rtcweb] On video codec for rtcweb Lorenzo Miniero
- Re: [rtcweb] On video codec for rtcweb Markus.Isomaki
- Re: [rtcweb] On video codec for rtcweb Timothy B. Terriberry
- Re: [rtcweb] On video codec for rtcweb Cavigioli, Chris
- Re: [rtcweb] On video codec for rtcweb Markus.Isomaki
- Re: [rtcweb] On video codec for rtcweb Basil Mohamed Gohar
- Re: [rtcweb] On video codec for rtcweb Timothy B. Terriberry
- Re: [rtcweb] On video codec for rtcweb Timothy B. Terriberry
- Re: [rtcweb] On video codec for rtcweb Timothy B. Terriberry
- Re: [rtcweb] On video codec for rtcweb Timothy B. Terriberry
- Re: [rtcweb] On video codec for rtcweb Martin Thomson
- Re: [rtcweb] On video codec for rtcweb Matthew Kaufman
- Re: [rtcweb] On video codec for rtcweb Basil Mohamed Gohar
- Re: [rtcweb] On video codec for rtcweb Roman Shpount
- Re: [rtcweb] On video codec for rtcweb Tim Panton
- Re: [rtcweb] On video codec for rtcweb Serge Lachapelle
- Re: [rtcweb] On video codec for rtcweb Basil Mohamed Gohar
- Re: [rtcweb] On video codec for rtcweb Schleef, David
- Re: [rtcweb] On video codec for rtcweb Roman Shpount
- Re: [rtcweb] On video codec for rtcweb Gregory Maxwell
- Re: [rtcweb] On video codec for rtcweb Cameron Byrne
- Re: [rtcweb] On video codec for rtcweb Roman Shpount
- Re: [rtcweb] On video codec for rtcweb Jean-Marc Valin