Re: [rtcweb] Video codec selection

Assuming we are talking about native support, Option #4 maximizes legal liability. Since this the major underlying issue it will be the hardest option to get past the legal department. If we aren't talking native but plugins then it is more forward thinking to focus on next generation codec support. Either way, Option 4 loses out to either 1, 2, or 7. 

> On Nov 13, 2013, at 18:26, "Jonathan Rosenberg" <jdrosen@jdrosen.net> wrote:
> 
> Regarding number 4, here is how I think of it:
> 
> If browsers implement both, it means that an application provider wishing to offer a service (take Hangouts or Skype as examples), can pick the one they like, implement just that in their native apps (mobile, desktop, etc.) where the app provider has control over the full stack, and still work with clients of that service which run in the browser, where the app provider does not have control over the full stack as the real-time media stack is provided by the browser and not the web app. 
> 
> The benefit of this approach is that it enables interoperability between clients on different platforms for the same provider.
> 
> The drawback is, for inter-service federation (which requires much more than just codecs to be aligned), you might run into a case where a user using a mobile app from provider 1 (say, Skype) calls a user using a mobile app from provider 2 (say, Hangouts), and then since each chose a different video codec, there is no common codec. Of course that assumes the two providers in question are willing to even federate in the first place. 
> 
> -Jonathan R.
> 
> 
> 
> 
>> On Wed, Nov 13, 2013 at 5:17 PM, Stephan Wenger <stewe@stewe.org> wrote:
>> Hi Gonzalo,
>> Re your point 5.: ³either or² is often understood as an exclusive or.  I
>> don¹t think anyone proposed that.  A better way to express 5. would be
>> ³All entities MUST support at least one of H.264 and VP8².
>> Stephan
>> 
>> On 11.13.2013, 12:23 , "Gonzalo Camarillo"
>> <Gonzalo.Camarillo@ericsson.com> wrote:
>> 
>> >Folks,
>> >
>> >I hope everybody had a safe trip back home after Vancouver.
>> >
>> >As you all know, we need to make progress regarding the selection of the
>> >MTI video codec. The following are some of the alternatives we have on
>> >the table:
>> >
>> > 1. All entities MUST support H.264
>> > 2. All entities MUST support VP8
>> > 3. All entities MUST support both H.264 and VP8
>> > 4. Browsers MUST support both H.264 and VP8
>> > 5. All entities MUST support either H.264 or VP8
>> > 6. All entities MUST support H.261
>> > 7. There is no MTI video codec
>> >
>> >If you want the group to consider additional alternatives to the ones
>> >above, please let the group know within the following *two weeks*. At
>> >that point, the chairs will be listing all the received alternatives and
>> >proposing a process to select one among them.
>> >
>> >Please, send your proposals in an email to the list. You do not need to
>> >write a draft; just send the text you would like to see in the final
>> >document regarding video codecs.
>> >
>> >Thanks,
>> >
>> >Gonzalo
>> >Responsible AD for this WG
>> >
>> >_______________________________________________
>> >rtcweb mailing list
>> >rtcweb@ietf.org
>> >https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> 
> -- 
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

Re: [rtcweb] Video codec selection - way forward