Re: [rtcweb] Proposed Video Selection Process

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 46E881AE2E6 for <>; Thu, 21 Nov 2013 12:32:24 -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 l2JzQaLlxoYc for <>; Thu, 21 Nov 2013 12:32:22 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 658E81AE291 for <>; Thu, 21 Nov 2013 12:32:22 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUo5tz8BR3e9VlsJmPL6G/; Thu, 21 Nov 2013 12:32:16 PST
Received: from ([fe80::edad:d9e3:99d1:8109]) by ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 14:28:37 -0600
From: Stefan Slivinski <>
To: "''" <>
Date: Thu, 21 Nov 2013 14:28:36 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7m9nH+O39+xfW2QtaUtKuNSDen8gAAc+Lt
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:32:24 -0000

So this is my concern.  On iOS for example it's pretty easy do decode large resolutions in software only using either h.264 or vp8 (and for that matter vp9 and h.265).  So making both h264 and vp8 decoders mandatory isn't a big technical problem.  The encoder however is a bigger issue.  A reasonably good implementation requires roughly 3x the compute to do this in software.  iOS however supports hardware encoding using H264 so there is an obvious advantage to using that specific codec on that device.  The same might be true for VP8 on other architectures.

So requiring all webrtc implementations to support H264 and VP8 gives the flexibility to pick the most appropriate encoder for a given architecture.

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

On 11/21/2013 03:02 PM, Stefan Slivinski wrote:
> 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

The discussions, up to this point, have been about choosing an MTI video
format so that rtcweb endpoints can communicate with one-another.  I am
not sure how this goal can be achieved without having an encoder and a
decoder on both ends, sharing at least one common format, whether it is
H.261, Theora, H.264, VP8, or something else.

Libre Video
rtcweb mailing list