Re: [rtcweb] Video codec selection: Dropping options

Magnus Westerlund <> Thu, 28 November 2013 14:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 432161AE13E for <>; Thu, 28 Nov 2013 06:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uD0XxHdTQG8r for <>; Thu, 28 Nov 2013 06:43:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9FD791AE103 for <>; Thu, 28 Nov 2013 06:43:27 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-3b-5297568df30e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 95.3E.03802.D8657925; Thu, 28 Nov 2013 15:43:25 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.328.9; Thu, 28 Nov 2013 15:43:25 +0100
Message-ID: <>
Date: Thu, 28 Nov 2013 15:43:25 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3VrcvbHqQwe6lLBbn/y5is1j7r53d gcljyZKfTB53b11iCmCK4rJJSc3JLEst0rdL4MrY3rGKpeC5dMXOB6wNjMvEuhg5OSQETCRe nd7KDGGLSVy4t56ti5GLQ0jgEKPEkSdvmCCc5YwS/x8+ZwGp4hXQlljbcpIJxGYRUJXYfnEb WJxNwELi5o9GNhBbVCBY4mrvOmaIekGJkzOfgNWICBhKbOiaxw5iCwvYSrxb+RXI5gBaEC7x Z6YVSJhTIEJi+rHDbCBhCQFxiZ7GIJAws4CexJSrLYwQtrxE89bZYNOFgK5paOpgncAoOAvJ sllIWmYhaVnAyLyKkT03MTMnvdxoEyMwHA9u+a26g/HOOZFDjNIcLErivB/eOgcJCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYFx0IPwR6/+QeK/w/vU9X3TCLzLMYRPYs/t8CFers+ZNaysR 4bI5Ho4H5A5ufs8dPGvxtJZDP1MTbthIpu2v/TwxsGLHtqACt/yYDc5Fnd/qPy1cOfnNCXlf UykR+VXXj3wPfvWyo3WtXo6WltKyg3f6Pz1avC7zgcjf9ykztqf7LI3csd1oTpcSS3FGoqEW c1FxIgAtn9oPFQIAAA==
Subject: Re: [rtcweb] Video codec selection: Dropping options
X-Mailman-Version: 2.1.15
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: Thu, 28 Nov 2013 14:43:30 -0000


I would note that I consider this suggestion highly problematic at this
time. Especially considering the process we have proposed for selecting
a winning alternative. The issue is that we had an open call for
proposals to be considered. To be able to exclude options I see a need
for both a process and consensus to use this process to eliminate options.

I hope you see the problem with eliminating alternatives by any form of
chair decision at this time. Thus we would be forced to run different
sets of consensus calls to determine if there are consensus to eliminate
as well as which.

Thus, I would consider your comment as, the process we chairs are
proposing is the wrong one.



On 2013-11-28 09:22, wrote:
> Hi,
> I'm not much in favor of the voting, but if we do it:
> Based on the consensus call we already held in Vancouver, I would propose to drop from the list in [1] any options that make exclusively VP8 mandatory to implement or exclusively H.264 mandatory to implement. I think we have already established that much, and including those options in any vote seems wrong. 
> In practice I'm talking about these four options:
> 1. All entities MUST support H.264
> 2. All entities MUST support VP8
> 3. All entities MUST support both H.264 and VP8 
> 4. Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8
> What the WG should focus on is to see if there is a consensus on any of the so called "fallback" options vs. no MTI. I think these are all valid as such as a "fallback":
> 5. All entities MUST support at least one of H.264 and VP8
> 6. All entities MUST support H.261
> 7. There is no MTI video codec
> 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8
> 9. All entities MUST support Theora
> 10. All entities MUST implement at least two of {VP8, H.264, H.261}
> 11. All entities MUST implement at least two of {VP8, H.264, H.263}
> 12. All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8
> 13. All entities MUST support H.263
> 14. All entities MUST implement at least two of {VP8, H.264 CBP, Theora}
> 15. All entities MUST support decoding using Theora.
> I think it would be problematic even if one of options 1-4 came out as a winner from a voting procedure, since it would force a large part of the community to implement something they have valid reasons to avoid. Some of the options 5-15 may have issues as well, but at least a consensus call among them would still be in order, since we haven't really had it so far. And presumably the issues and polarization are "smaller" than with the VP8 vs. H.264 argument. 
> Regards,
> 	Markus
> [1]
> _______________________________________________
> rtcweb mailing list


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: