Re: [rtcweb] Making both VP8 and H264 MTI

cowwoc <cowwoc@bbs.darktech.org> Wed, 06 November 2013 09:01 UTC

Return-Path: <cowwoc@bbs.darktech.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F39B21F9A97 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 01:01:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.432
X-Spam-Level:
X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u58hcZThqvgO for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 01:01:42 -0800 (PST)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id EAD7B21F9C68 for <rtcweb@ietf.org>; Wed, 6 Nov 2013 01:01:41 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id qd12so16618086ieb.19 for <rtcweb@ietf.org>; Wed, 06 Nov 2013 01:01:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=nlmEAPJUgYJXXiPYaOVhB1MVi7yZz7KSxsj7RmxF8lU=; b=k0pl1SirsgvCwolzbEnie//y5ZJ1QbzoWQNGvmqgzVe2FGdAHfxuUd1CxuTKzVxQMC EY399sEq6WkilRvkj0a+t3winoxtl+3IWLOKPQ0rZ0LGPblOOT4ZidzwcRAkbPAWGdDI bF5ybTHx9x5SM8/26eyxLErBn7DerIri2N7XABVViby1Utqqi4vw9zV++Fw8uyxY+MF3 yIlicCp7DhhP10j/xQGb6CaxYNn/QCvauowqgmNgRNtUfGEa913ALKHhZvLODX2oepHA +FG3QYPtNob7pVCR6bZDTORiFqfvYKOEj95YKa2eCKeG3jS1uvy1QHaUYx+zP9nxO0t3 4FSA==
X-Gm-Message-State: ALoCoQlaEAhPe/8HS2+j/teAgE4Rfpy8sIZyMw96wjtrYC4lyD6qjuH7QYR2ftDFyqAi0tB8TXO/
X-Received: by 10.50.225.39 with SMTP id rh7mr1650932igc.10.1383728500895; Wed, 06 Nov 2013 01:01:40 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ft2sm13087890igb.5.2013.11.06.01.01.39 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 01:01:40 -0800 (PST)
Message-ID: <527A0572.5000207@bbs.darktech.org>
Date: Wed, 06 Nov 2013 04:01:38 -0500
From: cowwoc <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CE9E91B2.1BEAA%mzanaty@cisco.com> <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <20131106084423.GC3245@audi.shelbyville.oz>
In-Reply-To: <20131106084423.GC3245@audi.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Making both VP8 and H264 MTI
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 06 Nov 2013 09:01:46 -0000

> "We don't want to" is not a blocker for consensus.

     Nice in theory, but that's not how things work in practice. Vendors 
have some very good (albeit subjective) reasons to align themselves with 
VP8 or H.264 and I don't fault them for doing so. Ignoring this reality 
will lead to a never-ending lack of consensus.

     Knowing that everyone will continue pushing their favorite horse 
regardless of the facts, I reiterate my proposal for a multi-phased 
vote, making it clear in advance that if we reach the last phase without 
a compromise we are implicitly voting for transcoding. The vote should 
end with a decision being made, one way or the other.

     TokBox enumerated some concrete compromises needed from either 
side: http://www.tokbox.com/blog/is-webrtc-ready-for-h-264/ ... We need 
to start moving down that road in order to meet in the middle.

Gili

On 06/11/2013 3:44 AM, Ron wrote:
> On Tue, Nov 05, 2013 at 01:06:19PM -0500, cowwoc wrote:
>>      In light of the fact that vendors are highly polarized on this
>> topic, I'd like to suggest the following voting order:
> I don't think it's really all that relevant for rough consensus if
> 'vendors are highly polarised' on the question at all.
>
> If you make that a consideration, I'm sure you can find some vendors
> (who may or may not be present here) who strongly wish that WebRTC
> will never exist at all in the form that this group's charter has
> envisaged, since its success would pose a very real threat to their
> current business monopolies.  That doesn't give them a right of veto
> to this work, though their input, like everyone else's, still merits
> consideration for its technical contribution to best achieving the
> charter's aims.
>
> Having a favourite horse in a race is fine.  Having that horse be the
> fittest to win is a far more objective measurement.
>
>
> The question of choosing a MTI codec hinges on interoperability, and
> we have established consensus that having a viable MTI codec is quite
> crucial for this.
>
> Right now we have 2 proposed candidates.  So the important questions
> are:
>
>   - Are either of those candidates suitable?
>   - Is one clearly more suitable than the other?
>
> And the present question has been framed by the WG chairs as:
>
>   - Are there reasons that people could not possibly use either choice?
>
>
> The reasons that people cannot possibly use H.264 are well established.
> Its licencing simply does not permit people to use it in all the varied
> ways that implementors and users of WebRTC would require.
>
> The Cisco announcement was clearly an attempt to mitigate this fatal
> constraint for their preferred choice, and while it goes some way toward
> doing that - and is certainly a bold and perceptive step for them to
> take to maintain the value of their existing investment - they are still
> constrained by these same licencing terms to only be able to offer a
> very limited solution, of limited use, to a limited number of people.
> And they still can't offer the sort of indemnity that the H.264 camp
> has demanded from VP8 in draft-dbenham-webrtc-videomti-02, and they
> aren't even offering a licence to _all_ of the known IPR covering H.264,
> only to that covered by the MPEG LA pool - which the Nokia portfolio,
> some of which was already disclosed, is notably outside of.
>
>
> The reasons that people cannot possibly use VP8 are far less clear.
> None of the objections beyond "we don't want to" so far have any
> grounding in reality.  The "but but submarine IPR!!" argument applies
> equally to *anything* that any WG might chose to do or use.
>
> Nokia tried to pull some out of their hat, but they lost in court.
> If they couldn't torpedo this, then the chances of anyone else being
> able to seem significantly diminished.  But the validity of their
> claims over H.264 are not challenged at all, and remain a clear and
> present danger for anyone using H.264.  Perhaps even more so now
> than ever, given their current financial situation and being the
> subject of a takeover bid.
>
>
> This is why I believe that although we have 2 proposals, only one
> of them can seriously stand up to scrutiny for being an acceptable
> choice that passes the muster of rough consensus.
>
> "We don't want to" is not a blocker for consensus.
>
> "The licence of this does not permit us to" is a very real blocker.
>
>
> Given we have consensus for picking an MTI codec, the only reason
> not to pick that remaining choice would be if someone springs yet
> another last minute surprise which would delay that decision again.
>
> If that actually happens, then maybe we can once again have the
> H.261 vs Theora debate - but if it doesn't, then VP8 is still the
> no-brainer choice that can stand up to the full test of having
> rough consensus and working code that meets the goals of this WG.
>
>
>
> Re this suggestion:
>
>> 1. Should *both* H.264 and VP8 be MTI?
>>
>> If there is a consensus for yes, stop here.
>>
>> 2a. Should *only* H.264 be MTI? or,
>> 2b. Should *only* VP8 be MTI?
>>
>> If there is a consensus for either one, stop here.
>>
>> 3a. Should *only* H.261 be MTI? or,
>> 3b. Should no codec be MTI? (this implies transcoding)
>>
>>      Given the final choice (H.261 or no MTI) I suspect many vendors
>> would choose H.261 and upgrade to H.264/VP8 at runtime. No one
>> really wants to go back to the days of transcoding.
> You might want to review the list archives.  This question has already
> been debated, and I thought the result of that was conclusive, and why
> we have only the current proposals that we do today.
>
>    Cheers,
>    Ron
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb