Re: [rtcweb] Making both VP8 and H264 MTI

cowwoc <cowwoc@bbs.darktech.org> Thu, 07 November 2013 14:56 UTC

Return-Path: <cowwoc@bbs.darktech.org>
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 5C8C521E80E8 for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 06:56:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.939
X-Spam-Level:
X-Spam-Status: No, score=-3.939 tagged_above=-999 required=5 tests=[AWL=-1.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_MEDS=0.842]
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 S1zA97Sncvba for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 06:56:27 -0800 (PST)
Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5A86A21E8213 for <rtcweb@ietf.org>; Thu, 7 Nov 2013 06:56:27 -0800 (PST)
Received: by mail-ie0-f176.google.com with SMTP id u16so947656iet.21 for <rtcweb@ietf.org>; Thu, 07 Nov 2013 06:56: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ESXasDyqMooCN0t4v88d/d7byrZfMcsp8HeZBv5FuAg=; b=QnmwAKn4n2pugRTCa0uzT9I0ZdRzprl7MPKzM73THsaG67AoA9VRZlf4lrXxdecYNY YTva4pnS8DDOTmRjlkdajP3S4M5Sb9eH1q4GUvytdTUmI+mwH+QUb+USkEuBilmQHd7s svcdGO5g0B0bKcLi/AuDayJQcBOGjlOJ5LIh8W/TQBUOc5FFiiQcOHLz3gHQx0MmydSr 7f2cldfAelpZidZxI53DWsjZlahUbFjPm1QEQMsImnyrOP+ws1FFLZhupiglO8DOhgZZ FtAnuQVaY/OqqK4W10azOoK5GqeT5GrkJZIJI8jbI7sOXgKapXa+QD4Ql4Lc7kdVVqaH Y5cg==
X-Gm-Message-State: ALoCoQnKJI3M2snzawBV3ArDmeSOpYAFbpGgbp5FXVT5tZTgih6Qx3BpNkLqHcBXPbnqbUMQdYnW
X-Received: by 10.43.11.69 with SMTP id pd5mr520960icb.62.1383836186457; Thu, 07 Nov 2013 06:56:26 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p5sm4501426igj.10.2013.11.07.06.56.25 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 06:56:25 -0800 (PST)
Message-ID: <527BAA17.40705@bbs.darktech.org>
Date: Thu, 07 Nov 2013 09:56:23 -0500
From: cowwoc <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CE9E91B2.1BEAA%mzanaty@cisco.com> <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <E44893DD4E290745BB608EB23FDDB7620A108AAB@008-AM1MPN1-041.mgdnok.nokia.com> <CAMwTW+g+iHWCkoUonjYFi6OrSNcSQZX2X4GtKG5Ae4Ubzv0LtA@mail.gmail.com> <A869F270-C9B9-48EE-9A71-75BA9F2684EC@apple.com> <527A06EF.2070007@bbs.darktech.org> <527A0C4D.7020707@gmail.com> <527A15A3.2090006@bbs.darktech.org> <CA+E6M0mrrj+hKgxkXyvsd+J1yLVV0WAtM_MsNP4qcFkd8F15hA@mail.gmail.com> <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com>
In-Reply-To: <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Thu, 07 Nov 2013 14:56:33 -0000

On 07/11/2013 1:04 AM, David Singer wrote:
> On Nov 7, 2013, at 5:33 , Mohammed Raad <mohammedsraad@raadtech.com> wrote:
>
>> Hi,
>>
>> There isn't much new in the arguments for and against VP8 vs H.264. Its clear that there are concerns that are beyond how well each codec performs and whether or not it is free. Although I recognize that the transcoding option does not address the P2P use case, I do think that the goal of interoperability can be better achieved through a two phase approach. The first is enabling end-points to inter-operate through the availability of transcoding from the service provider. The second is to make one of the codecs the defacto MTI because of the its higher level of adoption. Yes, we may never get to a single MTI if we follow this path but at least we will have endpoints inter-operating. Besides, there are multiple other difficulties in getting seamless P2P communications working all the time, so I would suggest focusing on the service provider centered use case first.
> You know, you're right.
>
> We could suggest or even recommend both, and mandate you must implement at least one of the two. That would identify precisely two interoperability points in an otherwise much larger space, at least, and make it fairly simple for those that can and wish to, to offer transcoding, since the two ends are now defined.  It's not ideal, but it might be better than saying nothing at all.

     I can't believe you guys are actually trying to convince us that 
being forced to use a transcoder is actually a *good* thing! Any 
solution that does not address the P2P use-case is a non-starter. Feel 
free to use this model in your own deployments, just don't force it on us.

Gili