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

Dean Willis <dean.willis@softarmor.com> Fri, 04 May 2012 05:11 UTC

Return-Path: <dean.willis@softarmor.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 44F7521F8744 for <rtcweb@ietfa.amsl.com>; Thu, 3 May 2012 22:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.524
X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LIx7f2dqiEyG for <rtcweb@ietfa.amsl.com>; Thu, 3 May 2012 22:11:51 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id A341C21F8741 for <rtcweb@ietf.org>; Thu, 3 May 2012 22:11:43 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so4093243obb.31 for <rtcweb@ietf.org>; Thu, 03 May 2012 22:11:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=subject:references:from:content-type:message-id:date:to :mime-version:x-mailer; bh=MgtHle7i+fmV9Ipkdvh3hiEmMI8ReoP3hhCDr828l/0=; b=M+0bVP39SAimYQVS0Z3ZnuzgImpUnaXWN7iBmFxONkt+f5EyQpL7vDr48akFcggNzo XAsU8Dj9pOcq+HeY0CJO3HhO7UEOPccYifs4mukpi/sjMqNXzA9SlyloHwzayJKDzTLn fP+EgzJGSHfp8XjLNN7xGutYqWP1YK6o7RQBg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:references:from:content-type:message-id:date:to :mime-version:x-mailer:x-gm-message-state; bh=MgtHle7i+fmV9Ipkdvh3hiEmMI8ReoP3hhCDr828l/0=; b=n3mRPpBps0Sp3/pCMMdBHNSFg9Kt8lP/Wqtz8/jwp0ayFwaITAvBG5Wdlh5xciZtDb VzPCz2TCy61iJ6yzFmDUjSmMP4C1CYUSAIJAS7xTI4XbPRYmueVqcuffTFroh+ZyIVHK MgnMt0CMJOX7nW7lSsTQuB1Z5nq7Gmk7Rzi9KLoQHGsMWjEO1m61J3zQPsyiSRfgpo6Y 9eI3CLwmSV6XayR2BeLMMboMsGJItGZ9v+lI8EaZhdWXanyPsd1ZkwKiyFgkktGGTfEE bgco5M5S+4KuEQWwJEJU5vswbZZZ/RIYU3ThosOnD3t4I+RGAsU7ka2KzFsul7xMP5Ty anqw==
Received: by with SMTP id j3mr6309344obn.65.1336108302887; Thu, 03 May 2012 22:11:42 -0700 (PDT)
Received: from [] (cpe-66-25-15-110.tx.res.rr.com. []) by mx.google.com with ESMTPS id vp14sm6539084oeb.5.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 22:11:42 -0700 (PDT)
References: <5B26F813B14D224999A508377061EDBBB1215C@EX2K10MB1.vb.loc>
From: Dean Willis <dean.willis@softarmor.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-11--828668167"
Message-Id: <A9FB11DB-8617-4ED6-BDB4-689FD5E7C0C7@softarmor.com>
Date: Fri, 04 May 2012 00:11:40 -0500
To: rtcweb@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Gm-Message-State: ALoCoQmZ5T2pr3BAzIQp/ewb3u8DXZQhIaMNw4t673Sj5W80LmiVdL40sEHnAh1/tgYExJQGktrw
Subject: [rtcweb] Discussion on codec choices from a developer who doesn't come to IETF
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, 04 May 2012 05:11:52 -0000

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 http://www.theregister.co.uk/2012/03/19/firefox_sucks_on_h264/
> 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.