Re: [rtcweb] MTI Video Codec: a novel proposal

Emil Ivov <> Mon, 10 November 2014 20:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 60AA11AC3A2 for <>; Mon, 10 Nov 2014 12:57:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xpp7lAMzUDpC for <>; Mon, 10 Nov 2014 12:57:33 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15BB11ACDF5 for <>; Mon, 10 Nov 2014 12:57:33 -0800 (PST)
Received: by with SMTP id kq14so8975106pab.24 for <>; Mon, 10 Nov 2014 12:57:32 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=4wr0wXsD1levcc9VU1tKoWop3mHC+Jy5u9hpepdeqVc=; b=EVQ9ZPpvEdtFAvRT4lax9hTUsTMocy6inTzcZNMNOfcEImwSe7xUVmq7w5ImvpC47A n1uHYtu0CfED6gKaveZmqRRZ6+zFfv1LEvP0psLejRRIBI++QSkpltqU9nhhKNwjwuIp BT5oNaaC/AxB8a+XUB+hkHs2kA1FcK4HGWYExfe7FsQTWKxLo6f6LMRjMK3EXZdA2F1D TiaDLfzU9N4rrZnqTQXU/St19Ec48EKSzaprrf1sHHogPIrRQRmc5DXI8dBiNtXo7hwF eGeAQ8EL+0pPmJvxvLU2Ecz86qM0TLvh2oU9/rmu1maoYX6sEfIC50uxDcwy08ozYUm/ oEiw==
X-Gm-Message-State: ALoCoQkruKNHL2+vDZNVK2cPyajeHelnTqturrpOAy4fREbH3AkFmE++Gmz/JMBQazXYF+/5ul94
X-Received: by with SMTP id kq2mr35398941pdb.54.1415653052498; Mon, 10 Nov 2014 12:57:32 -0800 (PST)
Received: from ( []) by with ESMTPSA id ki6sm14975444pdb.85.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 12:57:31 -0800 (PST)
Received: by with SMTP id v10so8509850pde.22 for <>; Mon, 10 Nov 2014 12:57:31 -0800 (PST)
X-Received: by with SMTP id dr8mr35329438pdb.58.1415653051481; Mon, 10 Nov 2014 12:57:31 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 10 Nov 2014 12:57:11 -0800 (PST)
In-Reply-To: <>
References: <>
From: Emil Ivov <>
Date: Mon, 10 Nov 2014 21:57:11 +0100
Message-ID: <>
To: Adam Roach <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal
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: Mon, 10 Nov 2014 20:57:35 -0000

Thanks for coming up with that Adam!

It does look like a reasonable compromise! In our project's community
we are happy that it would provide a means for people with different
browsers to participate in conferences based on video
routing/selective forwarding (as opposed to mixing), which we consider
to be a big win for WebRTC!

So, +1 to that!


On Mon, Nov 10, 2014 at 3:08 AM, Adam Roach <> wrote:
> It appears that we're running headlong into another in-person discussion
> about the relative merits of H.264 and VP8 as MTI candidates again. Matthew
> Kaufman has argued that this conversation is doomed to failure because no
> major player has been willing to change their position. The players he cited
> were Cisco, Google, and Mozilla, who have represented the three main
> positions on this topic pretty effectively. Although we participate as
> individuals in the IETF, I think it's fair to say that the last time we had
> this conversation, the median positions of participants from those companies
> were "H.264 or die", "VP8 or die", and "either one as long as it's *only*
> one", respectively.
> However, even if nothing else has changed, I think one salient point may
> have become quite important: we're all tired of this. Over two years ago, in
> March of 2012 -- before I even had an particular interest in WebRTC except
> as a user -- this had already become such a long-running acrimonious debate
> that I was brought in as a neutral third party to try to mediate. I'm weary
> of this argument; and, with the exception of a few aggressive voices who
> seem to enjoy the battle more than the outcome, I'm hearing a similar
> exhausted timbre in the messages of other participants (and the key
> stakeholders in particular).
> So, I want to float a proposal that represents a compromise, to see if we
> can finally close this issue. First, I want to start out by reiterating a
> well-worn observation that the hallmark of a good compromise is that nobody
> leaves happy, but everyone can force themselves to accept it. And I want to
> be crystal clear: the solution I'm about to float just barely clears the bar
> of what I think I can live with. This proposal is based on an observation
> that the dominating issues in this conversation remain those of licensing,
> not technology or even incumbency. I’ve discussed this extensively with
> representatives of all three of the players I mention above, and they are
> willing to sign on.
> This proposal is based on the definitions of "WebRTC User Agent", "WebRTC
> device", and "WebRTC-compatible endpoint" in section 2.2 of
> draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:
> WebRTC User Agents MUST implement both VP8 and H.264.
> WebRTC devices MUST implement both VP8 and H.264. If compelling evidence
> arises that one of the codecs is available for use on a royalty-free basis,
> such as all IPR declarations known for the codec being of (IETF)
> Royalty-Free or (ISO) type 1, the IETF will change this normative statement
> to indicate that only that codec is required. For absolute, crystal clarity,
> this provision is only applicable to WebRTC devices, and not to WebRTC User
> Agents.
> WebRTC-compatible endpoints are free to implement any video codecs they see
> fit, if any (this follows logically from the definition of
> "WebRTC-compatible endpoint," and doesn't really need to be stated, but I
> want this proposal to be as explicit as possible).
> This has the property of ensuring that all devices and user agents can work
> with all devices and user agents. This has the property of giving no one
> exactly what they want. And, unlike any other previous plans, this has the
> property of coming to a decision while maintaining pressure on the only
> parties who can make a change in the IPR landscape to do so.
> /a
> _______________________________________________
> rtcweb mailing list