Re: [rtcweb] Proposed Video Selection Process Fri, 22 November 2013 16:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E68E31AE1F3 for <>; Fri, 22 Nov 2013 08:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t4IjTqToe_7Z for <>; Fri, 22 Nov 2013 08:48:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c02::230]) by (Postfix) with ESMTP id B6E1D1AE3EE for <>; Fri, 22 Nov 2013 08:48:02 -0800 (PST)
Received: by with SMTP id x16so1034303vbf.35 for <>; Fri, 22 Nov 2013 08:47:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EktRLO48LXaF5Xlk1hbouysJ+fqB0JRgTo4rhRr+u1I=; b=DhstUYQxwIsHF1Vi3+rGGdxbkRVgZF8g/uN0xkD4pVE0vzPISlqeZ9ZgRYvoaX0+zc gl9XtaPRdlmJf3DCkuElXvs78stjJyvb8Cy99eR4tPp39KyXjflOyXq+kG/wDr5DcliJ 4sZYtBtQsRR7x8osNLogJ33PcCu/5qAMHyTTbvyQ85ZHZXvqrOtoCcTkQckr6mASrgXe bgEtdnICV8BOSxMArZmpFLqONIxOw/KTmLaaJlH4/xQvu6h7FjJCxFjfld4T4tz1/uuA 4sPvzqjnS+XTQmZLCDk+r06g8nKQlpSyIO4AjJA88B2IqyQa0RFMsOGEXZWpfR1UTSmv WKgA==
MIME-Version: 1.0
X-Received: by with SMTP id xk2mr10218764vdb.24.1385138875508; Fri, 22 Nov 2013 08:47:55 -0800 (PST)
Received: by with HTTP; Fri, 22 Nov 2013 08:47:55 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 22 Nov 2013 08:47:55 -0800
Message-ID: <>
To: tim panton <>
Content-Type: multipart/alternative; boundary=089e0160caaea3bbe104ebc6c660
Cc: "" <>
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:48:23 -0000

SDP can express sendonly and recvonly streams, so there is no inherent
problem with assymetry of codec choice.  But it would certainly complicate

I would be in favor of a solution that allowed anyone (all browsers) to
decode both VP8 and h.264, no matter what they are capable of encoding.  In
my 1-to-many conference software, all streams are unidirectional.

On Fri, Nov 22, 2013 at 8:40 AM, tim panton <> wrote:

> 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).
> T.
> 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
> _______________________________________________
> rtcweb mailing list