Re: [rtcweb] Proposed Video Selection Process

Basil Mohamed Gohar <> Thu, 21 November 2013 19:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 123511AE1BC for <>; Thu, 21 Nov 2013 11:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4AQ0PyrZnSbq for <>; Thu, 21 Nov 2013 11:56:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E49BF1AE17E for <>; Thu, 21 Nov 2013 11:56:40 -0800 (PST)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id E963B659765 for <>; Thu, 21 Nov 2013 14:56:33 -0500 (EST)
Message-ID: <>
Date: Thu, 21 Nov 2013 14:56:31 -0500
From: Basil Mohamed Gohar <>
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
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, 21 Nov 2013 19:56:42 -0000

On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
> I'm a new comer, so just a brief intro: I have a background developing real time video codecs for embedded devices so I'm in a position to comment at a technical level within this group
> For clarity purposes the proposed alternatives in Magnus' email on nov 18th; are we strictly speaking about decoders?  Historically mandatory requirements are they relate to video compatibility define just the decoders.  Obviously if there is only a single mandatory video decoder this implies a mandatory encoder, however in the case where there are 2 mandatory decoders only a single encoder is technically required.
> Clarifying this is fairly important because in the case of both h264 and vp8 (and in the future vp9 and h265) the decoder complexity is fairly low and hardware acceleration is not critical but in the case of the encoders where the complexity can be 3x or worse, hardware acceleration becomes increasingly important
> Stefan

What is being specified as MTI is a format, and not a specific
implementation.  So, MTI will not take the form of "OpenH264" or
"libvpx", but rather, "H.264 Constrainted Baseline Profile" or "VP8".

The same was done for the MTI audio codec, which is Opus, not *libopus*,
which is one specific implementation of the codec.

There was a suggestion that the WG also offer a reference implementation
of the MTI codec choice, but that seems like it won't happen, nor is it
really the purpose of the WG to do so.  We are picking from
already-existing and implemented formats in the first place.

Libre Video