Re: [rtcweb] Making both VP8 and H264 MTI

[cowwoc <[e-mail]>]

     I didn't mean to imply that we should only support the P2P 
use-case, but it is an important use-case to support. The problem with 
your solution is that for the P2P use-case where the endpoints don't 
implement the same codec, the connection would simply fail.

     Depending on your application, up to 95%+ of calls can be P2P. It 
is possible/probably that Chrome might only implement VP8 and IE/Safari 
might only implement H.264. In such a case, you have a fairly large 
probability of failure (less than 50% but still large). Whatever 
solution we could up with should have a 95% chance of success for both 
P2P and gateway use-cases.

Gili

On 05/11/2013 11:42 PM, Mohammed Raad wrote:
>
> Is WebRTC only intended for P2P implementations? Granted, you can't 
> get pure P2P if you have a gateway in the middle, but this would only 
> be the case for connections between endpoints that have not 
> implemented the same MTI.
>
> Mohammed
>
> On Nov 6, 2013 9:03 AM, "cowwoc" <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Mohammed,
>
>         Your approach does not work for the typical browser-to-browser
>     (P2P) connections.
>
>     Gili
>
>     On 05/11/2013 4:31 PM, Mohammed Raad wrote:
>>
>>     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]
>>     <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
>>
>>
>>
>>     _______________________________________________
>>     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
>