Re: [rtcweb] confirming sense of the room: mti codec

David Singer <singer@apple.com> Tue, 09 December 2014 01:19 UTC

Return-Path: <singer@apple.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40C11A6FF6 for <rtcweb@ietfa.amsl.com>; Mon, 8 Dec 2014 17:19:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.101
X-Spam-Level:
X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7MDmTDeDV1Q for <rtcweb@ietfa.amsl.com>; Mon, 8 Dec 2014 17:19:25 -0800 (PST)
Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB92E1A885B for <rtcweb@ietf.org>; Mon, 8 Dec 2014 17:19:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418087965; x=2282001565; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2Orx7NhbdOjm8MF/ZMc77jE6O1BrrQrFsBJ/7Br0OuE=; b=l8tOIVFGNIAqOi5/aRDeKxWe7dGU2EW0CkjLyaAc7bPKIY14YET/w+CN07V49b8o kD+3weMH30nXv4VU3XI8SXvv5J+GV/cinIZtRH54CHbbT6laZTvKAoJLThwnCvp/ eGm1FpqNwvernYFEEpu9azA9iK3QMqdn4DtY4V6aBHXvtO5iYzNjPRh0e3hhroL9 MIvJA9r21vErnKveXB7pdV3Khhinqk7LWmpYBaBVP0XHgez+C56bmpv+L9k9hgIF X610qm4bqPA53XI3i3GRAXm1HlUB9upOBgrhuLxWHdtkmXv036AK5xUVRn/QnCLI l4+lKR4uxe4KEWil9RhBLg==;
Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 5D.BD.26546.D1E46845; Mon, 8 Dec 2014 17:19:25 -0800 (PST)
X-AuditID: 11973e11-f79af6d0000067b2-3c-54864e1de357
Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 9F.5E.05998.E2E46845; Mon, 8 Dec 2014 17:19:42 -0800 (PST)
Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGA001FNJOCMS60@marigold.apple.com> for rtcweb@ietf.org; Mon, 08 Dec 2014 17:19:25 -0800 (PST)
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: David Singer <singer@apple.com>
In-reply-to: <CALiegfn0AH+2FKXJ2b3JWob-pETdD8fXS-OM0iq8p+txdq+mSQ@mail.gmail.com>
Date: Mon, 08 Dec 2014 17:19:24 -0800
Content-transfer-encoding: quoted-printable
Message-id: <21E818AE-0F44-4BA1-AA59-8322C982446E@apple.com>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <54820E74.90201@mozilla.com> <5485E627.5050706@jesup.org> <CALiegfn0AH+2FKXJ2b3JWob-pETdD8fXS-OM0iq8p+txdq+mSQ@mail.gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Mailer: Apple Mail (2.1993)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FAYrivr1xZiMGWhpMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOLL0NVvBZZGK/kk/2BoYNwt0MXJwSAiYSDTfie1i5AQyxSQu 3FvP1sXIxSEksJdR4s6iRjaIhInEp8//mCESk5gk9q75zQLhzGeS2Dh3MTvIJGYBdYkpU3JB GngF9CSanjxmAgkLC9hKbL0eBBJmE1CVeDDnGCOIzSkQLHGoYRkLiM0CFJ//6z0ziM0soC3x 5N0FVogxNhLvn1yDWrWPUaJ1xz6wIhGgVZcfXmCHOE5W4t/FM+wgRRICD1klpi7bzzKBUWgW wkmzkJw0C8mOBYzMqxiFchMzc3Qz84z0EgsKclL1kvNzNzGCgnW6neAOxuOrrA4xCnAwKvHw ali2hQixJpYVV+YeYpTmYFES571hAxQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAKHF+65Jc 1RvKSSmpVd5b3RTuTe05dHQyq/CymynnT8r/eaHwPJWbpylIpkr50sR9obtfOzT+93YrCr4j nyxzZ5v9imkNF5b+6I2f25bxILsqWCexkldJUilabEHj8g696DmV/Bov8yaeeCKaKGbiy+Oq c6ogvZ3zc6XphpRvMy5e61g1y2GvEktxRqKhFnNRcSIAr5RNVTcCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FDcoqvn1xZicO2JhsXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOLL0NVvBZZGK/kk/2BoYNwt0MXJySAiYSHz6/I8ZwhaTuHBv PVsXIxeHkMAkJom9a36zQDjzmSQ2zl3M3sXIwcEsoC4xZUouSAOvgJ5E05PHTCBhYQFbia3X g0DCbAKqEg/mHGMEsTkFgiUONSxjAbFZgOLzf70H28UsoC3x5N0FVogxNhLvn1yDWrWPUaJ1 xz6wIhGgVZcfXmCHOE5W4t/FM+wTGPlnIVwxC8kVs5CMXcDIvIpRoCg1J7HSRC+xoCAnVS85 P3cTIzi8CsN3MP5bZnWIUYCDUYmHV8OyLUSINbGsuDL3EKMEB7OSCO/yna0hQrwpiZVVqUX5 8UWlOanFhxilOViUxHmb3zWGCAmkJ5akZqemFqQWwWSZODilGhh3sUie2T/3X3a2t6rdO4vC uwZuLqzBi5Ybn+3WFpX6/+ijgiTrxNoKLl0dphp9/WtLKzvCkowqv6m9LW3+E2HaIqy7v8rG R/PMjk9vXot/KUwL7inYck5kLUu9elD74avFbxf/zzR9viko7f7h+wcOyzr6eaY8UF32Mvbx 9pwvnmLVEQkHfZRYijMSDbWYi4oTAe+PnGwrAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/23F1rnu3_QREq3eLaZ9kCWrX6pI
Subject: Re: [rtcweb] confirming sense of the room: mti codec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 09 Dec 2014 01:19:28 -0000

