IETF Logo Mail Archive

Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Bernard Aboba <bernard.aboba@gmail.com> Thu, 04 December 2014 03:22 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 A571E1A002F for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 19:22:43 -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 RxOpolo3pJcg for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 19:22:41 -0800 (PST)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8C81A000D for <rtcweb@ietf.org>; Wed, 3 Dec 2014 19:22:41 -0800 (PST)
Received: by mail-pd0-f175.google.com with SMTP id y10so16707110pdj.6 for <rtcweb@ietf.org>; Wed, 03 Dec 2014 19:22:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z5/Of2iW1K7NMO4sVdf9LDwRSDBGp5jQOrFaaCSvDU0=; b=JOnMv8Z3uJE3Femcaixfc8EjPRSXDmX5DtFTbR7fDGsjfNIKPP4oFgzu1Jr4Vfl4y4 okvtaaW7yKKpm8YJOnfvKdNbv1vCtlYFy5yagkvnXS34yf+AhuH+I8z4VtaQfBvmc5de Lzh3zRaTtV3y5JfczxkTRu4s1l+xGFi8WlbwiX5KfHycOVmjIzYya/v94FY9xmUVk6CC vpD2TN38Hb6SiNzT1CY6Qk9IIngzq3RnNaQfSGDFnx4cvGlaY2s80ecJRqV29u+VtMU/ acRpWQ8OmHXZA/W9oNF4b8B1/NtBHkHOVwdlBqhNTkGZOf/cAo7xNaQ79JB6KD8qLnDz jHNw==
X-Received: by 10.68.190.229 with SMTP id gt5mr21294342pbc.119.1417663360894; Wed, 03 Dec 2014 19:22:40 -0800 (PST)
Received: from [10.239.43.196] ([216.133.128.238]) by mx.google.com with ESMTPSA id ny9sm24537382pab.25.2014.12.03.19.22.39 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 19:22:39 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: iPad Mail (12B435)
In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net>
Date: Wed, 03 Dec 2014 19:22:36 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <70F7E827-EA9F-427D-8EDE-2FB9ADC93752@gmail.com>
References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net>
To: Gaelle Martin-Cocher <gmartincocher@blackberry.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gkP1GHqGPymTJqPx_MUg_3aOZRc
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
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: Thu, 04 Dec 2014 03:22:43 -0000

On Dec 3, 2014, at 3:32 PM, Gaelle Martin-Cocher <gmartincocher@blackberry.com> wrote:
> 
> a) How can the group composed by a vast majority of non-browser vendors force a decision on browser vendors against their statements? 

[BA]  The basic gist is "don't dual MTI him, don't dual MTI me, dual MTI the fellow behind the tree".  No mobile application or device maker will pay attention to the dual MTI requirement, nor should they - it adds overhead and potential liability/fees with little benefit.  For codec implementers, the timing couldn't be worse - with next generation codecs now appearing in products (e.g. H.265 and VP9), making an argument for diverting resources away into work on previous generation codecs is difficult at best.

There is a difference between suggesting a compromise that many people dislike but can live with versus one that is only palatable if it applies to someone else.

v2.23.0 | Report a Bug | By Email