Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF

Stephan Wenger <> Fri, 04 May 2012 09:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E035B21F862F for <>; Fri, 4 May 2012 02:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.802
X-Spam-Status: No, score=-3.802 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u0xNJmdXh87B for <>; Fri, 4 May 2012 02:36:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4EC6F21F84A7 for <>; Fri, 4 May 2012 02:36:27 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Fri, 4 May 2012 09:36:15 +0000
Received: from mail74-am1 (localhost []) by (Postfix) with ESMTP id DF88E220167; Fri, 4 May 2012 09:36:15 +0000 (UTC)
X-SpamScore: -26
X-BigFish: PS-26(zz1432N98dKzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839he5bh)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
Received-SPF: pass (mail74-am1: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail74-am1 (localhost.localdomain []) by mail74-am1 (MessageSwitch) id 1336124173374309_9215; Fri, 4 May 2012 09:36:13 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 536E7420070; Fri, 4 May 2012 09:36:13 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 4 May 2012 09:36:12 +0000
Received: from ([]) by ([]) with mapi id 14.16.0152.000; Fri, 4 May 2012 09:36:21 +0000
From: Stephan Wenger <>
To: Lorenzo Miniero <>, Dean Willis <>
Thread-Topic: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF
Thread-Index: AQHNKdJbp9KGAkNNHkG4ROjNnYqhkZa5gJsA
Date: Fri, 04 May 2012 09:36:20 +0000
Message-ID: <>
In-Reply-To: <20120504104446.2d7b2715@lminiero-acer>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF
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, 04 May 2012 09:36:29 -0000

If this is about the MPEG-LA license: it is my understanding that content
for conversational purposes is covered by that license without any charge.
 RTCWEB is about conversational.  We can worry about licensing for the
encoder and decoder (which are part of the web browser), but users should
be fine.
Of course it is fairly well known that MPEG-LA is not the only entity
which has the right to use patent claims against an H.264 implementation
or an H.264 bitstream.

On 5.4.2012 10:44 , "Lorenzo Miniero" <> wrote:

>Il giorno Fri, 4 May 2012 00:11:40 -0500
>Dean Willis <> ha scritto:
>> I asked a colleague who develops serious enterprise video stuff:
>> > Here's a question you can perhaps help me with. One of the big
>> > fights in the IETF right now is which codec to require as the "must
>> > implement" for real-time web communications. The leading candidates
>> > are H.264 and VP8, although I've proposed H.263 as a
>> > cheaper-to-license starting point. How much of an issue has codec
>> > licensing been for you, and what would you prefer as the "standard"
>> > codec? 
>> And the (somewhat surprising to me) response (which I've expurgated a
>> bit as I'm passing it on without explicit permission)  was:
>> > I believe the battle is over and H.264 has won. The question is
>> > ultimately where has the market gone in terms of playback
>> > mechanisms. The answer: Flash: H.264 and (maybe)VP8
>> > Adobe Adaptive HDS: H.264
>> > QuickTime: H.264
>> > Apple Adaptive HLS ­ H.264
>> > Smooth Streaming: VC-1 and H.264
>> > DASH ­ All implementations are H.264
>> > Android Cell Phones: H.264
>> > Cell Phone hardware: H.264
>> > HTML5 on IE: H.264
>> > HTML5 on Safari: H.264
>> > HTML5 on Firefox: VP8 but recently announced support for H.264 see
>> >
>> > HTML5 on Chrome: H.264 and VP8 Video Conferencing World: H.264
>> > supported universally Broadcast World ­ Moving from MPEG2 to H.264
>> > Every Set Top Box in the world ­ MPEG2 and H.264
>> >  
>> > Once the chip manufacturers started building H.264 into the
>> > hardware, it was game over. Even though Google was the big VP8
>> > developer/supporter, it had to support H.264 in Chrome and Android
>> > phones since that¹s all they had to work with on the phones. Pretty
>> > obvious pattern. Codec licensing is largely an issue of the past
>> > for us. We do license the H.264 encoders, but it is a miniscule
>> > part of our material cost. The decoder license is on a per-machine
>> > basis. Every PC/phone/pad that ships today has been licensed for
>> > H.264(and AAC) by the manufacturer of the hardware and/or the OS
>> > provider. Of course the main complaint on licensing of H.264 is
>> > from the content producers which is where the MPEG-LA members want
>> > to make money. I don¹t have much comment on that, but in our
>> > customer base ­ enterprise ­ I have never once heard it raised as
>> > an issue during a buying decision. Also ­ if VP8 really got popular
>> > it is likely that the MPEG-LA patent holders would come after them.
>> > Everything I have read indicates that it infringes lots of patents
>> > and is basically the same as H.264 in many ways. That is what
>> > happened to VC-1 (Windows Media Video). The patent holders won¹t
>> > bother unless is appears to be a real competitor. The html5 people
>> > originally wanted to insist on a royalty free codec and gave up
>> > based on the reality was that H.264 is the only essential codec. If
>> > IETF insists on VP8 or 363 as a ³must implement² they will be
>> > ignored. It would be a huge deviation from their general principal
>> > of consensus and following the market. I cannot conceive of how it
>> > could happen. We really like a standard codec since it eliminates
>> > one area of confusion.
>> This seems like a fairly compelling argument for H.264 as a baseline
>> must-implement in RTCWeb. I'm thinking of changing my position.
>> --
>> Dean
>Good arguments but this WILL cut out a lot of content producers or
>interested folks. As you pointed out, you asked someone "who develops
>serious enterprise video stuff", not the student, the geeky guy or the
>small startup who wants to try and make some business with a
>"funny-hat-chat" or "send-your-friends-a-silly-postcard" application
>based on RTCWEB, that is, what is supposed to be the real fuel behind
>innovation in RTCWEB in the future. None of them are likely to be
>able/willing to afford or be encumbered with the license fees and
>limitations such a choice would impose (what is "minuscule" to
>enterprises is not that tiny for the poor mob I'm part of).
>That said, I currently have no strong opinion towards any particular
>choice, but I really am not that comfortable with an H.264 mandatory
>Lorenzo Miniero, COB
>Meetecho s.r.l.
>Web Conferencing and Collaboration Tools
>rtcweb mailing list