IETF Logo Mail Archive

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

Gaelle Martin-Cocher <gmartincocher@blackberry.com> Fri, 12 December 2014 16:48 UTC

Return-Path: <gmartincocher@blackberry.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 9D38B1ACEF3 for <rtcweb@ietfa.amsl.com>; Fri, 12 Dec 2014 08:48:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level:
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 EhUArkjsq5OK for <rtcweb@ietfa.amsl.com>; Fri, 12 Dec 2014 08:48:07 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 8C59C1ACEE6 for <rtcweb@ietf.org>; Fri, 12 Dec 2014 08:48:07 -0800 (PST)
Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Dec 2014 11:48:02 -0500
Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0210.002; Fri, 12 Dec 2014 11:48:01 -0500
From: Gaelle Martin-Cocher <gmartincocher@blackberry.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Thread-Topic: [rtcweb] confirming sense of the room: mti codec
Thread-Index: AQHQEJCKBITgiQUj50CzzuygMU2TV5yGgaCAgAWZ93CAAGmcAP//r21g
Date: Fri, 12 Dec 2014 16:48:01 +0000
Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF3604E9@XMB111CNC.rim.net>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <D0AB64D8.3FA7A%mzanaty@cisco.com> <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net> <CALiegfnyNTB=C49BDefraYyJNu6AmewV=SK7Hw4aH7oWP2s4BA@mail.gmail.com>
In-Reply-To: <CALiegfnyNTB=C49BDefraYyJNu6AmewV=SK7Hw4aH7oWP2s4BA@mail.gmail.com>
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.250]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VHLZra5g9GxSplfWyt6y0zLiZBk
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:48:08 -0000

This is not at all what I implied.
I believe we will need new codecs in the future, say one that provide more compressions.
Will that have to be mandatory or recommended is TBD.

At the same time, if we have a new codec we need to ensure legacy systems will continue to work. 
This is the reason I do not agree with the note under webrtc-compatible endpoint which only take in account RF aspects.
I have proposed that the notes take RF aspects for VP8 and takes legacy aspects for H.264 as these are the arguments put forward by respective proponents.

Gaëlle


-----Original Message-----
From: Iñaki Baz Castillo [mailto:ibc@aliax.net] 
Sent: Friday, December 12, 2014 11:33 AM
To: Gaelle Martin-Cocher
Cc: Mo Zanaty (mzanaty); rtcweb@ietf.org
Subject: Re: [rtcweb] confirming sense of the room: mti codec

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. 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>

v2.23.0 | Report a Bug | By Email