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

Alexandre GOUAILLARD <agouaillard@gmail.com> Tue, 11 November 2014 05:23 UTC

Return-Path: <agouaillard@gmail.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 DD42F1A8714 for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 21:23:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 UtOLWEHqmtM2 for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 21:23:17 -0800 (PST)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913EE1A6FE9 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 21:23:17 -0800 (PST)
Received: by mail-oi0-f54.google.com with SMTP id a141so6537004oig.13 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 21:23:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=pHezftruDGf7248S3tcQxUhHXJCHAEk3B1TGHGR6zj8=; b=hYrD9SkRXrLzBAZMU0jZDiGQ356Rxn9pHIJEPItKVXZ61gEszg1dQCNgUe7yyZL9SK gV/WzakevpltV2hwKyTh+KdajnFj+U6K6WQ0YgYcF1/1tW4p9xFwym1+1PwnHStFoHQm BTg0v+GZaTOlzG5ycs+fxlKrp6BB+BDjV59q/9Z8L40LApOoAxN535j594Q1Tc1b/fD1 DQc1V2rdROWLvzbSKKgxg5fk/u5oaIkDLsk/MGi2yqN+GzlW05TLuh6l7k1WUyWnZ9qu F/JhnqT+/hZFxSv+0vN/jmj+xd8qRk5bhM8uT0J79YKr4v+1O/VzS1GSMl2t4mLQYpvs BK9Q==
MIME-Version: 1.0
X-Received: by 10.60.173.39 with SMTP id bh7mr31321395oec.32.1415683396777; Mon, 10 Nov 2014 21:23:16 -0800 (PST)
Received: by 10.202.209.8 with HTTP; Mon, 10 Nov 2014 21:23:16 -0800 (PST)
In-Reply-To: <BE15C090-239F-45BC-8747-501AC86653B2@gmail.com>
References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> <E18B79D1-D8C8-4A17-A2F0-93BDAAFED698@apple.com> <BE15C090-239F-45BC-8747-501AC86653B2@gmail.com>
Date: Tue, 11 Nov 2014 13:23:16 +0800
Message-ID: <CAHgZEq6HYgwGYcaa6fJr69LM0pLVH+nz9G_fmuEUzCHa-dhW1g@mail.gmail.com>
From: Alexandre GOUAILLARD <agouaillard@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bd6ba9afabe1105078e79f8"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OEDJUMFA-vdspjrybNzzId87PsQ
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal
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: Tue, 11 Nov 2014 05:23:20 -0000

+1 for this proposal.

Thanks adam for doing the background work to bring some parties closer to a
consensus.

On Tue, Nov 11, 2014 at 11:19 AM, Bernard Aboba <bernard.aboba@gmail.com>
wrote:

> I do not get it either. It seems like mobile apps (which count as devices)
> using a WEBRTC stack now have to include both codecs regardless of whether
> they need them. Do we really think app developers will pay attention? Why
> should they?
>
>
>
> > On Nov 10, 2014, at 3:20 PM, David Singer <singer@apple.com> wrote:
> >
> >
> >> On Nov 10, 2014, at 17:10 , Ron <ron@debian.org> 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?
> >
> > David Singer
> > Manager, Software Standards, Apple Inc.
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -