Re: [rtcweb] Proposed Video Selection Process

Stefan Slivinski <> Thu, 21 November 2013 20:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B82011AE2AB for <>; Thu, 21 Nov 2013 12:06:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3mt45wKkL9W1 for <>; Thu, 21 Nov 2013 12:06:37 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id A77621AE289 for <>; Thu, 21 Nov 2013 12:06:37 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Thu, 21 Nov 2013 12:06:31 PST
Received: from ([fe80::edad:d9e3:99d1:8109]) by ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 14:02:38 -0600
From: Stefan Slivinski <>
To: "''" <>
Date: Thu, 21 Nov 2013 14:02:37 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7m88vU75kinTTXTl+N5uM4vUQpkQAANQn3
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 20:06:39 -0000

I in no way intended to suggest  a specific implementation of a video codec.  My question was around whether we are voting on requiring decoders (my assumption) or both encoders and decoders

----- Original Message -----
From: Basil Mohamed Gohar []
Sent: Thursday, November 21, 2013 01:56 PM
To: <>
Subject: Re: [rtcweb] Proposed Video Selection Process

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
rtcweb mailing list