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

Daniel-Constantin Mierla <miconda@gmail.com> Mon, 10 November 2014 16:51 UTC

Return-Path: <miconda@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 29B201A011E for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 08:51:21 -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 7Sj1y7sSUg_w for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 08:51:14 -0800 (PST)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BCE1A00A8 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 08:51:14 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id n3so11124273wiv.0 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 08:51:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6ejra7ClBn4xi8Nv4kGRDp+EgjyHA+zSAT8fUNqluyU=; b=rDdQ+Ek3jKi+doNjWu2M2MnyK6RCMFC2jngjXpOJiZMgpK/ctkDItKZGRQzflrq59Y 6ozlyFIprvHBTZXNBLtxO9ySL5BrTCwlkRt0nK5FrTfddIJVCjHkC1PHmMSQedGARjnW ZppiI4JU/+expEVQ476Nu1VvF0w7EdH5g+FfkJouYnT9fNMY4exhLenv290Zd92XYklH EqWp2peufp6z9G0zyyJT0Fk3Y8UeqY9Q7s69nK3H0cneeb0HXyv3YflOZ2YAa3LogsGe DPZEvxgT4ztnnJq3Jgz9mHJU/BccLtpjlcCTpsufa6U2kCzzw4dn3bkoEygF7f3U0FBm utew==
X-Received: by 10.194.52.3 with SMTP id p3mr45352804wjo.93.1415638273062; Mon, 10 Nov 2014 08:51:13 -0800 (PST)
Received: from [127.0.0.1] ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id s10sm14071619wix.14.2014.11.10.08.51.11 for <rtcweb@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Nov 2014 08:51:12 -0800 (PST)
Message-ID: <5460ECFE.4000900@gmail.com>
Date: Mon, 10 Nov 2014 17:51:10 +0100
From: Daniel-Constantin Mierla <miconda@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <54601E19.8080203@nostrum.com> <6689CD42-C046-45DE-9871-16538A799810@phonefromhere.com>
In-Reply-To: <6689CD42-C046-45DE-9871-16538A799810@phonefromhere.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mmR3pOq_zulpPDvh-vTmqMPc8kI
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: miconda@gmail.com
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: Mon, 10 Nov 2014 16:51:21 -0000

On 10/11/14 11:29, tim panton wrote:
> Adam, thanks for sticking you head above the parapet ! 
> I’m largely in favour of this solution, further, I think it represents the realities on the ground

It looks more like the reality on the ground of a few groups of
interests (e.g, GSMA, telco vendors) trying to protect themselves. But
again, in the web/internet world I don't see the same reality, they must
stay competitive with features, not with restrictions or barriers to
potential competitors.

If something costly or with other restrictions is technically better or
improving the user experience a lot in some medium of communication,
then the developer of some app can decide to use/implement it. There is
no reason of enforcing limits and financial constraints to everyone in
open web via specs supposed to become standard.

Rather than forcing now something inconvenient to be re-evaluated later
for removal, better don't force anything now and re-evaluate later for
inclusion. It will allow the market (besides the big players) to decide
freely where it wants to move. The current proposal looks like: let's
close the group now and later decide if we allow others in. Why not the
other way around, keep the market fully open for new comers now and see
what is going to be out there in few years, whether it makes sense to
start building the walls at that moment.

Daniel

>  better
> than any other proposal to date, as such it merits support.
>
> On 10 Nov 2014, at 02:08, Adam Roach <adam@nostrum.com>; wrote:
>
>> WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents. 
> I do have a slight qualm about the " ‘both’ or perhaps only ‘one’ “ language above. I think irrespective of new data, there will 
> always be devices who’s hardware or business model is best served by a specific codec, but that can meet every other requirement
> of a webRTC device.
>
> I feel the appropriate language here is ‘either’ , ensuring that every device can always interact with a user agent
> but that devices can’t necessarily communicate video between each other without a transcoding middle man.
>
> This leaves WebRTC-compatible endpoint as a category for things that implement neither video codec (e.g. audio only devices), or
> don’t implement the data channel because it isn’t relevant to their application domain or only implement SDES (etc) - This gives a 
> clearer separation.
>
> This language choice matters most for developers who are selecting a native library to use when building a webRTC device. They need to
> know what is supported -  'WebRTC-compatible’ means that they have to look very carefully at all the missing features, WebRTC-device
> says that it will work with any user agent. 
>
> With the current formulation there are no libraries that I know of suitable for building a webRTC device, making it an empty category.
>
> Tim.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda