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

Harald Alvestrand <> Mon, 10 November 2014 20:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 500091A90CC for <>; Mon, 10 Nov 2014 12:06:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.493
X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4j3AlYB5EByI for <>; Mon, 10 Nov 2014 12:06:54 -0800 (PST)
Received: from ( [IPv6:2001:700:1:2::117]) by (Postfix) with ESMTP id 774691A6F86 for <>; Mon, 10 Nov 2014 12:06:35 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 885307C04A6 for <>; Mon, 10 Nov 2014 21:06:34 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tb18mDG5_tPr for <>; Mon, 10 Nov 2014 21:06:30 +0100 (CET)
Received: from [] ( []) by (Postfix) with ESMTPSA id 3100B7C0495 for <>; Mon, 10 Nov 2014 21:06:29 +0100 (CET)
Message-ID: <>
Date: Mon, 10 Nov 2014 12:06:25 -0800
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------010203020406060005040604"
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:07:00 -0000

FWIW, I'm firmly with Tim on the proposal: I don't like to declare that
a royalty-bearing technology is mandatory to implement in an IETF
standard, but given the realities of the situation, I think it is better
to adopt this proposal than continuing to leave the MTI decision in flux.

About the language on "reconsideration": Given all the legal issues
involved, it would in my opinion be foolhardy to adopt a prescriptive,
mechanical trigger for a reclassification - but I would be unhappy about
abandoning all hope that the situation could improve - if we are in a
situation (years from now?) where it's obvious that we have a royalty
free, safely deployable codec available, it would be a strange thing not
to say "the way is clear, let's pick the freely available alternative!"

I do expect that, if the proposal is adopted, browsers will support both
codecs for the foreseeable future (and probably longer than that - "the
foreseeable future" tends to be short these days). Adam's
"reconsideration" proposal applies only to the class of non-browser
things that implement RTCWEB (aka "devices").


On 11/10/2014 11:14 AM, Stephan Wenger wrote:
> Hi,
> I like and support the spirit of this proposal, but have one issue
> with the formulation below, and would like to see it clarified.
> Stephan
> From: Adam Roach < <>>
> Date: Sunday, November 9, 2014 at 18:08
> To: " <>" <
> <>>
> Subject: [rtcweb] MTI Video Codec: a novel proposal
> […]
> 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. 
> […]
> First: “the IETF WILL CHANGE”: I don’t think that such forward
> looking, absolute statements are appropriate.  And probably also not
> correct.  Some of the objections here are not over royalties, but over
> ecosystem dominance; never mind the money.  Whether or not the IETF
> changes its opinion will at least partly be based based on the power
> distribution of players subscribing to ecosystem agendas at the time
> the situation changes.
> Second, “all IPR declarations known for the codec being of (IETF)
> Royalty-Free or (ISO) type 1” is IMO not compelling evidence for a
> royalty free codec; for many reasons that have been spelled out
> before.  Similarly, type 2 RAND statements are not evidence that
> royalties are necessarily being paid.  
> To me, evidence for a (practically) RF H.264 codec would be an MPEG-LA
> pool rightholder decision not to require the payment of royalties.
>  For VP[8,9], the licensing arrangement google has made got a long way
> to convince me, but what would be needed in addition is to overcome
> known objections by players, however expressed.  (Note that legal
> departments will typically be very reluctant to submit type 1
> statements, whereas the business groups may be more easily able to
> communicate a company decision for zero royalty.)  For newer codecs,
> what would be needed is both very wide participation (including all
> the key players in both IETF and VCEG/MPEG) and RF declarations in
> whatever organization doing the work.  Clearly, at this point, none of
> H.265, VP10, or Daala fulfill those conditions.
> Thanks,
> Stephan
> _______________________________________________
> rtcweb mailing list

Surveillance is pervasive. Go Dark.