Re: [rtcweb] Video codecs: Clear positions....

Ron <ron@debian.org> Tue, 09 December 2014 22:44 UTC

Return-Path: <ron@debian.org>
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 DDAD31A6EE7 for <rtcweb@ietfa.amsl.com>; Tue, 9 Dec 2014 14:44:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 RrhLljSifIot for <rtcweb@ietfa.amsl.com>; Tue, 9 Dec 2014 14:44:08 -0800 (PST)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id AAC011A3BA1 for <rtcweb@ietf.org>; Tue, 9 Dec 2014 14:44:07 -0800 (PST)
Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail05.adl6.internode.on.net with ESMTP; 10 Dec 2014 09:13:47 +1030
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 1CB89FFCAD for <rtcweb@ietf.org>; Wed, 10 Dec 2014 09:13:46 +1030 (ACDT)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fcTuWexhPn1e for <rtcweb@ietf.org>; Wed, 10 Dec 2014 09:13:45 +1030 (ACDT)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 7B020FF892 for <rtcweb@ietf.org>; Wed, 10 Dec 2014 09:13:45 +1030 (ACDT)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 7013F80470; Wed, 10 Dec 2014 09:13:45 +1030 (ACDT)
Date: Wed, 10 Dec 2014 09:13:45 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20141209224345.GJ19538@hex.shelbyville.oz>
References: <5486C48D.8040602@alvestrand.no> <F092E8C6-380C-4B20-B71F-449162617BC5@apple.com> <54873575.3030804@nostrum.com> <CAOW+2dskg9CQF9qw3oktcEGySdWJZCF6sXHXdgAnwc8ph1iVtw@mail.gmail.com> <54874B66.5050700@nostrum.com> <AE151623-3747-4835-AF3E-2953F442E995@apple.com> <9BDCD7D8-B274-4970-A01B-D31069AEA935@phonefromhere.com> <D3321473-D2F4-407F-96FB-BE58F38683A2@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D3321473-D2F4-407F-96FB-BE58F38683A2@apple.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Kfc0x8rZ5H3nfUNAFTAr9gYD198
Subject: Re: [rtcweb] Video codecs: Clear positions....
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: Tue, 09 Dec 2014 22:44:10 -0000

On Tue, Dec 09, 2014 at 12:29:46PM -0800, David Singer wrote:
> 
> An earlier suggestion on this thread was that one could be conformant
> with the WebRTC specs if one simply claimed that one was building a
> webrtc-compatible endpoint;  even if the implementation was of webrtc,
> in a browser, it would not be labeled as “WebRTC Browser”.
> 
> That, to me, is sleight of hand;  a neat trick, but not quite what we
> want to have happen.  I’d rather not suggest it to anyone.

Those definitions aren't badges you get to sew onto your scout uniform
to claim as some level of achievement or entitlement.

They are descriptive jargon that lets us refer to those things in
other areas of the spec without having to be repetitively verbose.

If what you build is a compatible endpoint, then what you have is a
compatible endpoint.  If what you build is a half-assed browser, then
what you have is a half-assed browser.  What your marketing dept.
chooses to call it is none of our business.

There are people who like to call Theora a "proprietary codec" and call
H.264 an "open standard", but nobody actually buys that bullshit either.


Nothing about this proposal is about weasel words or smoke and mirrors,
it's about establishing the benchmarks we think are needed to have the
best chance of interoperability.  Some people will have extenuating
circumstances that mean they simply can't fulfill every requirement.
This compromise acknowledged that from the outset.  Some of us *are*
going to have difficulties complying with the onerous requirements of
the selectively enforced H.264 licencing, and in some cases may not be
able to distribute it at all in any general way, even if the code does
ostensibly have support for it.  Or even if we distribute it, the end
user may not be permitted to use it in the way they wish to, or at all.

Don't forget that you aren't licenced to shoot and freely distribute
videos in H.264 using the professional video camera you bought which
came with a licence to H.264 ...  if that's not the pinnacle of
braindead restrictive practices, founded on a sense of unrestrained
entitlement to a stranglehold on the work of others, then I can't
wait to see the full glorious irony of what is.

Some of us have code that is freely distributed in unrestrictedly
international markets.  That includes countries that would laugh at
any attempt to enforce IPR on software -- and possibly even countries
where the H.264 patent holders are embargoed from being able to legally
enter into business agreements with users and companies there (I've not
actually looked to see if that is currently the case, but even if it is
not at present, it seems like a not impossible future circumstance).

There are a long list of principles and problems beyond "objecting to
paying fees" (which afaics is a complete strawman that nobody has ever
claimed to object to).

If everybody who actually can makes a best effort, I think we'll manage
a high level of interop, despite these known problems, until the video
codec WG gives us a real solution (where we can reprise the fun of
having the same group of people try to obstruct it in the same tiring
ways again too!).  We have commitments from enough of the major players
to put that on a fairly solid foundation right from the start.

If people who could comply to this simply don't want to, and would
prefer to make up some meretricious pretense about that instead of
doing so, then we can't stop them from doing that.  But as people
opposing this have been so fond of pointing out - the market will
in all probability decide on their fate, right?

It's never easy to get a dead whale off your beach.  But if some
of us don't pull together and try, it's going to stink the place up
for a whole lot longer and ruin it for everyone.  I'm willing to
hold my nose for a little while to help with that, though I don't
speak for anyone but myself.

  Vomeronasally,
  Ron