Re: [rtcweb] Making both VP8 and H264 MTI

[cowwoc <[e-mail]>]

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] 
> <mailto:[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] <mailto:[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]
>             <mailto:[e-mail]>> wrote:
>
>             On 5 November 2013 06:18, Hutton, Andrew
>             <[e-mail] <mailto:[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] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/rtcweb
>
>         _______________________________________________
>         rtcweb mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>