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

Harald Alvestrand <harald@alvestrand.no> Mon, 10 November 2014 20:06 UTC

Return-Path: <harald@alvestrand.no>
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 500091A90CC for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 12:06:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.493
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j3AlYB5EByI for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 12:06:54 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 774691A6F86 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 12:06:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 885307C04A6 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 21:06:34 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb18mDG5_tPr for <rtcweb@ietf.org>; Mon, 10 Nov 2014 21:06:30 +0100 (CET)
Received: from [31.133.167.224] (dhcp-a7e0.meeting.ietf.org [31.133.167.224]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3100B7C0495 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 21:06:29 +0100 (CET)
Message-ID: <54611AC1.7020509@alvestrand.no>
Date: Mon, 10 Nov 2014 12:06:25 -0800
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <54601E19.8080203@nostrum.com> <D08625BB.4ACA8%stewe@stewe.org>
In-Reply-To: <D08625BB.4ACA8%stewe@stewe.org>
Content-Type: multipart/alternative; boundary="------------010203020406060005040604"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H3Vusn79aF1sB9rVZ7p4nl49X5M
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal
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: 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").

Harald


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 <adam@nostrum.com <mailto:adam@nostrum.com>>
> Date: Sunday, November 9, 2014 at 18:08
> To: "rtcweb@ietf.org <mailto:rtcweb@ietf.org>" <rtcweb@ietf.org
> <mailto:rtcweb@ietf.org>>
> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Surveillance is pervasive. Go Dark.