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

[Eric Rescorla <[e-mail]>]

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 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.
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>