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

[Iñaki Baz Castillo <[e-mail]>]

+1

I just hope that those promoting H264 have something to say about this
instead of ignoring this great and realistic rationale.



2014-11-06 22:00 GMT+01:00 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
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Iñaki Baz Castillo
<[e-mail]>