Re: [rtcweb] A different perspective on the video codec MTI discussion

Erik Lagerway <> Fri, 15 March 2013 00:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 162EA11E8104 for <>; Thu, 14 Mar 2013 17:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.422
X-Spam-Status: No, score=-0.422 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24, SARE_MILLIONSOF=0.315]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9SSLX+mkf0mi for <>; Thu, 14 Mar 2013 17:17:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22e]) by (Postfix) with ESMTP id 052F811E80D9 for <>; Thu, 14 Mar 2013 17:17:37 -0700 (PDT)
Received: by with SMTP id hi8so27466wib.7 for <>; Thu, 14 Mar 2013 17:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Jyefbu25JaH/geNZOOr9r0Ixt14k7lBDjcNC7TqIT98=; b=S85UylK8MXGV4yDi8ATZ2BVdVOEl07mMO8/4P5PPEQrDFWI6zXJepLReU2WEkdSj6f N1tx/AE8QsR+cpacIzUiqMaF97yFroZg3vupKHoDQqDJ4g61BlS8VseOyfWHAEC05VA9 eEN+n2Cf6GSeSVqTf+KBkCmVF4OmlYbUTQ7cwYutZITfu2zGBvRpnlmq+S4ut1O7nHSr 4mnnNyMOGPOPivnCYc8VmhCbs0F3YmgoRrESy68uwMPMgHr2hgYhnJoFHVJRYqTlKLkr MSSBBGRaNoi6zJZhJOCertDqUKelsZoxeBPGBwM3K3GlkuB2rZvNQ2n2HT/am4JrnYU2 +erw==
MIME-Version: 1.0
X-Received: by with SMTP id v2mr21564wix.17.1363306657153; Thu, 14 Mar 2013 17:17:37 -0700 (PDT)
Received: by with HTTP; Thu, 14 Mar 2013 17:17:36 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 14 Mar 2013 17:17:36 -0700
X-Google-Sender-Auth: SG-JxHGejm8f_2WL172rqDkxKnE
Message-ID: <>
From: Erik Lagerway <>
To: Chris Wendt <>
Content-Type: multipart/alternative; boundary="f46d04428296050a3004d7eb91f4"
Cc: "" <>
Subject: Re: [rtcweb] A different perspective on the video codec MTI discussion
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, 15 Mar 2013 00:17:40 -0000


Well said Chris, this is pretty much what I wrote earlier today...

The WG has been through this debate many times and it seems rather obvious
that this is not likely to get resolved anytime soon.

Let's remove the MTI video codec requirement now and get on with life.


On Thu, Mar 14, 2013 at 3:41 PM, Chris Wendt <> wrote:

> As mostly an observer over the past year or two, this issue of MTI has
> come a long way, both good and bad.
> First, I will state, my employer, Comcast, has millions of boxes deployed
> and more in the pipeline where one could imagine webrtc capabilities being
> utilized.
> Short term, VP8 does pose us the most challenge in terms of either
> suboptimal or total lack of support because of limited cpu/gpu
> capabilities, etc.
> Longer term, this would be less of an issue, certainly, but perhaps in
> that time frame we will be talking the virtue of a brand new set of codecs
> anyway.
> In terms of quality per bit/cpu/transistor, I believe nobody can credibly
> say that either codec is a horrible choice.  To me, any further argument or
> quantitative/perceptual testing on that is wasting time.
> IPR, I'm not going to comment, because the clarity of the IPR situation is
> in the eye of the beholder.
> While it would be wonderful if everybody agreed on a single video codec, I
> don't see any possibility that one can satisfy all use-cases in any
> practical way.  Whether it's browser to browser or browser to terminal, one
> can argue that her use-case is more valuable than the other, but we can't
> all agree on that either.
> To me, the only choice left, and I think many others agree and some have
> stated it already, is either to make both codecs MTI or remove the MTI
> requirement.  The former, likely would take an act of God and for various
> reasons I don't think is the right choice anyway.  So, I would strongly
> encourage the latter, in full acknowledgement that there have been
> decisions made against this.
> (ASCII codec being a third choice, but I haven't seen the draft )
> Note, regardless of either choice, we would likely be required to
> implement both codecs anyway to avoid the transcoding penalty if we want to
> reasonably support interoperability.
> In the end, we currently sit in the likely position that the market will
> decide this debate anyway, it already seems to be underway, so why keep
> wasting time debating.  Besides being a complete waste of valuable brain
> cycles, and delaying more important work to resolve, I think it has become
> or is close to becoming much more destructive to the process than the value
> of having a half-supported, forced choice MTI codec.
> -Chris
> _______________________________________________
> rtcweb mailing list