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

[Ron <[e-mail]>]

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