Re: [rtcweb] Making both VP8 and H264 MTI

David Singer <singer@apple.com> Thu, 07 November 2013 06:04 UTC

Return-Path: <singer@apple.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE4F11E813A for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 22:04:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.178
X-Spam-Level:
X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_MEDS=0.842]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiEX8ws80EDb for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 22:04:08 -0800 (PST)
Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) by ietfa.amsl.com (Postfix) with ESMTP id 86A0411E8151 for <rtcweb@ietf.org>; Wed, 6 Nov 2013 22:04:07 -0800 (PST)
Received: from relay1.asia.apple.com ( [17.82.200.18]) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id E5.1C.21841.65D2B725; Thu, 7 Nov 2013 14:04:06 +0800 (MYT)
X-AuditID: 1152fe11-b7f256d000005551-01-527b2d565fd5
Received: from echium.asia.apple.com ( [17.82.200.52]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id F1.34.14371.65D2B725; Thu, 7 Nov 2013 14:04:06 +0800 (MYT)
Received: from [17.83.34.149] (unknown [17.83.34.149]) by echium.asia.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVV00EK7Q6TVJ10@echium.asia.apple.com> for rtcweb@ietf.org; Thu, 07 Nov 2013 14:04:06 +0800 (SGT)
Content-type: text/plain; charset=iso-8859-1
MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: David Singer <singer@apple.com>
In-reply-to: <CA+E6M0mrrj+hKgxkXyvsd+J1yLVV0WAtM_MsNP4qcFkd8F15hA@mail.gmail.com>
Date: Thu, 07 Nov 2013 15:04:06 +0900
Content-transfer-encoding: quoted-printable
Message-id: <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com>
References: <CE9E91B2.1BEAA%mzanaty@cisco.com> <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <E44893DD4E290745BB608EB23FDDB7620A108AAB@008-AM1MPN1-041.mgdnok.nokia.com> <CAMwTW+g+iHWCkoUonjYFi6OrSNcSQZX2X4GtKG5Ae4Ubzv0LtA@mail.gmail.com> <A869F270-C9B9-48EE-9A71-75BA9F2684EC@apple.com> <527A06EF.2070007@bbs.darktech.org> <527A0C4D.7020707@gmail.com> <527A15A3.2090006@bbs.darktech.org> <CA+E6M0mrrj+hKgxkXyvsd+J1yLVV0WAtM_MsNP4qcFkd8F15hA@mail.gmail.com>
To: Mohammed Raad <mohammedsraad@raadtech.com>
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUiGHRCSDdMtzrIYFarpsXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeDxVvKBdvGLumhbWBsZ9Ql2MnBwSAiYSh488ZoawxSQu3FvP 1sXIxSEksJtR4vP0NWwwRc/2wyR6mCT6Dy1ggXCWMkm82dwM1s4soCPR+/0bmM0roCexc+82 VhBbWMBI4s7GFkYQm01AVeLBnGNgNqdAsETHtNPsIDYLUHxZy2lGiDnCEt8f32OBsLUlnry7 wAox00bi4LpTrBCL/zNLzD53CKxIBGjZ1bfboU6VlTh97jkLhP2SVeLwQosJjMKzkNw3C8l9 s5DsWMDIvIpRPDcxM0c3M89QL7E4M1EvsaAgJ1UvOT93EyM4pP8J7mCcutDwEKMAB6MSD69n UnGQEGtiWXFl7iFGCQ5mJRHee8+qgoR4UxIrq1KL8uOLSnNSiw8xSnOwKInz/v5bHiQkkJ5Y kpqdmlqQWgSTZeLglGpgdOWZvuzg6wfx86Zz5HzsMZ3lL8nyL6D3m5bd++drma/OXPCSIfVW dM+iurCrxmezl5or7yhrmW97RP5y07/jK07lsv1MFvzcf8l5x8wLH/X36WidEb9vK1g/Me5m 0eyFsTuuTU4KPaHRanBkzt0/nJcdBLucnZfwBDy/0LPy+aKND0Wu1nWse6jEUpyRaKjFXFSc CAD/pzpxZQIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUiGHTCRDdMtzrI4GCzmsXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeDxVvKBdvGLumhbWBsZ9Ql2MnBwSAiYSz/avZ4OwxSQu3AOx uTiEBHqYJPoPLWCBcJYySbzZ3MwMUsUsoCPR+/0bmM0roCexc+82VhBbWMBI4s7GFkYQm01A VeLBnGNgNqdAsETHtNPsIDYLUHxZy2lGiDnCEt8f32OBsLUlnry7wAox00bi4LpTrBCL/zNL zD53CKxIBGjZ1bfboU6VlTh97jnLBEaBWUhumoXkpllI5i5gZF7FKFqUmpNYaaiXWJyZqJdY UJCTqpecn7uJERKEQjsYP+43OMQowMGoxMN7/UFRkBBrYllxZe4hRgkOZiUR3nvPqoKEeFMS K6tSi/Lji0pzUosPMUpzsCiJ88r+Kw8SEkhPLEnNTk0tSC2CyTJxcEo1MNo0zTu6qvvA7qDI 9Um1c55m5WqZrfsgFu13rEVox1lm6e6GsOQO5p8hT1787X/wfOOpFwIs94Pl+NzLfE3XmmQI LPNgmiz18vyJ7klfXVjOrk5luxmwOm3LvJdiGfdX3hSqZterb67YUvMppsKh/ClDV/GMpa5b bLYwhnI0skaf3npo5ce2mUosxRmJhlrMRcWJAE0+htw+AgAA
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Making both VP8 and H264 MTI
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 07 Nov 2013 06:04:13 -0000

On Nov 7, 2013, at 5:33 , Mohammed Raad <mohammedsraad@raadtech.com> wrote:

> Hi,
> 
> There isn't much new in the arguments for and against VP8 vs H.264. Its clear that there are concerns that are beyond how well each codec performs and whether or not it is free. Although I recognize that the transcoding option does not address the P2P use case, I do think that the goal of interoperability can be better achieved through a two phase approach. The first is enabling end-points to inter-operate through the availability of transcoding from the service provider. The second is to make one of the codecs the defacto MTI because of the its higher level of adoption. Yes, we may never get to a single MTI if we follow this path but at least we will have endpoints inter-operating. Besides, there are multiple other difficulties in getting seamless P2P communications working all the time, so I would suggest focusing on the service provider centered use case first.

You know, you're right.  

We could suggest or even recommend both, and mandate you must implement at least one of the two. That would identify precisely two interoperability points in an otherwise much larger space, at least, and make it fairly simple for those that can and wish to, to offer transcoding, since the two ends are now defined.  It's not ideal, but it might be better than saying nothing at all.


> 
> BR,
> Mohammed
> 
> 
> On Wed, Nov 6, 2013 at 9:10 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
> On 06/11/2013 4:30 AM, Daniel-Constantin Mierla wrote:
> As it stands today, there are well known IPR issues with h264. Cisco's move doesn't lift them.
> 
> So why to choose it if falls under the rules to remove it?
> 
> 
>     No one says it has to be H.264 and VP8. It could be H.261 and VP8.
> 
> 
> With both on board, I still expect the majority of the apps will implement only the most convenient for them, eventually expecting the other to have both. Then responsibility is getting divided, like "it's not _only_ my fault", blaming the other end point as well. 
> 
>     That is a reasonable concern, and one that we need to address. Implementations that violate these rules will make it harder for us to replace older MTI codecs without breaking backwards compatibility.
> 
> Gili
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> 
> -- 
> Mohammed Raad, PhD.
> Partner
> RAADTECH CONSULTING
> P.O. Box 113
> Warrawong
> NSW 2502 Australia
> Phone: +61 414451478
> Email: mohammedsraad@raadtech.com
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

David Singer
Multimedia and Software Standards, Apple Inc.