Re: [rtcweb] MTI Video Codec: a novel proposal

Harald Alvestrand <> Tue, 11 November 2014 01:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E86931AD3C1 for <>; Mon, 10 Nov 2014 17:45:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AGf4Ee5V2IO5 for <>; Mon, 10 Nov 2014 17:45:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2E4201A1A4D for <>; Mon, 10 Nov 2014 17:45:40 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 712737C0536 for <>; Tue, 11 Nov 2014 02:45:39 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VqY6NOctFf7q for <>; Tue, 11 Nov 2014 02:45:38 +0100 (CET)
Received: from [IPv6:2001:67c:370:168:4805:b828:f652:a1bd] ( [IPv6:2001:67c:370:168:4805:b828:f652:a1bd]) by (Postfix) with ESMTPSA id 245EF7C00DD for <>; Tue, 11 Nov 2014 02:45:37 +0100 (CET)
Message-ID: <>
Date: Mon, 10 Nov 2014 17:45:31 -0800
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
References: <> <> <> <20141111011054.GR8092@hex.shelbyville.oz> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal
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: Tue, 11 Nov 2014 01:45:43 -0000

On 11/10/2014 05:20 PM, David Singer wrote:
> On Nov 10, 2014, at 17:10 , Ron <> wrote:
>> His option guarantees that anyone implementing only their preferred
>> codec will be able to interop with any compliant implementation,
>> though it may not be able to do so with another non-compliant
>> implementation that similarly opted out of supporting that codec.
> I am sorry, I don’t get it.  The spec. defines “WebRTC-compatible endpoint”
> A WebRTC-compatible endpoint is an endpoint that is capable of
>       successfully communicating with a WebRTC endpoint, but may fail to
>       meet some requirements of a WebRTC endpoint.  This may limit where
>       in the network such an endpoint can be attached, or may limit the
>       security guarantees that it offers to others.
> but says nothing about it being ‘non-compliant’.  So anyone can say “I claim that this is compliant to the spec.” (as a webrtc-compatible endpoint) — and it might not interoperate. Basically, this proposal assigns different names to the devices that implement both, and those that implement only one or none, but does that really further the cause of interoperability?
Video codecs weren't part of the discussion when we introduced those terms.

The obvious examples were ICE-Lite for gateways that reside at public IP
addresses, and datachannel and video for POTS telephone gateways - and
yes, also OPUS codecs for POTS gateways. (those that have *only* g.711
on the other side - there are better codecs in that environment too,
where bridging to OPUS may make sense.)

The theory is that those devices will exist and do what they will do no
matter what we specify here, so we might as well

We'll go through terminology in an hour or so in the meeting.

> David Singer
> Manager, Software Standards, Apple Inc.
> _______________________________________________
> rtcweb mailing list

Surveillance is pervasive. Go Dark.