Re: [rtcweb] Proposed Video Selection Process

Basil Mohamed Gohar <basilgohar@librevideo.org> Thu, 21 November 2013 20:48 UTC

Return-Path: <basilgohar@librevideo.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 638E31AE32B for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 12:48:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level:
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no
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 1jJNWZscR1Hv for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 12:48:54 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 52D7A1AE329 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 12:48:54 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 594A2659691 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 15:48:47 -0500 (EST)
Message-ID: <528E71AC.4040202@librevideo.org>
Date: Thu, 21 Nov 2013 15:48:44 -0500
From: Basil Mohamed Gohar <basilgohar@librevideo.org>
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com> <CAEqTk6RrHSzgJ9QA_spJQWN+6SaRWwwq6H4cwBxNbTHXnHmhYA@mail.gmail.com> <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com> <CAOJ7v-1kdXreZbF0Q7=DinObV5=eWcdfFuwrJ13BQ0Hk=Fec-Q@mail.gmail.com> <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz>
In-Reply-To: <20131121204147.GV3245@audi.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
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: Thu, 21 Nov 2013 20:48:56 -0000

On 11/21/2013 03:41 PM, Ron wrote:
> 
> I'd assumed that Justin was referring to the fact that people were
> objecting to jabber participants but not the blue sheet tourists
> who packed the room for the session with a hum.
> 
> So I'm glad you've made that (IMO obvious and important) extra detail
> quite specific.
> 
> 
> But that said, I think I'm firmly with Peter Saint-Andre here.
> Taking this straight to (another) vote seems like a questionable
> choice, with a very high chance of an even more questionable and
> protested outcome (and precedent). [1]
> 
> 
> My understanding of the current situation is:
> 
>  - We established consensus long ago that MTI codecs are a very
>    important part of this specification.
> 
>  - We've had 2 seriously proposed codecs prior to the last meeting.
> 
>  - We have people expressing objections to both of them, that the
>    chairs consider sufficient to declare there is no workable
>    consensus for either at present.
> 
>  - The sustainable objections to both all boil down to people claiming
>    there are insurmountable IPR difficulties.  Whether that be mythical
>    risk, or clear impossibilities of obtaining a licence.
> 
>  - We've now had people resign themselves to the fact that this is the
>    blocking issue for consensus that needs to be resolved, and propose
>    solutions that directly address that issue, through the use of a
>    codec that is broadly agreed does not have this problem.
> 
> 
> So to me the obvious next step would be to probe for consensus about
> the codec options that _do_ remain on the table - and see if anybody
> has an actually sustainable objection that would prevent achieving a
> rough consensus that the concerns surrounding our original preferred
> choices are indeed satisfied by taking this path.
> 
> The strong objections that people have had to H.264 and VP8 aren't
> going to go away, however a vote might decide - so unless those people
> are going to retract their objections now (or the chairs are going to
> declare them vexatious and irrelevant), then 'voting' for either of
> those as MTI seems utterly pointless.
> 
> By my understanding we so far have 2 possible candidates for a MTI
> codec that may satisfy the IPR and licencing concerns that have
> blocked us from a decision to date:
> 
>  - H.261, for which everyone seems to agree the IPR is exhausted.
> 
>  - MPEG1, which Stephan raised some oblique concerns about, that
>    might still prove unfounded with a little more investigation.
> 
> Theora I'm assuming will attract the same FUD that it did with W3C
> (since people have already quoted the farce that occurred there)
> and that VP8 has attracted.  All the other H.xxx codecs are still
> within the lifetime of live patents.  So if we can rule out H.264
> and VP8, then we can immediately rule these out too without going
> through the motions of repeating all the same arguments again,
> with a just some search and replace for the codec names.
> 
> 
> So wouldn't a better first step be to:
> 
>  - See if MPEG1 can actually be ruled out with plausible indications
>    of real remaining IPR trouble.
> 
>  - If it is, we only have one codec left for people to try to raise
>    objections about that might be sustained.
> 
>  - If it isn't, we really still only have one codec left for people
>    to raise objections about, since there's obvious agreement that
>    it would be superior to H.261 in every other way.
> 
> 
> Given the agreement we've previously seen on what a MTI codec is
> supposed to achieve, I'm having a hard time seeing how consensus
> couldn't be established for at the worst H.261.  We'll all agree
> that it sucks -- but I'm yet to see any reasonable objection about
> why it _can't_ satisfy the requirements for being the MTI fallback,
> in the absence of working agreement for a better alternative.
> 
> So why don't we just skip straight to seeking consensus on this?
> 
> Instead of having a vote stacked with multiple options that will remain
> just as unacceptable as they are today, for all the same reasons, where
> people won't have to actually _justify_ why they consider some option
> or another to be unacceptable.
> 
>   Ron
> 
> 
> [1] - though I'm not at all questioning the good faith of the chairs
>       in trying to find an adequate way to resolve this (or envious
>       of their predicament here).
> 

I think that what Ron is presenting here is likely the only sensible
action that's left for us.  I am not sure if there's a possibility to
just condense all the options down into this one.

Has anyone actually objected to H.261 being the one MTI codec, while
leaving VP8 and H.264 as shoulds, as a whole and complete resolution to
our situation?

-- 
Libre Video
http://librevideo.org