IETF Logo Mail Archive

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

Bernard Aboba <bernard.aboba@gmail.com> Tue, 11 November 2014 03:19 UTC

Return-Path: <bernard.aboba@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 7B1061AD44F for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 19:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 5lflgYW-fDvw for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 19:19:14 -0800 (PST)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E031A887C for <rtcweb@ietf.org>; Mon, 10 Nov 2014 19:19:14 -0800 (PST)
Received: by mail-pa0-f47.google.com with SMTP id kx10so9671050pab.34 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 19:19:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=+mp2XlK6Mr/Zz3XtbKOy9SbpORvb3rNh9uEeuHY/T9c=; b=SvGUBstHYLiZ77kGBVh/w3HevjzuswL1mtznBFUA0Z8YDLl6b4cffhsqB/IzwCu/Oj kWR7jF34unWs0UjcsjuJUgaLDpSrhIs3qoiaFLseWbK+90XhrzJr9E23qfGhR0HwKmrx x7QnmERWKcnVXXDal2W/agudbSWTCM7+IWyKuMuUJ8p5gCbF8yG+f1pkhR2i+S1Pfm9+ srhCPFfZABBXm5lb+ry6iq6FMrVehletrBZr1jfB7M6SlykxC02GyaQwprhiNEvZXu/2 zKNX5YMqhOSatJPcEwiAnEPo61omswAG01XejnIoQv2YXx7LHBFmkam5UB9V2QALzzp/ nH9w==
X-Received: by 10.69.26.38 with SMTP id iv6mr8493578pbd.154.1415675954035; Mon, 10 Nov 2014 19:19:14 -0800 (PST)
Received: from [10.219.121.254] ([166.170.51.122]) by mx.google.com with ESMTPSA id oc2sm17735108pbb.90.2014.11.10.19.19.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 19:19:12 -0800 (PST)
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>
Mime-Version: 1.0 (1.0)
In-Reply-To: <E18B79D1-D8C8-4A17-A2F0-93BDAAFED698@apple.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE15C090-239F-45BC-8747-501AC86653B2@gmail.com>
X-Mailer: iPhone Mail (12B411)
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 10 Nov 2014 17:19:08 -1000
To: David Singer <singer@apple.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vNwPyXSLejhRhDmuw5usrfQJI0Y
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 03:19:16 -0000

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

v2.23.0 | Report a Bug | By Email