> On Dec 8, 2014, at 10:00 , Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 
> 2014-12-08 18:55 GMT+01:00 Randell Jesup <randell-ietf@jesup.org>rg>:
>> +1 - it's by no means my preferred solution, but it's one I can live with,
>> and better than the alternative of the status-quo - no MTI at all.  If it
>> wasn't for OpenH264, my answer would be different.
>> 
>> I can't see adopting H.264 as sole MTI, and I can't see that we'd get
>> consensus to adopt VP8 as sole MTI.
> 
> There was a much better solution:
> 
> - Don't make VP8 nor H264 MTI.
> - So for now no MTI video codec.
> - And a W3C compromise: First video codec 100% royalty free would
> become MTI in WebRTC.
> 
> Things would be exactly as they are now, but at least we avoid a
> "MUST" that will be ignored by 50% of the market.

That would be more honest, indeed. It is effectively where we are going to be.  And it offers a carrot in the right direction.

I am curious to know how many of the people supporting the proposed position actually would implement both encode and decode of both codecs?  This follows from comments on this thread that people who feel they fall into a different category are asking others to solve their problem.

So, rather than +1, please say “I would expect to implement both” (non-binding, of course) — it would be a more useful thing to see, I think.



Another possible choice:

* admit that we already have possible non-interoperability (WebRTC-compatible Endpoints that choose differently), and that anyone who doesn’t want to do both will say that this what they are making (as was suggested):  simply delete the requirement or definitions for WebRTC User-agent and Device. Nothing stops those that want to from implementing both, without or without the mandate.  I don’t think this would make any material difference to what happens, but it makes the spec and reality a little closer.



Finally, I wonder, what would it be like if we actually tried to get closer to interop: ALL endpoints — anything that can operate at one end of a WebRTC session, be it device, UA, gateway, compatible-endpoint, whatever — must be able to decode (actually, offer to receive) both, and must be able to encode at least one?  I’d have to think about the consequences of doing decode-only, but it’s a loss less work than a decent encoder, for a start. This would result in interop if people actually did it.


David Singer
Manager, Software Standards, Apple Inc.