Re: [rtcweb] Making both VP8 and H264 MTI

David Singer <> Fri, 08 November 2013 00:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30AB321E80E6 for <>; Thu, 7 Nov 2013 16:14:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.125
X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_MEDS=0.842]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6s24f8tkoPo4 for <>; Thu, 7 Nov 2013 16:14:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5A1C821E8169 for <>; Thu, 7 Nov 2013 16:14:24 -0800 (PST)
Received: from ( []) by (Apple Singapore Mail Gateway) with SMTP id 27.DA.03695.DDC2C725; Fri, 8 Nov 2013 08:14:21 +0800 (MYT)
X-AuditID: 1152fe06-b7f5a6d000000e6f-01-527c2cdd97aa
Received: from ( []) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by (Apple Singapore relay) with SMTP id D2.74.14371.DDC2C725; Fri, 8 Nov 2013 08:14:21 +0800 (MYT)
Received: from [] (unknown []) by (Oracle Communications Messaging Server 7u4-27.01( 64bit (built Aug 30 2012)) with ESMTPSA id <> for; Fri, 08 Nov 2013 08:14:21 +0800 (SGT)
Content-type: text/plain; charset=us-ascii
MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: David Singer <>
In-reply-to: <>
Date: Fri, 08 Nov 2013 09:14:20 +0900
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: cowwoc <>
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUiGHRCSPeuTk2QwYavKhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/ufPSwFO4Uqzm3ey9jAeJuvi5GTQ0LAROLmk0PsELaYxIV7 69m6GLk4hAR2M0p8uviYGaboyclZUInJTBKflj9hgnA2MUnc3LOPEaSKWUBLYv3O40wgNq+A nsTOvdtYQWxhASOJOxtbwGrYBFQlHsw5BmZzAtV8PnIdaAMHBwtQfG2jIcQYYYnvj++xQNja Ek/eXWCFGGkj8XfLN0aIvddYJPq+nAVLiAioSNw4dgvqBVmJ0+ees4AUSQh8ZJU4d7OPdQKj 8Cwk981Cct8sJEsWMDKvYhTPTczM0c3MM9JLLM5M1EssKMhJ1UvOz93ECA7qf2w7GBe8NjzE KMDBqMTDO/ttUZAQa2JZcWXuIUYJDmYlEd5nijVBQrwpiZVVqUX58UWlOanFhxilOViUxHk/ u1QHCQmkJ5akZqemFqQWwWSZODilGhgXbPqepfcswzRQoEr16+Lea5NP2q5kyUoVU10p+HxO 2wp3pcpLfxa1CXvHTZeYO4ltf9tvIxPn7w6L7jMdzO1yS84NThNk1jv8Se3IZ1XW1NY1Z31P fMrRnd6hu9uV2/DnvLq9Z29Gb7ufY7vLr1hB+cgvxYN/XfkOv3dxFKme/VT1WKu9vq0SS3FG oqEWc1FxIgC6s6mwZgIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUiGHTCSveuTk2QwZXNihZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/ufPSwFO4Uqzm3ey9jAeJuvi5GTQ0LAROLJyVlsELaYxIV7 64FsLg4hgclMEp+WP2GCcDYxSdzcs48RpIpZQEti/c7jTCA2r4CexM6921hBbGEBI4k7G1vA atgEVCUezDkGZnMC1Xw+cp25i5GDgwUovrbREGKMsMT3x/dYIGxtiSfvLrBCjLSR+LvlGyPE 3mssEn1fzoIlRARUJG4cu8UOcamsxOlzz1kmMArMQnLSLCQnzUIydwEj8ypG0aLUnMRKQ73E 4sxEvcSCgpxUveT83E2MkCAU2sH4cb/BIUYBDkYlHt7rD4qChFgTy4orcw8xSnAwK4nwPlOs CRLiTUmsrEotyo8vKs1JLT7EKM3BoiTOa+dRHSQkkJ5YkpqdmlqQWgSTZeLglGpgXPzh9/zq EzrvIg7f9bO8oRTNcThjhpV78IoljEd71ngsUWFmYSi+8HZHWt762fUeWvoHuCd8d571xTmw 3yXx5fmIvQee/as4XHSdvfvpy0+sm96dUdnUOSuyfUXW0rOyLwslS8N5BKNU1+zQZVy37NHM usAoV+YWrk/siwVFjmbXp07fLzv7rhJLcUaioRZzUXEiAEuPXjc+AgAA
Subject: Re: [rtcweb] Making both VP8 and H264 MTI
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Nov 2013 00:14:36 -0000

On Nov 7, 2013, at 23:56 , cowwoc <> wrote:

> On 07/11/2013 1:04 AM, David Singer wrote:
>> On Nov 7, 2013, at 5:33 , Mohammed Raad <> 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.
>    I can't believe you guys are actually trying to convince us that being forced to use a transcoder is actually a *good* thing! Any solution that does not address the P2P use-case is a non-starter. Feel free to use this model in your own deployments, just don't force it on us.

For a start, not everyone would have to transcode, only those cases where there the two ends implement only one, and different, codecs.  Secondly, I didn't say it was ideal, I I said it was better than saying nothing.  Third, if you implement both, you would never need to use a transcoder for this reason, but you nonetheless might use a bridge or intermediary for a whole host of other reasons.

David Singer
Multimedia and Software Standards, Apple Inc.