Re: [rtcweb] Proposed Video Selection Process

Leon Geyser <lgeyser@gmail.com> Thu, 21 November 2013 21:01 UTC

Return-Path: <lgeyser@gmail.com>
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 25A711AE2FE for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 13:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 ZuGiHFEjW_AL for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 13:01:48 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B7D4E1AE2FD for <rtcweb@ietf.org>; Thu, 21 Nov 2013 13:01:47 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id eh20so257018lab.18 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 13:01:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5vLz7c/z5ZvhKb8WlZqsZZJyxVIgrE9Vtlyz8qLhLbA=; b=CLfDYAiFrVTFlz+QUWfzitKIp7UWYAxklAYQEs3yCJkqnIpUMs5VJLgQktrNWHkmf2 xKioKX44ea09WjMHwxo5RZrXsZf8wlkDYqiMZK6NmiHuELbGwJAq5VkpsuyRwDxBRDYO /oJWUAvneItWJcx6U8jND6usM2e2QZKxUwAju4tQodoNAu3JsU2iB8tJGPypC18O+DDq fvpSPpb1od7Ho/w4WwUIaugSZiVXVu0o1anaOdvCydEIOKxgLc+iv7zHdZwhxO/QGtWT M0rejF4Txtw7Y+nhUFVCGoNE/XOhXM8t4yn7HA3Q2dIz3427XHmDVZOKXJl1I5n5ndGX F5jw==
MIME-Version: 1.0
X-Received: by 10.112.200.170 with SMTP id jt10mr6176638lbc.10.1385067700243; Thu, 21 Nov 2013 13:01:40 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 21 Nov 2013 13:01:40 -0800 (PST)
In-Reply-To: <528E7265.7010303@googlemail.com>
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> <528E7265.7010303@googlemail.com>
Date: Thu, 21 Nov 2013 23:01:40 +0200
Message-ID: <CAGgHUiTqK91TcHqxvb-AK8en4mP5YVcmpyqxAozVzHNgGYHa_Q@mail.gmail.com>
From: Leon Geyser <lgeyser@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c265b843514504ebb63499
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 21:01:52 -0000

>>This is IMO a very nice summary of issues and options.
>>
>>Maik

+1


On 21 November 2013 22:51, Maik Merten <maikmerten@googlemail.com>; wrote:

> This is IMO a very nice summary of issues and options.
>
> Maik
>
> Am 21.11.2013 21:41, schrieb Ron:
>
>  On Thu, Nov 21, 2013 at 11:13:11AM -0800, Adam Roach wrote:
>>
>>> On 11/21/13 10:56, Justin Uberti wrote:
>>>
>>>> Following an IETF meeting on Jabber doesn't count as participating?
>>>>
>>>> The "big guy vs little guy" narrative continues...
>>>>
>>>
>>> I think that's a bit specious. If someone is following the issue at
>>> such a distance that they haven't expressed an opinion on the
>>> mailing list, I can't see how taking a vote from them counts as
>>> anything other than simple, old-fashioned ballot stuffing.
>>>
>>> I'll take it one step further. I find the prospect that we're
>>> allowing blue sheets to stand in for participation to be highly
>>> questionable: letting the tourists vote is weighting the opinion of
>>> demonstrably uninvolved (or less-involved) parties at the same level
>>> as those who have actually been working on the topic. I do not think
>>> that a blue-sheet sign in without any on-list participation should
>>> be sufficient to participate in the kind of process the chairs are
>>> proposing.
>>>
>>> Or perhaps I'm missing something.
>>>
>>
>> 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).
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>