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

Iñaki Baz Castillo <ibc@aliax.net> Fri, 12 December 2014 16:33 UTC

Return-Path: <ibc@aliax.net>
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 34F251ACEB0 for <rtcweb@ietfa.amsl.com>; Fri, 12 Dec 2014 08:33:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
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 avqo_5mb3rkn for <rtcweb@ietfa.amsl.com>; Fri, 12 Dec 2014 08:33:05 -0800 (PST)
Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537781ACE61 for <rtcweb@ietf.org>; Fri, 12 Dec 2014 08:33:05 -0800 (PST)
Received: by mail-qg0-f41.google.com with SMTP id j5so5736443qga.28 for <rtcweb@ietf.org>; Fri, 12 Dec 2014 08:33:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Xv0eKLDbUPJNaQv6pJ871sil6mZSlR6ybWGecVGOsNY=; b=lSFsytVeQkkEVZ+qPVnHevz4e2n2RRyzscMmNouqFXJXThkutLTKz+fYwiHwfUGjsC p0MDu8F3anK7Jb3kyGoPLaNd2EvY0BzSw8csI9a8PGfBGS4Msdo/o3dyLedLhGQmGWRT 7u0N3TXD6JYlos+qMlCFzXBh/AFnMjRn8m13UQ7HOioK8qX5fn3Bq5ED0O8WdqAIESF4 jo+ta4fRq3P+DM0bbutH6hjRYd/Ye1N78alhCueaLyQmb3MCxzUHlub8JgUzD1YjlSL3 ROMG2Vs/D7H03f6xCmGLIRXNPJahBpEfNiI4Cqw6xE2w2SmRdJ+hj9gGvO3Tw9Wyh7ef 6bdw==
X-Gm-Message-State: ALoCoQn5t39iLN5NsJeceieUXCgnZrGJ7mFm+pFjbsuVL3+6sRxJgaEJcI+i89ZQF3Dpw7jG44eo
X-Received: by 10.224.65.134 with SMTP id j6mr32232103qai.90.1418401984356; Fri, 12 Dec 2014 08:33:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.96.26.135 with HTTP; Fri, 12 Dec 2014 08:32:44 -0800 (PST)
In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <D0AB64D8.3FA7A%mzanaty@cisco.com> <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Fri, 12 Dec 2014 17:32:44 +0100
Message-ID: <CALiegfnyNTB=C49BDefraYyJNu6AmewV=SK7Hw4aH7oWP2s4BA@mail.gmail.com>
To: Gaelle Martin-Cocher <gmartincocher@blackberry.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sMbMQ4MGxqnctKEJTmG2dus899I
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 16:33:07 -0000

2014-12-12 16:27 GMT+01:00 Gaelle Martin-Cocher <gmartincocher@blackberry.com>om>:
> 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. 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?


-- 
Iñaki Baz Castillo
<ibc@aliax.net>