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

Lorenzo Miniero <lorenzo@meetecho.com> Fri, 04 May 2012 08:46 UTC

Return-Path: <lorenzo@meetecho.com>
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 14F6E21F846A for <rtcweb@ietfa.amsl.com>; Fri, 4 May 2012 01:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level:
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 0g0XS4o9eoYw for <rtcweb@ietfa.amsl.com>; Fri, 4 May 2012 01:46:02 -0700 (PDT)
Received: from smtplq02.aruba.it (smtplqs-out17.aruba.it [62.149.158.57]) by ietfa.amsl.com (Postfix) with SMTP id 9288621F846C for <rtcweb@ietf.org>; Fri, 4 May 2012 01:46:01 -0700 (PDT)
Received: (qmail 16876 invoked by uid 89); 4 May 2012 08:44:50 -0000
Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq02.aruba.it with SMTP; 4 May 2012 08:44:50 -0000
Received: (qmail 32670 invoked by uid 89); 4 May 2012 08:44:49 -0000
Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.200) by smtp8.ad.aruba.it with SMTP; 4 May 2012 08:44:49 -0000
Date: Fri, 04 May 2012 10:44:46 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Dean Willis <dean.willis@softarmor.com>
Message-ID: <20120504104446.2d7b2715@lminiero-acer>
In-Reply-To: <A9FB11DB-8617-4ED6-BDB4-689FD5E7C0C7@softarmor.com>
References: <5B26F813B14D224999A508377061EDBBB1215C@EX2K10MB1.vb.loc> <A9FB11DB-8617-4ED6-BDB4-689FD5E7C0C7@softarmor.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Spam-Rating: smtp8.ad.aruba.it 1.6.2 0/1000/N
X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N
Cc: rtcweb@ietf.org
Subject: Re: [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 08:46:03 -0000

Il giorno Fri, 4 May 2012 00:11:40 -0500
Dean Willis <dean.willis@softarmor.com> 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
> > 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.
> 
> --
> 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
codec.

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com