Re: [rtcweb] Making both VP8 and H264 MTI

[Mohammed Raad <[e-mail]>]

Hi,

Given the lack of agreement on a single MTI, for business reasons
primarily, and given that the debate is really focused on two candidates, I
suggest that a transcoding function between these two codecs be defined at
the service provider level.

I suggest that the transcoding function only include the VP8 and AVC CBP to
make the development and use of this part of the service feasible.

Having such a function would allow different organizations to make their
own decision about what works for them. I sense that different experts have
become entrenched in their respective positions with very little freedom to
make a change, for multiple reasons. I think it should be clear that having
transcoding at the service level would be a reasonable compromise. Note
that no end device would be required to perform the transcoding, this would
be done at the service provider level.

BR,
Mohammed
On Nov 6, 2013 5:07 AM, "cowwoc" <[e-mail]> wrote:

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