Re: [rtcweb] Proposed Video Selection Process

Silvia Pfeiffer <> Fri, 22 November 2013 16:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EF62D1ADEA1 for <>; Fri, 22 Nov 2013 08:24:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SjZLpF8m13Z2 for <>; Fri, 22 Nov 2013 08:24:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::234]) by (Postfix) with ESMTP id 6EDFC1ADBE5 for <>; Fri, 22 Nov 2013 08:24:23 -0800 (PST)
Received: by with SMTP id wo20so1530074obc.11 for <>; Fri, 22 Nov 2013 08:24:16 -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=2CyxzvWf3QuOXwGDz2OihVdr4kS3M+iH1zzQBjMFouo=; b=ZX8qnkfQ6bE7Ck3xt6zMJbkRpotddhg2Gq78YJxRJ4rST8qcH+bs4oGTGAozk8gWKl 45Lye/E6VJS4jBn8lTBtTf91azNYs3SVlwha/PMfOvbaMGJtLch4wMOtTzThJGHonMRT W1//kkcFsakK1ywjjhJa9Y1KU3oPU2GVcmFr0L1ZRq+nMGGsH/iDQt1Wz+ClrNi/kFeg SkgdC9EFgRF21X5t4cGoOYtqPzip7JDeiVp6ep4r9WBvfkaMvTw5yORhIbuUYmduFdCf 7eLUkJN0qp/eh4TLVi2vlbd0BoVQfEVAlFei2ur0qNYlBHCIIRopPMXInY5eUM7a5J/K 9KKw==
MIME-Version: 1.0
X-Received: by with SMTP id co2mr275794oec.85.1385137456217; Fri, 22 Nov 2013 08:24:16 -0800 (PST)
Received: by with HTTP; Fri, 22 Nov 2013 08:24:15 -0800 (PST)
Received: by with HTTP; Fri, 22 Nov 2013 08:24:15 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Fri, 22 Nov 2013 08:24:15 -0800
Message-ID: <>
From: Silvia Pfeiffer <>
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= <>
Content-Type: multipart/alternative; boundary=047d7bd6b03a0b0b6a04ebc67200
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:24:28 -0000

I think this has value. It might bring apple and Microsoft to the table,
since decoding-only is often the less patent-affecting part.

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