Re: [rtcweb] Video codec selection: Dropping options

Eric Rescorla <ekr@rtfm.com> Thu, 28 November 2013 18:06 UTC

Return-Path: <ekr@rtfm.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 B8EAC1AE02C for <rtcweb@ietfa.amsl.com>; Thu, 28 Nov 2013 10:06:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 ERl7yeGwmFit for <rtcweb@ietfa.amsl.com>; Thu, 28 Nov 2013 10:05:59 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 976501ADF5A for <rtcweb@ietf.org>; Thu, 28 Nov 2013 10:05:59 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id en1so1150902wid.11 for <rtcweb@ietf.org>; Thu, 28 Nov 2013 10:05:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kyCF42YvW0xgVh4jFXGEVUmRQKUca/+3c+Ta2VRgwAU=; b=QnzkW591aAGRTo728OLoE/8mcoalFRz8Shmro2+8b1zfavDjiJgjNHeNdZeIIfpfHJ 4UW2YgJLYDC2Uo59ofvNd4prjKlLXD6zmfAcZX8CcXGkP90K4d8Sxzy+IhKaHPR8jJ/j nkxpw3/MSS34nCIPO/aYOrY3MTo2GsB1WlB+tJwg2/dmHMRWAAn5lxoz5z4m5itc8ZAH vTUWox8/ZP8xYfzpbyaLctVBi7TsWfWk0SrG6T5SUNKCnwBJg+e2YG0v+i7LkoMurSAE t5mH34QjkzHPo5HIJUKwEMdX4CPlV4tUlTXXHWrLobi7+fOZwSXQdZ8/4LQaUkRwfr+5 hV5w==
X-Gm-Message-State: ALoCoQkNUF0Df+0/o5YArw0Up/6kHEK19YHbTFnNQN/E/wfKHKbzzjX0bCodCNXPfnNVx9yy+xCD
X-Received: by 10.180.221.38 with SMTP id qb6mr3526311wic.8.1385661958116; Thu, 28 Nov 2013 10:05:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 28 Nov 2013 10:05:18 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <52978488.4010108@alvestrand.no>
References: <D9C9C6C10CA24644B3A854DB0C12E7D5014C1346A1@gbplmail03.genband.com> <52978488.4010108@alvestrand.no>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 28 Nov 2013 10:05:18 -0800
Message-ID: <CABcZeBNz6dYtgK84RkTz9L0vFp5oafBxC8Uc5CDZbXvSexVp-g@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Video codec selection: Dropping options
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, 28 Nov 2013 18:06:02 -0000

On Thu, Nov 28, 2013 at 9:59 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
> On 11/28/2013 11:40 AM, Jeremy Fuller wrote:
>> Since we appear to be entering the realm of voting game theory, +1 to dropping options where consensus has previously proven to be unobtainable. These options have had their moment, time to focus on something else.
>
> The WG has never voted on these alternatives; what failed was an attempt
> at finding consensus.
>
> Furhtermore, the choice of voting method that the chairs are still
> advocating (IRV) is one where presence of non-selected alternatives on
> the slate can influence the outcome.

Without taking a position on which system we should use, I would note
that this is also true of Condorcet.

http://en.wikipedia.org/wiki/Condorcet_method#Evaluation_by_criteria

-Ekr



> I'm not enough of a game theorist to figure out which way the presence
> of the previously non-consensual options may influence the ballot, but I
> don't think I am in agreement with dropping these alternatives from the
> ballot.
>
> (I still haven't decided whether or not I'm in agreement with doing a
> ballot at all, though.)
>
>>
>> "Insanity is doing the same thing over and over and expecting different results"
>>
>> Date: Thu, 28 Nov 2013 12:20:25 +0200
>> From: Leon Geyser <lgeyser@gmail.com>
>> To: "rtcweb@ietf.org" <rtcweb@ietf.org>
>> Subject: Re: [rtcweb] Video codec selection: Dropping options
>> Message-ID:
>>       <CAGgHUiQLXSzU+AvCcvDa383DA=OGd9-NTedfFOAVGt+OmyKwwg@mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> I also agree on this.
>>
>> Also 5 does not mean anything.
>> I don't like my own option of 8 that much, because 10 is much better :)
>> 11 and 13 are scary options.
>> If 12 is possible it would be a great option. Do most patents only apply for encoding?
>>
>> I am a bit confused about option 15. How does that one work?
>> Let's say I have a two sides: H.264 encoding/decoding + Theora decoder and the other side has VP8 encoding/decoding + Theora decoder. How do they communicate?
>>
>>
>> On 28 November 2013 10:22, <Markus.Isomaki@nokia.com> wrote:
>>
>>> Hi,
>>>
>>> I'm not much in favor of the voting, but if we do it:
>>>
>>> Based on the consensus call we already held in Vancouver, I would
>>> propose to drop from the list in [1] any options that make exclusively
>>> VP8 mandatory to implement or exclusively H.264 mandatory to
>>> implement. I think we have already established that much, and
>>> including those options in any vote seems wrong.
>>>
>>> In practice I'm talking about these four options:
>>> 1. All entities MUST support H.264
>>> 2. All entities MUST support VP8
>>> 3. All entities MUST support both H.264 and VP8 4. Browsers MUST
>>> support both H.264 and VP8, other entities MUST support at least one
>>> of H.264 and VP8
>>>
>>> What the WG should focus on is to see if there is a consensus on any
>>> of the so called "fallback" options vs. no MTI. I think these are all
>>> valid as such as a "fallback":
>>>
>>> 5. All entities MUST support at least one of H.264 and VP8 6. All
>>> entities MUST support H.261 7. There is no MTI video codec 8. 5+6,
>>> i.e. All entities MUST support H.261 and all entities MUST support at
>>> least one of H.264 and VP8 9. All entities MUST support Theora 10. All
>>> entities MUST implement at least two of {VP8, H.264, H.261} 11. All
>>> entities MUST implement at least two of {VP8, H.264, H.263} 12. All
>>> entities MUST support decoding using both H.264 and VP8, and MUST
>>> support encoding using at least one of H.264 or VP8 13. All entities
>>> MUST support H.263 14. All entities MUST implement at least two of
>>> {VP8, H.264 CBP, Theora} 15. All entities MUST support decoding using
>>> Theora.
>>>
>>> I think it would be problematic even if one of options 1-4 came out as
>>> a winner from a voting procedure, since it would force a large part of
>>> the community to implement something they have valid reasons to avoid.
>>> Some of the options 5-15 may have issues as well, but at least a
>>> consensus call among them would still be in order, since we haven't really had it so far.
>>> And presumably the issues and polarization are "smaller" than with the
>>> VP8 vs. H.264 argument.
>>>
>>> Regards,
>>>         Markus
>>>
>>> [1] http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart
>>>
>>> _______________________________________________
>>> 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
>
>
> --
> Surveillance is pervasive. Go Dark.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb