Re: [rtcweb] Making both VP8 and H264 MTI

[Justin Uberti <[e-mail]>]

True P2P isn't always possible, witness TURN. So everyone deploying a
reliable WebRTC app is going to have bandwidth costs.

Those costs will be higher and/or quality much lower, when using H.261 or
comparable codecs.

On Tue, Nov 5, 2013 at 3:59 PM, cowwoc <[e-mail]> wrote:

>  Justin,
>
>     What happens to P2P video chat? Are we throwing that out of the
> window? A P2P-based mesh is superior to one with AWS in the middle for a
> couple of reasons:
>
>    - Privacy
>    - Cost
>    - Consistent latency
>    - Ease of deployment
>
> Gili
>
>
> On 05/11/2013 6:25 PM, Justin Uberti wrote:
>
> The cost equation for CPU versus network is shifted enough in favor of CPU
> that considering old codecs like H.261 makes no financial sense. If you
> look at AWS pricing, the CPU cost of reducing bitrate from 1 Mbps to 750
> Kbps is more than made up by the network cost.
>
>  http://aws.amazon.com/ec2/pricing/
> 250 Kbps * 1 hour = $0.11
> high-compute instance for an hour = $0.05 (1 HD transcode = 4 SD
> transcodes)
>
>  Transcoding isn't the bogeyman people are making it out to be.
>
>
> On Tue, Nov 5, 2013 at 10:06 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
>>
>
>
>