Re: [rtcweb] Making both VP8 and H264 MTI

["Karl Stahl" <[e-mail]>]

I support this voting suggestion and don't think it violates the proposals
on the table. 

I actually think "1. Should *both* H.264 and VP8 be MTI?" is the only one
that has a chance of reaching consensus.

Also, 
- it is the best to avoid connection failure
- it will avoid requests for transcoding in the network (which would be very
bad technically)
- with the royalty free solutions VP8 from Google and H.264 from Cisco, why
not? None of these offers are conditioned being the only MTI. It is
technically not more difficult to include both than H.264 only.
- if any real IPR issue appears for H.264 or VP8, we have a fallback by
removing the MTI for one of these.
- we will see the Cisco codec plug-in slot model at least in some popular
browsers, which could be used for future codec plug-ins; better and
innovative codecs for general or specialized usage-

In short: Why not making both MTI? We have both G.711 and Opus for Audio.  

/Karl

-----Ursprungligt meddelande-----
Från: [e-mail] [mailto:[e-mail]] För cowwoc
Skickat: den 5 november 2013 19:06
Till: [e-mail]
Ämne: Re: [rtcweb] Making both VP8 and H264 MTI

Cullen,

     In light of the fact that vendors are highly polarized on this topic,
I'd like to suggest the following voting order:

1. Should *both* H.264 and VP8 be MTI?

If there is a consensus for yes, stop here.

2a. Should *only* H.264 be MTI? or,
2b. Should *only* VP8 be MTI?

If there is a consensus for either one, stop here.

3a. Should *only* H.261 be MTI? or,
3b. Should no codec be MTI? (this implies transcoding)

     Given the final choice (H.261 or no MTI) I suspect many vendors would
choose H.261 and upgrade to H.264/VP8 at runtime. No one really wants to go
back to the days of transcoding.

Gili

On 05/11/2013 12:44 PM, Cullen Jennings (fluffy) wrote:
> Right now there is no proposal on the table for the MTI to be both VP8 and
H.264 and the deadline was back in October so it's not a topic the chairs
feel ready to discuss in the thursday meeting.
>
> I will note that in the past when this idea was discussed, the people who
were concerned about IPR for either codec pointed out that this could only
increased, not decreased, the IPR concerns.
>
> The chairs are more concerned about neither choice being acceptable. If we
found out that both are acceptable, that will be a good situation and we
will find a reasonable way to proceed from there that is acceptable to the
WG. Alternative process is the last resort. From a chair point of view, it
really better if people actually honestly answer the question in a consensus
call instead gaming the system.
>
> Cullen - Just one of the chairs and I hope my co-chairs add more but 
> they are both in meetings right now
>
>
> On Nov 5, 2013, at 9:27 AM, "Mo Zanaty (mzanaty)" <[e-mail]>
>   wrote:
>
>> This is an important point the chairs must clarify. If there is 
>> strong support for both questions, will the chair interpret that as 
>> support for 2 MTIs, or declare no consensus, forcing us into 
>> alternative processes? I support both as MTI. But if raising my hand 
>> twice increases the likelihood of an alternative process, I will only 
>> support one (despite objecting to being forced to support only one).
>>
>> Mo
>>
>>
>> On 11/5/13, 9:46 AM, Martin Thomson <[e-mail]> wrote:
>>
>> On 5 November 2013 06:18, Hutton, Andrew <[e-mail]> wrote:
>>> How would we conclude that the community would like both to be made MTI?
>>
>> If I were to pretend that I am a process wonk, I might say something
>> like: if the objections to both questions are weak AND if the 
>> objectors are unable to find reasons that pass muster.
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb