Re: [rtcweb] Proposed Video Selection Process

Maik Merten <> Thu, 21 November 2013 20:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0B0611AE32D for <>; Thu, 21 Nov 2013 12:52:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R-P9NRjcxDTV for <>; Thu, 21 Nov 2013 12:52:00 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4013:c01::236]) by (Postfix) with ESMTP id 184561AE291 for <>; Thu, 21 Nov 2013 12:51:59 -0800 (PST)
Received: by with SMTP id o10so155131eaj.27 for <>; Thu, 21 Nov 2013 12:51:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=md3Kj1vsSv4kz+hlUhFGl63AL+FsRvloFqez2tK4aLw=; b=sbeiPRe3epD6GF0+7h+LJ7eoVvk+0V1X6AHU5786rOMUX/7w50TOGKqapFWKuJ+M0H TL8SFXeWzZzJaStBgrrxMgm1aqxz4i+ew/J4NUiUwq9lYPn1KJkgkIV8F7pG7PKA9Fr9 lcmFx4zbrEAt62bXQz0j1hfFgPzRd8EvX8B1slNI+jHcRXyAovv9pfzL0HSaj+uVRt5y Y5KyJAFOZ1k7TJZZ7czuJOgwKFKhZwG1uBO8lIda3KEyFLiVlFdTJ+FKGvteOYKAUT/9 iY/28JlVB+2/PCG+QQA6C1NX0/Cj+o3gtnFtiCAzE0ITqcMBfm0fRdk+L7PQ4QXv9jiw pf+g==
X-Received: by with SMTP id w1mr11191922een.29.1385067112754; Thu, 21 Nov 2013 12:51:52 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id 8sm73687818eem.15.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 12:51:51 -0800 (PST)
Message-ID: <>
Date: Thu, 21 Nov 2013 21:51:49 +0100
From: Maik Merten <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
References: <> <> <> <> <> <20131121204147.GV3245@audi.shelbyville.oz>
In-Reply-To: <20131121204147.GV3245@audi.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
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: Thu, 21 Nov 2013 20:52:04 -0000

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


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 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