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

[tim panton <[e-mail]>]

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). I suspect those users might be prepared to forego the ‘w3c webRTC compliant’
logo in exchange for increased security.

Khtml is interesting - it isn’t a browser, it is a component (I think) - ideally it would come under the ‘either’ codec
rule - but since it implements a javascript API it falls into the ‘wrong’ category. Konquorer is the browser app I think?

> 
>> The combination of the Cisco h264 plugin ugliness and the exposure of h264 hardware on iOS also
>> mitigate the problem. It is however still a problem, but on balance having no webRTC MTI for video is 
>> worse IMHO.
> 
> Any kind of restricting the freedom to implement open protocols/specs is
> worse than no MTI for video, IMO.

I am very keen to avoid a restriction at the protocol (IETF) level, but feel it is marginally acceptable at the
API (w3c) layer for those who choose to implement the full spec.

Tim.