Re: [rtcweb] Proposed Video Selection Process

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 22 November 2013 10:24 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 4401F1ACC86 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 02:24:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] 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 p4OPSwMOGczD for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 02:24:30 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 91D951AC829 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 02:24:30 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAMAOKHP015857; Fri, 22 Nov 2013 19:24:20 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 2091_0829_3fae9746_5360_11e3_a6e0_001e6722eec2; Fri, 22 Nov 2013 19:24:19 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 68810BF50F; Fri, 22 Nov 2013 19:24:19 +0900 (JST)
Message-ID: <528F30C1.8040208@it.aoyama.ac.jp>
Date: Fri, 22 Nov 2013 19:24:01 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Stefan Slivinski <sslivinski@lifesize.com>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "'rtcweb@ietf.org'" <rtcweb@ietf.org>
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: Fri, 22 Nov 2013 10:24:32 -0000

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 [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.
>