Re: [rtcweb] Proposed Video Selection Process

tim panton <> Fri, 22 November 2013 16:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3A8DF1ADF72 for <>; Fri, 22 Nov 2013 08:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OSkQW1fP6OUX for <>; Fri, 22 Nov 2013 08:40:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8BC8C1ADBE5 for <>; Fri, 22 Nov 2013 08:40:56 -0800 (PST)
Received: (qmail 28962 invoked from network); 22 Nov 2013 16:40:48 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 10136
Received: from unknown (HELO ( by with SMTP; 22 Nov 2013 16:40:48 -0000
Received: from (localhost []) by (Postfix) with ESMTP id 2243218A036D; Fri, 22 Nov 2013 16:40:48 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id B47BA18A05C2; Fri, 22 Nov 2013 16:40:46 +0000 (GMT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_71F1EABD-1B6F-4BAC-ACAC-C3AA988DF887"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: tim panton <>
In-Reply-To: <>
Date: Fri, 22 Nov 2013 08:40:48 -0800
Message-Id: <>
References: <> <> <>
To: Silvia Pfeiffer <>
X-Mailer: Apple Mail (2.1822)
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: Fri, 22 Nov 2013 16:41:00 -0000

Surely this flies in the face of the whole O/A model, which imposes a sort of symmetry on the endpoints ?
(Unless there is some arcane SDP FRACK at play here).


On 22 Nov 2013, at 08:24, Silvia Pfeiffer <> wrote:

> I think this has value. It might bring apple and Microsoft to the table, since decoding-only is often the less patent-affecting part.
> Silvia.
> On 22 Nov 2013 02:24, Martin J. Dürst <> wrote:
> On 2013/11/22 5:02, 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
> My understanding is that all the proposals in each instance mean "both encoder and decoder". So as an example, a proposal of "MUST implement both VP8 and H.264" means "MUST implement both VP8 encoder and decoder, and H.264 encoder and decoder".
> Your question brings up other choices. For example, interoperability would be satisfied by something like "MUST implement both VP8 and H.264 decoders, and MUST implement at least one of VP8 and H.264 encoders".
> One condition for this to work is the possibility of asymmetric communication, i.e. if side A implemented only a VP8 encoder, and side B only implemented a H.264 encoder, then traffic A->B would be VP8, whereas traffic B->A would be H.264. I don't know the in's and out's of the negotiation and protocol machinery to confirm or deny that this is possible.
> Choices like the one above definitely open new horizons for Eric's selection generator. But frankly speaking, except for the specific choice of "MUST implement both VP8 and H.264 decoders, and MUST implement at least one of VP8 and H.264 encoders", which is less onerous than "MUST implement both VP8 and H.264", but still interoperable, I don't see any choices with different requirements for encoders and decoders that would make sense.
> Regards,   Martin.
> ----- 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.
> _______________________________________________
> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list