IETF Logo Mail Archive

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

Chris Wendt <chris@chriswendt.net> Thu, 14 March 2013 22:41 UTC

Return-Path: <chris@chriswendt.net>
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 5D4CD11E81A2 for <rtcweb@ietfa.amsl.com>; Thu, 14 Mar 2013 15:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.044
X-Spam-Level:
X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, SARE_MILLIONSOF=0.315]
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 QImuHutFLnVP for <rtcweb@ietfa.amsl.com>; Thu, 14 Mar 2013 15:41:11 -0700 (PDT)
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id E323411E8158 for <rtcweb@ietf.org>; Thu, 14 Mar 2013 15:41:11 -0700 (PDT)
Received: by mail-pb0-f45.google.com with SMTP id ro8so2899469pbb.4 for <rtcweb@ietf.org>; Thu, 14 Mar 2013 15:41:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Mm677Xly+aexbwgbKFLhAMmUUT4KLDdkroY34oD09QQ=; b=OSIGVk7opZAvm9xSvZfGH/2Tnv4bya2uS7wFoPuAE6l8UzyiqOMJYp2FGjszBRhU8o riaAHi66kBFB3kTjWdAOlDTEnAJ/yfgrysUHRa84XkiQ/huzef0ob40IMcUN4DcKBSyz 1FIbGkxXQQm18RLamQvlwnHm7qa7QfmNY/VlvGMmL/x9vbCTTwJ9tY648wJcXak79Bek 62OZqxsacHYpjdjpkDV/x8YUlCQ9e9glz/buA0dWoxlDPcKjAhHFfBVHjC4mz0GBy1GN LrhMfVs2YZRWEzS2jNALcghVQ6+4ZWor1GegWQNOSDd15bDAoWwHYLMkAGc4wLQtxMwS JJDQ==
X-Received: by 10.68.220.9 with SMTP id ps9mr9724783pbc.38.1363300871223; Thu, 14 Mar 2013 15:41:11 -0700 (PDT)
Received: from dhcp-474b.meeting.ietf.org (dhcp-474b.meeting.ietf.org. [130.129.71.75]) by mx.google.com with ESMTPS id tm1sm5242286pbc.11.2013.03.14.15.41.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 15:41:10 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Chris Wendt <chris@chriswendt.net>
In-Reply-To: <FEA80D86BEEC134D88CA45E53A0D3408180DA31B@EXCHANGE.cablelabs.com>
Date: Thu, 14 Mar 2013 18:41:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <BB0010DD-AD20-4076-8D20-5F739AF1ABB8@chriswendt.net>
References: <FEA80D86BEEC134D88CA45E53A0D3408180DA31B@EXCHANGE.cablelabs.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnxx6v3Zv/yOw18FGJ7CjRGO51Ee+ZpStwNyXrQdI+uOsEglM4R0kfw8FcOtf4VyxTjJ8+/
Subject: Re: [rtcweb] A different perspective on the video codec MTI discussion
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: Thu, 14 Mar 2013 22:41:12 -0000

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

v2.23.0 | Report a Bug | By Email