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

[Silvia Pfeiffer <[e-mail]>]

+1
That's the best summary of our current state wrt MTI that I've heard.

Best Regards,
Silvia.
On 7 Nov 2014 08:01, "Ron" <[e-mail]> wrote:

> On Thu, Nov 06, 2014 at 07:11:21PM +0000, Mo Zanaty (mzanaty) wrote:
> > We are also working with Red Hat on a potential Gstreamer plugin.
> > We would be happy to work with Debian or anyone else on other wrappers
> > for projects that want to download some wrapper format beyond the raw
> > library.
> >
> > It would be ideal to have a single binary (per platform) that works for
> > all applications, without many different wrappers. That was the goal of
> > the raw library, but apparently this is not sufficient for most projects.
> > Until we reach an acceptable common wrapper (with verifiable builds),
> > we¹re happy to have folks contribute their desired wrapper for hosting.
> > Mozilla contributed the Firefox Gecko Media Plugin (GMP) wrapper. They
> > were first to contribute, so they were hosted first, not due to any
> > special privilege.
>
> For Debian, this gets complicated really quickly on lots of fronts,
> not the least being the basic principle of not entering into licence
> agreements that don't apply equally to everybody.  If someone with a
> copy of Debian doesn't have the same rights to use/distribute/modify
> it as Debian itself does, then it doesn't meet even the most basic
> test of "is it Free/Open".
>
> While the IETF does give working groups some freedom to make exceptions
> where exceptional circumstances might justify it, I do think that the
> aspirational requirements for freedom to implement proposed standards
> are fairly closely aligned to what Debian requires more strictly.
>
>
> I agree that reproducible builds would go some way toward making a
> "single binary" more viable - but that also is a Hard Problem, and
> while people are working on it, I don't see it being universally
> solved before H.264 has gone the same way as H.261 has.  It does
> also still leave the problem of people needing custom and/or urgent
> fixes, whether for security reasons or simply because of some show
> stopper bug that might be specific to some narrow use case.
>
> What happens when fixing that bug for your app causes somebody else's
> app to break because of some other assumption they made in their code?
> Who gets to decide whose app gets to stay broken?
>
>
> I definitely appreciate the good will that Cisco has put into trying
> to find viable answers for other groups that would allow its preferred
> choice to actually be a viable one, but at the end of the day it is a
> hack around the H.264 licencing, and I don't think we're really even
> close to having charted the full extent of the thin ice that it is
> currently floating on.  The cap announced for H.265 definitely appears
> to have responded to this challenge already ...
>
> So the question for me at this stage still really is:
>
>  What exceptional circumstances exist to justify this group deciding
>  to go out on such a thin and completely untested limb, to mandate a
>  technology that is so obviously, and undisputedly, encumbered?
>
> Especially when we have an alternative choice available to us which is
> its technical equal, and for which the equivalent encumberance is, at
> best, still the untested assertion of a few far-from-unbiased parties.
>
>
> I'm not ruling out that there may be *some* solution which makes H.264
> viable without needing to resort to Clever Hacks, but so far we seem
> to be still well short of that.  At the same time, VP8 is currently
> under consideration to become an international standard. And there are
> other codecs under development which may change the facts on the ground
> too before the work of this group is completed.
>
> I do think we want an MTI video codec, but it's less clear we need to
> rush this decision while things that may be quite pertinent to it are
> still evolving in new and potentially game changing ways.
>
>
> > On 11/6/14, 1:29 PM, Ron <[e-mail]> wrote:
> > On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote:
> > > On Wed, Nov 5, 2014 at 2:39 PM, tim panton <[e-mail]>
> wrote:
> > > >
> > > > 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?
> >
> > Is Cisco offering to ship such binaries for anyone who wants to build
> > them, or is this a special privilege they offered to you to win your
> > support for their scheme?
> >
> >   Ron
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>