Re: [rtcweb] Proposed Video Selection Process

Justin Uberti <juberti@google.com> Fri, 22 November 2013 17:04 UTC

Return-Path: <juberti@google.com>
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 811D21AE06F for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 09:04:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] 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 VtSVsdYl6TtQ for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 09:04:00 -0800 (PST)
Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0559A1ADFC6 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 09:03:59 -0800 (PST)
Received: by mail-ve0-f172.google.com with SMTP id jw12so1121305veb.3 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 09:03:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=csGZNeNa3QQ0+QYUPkapFnbMe9m7KGDkhxP1hKKQ4Ro=; b=Arhhb1DDTKbjPakuLlkYpdRdliG/c5DomqaqJ3fwjHFI8vKj15eStD9D2+isl91yHx puHHNo7uNZU0WqM6ItFjV3UCoH6Df3TDQOxfcRTFQF0Pa3l3vHRiLlBJ831LG0BVOuKf z0xFdLVo6z/qnpZu/9KSwH9vRHhpuZ+Bz/meZ7f30aUCbwFcqgWzf6w8leN5qSpoTar5 nRW6YhULzRc1iHh6rx11TeaseabcqNiNyWvIF4sTAHCIUXPvVoIQOWNHmUwR5m0S56OO SzlOfCHMCjerGfmNw26iqaRCJ6ynK3bd8NojLsU2k8L7ckqzXmfnKtJ6PMo3hyV6MYIt sjEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=csGZNeNa3QQ0+QYUPkapFnbMe9m7KGDkhxP1hKKQ4Ro=; b=cTCPOQS5WETq5BFIIy996QgAVfnYiTuytTFf60RB3TUWw2vKVRoy5RY4ZCcVdsHove O+v/VB7ptXI+M6qeaf5FLgIV4xLSp1bqQCM5Mjpr/eufAeOFFxS8QslaEkPzeLl++/gR e3Zi3TClhD91OcvJS/HCOiztfWOh+qj0j15wcivoPGdVPAtuJDDLtw3EShyk0uhBGAzP tAV+DxkF69qh0uj15TeBj/qg+R0x45x3DwOXtNbaPLqLQTgGEkOW8BAmcnFo0MK4KhOh qNONqALHYt7dNlK0P//mSQCEPl9ZJokpgyVwjmPvC7SZ5rO53MOEIDUWVafGOl1WUrUA sQrA==
X-Gm-Message-State: ALoCoQni14wFGNScDjeV2ekxwosMRsnxeFae07LunM/iqOk9lemLbZBs1P1GME+m54+98k0/JHeyqlx68fyIbnq2spDDE4OPcm6eoGi09U6DssAkwz+gtN0ftA5XxCJoV1NozcAjzJjIv7yFwqT8fTNMeiByfb7yMtiWZZ6iMCagtQljBn3h5pihZ0ZIWaLewks9SaBLqRg+
X-Received: by 10.53.2.36 with SMTP id bl4mr513589vdd.32.1385139832509; Fri, 22 Nov 2013 09:03:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Fri, 22 Nov 2013 09:03:32 -0800 (PST)
In-Reply-To: <CAMwTW+iR58vbu8=5d0OSgt2jtU4ri63821LHh+hPjwc5o3suaw@mail.gmail.com>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com> <528F30C1.8040208@it.aoyama.ac.jp> <CAHp8n2mYKgrpRDmC1h76X2CWYpOZcaKAxtjCS8fzcYpiYPwLnQ@mail.gmail.com> <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com> <CAMwTW+iR58vbu8=5d0OSgt2jtU4ri63821LHh+hPjwc5o3suaw@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Fri, 22 Nov 2013 09:03:32 -0800
Message-ID: <CAOJ7v-1a+0Utz8yNh_h_Od-2ZHiiT5yeywsvcxM+Qv3LdnTLpw@mail.gmail.com>
To: bryandonnovan@gmail.com
Content-Type: multipart/alternative; boundary=001a113637d4ae6fa004ebc6ffdb
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 17:04:03 -0000

In the basic case, I don't think O/A will have a problem with this, without
even needing to resort to 1-way streams.

Each side would offer both codec X and codec Y, and the remote side will
simply choose to send the one it supports (or prefers, if it supports both)


On Fri, Nov 22, 2013 at 8:47 AM, <bryandonnovan@gmail.com>; wrote:

> SDP can express sendonly and recvonly streams, so there is no inherent
> problem with assymetry of codec choice.  But it would certainly complicate
> things.
>
> 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 <tim@phonefromhere.com>; 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 <silviapfeiffer1@gmail.com>;
>> 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 <duerst@it.aoyama.ac.jp>; 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 [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.
>>>>
>>>>  _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>