IETF Logo Mail Archive

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

David Singer <singer@apple.com> Fri, 12 December 2014 23:39 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 4FA941A00FF for <rtcweb@ietfa.amsl.com>; Fri, 12 Dec 2014 15:39:41 -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 kENrUzYOsLCM for <rtcweb@ietfa.amsl.com>; Fri, 12 Dec 2014 15:39:39 -0800 (PST)
Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D749D1A00CD for <rtcweb@ietf.org>; Fri, 12 Dec 2014 15:39:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418427579; x=2282341179; 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=I/pgNk7WUiOaZY61qk0Tnx05z3NGOuLcLJjmYeTLj5o=; b=PQw7OfV3Ebf3tGTM7G8/jhUGdFMCRHY5ip/Gxtdc7ufuQoGHkFGgG0HGI1JaO/sX TtJexoNmeTxcbNA46qTZaBm0l9m/Xev1HzQvLw9IVa/u4DkJfqv8iPk802mOONdh /ArcApEGWNL1PuJq3SRa1dKch9TNHLrMeTuHDX/Ygi5L0DwIJXFzEUN0Bt70vKFe Irji5YjGZjRcuac6hxRa5UK8yPrMyAUk4w2jzA+VgckZ8ZoIEdUXwWGOfMNTQ+6C PDAFTxy6mD4f4uGANyjgd/ygMuO/No+jEpROfdv0M3bwnYsLiKIh/OicvpU8rc50 sPLFnD9kLd1etSdPfgnrzg==;
Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id F9.F3.12074.BBC7B845; Fri, 12 Dec 2014 15:39:39 -0800 (PST)
X-AuditID: 11973e12-f79f86d000002f2a-47-548b7cbbaad5
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 relay7.apple.com (Apple SCV relay) with SMTP id 0E.DB.06091.B9C7B845; Fri, 12 Dec 2014 15:39:07 -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 <0NGH00B8LTQ3LJ70@marigold.apple.com> for rtcweb@ietf.org; Fri, 12 Dec 2014 15:39:39 -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: <CALiegfnyNTB=C49BDefraYyJNu6AmewV=SK7Hw4aH7oWP2s4BA@mail.gmail.com>
Date: Fri, 12 Dec 2014 15:39:38 -0800
Content-transfer-encoding: quoted-printable
Message-id: <0AD9F067-0C36-48FD-AE22-AC786FA8718C@apple.com>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <D0AB64D8.3FA7A%mzanaty@cisco.com> <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net> <CALiegfnyNTB=C49BDefraYyJNu6AmewV=SK7Hw4aH7oWP2s4BA@mail.gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Mailer: Apple Mail (2.1993)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUi2FCYqru7pjvE4OseRYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcX/xJ8aCr7wVfR83MjUwtnF3MXJySAiYSDybvZMdwhaTuHBv PVsXIxeHkMA+Ron3v08AORxgRSdueYHUCAlMYpL43uMOYc9nklj1zw6khFlAXWLKlFyQMK+A nkTTk8dMIGFhAVuJrdeDQMJsAqoSD+YcYwSxOQWCJWY/7GIGsVmA4qt+tIBdwCygLfHk3QVW iDE2Eq8OtDBBbHrGKNE8IQvEFgHadPnhBaiLZSX+XTzDDnKxhMBdVol9i26yTWAUmoVw0Swk F81CsmIBI/MqRqHcxMwc3cw8E73EgoKcVL3k/NxNjKAwnW4ntIPx1CqrQ4wCHIxKPLwvUrtC hFgTy4orcw8xSnOwKInzLnfrDhESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWGLfMuVCkJTf O/8fL85dmcBgqHT60RGHI6/3cEz4FVZlKHpg/tztsk1qs0U0zDveZaenhe2pZy0yUw3dfGj5 7VMvhTj7NMWWNpdX38i+UB33qn/L2Ybp1emiNesjY79yTdycVM61J042KGWBlPsiqZWVpxd9 SExseWHBvrevq1B73RcOLsUfSizFGYmGWsxFxYkAy3ScjzQCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUi2FDcoju7pjvEYPZHWYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcX/xJ8aCr7wVfR83MjUwtnF3MXJwSAiYSJy45dXFyAlkiklc uLeeDcQWEpjEJPG9xx3Cns8kseqfHUg5s4C6xJQpuSBhXgE9iaYnj5lAwsICthJbrweBhNkE VCUezDnGCGJzCgRLzH7YxQxiswDFV/1oYQexmQW0JZ68u8AKMcZG4tWBFiaITc8YJZonZIHY IkCbLj+8wA5xmazEv4tn2Ccw8s9COGIWkiNmIZm6gJF5FaNAUWpOYqW5XmJBQU6qXnJ+7iZG cFgVpu5gbFxudYhRgINRiYd3QnJXiBBrYllxZe4hRgkOZiURXkvx7hAh3pTEyqrUovz4otKc 1OJDjNIcLErivCHvGkOEBNITS1KzU1MLUotgskwcnFINjAYed1c8nNv5b11eg31ox5t3cq6L Ch4IN7mpOf99rnDr3rzb2/ymmxt83TRrz+b2nc3PE/T6Z7EEyPWsu3VcW21dByd3ZnDg4/cL N3j9OOwWfjdmg7HK+pSm3AL/zTN8liU8mmY437pgonOS/ORtvSmC3hMdhFWEuEwi1N6kR2Wu n5SskXn6iBJLcUaioRZzUXEiAH4qdO4nAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2If991397EKpktp4UZ2REH5kBWg
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: Fri, 12 Dec 2014 23:39:41 -0000

> On Dec 12, 2014, at 8:32 , Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 
> 2014-12-12 16:27 GMT+01:00 Gaelle Martin-Cocher <gmartincocher@blackberry.com>:
>> The question is not do we need multiple codecs but do we need multiple MTIs (and which).
> 
> We need MTI codecs, but no patent/license polluted ones.

I think hoping for an RF codec is optimistic but may be achieved.  Hoping for a codec which has needs/has no license is definitely further out on the optimism scale.

We can hope for Reasonable licenses, of course, but then we rapidly find that we don’t have a consensus definition, in the industry, for what is reasonable. I have struggled with this for years.

> That's the
> reason of my question. Will those non 100% RF video codecs be removed
> as MTI *if* a new 100% RF good video codec appeared? Will we have to
> deal with non RF MTI codecs forever?
> 
> The arguments I'm reading in this thread about the no-need for more
> MTI codecs in the future could also be applied for the no-need of
> defining any MTI codec now. At the end we do have a "codec
> negotiation/capability discovery" mechanism, right?

My experience is that once something is mandatory in a spec., it can get very wedged; people say (reasonably) it has to remain mandatory to ensure interop with the established base.  Part of my concern is that it may lock almost everyone into a state of perpetual unhappiness.

For example, it took many years to get 3GPP to move H.263 from mandatory to only recommended. :-(

This is, I admit, at odds with the “be agile” mood of the times.  YMMV.

best wishes of the season! sorry to be dismal.

David Singer
Manager, Software Standards, Apple Inc.

v2.23.0 | Report a Bug | By Email