Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8

"Karl Stahl" <> Sat, 02 November 2013 12:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E6A121E80E1 for <>; Sat, 2 Nov 2013 05:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2zCxPsYFemgy for <>; Sat, 2 Nov 2013 05:04:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 28AD321E80BE for <>; Sat, 2 Nov 2013 05:04:38 -0700 (PDT)
Received: from ([]) by (Telecom3 SMTP service) with ASMTP id 201311021304351188 for <>; Sat, 02 Nov 2013 13:04:35 +0100
From: Karl Stahl <>
References: <> <> <20131101211922.3ed7833d@rainpc> <>
In-Reply-To: <>
Date: Sat, 02 Nov 2013 13:04:33 +0100
Message-ID: <0b2901ced7c3$b1985c70$14c91550$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7Xs85DbF2lu5AzQNmHLqSUx77grQACfZEw
Content-Language: sv
Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8
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: Sat, 02 Nov 2013 12:04:44 -0000

>From below:> "will *only* provide H.264, thus forcing everyone to comply
with it. Who's going to do anything else, when you know the only way to
reach all browsers is *the* codec?"

--- That fear should not be underestimated: Compare telephony, where 3.5kHz
G.711 still is 99% of the traffic, and use of wide band audio codecs to
reach 7kHz AM-radio quality between two different carriers is yet to be seen
(in spite of IP/IMS/VoLTE)... 

I thanked Cisco for their free H.264 offering - WebRTC needs video
compatibility when connecting with existing services - but many thanks to
Google also: That free baseline H.264 would hardly have happened without
their free VP8 offering...

Note that neither free H.264 nor free VP8 are conditioned any one of them
being selected MTI!

For compatibility using Cisco's free H.264 offering, the codec plug-in slot
and download of a H.264 codec are required, so that must be made mandatory,
must it not?

Then, when minimum video compatibility thus is assured, maybe IETF could
reach consensus about a free and good video codec that could be included in
a WebRTC browser from the beginning?

BTW: In an IETF recommendation, mustn't such codec plug-in slot be open for
more than download from Cisco and for more than H.264 baseline?

And, with compatibility assured, wouldn't VP9 be an even better video codec


-----Ursprungligt meddelande-----
Från: [] För
Alessandro Amirante
Skickat: den 2 november 2013 11:10
Ämne: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still
prefer VP8

Il 01/11/2013 21:19, Lorenzo Miniero ha scritto:
> On Fri, 01 Nov 2013 14:43:52 -0500
> Adam Roach <> wrote:
>> On 10/31/13 13:47, Harald Alvestrand wrote:
>>> We congratulate Cisco on their intention to make an open source 
>>> H.264 codec available and usable by the community. We look forward 
>>> to seeing the result of this effort.
>>> Google still believes that VP8 - a freely available, fully open, 
>>> high-quality video codec that you can download, compile for your 
>>> platform, include in your binary, distribute and put into production 
>>> today - is the best choice of a Mandatory to Implement video codec 
>>> for the WebRTC effort.
>> I agree with Harald that VP8 is a better codec than H.264 baseline in 
>> a number of important ways.
>> But I also want to reiterate that having an MTI codec has never been 
>> about choosing the best codec or even a good codec. It's about 
>> choosing an emergency backup codec-of-last-resort. It's about having 
>> one single mandated codec that everyone has in their back pocket in 
>> case nothing else works.
>> The core of RTCWEB is about session *negotiation*. Endpoints will 
>> negotiate the best codec they have in common. Once the next 
>> generation of codecs come out, this "best codec in common" will only 
>> be the MTI if they were about to fail anyway.
>> So it doesn't have to be good.
>> It just has to be better than failure.
>> /a
> Those are good points. But were that the case, we could have sticked with
an older codec, one that didn't have to carry the burden of royalty fees: a
choice that several people have often discarded exactly because it wasn't
good enough.

I could not agree more.

> That's also why I, as it is probably redundant to restate, actually
support Harald's view. My concern is that, with H.264, MTI will not mean *a*
codec in a negotiatiated session, which is what we all agree RTCWEB still
is, or should be. It will be *the* codec, because several implementations,
including two currently missing browsers (whenever they'll start to care),
will *only* provide H.264, thus forcing everyone to comply with it. Who's
going to do anything else, when you know the only way to reach all browsers
is *the* codec? And for a lot of people, including me, there's currently (or
actually, will be) only one way to do so, which is a plugin (in RTCWEB,
ironic) that may or may not be available two months after we start using it.

+1 for VP8 as MTI.


> I'm at the wrong edge of the knife, and I don't like it.
> Lorenzo
> _______________________________________________
> rtcweb mailing list

Alessandro Amirante, Ph.D.
Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione
Universita' degli Studi di Napoli "Federico II"
Via Claudio, 21 - 80125 Napoli - Italy

Phone:    +39 081 7683821
Fax:      +39 081 19730464
Skype-ID: alessandro.amirante

rtcweb mailing list