Subject: [rtcweb] Video codec selection: Dropping options

From: <[email-masked]>
Date: Thu, 28 Nov 2013 08:22:59 +0000

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

---

From: Leon Geyser <[email-masked]>
Date: Thu, 28 Nov 2013 12:20:25 +0200

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, <[email-masked]> wrote:

> 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.
>
> 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":
>
> 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
> 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
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Nov 2013 15:43:25 +0100

Markus,

I would note that I consider this suggestion highly problematic at this
time. Especially considering the process we have proposed for selecting
a winning alternative. The issue is that we had an open call for
proposals to be considered. To be able to exclude options I see a need
for both a process and consensus to use this process to eliminate options.

I hope you see the problem with eliminating alternatives by any form of
chair decision at this time. Thus we would be forced to run different
sets of consensus calls to determine if there are consensus to eliminate
as well as which.

Thus, I would consider your comment as, the process we chairs are
proposing is the wrong one.

Cheers

Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: cowwoc <[email-masked]>
Date: Thu, 28 Nov 2013 12:56:24 -0500

On 28/11/2013 5:20 AM, Leon Geyser wrote:
> 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?

Any option that mandates one or more decoders implies "and MUST support 
encoding of one of the aforementioned formats".

Gili

>
>
> On 28 November 2013 10:22, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     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.
>
>     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":
>
>     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
>     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
>
>     [email-masked] <mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 29 Nov 2013 10:32:31 +0100

On 11/28/2013 11:20 AM, Leon Geyser wrote:
> If 12 is possible it would be a great option. Do most patents only 
> apply for encoding?
>
One curiosity of the way standards for codecs are produced is that only 
the decoder is normative. So the only patents licensors are required to 
disclose in the standards process are patents on the decoder.

In theory, I think they could also be required to disclose patents that 
apply to any possible encoder for which this is a valid decoder, but I 
think this is unlikely to happen in practice (because most such patents 
would also describe the decoding part). But that is uncomfortably close 
to speculation, so don't trust me on that.

---

From: <[email-masked]>
Date: Fri, 29 Nov 2013 12:43:17 +0000

Hi Magnus,

Thanks for your reply.

[email-masked] wrote:
>  
> I hope you see the problem with eliminating alternatives by any form of chair
> decision at this time. Thus we would be forced to run different sets of
> consensus calls to determine if there are consensus to eliminate as well as
> which.
> 

OK, fair enough. I understand the chairs are in a difficult situation with all the proposals flying around. 

> Thus, I would consider your comment as, the process we chairs are proposing
> is the wrong one.
>

Yes. My opinion is that we should NOT go for the vote as currently proposed. 

I think the right track would be along the lines that Maik Merten recently suggested:

> So it appears that we need $fallback (to be later used in something like "all
> entities MUST implement $fallback" or "all entities MUST implement at least
> two of {H.264, VP8, $fallback}" etc.). As far as I can see following codecs have
> been mentioned as possible candidates for $fallback:
> 
> H.261, MPEG-1 Part 2, H.263, Theora (sorted by age and performance)

And if the there is no rough consensus for any of these fallback options declare "no MTI". 

(Perhaps it can be argued that the proposed voting method will find the same out as well, but it is much less clear.) 

Markus