Re: [rtcweb] Summary of Video Codec contributions

Erik Lagerway <> Mon, 22 October 2012 15:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDFB921F8C11 for <>; Mon, 22 Oct 2012 08:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.394
X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TMBvG54djrLv for <>; Mon, 22 Oct 2012 08:39:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C4D3A21F84DD for <>; Mon, 22 Oct 2012 08:39:15 -0700 (PDT)
Received: by with SMTP id k13so2037306lbo.31 for <>; Mon, 22 Oct 2012 08:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=p+KmBAF/jDvn8efBrSUU1H4w4O5pI9bVxtE8HJErD0E=; b=RFuHk8nfWQo4OAaTHH7HXT5rbCzW9NLHHlnIttrCPfGDjvIDDWBGo39nKhtCE6ATe7 MdSesDea1Et0qPfeI2eCDYvYYr2IzT18xvai0Jz4K2fNrHPG7MIVL7TUYeAAfpCbn7im llJWQcsXDv/69yPHCCNlzi0rZ8Gf6V3E6vEKfua+Z2WnSGzjrOoJJs/yK8TacRuXDBlG uxfjJyH1RwY+LxacODkgOZH+vL6OWJvodYEXAcrav1c5DJ9wcsuV6AtzJ6h9zcsEmkg3 36B6wnN7epqMc7ewWvBI+CnVu6oXV5jOjkXdd2wTsgTjiTcFnB5vdx4iYzonMQ72xV0Y Nc7A==
MIME-Version: 1.0
Received: by with SMTP id gw20mr8599765lab.8.1350920354651; Mon, 22 Oct 2012 08:39:14 -0700 (PDT)
Received: by with HTTP; Mon, 22 Oct 2012 08:39:14 -0700 (PDT)
In-Reply-To: <20121017192046.GO6812@audi.shelbyville.oz>
References: <> <> <20121017192046.GO6812@audi.shelbyville.oz>
Date: Mon, 22 Oct 2012 08:39:14 -0700
X-Google-Sender-Auth: Fw-cTozYBbo0LDlV6PcKUE6D_MA
Message-ID: <>
From: Erik Lagerway <>
Content-Type: multipart/alternative; boundary=f46d0420a695dbdfd304cca7a735
Subject: Re: [rtcweb] Summary of Video Codec contributions
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: Mon, 22 Oct 2012 15:39:25 -0000

On Wed, Oct 17, 2012 at 12:20 PM, Ron <> wrote:

> 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.

Yes, I see your point and agree.

> > 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.

Seems to me that if we want to see the indie webrtc developers flourish, we
need to implement a RF codec = VP8.  Unless of course the MPEG LA decides
to grant a RF license on 264/AVC before the WG votes on the MTI? Which does
not seem likely given the time frame. That plus the fact this 264/AVC non
royalty codec concept was tabled in the past and went nowhere, it seems.

I would like to see us foster grassroots innovation by making this tech
accessible to all developers, which essentially means zero royalty and
admin overhead.

>  Stay sharp!
>  Ron
> _______________________________________________
> rtcweb mailing list