Re: [rtcweb] Video codec selection: Dropping options

Harald Alvestrand <harald@alvestrand.no> Thu, 28 November 2013 17:59 UTC

Return-Path: <harald@alvestrand.no>
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 725101ADF5A for <rtcweb@ietfa.amsl.com>; Thu, 28 Nov 2013 09:59:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 qrMc0UlXG_2P for <rtcweb@ietfa.amsl.com>; Thu, 28 Nov 2013 09:59:39 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1A81ACCE6 for <rtcweb@ietf.org>; Thu, 28 Nov 2013 09:59:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7D82239E0C8 for <rtcweb@ietf.org>; Thu, 28 Nov 2013 18:59:39 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUdabE6L5HF9 for <rtcweb@ietf.org>; Thu, 28 Nov 2013 18:59:38 +0100 (CET)
Received: from [10.130.3.90] (unknown [193.110.199.36]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5EA4539E09F for <rtcweb@ietf.org>; Thu, 28 Nov 2013 18:59:38 +0100 (CET)
Message-ID: <52978488.4010108@alvestrand.no>
Date: Thu, 28 Nov 2013 18:59:36 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <D9C9C6C10CA24644B3A854DB0C12E7D5014C1346A1@gbplmail03.genband.com>
In-Reply-To: <D9C9C6C10CA24644B3A854DB0C12E7D5014C1346A1@gbplmail03.genband.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 17:59:42 -0000

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.

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.