Re: [rtcweb] revisiting MTI

Roman Shpount <> Tue, 16 December 2014 20:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2B31F1A87CE for <>; Tue, 16 Dec 2014 12:42:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LwboUgtoS8zU for <>; Tue, 16 Dec 2014 12:42:06 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 597E31A8777 for <>; Tue, 16 Dec 2014 12:42:06 -0800 (PST)
Received: by with SMTP id r20so13565436wiv.6 for <>; Tue, 16 Dec 2014 12:42:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OtDrsOmoTRX82JxmO7GYhTBkmCj/W7CPfUARALA6V+U=; b=fiOyCxr6d1/zj4gzddiPlPCaZL67owzoNujF/KGywxOPbdxVWCLMHMKF6nT3T3+SE5 4EXYD5Fdirgkf0KGaWOu+nnrk9c3FgOrBbXYpHh6DK36pnsKsLaM1Vt3Z5WT4BJGpWO+ fjz51gdOGqtmznzhDwpazyfD0sYNhN0uGj8BD6VmaQopp3qU4GcQdDpKjCcgLWpYng90 j2Uib05zliy/GIVo16br0AWknqYg5eKFFiP/WIbliv2q1JZiBgNpskjjPd6dI+IDj7zS YY7Cnfd6RY8QbODfSO7GUYAZAbbWdiodp5FRuwGUqXMIGIu2rhqNSZgVkxVinBU24m3q fDKg==
X-Gm-Message-State: ALoCoQlfE0w/YHPGS5nOFs5EzhMj0eYx4pXObRvw44Oa+q8JavPNhXzFQ51Fzcvj82ksdARAiVty
X-Received: by with SMTP id l9mr7805130wia.80.1418762525191; Tue, 16 Dec 2014 12:42:05 -0800 (PST)
Received: from ( []) by with ESMTPSA id f7sm3466824wiz.13.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 12:42:04 -0800 (PST)
Received: by with SMTP id n3so13851803wiv.13 for <>; Tue, 16 Dec 2014 12:42:03 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id c6mr8152616wik.38.1418762523798; Tue, 16 Dec 2014 12:42:03 -0800 (PST)
Received: by with HTTP; Tue, 16 Dec 2014 12:42:03 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <20141216150303.GT47023@verdi> <> <20141216152100.GU47023@verdi> <> <20141216162534.GV47023@verdi> <> <> <> <> <>
Date: Tue, 16 Dec 2014 15:42:03 -0500
Message-ID: <>
From: Roman Shpount <>
To: "DRAGE, Keith (Keith)" <>
Content-Type: multipart/alternative; boundary="e89a8f64334e40773e050a5b64fd"
Cc: "" <>
Subject: Re: [rtcweb] revisiting MTI
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Dec 2014 20:42:09 -0000

On Tue, Dec 16, 2014 at 2:56 PM, DRAGE, Keith (Keith) <> wrote:
>  Forget it.
> You are making an attempt to reduce the entire issue to IPR, and the
> discussion prior to the last meeting had been wider that that, including
> issues of interoperability with endpoints outside webRTC.
> 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.

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.
Roman Shpount