Re: [rtcweb] revisiting MTI

Randell Jesup <randell-ietf@jesup.org> Wed, 17 December 2014 00:44 UTC

Return-Path: <randell-ietf@jesup.org>
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 CEE191A1A11 for <rtcweb@ietfa.amsl.com>; Tue, 16 Dec 2014 16:44:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 WXcXWnBwQ1RW for <rtcweb@ietfa.amsl.com>; Tue, 16 Dec 2014 16:44:28 -0800 (PST)
Received: from relay.mailchannels.net (ar-005-i207.relay.mailchannels.net [162.253.144.89]) by ietfa.amsl.com (Postfix) with ESMTP id 4F70B1A1A06 for <rtcweb@ietf.org>; Tue, 16 Dec 2014 16:44:26 -0800 (PST)
X-Sender-Id: wwwh|x-authuser|randell@jesup.org
Received: from r2-chicago.webserversystems.com (ip-10-33-12-218.us-west-2.compute.internal [10.33.12.218]) by relay.mailchannels.net (Postfix) with ESMTPA id 5B1EB1208D9 for <rtcweb@ietf.org>; Wed, 17 Dec 2014 00:44:23 +0000 (UTC)
X-Sender-Id: wwwh|x-authuser|randell@jesup.org
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.245.145.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.2); Wed, 17 Dec 2014 00:44:23 GMT
X-MC-Relay: Neutral
X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org
X-MailChannels-Auth-Id: wwwh
X-MC-Loop-Signature: 1418777063644:2910515384
X-MC-Ingress-Time: 1418777063644
Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:60092 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <randell-ietf@jesup.org>) id 1Y12io-0002mg-9u for rtcweb@ietf.org; Tue, 16 Dec 2014 18:44:10 -0600
Message-ID: <5490D1BB.2040309@jesup.org>
Date: Tue, 16 Dec 2014 19:43:39 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <548F54A5.2060105@andyet.net> <CA+9kkMDNhRdbzCs9vrqDeD4CoWWK1xS5o0z3jL0DvNpDuLfCPw@mail.gmail.com> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <CABcZeBOAfuscG28PMAu8JJ4yAAt1-ohnuqCaeoa+jkpDkJhhpw@mail.gmail.com> <20141216152100.GU47023@verdi> <CABcZeBOykRm1RCupB6905AOikXrcrmeSjE45Yqf1mHL3aed2Zg@mail.gmail.com> <20141216162534.GV47023@verdi> <CABcZeBNDiDyYtv_0vZyO_mGuFi-dn4s0CXEo1agMmRSvsLNR8w@mail.gmail.com> <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> <CAD5OKxscDvS7SURWido5k5tsVhmMwWU7kVvGqEcTSdAMkWw8Fg@mail.gmail.com> <CALiegf=JP2zCWz-OD0c2DFoguaME5fWtuq67=+bkZ4syCL2mow@mail.gmail.com> <949EF20990823C4C85C18D59AA11AD8B296427@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CAD5OKxva4bp=6FNytHyjY5Z71Mvs=90acoygh6PLgs_GG3md5g@mail.gmail.com>
In-Reply-To: <CAD5OKxva4bp=6FNytHyjY5Z71Mvs=90acoygh6PLgs_GG3md5g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------040006010303020105090908"
X-AuthUser: randell@jesup.org
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hOBWBbDuQfTuZGCbAuOUfypJhZk
Subject: Re: [rtcweb] revisiting MTI
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: Wed, 17 Dec 2014 00:44:30 -0000

On 12/16/2014 3:42 PM, Roman Shpount wrote:
> On Tue, Dec 16, 2014 at 2:56 PM, DRAGE, Keith (Keith) 
> <keith.drage@alcatel-lucent.com 
> <mailto:keith.drage@alcatel-lucent.com>> wrote:
>
>     As far as I am concerned an IPR free codec is irrelevant if I
>     cannot talk to the endpoints I need to, and just concentrating on
>     the webrtc community as the available endpoint may meet some
>     deployers use cases, but not others.
>
>
> There is no such thing as IPR free codec, unless you are talking about 
> H.261 or MJPEG where IPR has expired. What we are looking for is a 
> video codec with an acceptable quality (both VP8 and H.264 qualify) 
> and reasonable licensing (both VP8 and H.264 have serious issues 
> here). If it is confirmed the VP8 licensing issues are resolved (i.e. 
> it went through the standardization process, all IPR declaration 
> against it which prevent licensing are confirmed to not apply in court 
> or due to some sort of licencing agreement), then VP8 is clearly 
> superior. If H.264 fixes its licensing (i.e. present a clear, 
> published, no royalty licensing terms with no use restrictions), it 
> can be a superior codec. Legacy interop support is important, but to 
> me at least, it is secondary to unrestricted use. Please see Opus vs 
> AMR-WB+ for clear similarities.

+1.  "IPR-free" barely would even apply to H.261 - you'd also have avoid 
any of the (patented) tricks on the encoding side that have shown up 
during later codec evolution from that  - but you always *can* avoid 
them by basing on ancient implementations.

> Also, VP9 or H.265 would clearly  improve video quality, but both VP8 
> and H.264 with the current connection speeds allow for the highly 
> usable video communications. I think that quality wise, either one of 
> VP8 and H.264 can serve as usable MTI for a lot longer then the next 
> two years or whatever time is required for the next great video codec 
> to be developed. Especially in another 5-6 years when all the IPR on 
> these codecs will expire.

+1 (Well, most of the patents on the decoder side and basic 
non-performant encoders may expire.  Patents are weird.)

We have better things to do...

-- 
Randell Jesup -- rjesup a t mozilla d o t com