Re: [rtcweb] Proposed Video Selection Process

Roman Shpount <roman@telurix.com> Fri, 22 November 2013 17:19 UTC

Return-Path: <roman@telurix.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 144631AE047 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 09:19:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 S6RsvNS8T9GO for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 09:19:14 -0800 (PST)
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id E91861AE04C for <rtcweb@ietf.org>; Fri, 22 Nov 2013 09:19:13 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id m15so1405755wgh.13 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 09:19:06 -0800 (PST)
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:date :message-id:subject:from:to:cc:content-type; bh=79p60v5xnfsONenyqh/rI+5r9GeSC/uF3hpgvhAhh8M=; b=SaWujiaaNYnJR1FiqlZ4tXTNFGYZ2XZmOcHA1TuPBUNi8eJlL5beU+ukEStVu5UIOY 5sCUpBk06Na9TCEnYyy592jtzN7mT8YPBCon2gfMv2+JQo/ypFEipUBCtq2ubUQ5FHa5 481mJ6ggyC4iskmCInlFhP6e7xjiKSITkNEETWQEd3UKdtWMrs1lhRvrGsbHTI65HUKm MPfcmHsCLEDX/5AK8NigIqNXGIpQjZvcI7eao/Pjz79s0np8aMppJ4EjUsrxDnjcbzIQ /34FNvZSLgvcS+NnfqecGzrCp7cKrG7IV3H+UGVRIcldZdQZibBA2W2lL8H2p1lxx6aJ I8rw==
X-Gm-Message-State: ALoCoQni75bEZTDAXVb3fvh9/e04Q96icl5R99EHyTZaP2kZm8RpNYMJW4BLCPKouvjrg/B5b+U2
X-Received: by 10.180.86.102 with SMTP id o6mr3563713wiz.30.1385140746365; Fri, 22 Nov 2013 09:19:06 -0800 (PST)
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by mx.google.com with ESMTPSA id gb1sm17804301wic.0.2013.11.22.09.19.04 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 09:19:04 -0800 (PST)
Received: by mail-wi0-f169.google.com with SMTP id hm6so1879287wib.0 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 09:19:04 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.198.170 with SMTP id jd10mr3415547wic.65.1385140744413; Fri, 22 Nov 2013 09:19:04 -0800 (PST)
Received: by 10.217.88.133 with HTTP; Fri, 22 Nov 2013 09:19:04 -0800 (PST)
In-Reply-To: <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com> <528F30C1.8040208@it.aoyama.ac.jp> <CAHp8n2mYKgrpRDmC1h76X2CWYpOZcaKAxtjCS8fzcYpiYPwLnQ@mail.gmail.com> <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com>
Date: Fri, 22 Nov 2013 12:19:04 -0500
Message-ID: <CAD5OKxskj+VKroT5P47o6ke6LSGmx62OCEneD5JA5+n9N2NCAg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: tim panton <tim@phonefromhere.com>
Content-Type: multipart/alternative; boundary=047d7b62509e08ec9504ebc73638
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:19:18 -0000

Actually O/A model is asymmetric by default. All you specify in SDP are the
codecs you can receive. You are allowed to send a stream in any codec
remote side supports. So if both sides state that they support codecs X and
Y in SDP, one side can send X in one direction and another side can send Y
in opposite.

_____________
Roman Shpount


On Fri, Nov 22, 2013 at 11: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
>
>