Re: [rtcweb] Making both VP8 and H264 MTI

Mohammed Raad <mohammedsraad@raadtech.com> Wed, 06 November 2013 04:42 UTC

Return-Path: <mohammedsraad@raadtech.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA2221E80A9 for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2013 20:42:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmi4Vj97G8aj for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2013 20:42:27 -0800 (PST)
Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8A11E80E7 for <rtcweb@ietf.org>; Tue, 5 Nov 2013 20:42:27 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id u57so4340370wes.18 for <rtcweb@ietf.org>; Tue, 05 Nov 2013 20:42:26 -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=IahBrXk8JyId8GFivoHj/4mXlvTdFcYxQgcZhDOpwOs=; b=AuxB7Jpp0VgY8mg4i+hOoRz8GBJY09EyzCmDuwGuwGQ40C/quYo0mEGXS03fafTGvz jttdXdKD04Jc4Eg6dPacHvUS+ewh5NXMu/XSGyoua308bRcVIL9S7rP7wuQygLhcmTQX L0zrWQfUt4w0oKrGNgV/Bh3YtLW0YtTz3UEZkiQaC7FheygsfuZVw0VeSwF2FydxwRl+ Ss0cTcb4dveYQznuHQndufeTAt6s1Dewd49VICRaK556pLKHrG0+bAWlPT31dFfwScFh b6XPG9xdMfQEIlpJFS9qzmT0lRqRWVjkNVRFia/ypLnO9FCIHxf5p2RbR/yR+1zZNHmG SV2g==
X-Gm-Message-State: ALoCoQk77b+7yKYGjzAUa2M1IolVmN+e4SjLYulvcrBNCzPmJckrbIlmtTFP7KXyHq/iEX7G8K+Q
MIME-Version: 1.0
X-Received: by 10.180.184.14 with SMTP id eq14mr818138wic.56.1383712945905; Tue, 05 Nov 2013 20:42:25 -0800 (PST)
Received: by 10.194.179.166 with HTTP; Tue, 5 Nov 2013 20:42:25 -0800 (PST)
Received: by 10.194.179.166 with HTTP; Tue, 5 Nov 2013 20:42:25 -0800 (PST)
In-Reply-To: <52796B1D.5030704@bbs.darktech.org>
References: <CE9E91B2.1BEAA%mzanaty@cisco.com> <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <CA+E6M0mMs3WhwVtx5fgkAz_=u7U5cSd6ns+B9kY3UmboGkz2CA@mail.gmail.com> <52796B1D.5030704@bbs.darktech.org>
Date: Wed, 6 Nov 2013 15:42:25 +1100
Message-ID: <CA+E6M0mZMg+tFXTu3Q00SvOSUMbNFVS+4Ki7xiGEO4kGD8BF2Q@mail.gmail.com>
From: Mohammed Raad <mohammedsraad@raadtech.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Content-Type: multipart/alternative; boundary=001a11c2436e9cba8804ea7ac6bd
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Making both VP8 and H264 MTI
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 06 Nov 2013 04:42:32 -0000

Is WebRTC only intended for P2P implementations? Granted, you can't get
pure P2P if you have a gateway in the middle, but this would only be the
case for connections between endpoints that have not implemented the same
MTI.

Mohammed
On Nov 6, 2013 9:03 AM, "cowwoc" <cowwoc@bbs.darktech.org> wrote:

>  Mohammed,
>
>     Your approach does not work for the typical browser-to-browser (P2P)
> connections.
>
> Gili
>
> On 05/11/2013 4:31 PM, Mohammed Raad wrote:
>
> Hi,
>
> Given the lack of agreement on a single MTI, for business reasons
> primarily, and given that the debate is really focused on two candidates, I
> suggest that a transcoding function between these two codecs be defined at
> the service provider level.
>
> I suggest that the transcoding function only include the VP8 and AVC CBP
> to make the development and use of this part of the service feasible.
>
> Having such a function would allow different organizations to make their
> own decision about what works for them. I sense that different experts have
> become entrenched in their respective positions with very little freedom to
> make a change, for multiple reasons. I think it should be clear that having
> transcoding at the service level would be a reasonable compromise. Note
> that no end device would be required to perform the transcoding, this would
> be done at the service provider level.
>
> BR,
> Mohammed
> On Nov 6, 2013 5:07 AM, "cowwoc" <cowwoc@bbs.darktech.org> wrote:
>
>> Cullen,
>>
>>     In light of the fact that vendors are highly polarized on this topic,
>> I'd like to suggest the following voting order:
>>
>> 1. Should *both* H.264 and VP8 be MTI?
>>
>> If there is a consensus for yes, stop here.
>>
>> 2a. Should *only* H.264 be MTI? or,
>> 2b. Should *only* VP8 be MTI?
>>
>> If there is a consensus for either one, stop here.
>>
>> 3a. Should *only* H.261 be MTI? or,
>> 3b. Should no codec be MTI? (this implies transcoding)
>>
>>     Given the final choice (H.261 or no MTI) I suspect many vendors would
>> choose H.261 and upgrade to H.264/VP8 at runtime. No one really wants to go
>> back to the days of transcoding.
>>
>> Gili
>>
>> On 05/11/2013 12:44 PM, Cullen Jennings (fluffy) wrote:
>>
>>> Right now there is no proposal on the table for the MTI to be both VP8
>>> and H.264 and the deadline was back in October so it's not a topic the
>>> chairs feel ready to discuss in the thursday meeting.
>>>
>>> I will note that in the past when this idea was discussed, the people
>>> who were concerned about IPR for either codec pointed out that this could
>>> only increased, not decreased, the IPR concerns.
>>>
>>> The chairs are more concerned about neither choice being acceptable. If
>>> we found out that both are acceptable, that will be a good situation and we
>>> will find a reasonable way to proceed from there that is acceptable to the
>>> WG. Alternative process is the last resort. From a chair point of view, it
>>> really better if people actually honestly answer the question in a
>>> consensus call instead gaming the system.
>>>
>>> Cullen - Just one of the chairs and I hope my co-chairs add more but
>>> they are both in meetings right now
>>>
>>>
>>> On Nov 5, 2013, at 9:27 AM, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
>>>   wrote:
>>>
>>>  This is an important point the chairs must clarify. If there is strong
>>>> support for both questions, will the chair interpret that as support
>>>> for 2
>>>> MTIs, or declare no consensus, forcing us into alternative processes? I
>>>> support both as MTI. But if raising my hand twice increases the
>>>> likelihood
>>>> of an alternative process, I will only support one (despite objecting to
>>>> being forced to support only one).
>>>>
>>>> Mo
>>>>
>>>>
>>>> On 11/5/13, 9:46 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
>>>>
>>>> On 5 November 2013 06:18, Hutton, Andrew <andrew.hutton@unify.com>
>>>> wrote:
>>>>
>>>>> How would we conclude that the community would like both to be made
>>>>> MTI?
>>>>>
>>>>
>>>> If I were to pretend that I am a process wonk, I might say something
>>>> like: if the objections to both questions are weak AND if the
>>>> objectors are unable to find reasons that pass muster.
>>>> _______________________________________________
>>>> 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 listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>