Re: [rtcweb] Proposed Video Selection Process

Stefan Slivinski <sslivinski@lifesize.com> Thu, 21 November 2013 20:06 UTC

Return-Path: <sslivinski@lifesize.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82011AE2AB for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 12:06:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mt45wKkL9W1 for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 12:06:37 -0800 (PST)
Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id A77621AE289 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 12:06:37 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUo5nxw6kT2AXCrJ5a2x6QtVB+ktsvGjT@postini.com; Thu, 21 Nov 2013 12:06:31 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 14:02:38 -0600
From: Stefan Slivinski <sslivinski@lifesize.com>
To: "'rtcweb@ietf.org'" <rtcweb@ietf.org>
Date: Thu, 21 Nov 2013 14:02:37 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7m88vU75kinTTXTl+N5uM4vUQpkQAANQn3
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <528E656F.2070404@librevideo.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 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 [mailto:basilgohar@librevideo.org]
Sent: Thursday, November 21, 2013 01:56 PM
To: rtcweb@ietf.org <rtcweb@ietf.org>;
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
http://librevideo.org
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb