Re: [rtcweb] Video codec selection: Dropping options

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. 

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