Re: [rtcweb] H.261

cowwoc <> Wed, 27 November 2013 18:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 75F971AD8EE for <>; Wed, 27 Nov 2013 10:54:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qHzbb4IIOERc for <>; Wed, 27 Nov 2013 10:54:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 926621ADFAD for <>; Wed, 27 Nov 2013 10:54:41 -0800 (PST)
Received: by with SMTP id tp5so12279980ieb.22 for <>; Wed, 27 Nov 2013 10:54:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=M/z3lflMS4VVxF6vI4rARM8GFStBlkbsmK3HUpkrT28=; b=aYI1LPglV2SRd2TYeywRY5pBHwAQ/aEMskNh3LKSg4iCyV82JRWZz1Gamkz4OuEiRL 6HK+AtXSklSWXaFr4GDJl8IkmuGG3Dfi+DUG/Fqvhf7EdX152bhO6QrLPzmuqPa3bEmL raVrn0kPup4K2S9TL/aNXEKid3J5pl3cn/VPnEUGepo+gOYq74fuQvdr4TNWXxhMvnB5 pOxU7B3gd5aT8MTSKzKqb1RJra87XiKcyVk9/bbDptARr9RoMkA73wesDZuEX/CixNSx E8sVm2tur/+MlI1F0sp65gNcaSBnvv+IKUyyWpQ2e32VUcwDENaaKmzq7xMNK4WUyjd7 NRBA==
X-Gm-Message-State: ALoCoQl+qZbyxcg8345Lzu8vLvo7QkbDrvq3SgJ6vBosuHKHnIQasJdDSIYa4JXP0++YFPnaSwyb
X-Received: by with SMTP id s8mr1575127icv.67.1385578481040; Wed, 27 Nov 2013 10:54:41 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id a17sm4534604ign.2.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 10:54:40 -0800 (PST)
Message-ID: <>
Date: Wed, 27 Nov 2013 13:53:54 -0500
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
References: <20131122171020.GY3245@audi.shelbyville.oz> <> <> <> <> <> <> <> <> <> <20131127162552.GP3245@audi.shelbyville.oz>
In-Reply-To: <20131127162552.GP3245@audi.shelbyville.oz>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H.261
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: Wed, 27 Nov 2013 18:54:43 -0000

+1. There seems to be a lot of hand waving when it comes to H.264. Some 
very concrete questions are going unanswered.


On 27/11/2013 11:25 AM, Ron wrote:
> On Wed, Nov 27, 2013 at 03:30:55AM +0000, Cullen Jennings (fluffy) wrote:
>> I do get they MPEG LA terms can be confusing at times
>> but lots of people have figured it out.
> I can only assume that you mean this in the same sense that "lots of people"
> have "figured out" those click through EULA conditions that don't actually
> allow them to do the things they'll be doing but obviously aren't intended
> to be read since a 50 page document is presented in a 4 line scroll box with
> no button that says "click here to send this to your lawyer". [1]
> Like the ones that say your TV can report everything that's ever watched on
> it to the manufacturer, even after you click the Don't Do That button. [2]
> Or in the same sense that they drive their motor vehicles without complying
> with their legal obligation to keep a bale of hay in the trunk or have some
> person walk in front at all times waving a flag.
> A licence that says "we'll take your money, but we can't actually grant you
> the rights to use this since we don't own or control them - we'll just sort
> of promise that WE won't drag you through the courts, in exchange for being
> able to track exactly how profitable your business is" -- isn't a licence at
> all.  It's a protection racket.  With a dash of industrial espionage thrown
> in for good measure.
> This isn't something we should be booby trapping IETF standards with.
> The IETF has disclosure rules that are aimed at avoiding, so much as is
> possible, this sort of Don't ask Don't tell nonsense.  And yet we *still*
> don't have disclosures from the H.264 IPR holders that *are* present here
> for the use of H.264 in this standard.  Despite them having core dumped
> their IPR restrictions on alternative proposals.
> How can we possibly take mandating that technology seriously in this light?
> That alone should already rule this out from consideration.
>> If people have questions about specific use case I'm glad to try and get
>> them answers.
> The specific question about how the Cisco offer resolves the problem of
> MPEG LA not being the only holder of IPR that would need to be licenced
> has so far met with deafening silence.
> Glad answers to that would certainly be nice.
> People keep making claims about that offer "solving everything", which
> can't possibly be true unless you pretend those other licence holders
> don't exist.
> By comparison, Google at least has shown that it is *very* willing to
> do whatever is necessary to ensure that the licence and IPR of VP8 is
> very unambiguously exactly as they claim it to be.
> That seems a lot more reassuring than the state of denial that has
> surrounded promoting H.264.  First pretending the IPR wasn't a problem,
> then pretending they could buy us all free tickets, then claiming they
> "really wished there was a solution with no IPR burden", then rejecting
> that solution when it was actually presented as a compromise.
> Then pushing for getting the IETF to vote ...
> The number of dimensions in which we'd have to disconnect from reality
> to make this proposal acceptable makes even string theory start to look
> well grounded.
>    Ron
> [1]
> [2]
> _______________________________________________
> rtcweb mailing list