Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them)

[tim panton <[e-mail]>]

On 6 Nov 2014, at 05:14, Eric Rescorla <[e-mail]> wrote:

> 
> 
> On Wed, Nov 5, 2014 at 2:39 PM, tim panton <[e-mail]> wrote:
> 
> On 5 Nov 2014, at 19:44, Daniel-Constantin Mierla <[e-mail]> wrote:
> 
>> 
>> On 05/11/14 20:09, tim panton wrote:
>>> On 5 Nov 2014, at 17:46, Daniel-Constantin Mierla <[e-mail]> wrote:
>>> 
>>>> On 05/11/14 18:16, Victor Pascual Avila wrote:
>>>>> On Tue, Nov 4, 2014 at 6:01 PM, tim panton <[e-mail]> wrote:
>>>>>> All implementations of the rtcweb specification must implement at least one of  VP8 or H.264,
>>>>>> implementations that also implement the w3c’s webRTC javascript  API must implement  both VP8 and H264
>>>>> I'd be OK with that
>>>> I don't see any reason to split on JavaScript API implementations and
>>>> the rest.
>>>> 
>>>> Moreover, looking back, the web browsers (and the web ecosystem itself)
>>>> got to this level mainly due to open source implementations, via
>>>> khtml/webkit and gecko/firefox (then servers and other tools), which at
>>>> some point were small and not benefiting of any substantial resources.
>>>> If any of "must implement" requirements adds limits (financial or not)
>>>> to the usage in any kind of major open source licensing models, it is
>>>> going to block a lot of innovation and disruption in the field.
>>>> 
>>>> Better the freedom to negotiate anything and fail to find some common
>>>> grounds in a session than building a walled garden for 'the chosen ones'
>>>> -- hopefully the aim is not to build a new pstn-like ecosystem.
>>> I accept that argument, to an extent. However I think the costs of producing an all new browser
>>> are now so high that the H264 license won’t be the blocker. I have no evidence for this opinion.
>> 
>> I don't want to rule out the possibility of having a completely new
>> implementation.
>> 
> 
> I’m not ruling it out, I just claim that any full fresh implementation of all the w3c specs
> would be an order of magnitude more expensive to produce than the maximum cost of the H264 license.
> I admit that I have no evidence to back that view.
> 
>> Anyhow, by the nature of open source, if someone doesn't like the path a
>> project goes, then the project can forked. Even the big players that
>> could eventually afford plenty of resources do that: webkit was started
>> by apple as fork of khtml, (afaik) blink from chrome is forked from webkit.
>> 
>> We already have small players around (khtml is still there, popular
>> within kde) or tailored versions (debian ships own browser built out of
>> mozilla code -
>> http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project).
> 
> Agreed, the worst aspect of any adoption of H264 is that it makes it significantly more difficult to
> produce a custom ’secure’ build of firefox that has been independently reviewed for special use-cases
> (press, humanitarian workers etc).
> 
> Why is this true? We currently build OpenH264 and then send the binary to
> Cisco but keep a hash for comparison. Why is it more difficult to review this?
> 
> -Ekr

I can’t speak for people who actually do that build, but I imagine that they would also need to review
the plug-in mechanism, decide if downloading the plugin on first use represents a threat in itself, decide
how to protect the hash they use to do the comparison and factor in any mechanisms for upgrades of the 
plugin (and therefor changes in the hash).
All of which would represent a significant effort beyond the pure code review. I imagine most will simply remove the
module from the build to save themselves the work.

Tim.