Re: [rtcweb] Summary of Video Codec contributions
Ron <ron@debian.org> Wed, 17 October 2012 19:20 UTC
Return-Path: <ron@debian.org>
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 6282E21F861A for <rtcweb@ietfa.amsl.com>; Wed, 17 Oct 2012 12:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.034
X-Spam-Level:
X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MBMh2AfE2Zc for <rtcweb@ietfa.amsl.com>; Wed, 17 Oct 2012 12:20:50 -0700 (PDT)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFF121F8634 for <rtcweb@ietf.org>; Wed, 17 Oct 2012 12:20:49 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANEDf1B20idQ/2dsb2JhbABFwCeBCYIgAQEEATocKAsLGC4UGA1Sh2MFvAiLWIZCA44Bh2kBkDSDAg
Received: from ppp118-210-39-80.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.39.80]) by ipmail06.adl2.internode.on.net with ESMTP; 18 Oct 2012 05:50:48 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id C98DA4F8F3 for <rtcweb@ietf.org>; Thu, 18 Oct 2012 05:50:46 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bttJe36CLlus for <rtcweb@ietf.org>; Thu, 18 Oct 2012 05:50:46 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 42D474F902; Thu, 18 Oct 2012 05:50:46 +1030 (CST)
Date: Thu, 18 Oct 2012 05:50:46 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20121017192046.GO6812@audi.shelbyville.oz>
References: <507D4302.9050108@ericsson.com> <CAPF_GTaxcBezxbjd36Xkev5ugof9BAt3vdpZaO_qA7A0ujhp3Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAPF_GTaxcBezxbjd36Xkev5ugof9BAt3vdpZaO_qA7A0ujhp3Q@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Summary of Video Codec contributions
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: Wed, 17 Oct 2012 19:20:51 -0000
Hi Erik, On Wed, Oct 17, 2012 at 01:56:55AM -0700, Erik Lagerway wrote: > Thought it important to point out the fact that FREE-P8 (VP8) would likely > be the preferred codec implemented by independent developers. Royalties and > admin headaches create a barrier to entry. Independent dev shops equate to > a great deal of innovation and some of these have been responsible for > dictating the standard in market with hundreds of millions of users. Yes, > there is plenty of interoperability with 264 today but that doesn't mean it > will be that way tomorrow. Very true. Though for developers who don't click-track and count users of their software it is more than just preferred. An RF solution is actually the only viable way for this standard to be accessible to them. Any standard that immediately excludes a large portion of potential developers and adopters can only ever be of niche value and is certain to be replaced before long by an alternative that doesn't have that constraint as a fundamental flaw preventing its broadest use. If the whole point of this group was to avoid further fracturing of the developer efforts in this space, then solving this problem now would be much preferable to forcing another group to develop another competing standard that does address that issue. It would be a sad waste of the invested time of the people here if we didn't recognise this necessity. I think the points you make above are very relevant here. > Can't we do both, as we have done for Audio MTI? Well, the M in MTI stands for Mandatory. So mandating both would be mandating the barriers to entry that you so clearly identified above? Mandating an RF video codec, and permitting any other to be negotiated as an extension would be more like what we decided was best for audio. > If unknown IPR is the only real reason not to include VP8 then I maybe we > are not trying hard enough. If that's the only reason people have for opposing VP8 then maybe they're trying too hard. Resorting to imaginary reasons to make the issue seem more complex than it really is doesn't seem very enlightening. Every day that goes by leaves this argument dangling from a thinner, more strained thread of tenuousness. It's been well over a year since the very public call to form an offensive pool was made or even since the last very vague mumbling of "yeah, some people responded. honest." - meanwhile VP8 continues to serve millions of users every day through things like youtube et al. with no concrete claim being made against them of infringement. It's not like this is a secret, so any submarine patent holder must know that laches is now daily eroding their 'investment'. The extensive patent search made in the attempt to form a pool surely only weakens their case further in the absence of any real disclosure or claim being made - if not outright coming close in itself to 'proving' that no such IPR exists. If VP8 was mandated here, I presume that would additionally place an obligation of disclosure on any of the participants of this group, which would strengthen that protection even more. If we get to the end of this process and there are still no actual claims being presented for substantiation, then it seems reasonable to conclude that we may be as safe as it is ever possible to be from "unknown IPR" (until the laws are changed to end that kind of madness once and for all). By contrast the present day known burdens of H.264 are very real, and if we're going to project our future concerns, then I think we've got more to worry about from the royalties for H.264 being dialled up greatly as the patents on it begin to expire and their holders want to 'encourage' people to switch to H.265 while its patents are still nice and fresh. Locking people into that seems like a far greater danger. Especially since unlike VP8, H.264 really has had submarine patents surface on it and really is an exposed pawn in the present theatre of patent warfare that everyone else seems to be ducking stray bullets from these days. So spruiking there's somehow a spookier risk to VP8 in the face of all available evidence to the contrary seems like some sport where you have to squint pretty hard and tip your head 90 degrees to the left in a dark room, before that line of plot extrapolation might perhaps appear to be spinning in an even vaguely-real kind of direction, sort of ... And even then, only if the people wanting you to buy that proposition don't properly label their axes ... > RTCweb / WebRTC is supposed to be the next big thing, why hamper > innovation like this? Indeed we should not, and I for one certainly hope consensus is that we will not. Stay sharp! Ron
- [rtcweb] Summary of Video Codec contributions Magnus Westerlund
- Re: [rtcweb] Summary of Video Codec contributions Neil Stratford
- Re: [rtcweb] Summary of Video Codec contributions Harald Alvestrand
- Re: [rtcweb] Summary of Video Codec contributions Erik Lagerway
- Re: [rtcweb] Summary of Video Codec contributions Ron
- Re: [rtcweb] Summary of Video Codec contributions Erik Lagerway