Re: [rtcweb] On the topic of MTI video codecs

[cowwoc <[e-mail]>]

     Everyone seems to be fixated on web browsers. What happens to those 
of us who wish to integrate WebRTC as a library into non-browser 
applications? What about standalone (client) applications? What about 
(auditing) web servers? Are we expected to download the binary module 
once per user? Or does our build machine download it once and deploy it 
to a million users?

     VP8 is far more attractive from a security and deployment point of 
view.

Gili

On 31/10/2013 5:08 PM, Daniel-Constantin Mierla wrote:
>
> On 10/31/13 4:10 PM, Olle E. Johansson wrote:
>> On 31 Oct 2013, at 10:02, Neil Stratford <[e-mail]> wrote:
>>
>>> On 30 Oct 2013, at 17:55, Adam Roach <[e-mail]> wrote:
>>>
>>>> As Jonathan mentioned earlier, this morning Cisco announced that it 
>>>> will be open sourcing an H.264 implementation as well as gratis 
>>>> binary modules compiled from that source and hosted by Cisco for 
>>>> download. Mozilla will be modifying Firefox to support H.264 by 
>>>> downloading Cisco's binary module.
>>>
>>> It seems like most of the groundwork is being done here for a real 
>>> codec plugin API which would obviate the need for any particular 
>>> codec to be selected as MTI.
>>>
>>> Can we encourage this new codec plugin API to be developed in an 
>>> open way as part of the standards process and therefore be supported 
>>> in all browsers? (Enabling for example the addition of VP8 to a 
>>> browser that may not natively ship with it.)
>> I don't agree. The idea was to create a realtime web platform without 
>> the need for any plugins or downloadable modules. We've had that for 
>> ages and it is not a good solution.
>>
>> I am still for a MTI codec or set of codecs so we always can set up 
>> video calls, regardless of implementation and if it's possible to 
>> download by policy or network conditions a specific binary.
> Downloading a binary opens doors for tons of risks, knowing that lot 
> of carriers do caching or interpose themselves (e.g., it happens very 
> commonly for dns to redirect you to some adds page when typing an 
> invalid domain), thus is easy to replace the original source, so a 
> rather complex security mechanism has to be put in place.
>
> Even the argument that the code can be compiled and signatures 
> compared is not really feasible - simply it cannot be done by mobile 
> devices - they don't have the sdk installed.
>
> I can't see an impediment for Cisco to grant the main web browsers 
> (e.g., Mozilla, ...) to simply have the codec built in, using the BSD 
> open sourced codec. If the webrtc is going to the masses, then the 
> yearly fee cap will be reached anyhow.
>
> For the sake of clarification, I am not in a favor of a particular 
> video codec, but the one to be selected has to be embedded directly in 
> all browsers, specially in those open source, for full transparency. 
> Otherwise, better as Neil said, make it a plugin API so there can be 
> many providers - with binary blob download, there has to be an API 
> anyhow, make that the standard.
>
> Daniel
>