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

"Mo Zanaty (mzanaty)" <> Fri, 12 December 2014 17:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BD2831ACEC2 for <>; Fri, 12 Dec 2014 09:54:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qEojZ8SEUoED for <>; Fri, 12 Dec 2014 09:54:41 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB8B41A7029 for <>; Fri, 12 Dec 2014 09:54:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3040; q=dns/txt; s=iport; t=1418406881; x=1419616481; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LGHTLrvqJ4Bo1LJ5IlUjhcpocKCSA9Y4TYJtzMozQ1c=; b=GZOH0SWYh7Koz0rNJ3e2cO2mk3/vdSZKCLzltWI6/aSdpL0Rw+xK4HG/ 1HO7ehq7MAALlZZXwn3gCh9Ux9L6ueS6VWkzOgft0Py7kYk3Z7w5cYjqa MTopoJamrn7cfud1Elm9RywBUDBhRFPdZRi1kNjbTio2GqvVEPDt5I9P3 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,565,1413244800"; d="scan'208";a="105239383"
Received: from ([]) by with ESMTP; 12 Dec 2014 17:54:40 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id sBCHseBg027730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Dec 2014 17:54:40 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 11:54:39 -0600
From: "Mo Zanaty (mzanaty)" <>
To: Gaelle Martin-Cocher <>, "" <>
Thread-Topic: [rtcweb] confirming sense of the room: mti codec
Thread-Index: AQHQFjSztNbhnJ5pX0SSlP6pLau9Tg==
Date: Fri, 12 Dec 2014 17:54:39 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] confirming sense of the room: mti codec
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Dec 2014 17:54:42 -0000

Agreed, from the viewpoint of specifications. But from the viewpoint of
implementations, there is often quite a difference between the level of
support when the spec says ³can² versus ³MUST².

Mandatory codec agility is even more important than specific mandatory
codecs, but it may take the latter to force the former.

My comment was not based on hypothetical concerns or foresight. It was
from direct experience trying to add H.264 into the codebase
and Mozilla¹s fork. The current support in Firefox barely meets the bar of
shippable, and support is not shippable at all. (I think your
Blackberry colleagues who also started down this path can corroborate
this.) There are still many holes, and lots of refactoring is still in
progress to have a truly robust multi-codec media engine where resilience
and other aspects are harmonized for all codecs. The end result will be a
platform that can more easily and rapidly handle VP9, H.265, Daala, netvc,
etc. without lots of additional refactoring or gaps in functionality
across codecs. It does require extra effort, but I see it as essential
investment that should not be deferred.

Actually implementing multiple codecs can also reveal gaps in specs. For
example, I strongly support your argument for decoding many formats even
if you can only encode one or a few. It is a good technical direction. But
try to implement it with current standards, and you will hit some walls.


On 12/12/14, 10:27 AM, Gaelle Martin-Cocher <>

Multiple codecs can be supported even if there is only a single MTI
defined in WebRTC. 
This has been confirmed by those who will implement scalable codecs.

I am not aware of anyone asking for removing the codec
negotiation/capability discovery even if there is a single MTI.
As such supporting multiple codecs is independent from the MTI discussion.
The question is not do we need multiple codecs but do we need multiple
MTIs (and which). 


-----Original Message-----
From: rtcweb [] On Behalf Of Mo Zanaty
Sent: Monday, December 08, 2014 3:42 PM
To: Sean Turner;
Subject: Re: [rtcweb] confirming sense of the room: mti codec

To reiterate another point from the meeting, there are technical
advantages to supporting multiple codecs. Dynamic discovery of local
capabilities, negotiation of remote capabilities, understanding how
different error resilience mechanisms can work (or not) with different
codecs, faster adoption of new (non-mandatory) codecs, easier path to
deprecating old (mandatory) codecs, etc. All those legs never get
exercised effectively in single-codec implementations, leaving land mines
in browsers, apps, services and sometimes even specs. They become easier
or free once the groundwork is laid for multiple codecs. While some have
argued against that extra complexity, I see it as essential for any
important standard.