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

[cowwoc <[e-mail]>]

Or design based on the de-facto situation (no MTI) until the situation 
changes to the point where we can revisit this issue.

Hopefully things will improve. But if they don't... we shouldn't wait 
forever.

Gili

On 07/11/2014 10:31 AM, Bo Burman wrote:
> I think, as was also said by others, we are moving in circles without very much progress. What seems to be the most pressing issue, the licensing landscape, has changed somewhat since last time we tried to decide on video MTI, but there are still major objections to that landscape and it is also still changing. While I do think we need an MTI video codec, I believe we would make better use of our time postponing the decision a bit longer, at least until VCB is fully settled in MPEG.
>
> /Bo
>
>> -----Original Message-----
>> From: rtcweb [mailto:[e-mail]] On Behalf Of Ron
>> Sent: den 6 november 2014 22:59
>> To: [e-mail]
>> Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them)
>>
>> On Thu, Nov 06, 2014 at 01:08:21PM -0800, Eric Rescorla wrote:
>>> On Thu, Nov 6, 2014 at 10:29 AM, 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
>>> I think Mo has answered this.
>>>
>>>> , or is this a special privilege they offered to you to win your
>>>> support for their scheme?
>>> It certainly wasn't this. When we agreed to do this, the intent was to
>>> do reproducible builds, but then as we got closer to ship engineering
>>> realities intervened and it became clear that it was easier for
>>> Mozilla to do the builds in the interim, but that decision was only
>>> made recently and we would prefer to have reproducible builds, as Mo
>>> says..
>> Right, that was sort of the point I elaborated on in my reply to Mo, there's a very real gulf between how we might like to
>> imagine things could work, and what's actually going to happen or be possible in the real world that we actually have to
>> work within.
>>
>> It's perfectly fine for Mozilla and Cisco to take shortcuts that they agree serves them both well to make things happen in
>> a timely way.
>>
>> Where that leaves everyone else is the question I was asking here.
>> This isn't a shortcut that would seem to scale well to other users, or one that seems likely to cease to be "necessary" any
>> time soon.
>>
>> (I believe I already noted the difficulty of doing this when it was first proposed, so I'm definitely not surprised at it
>> remaining just a promise at this stage)
>>
>> I've seen enough engineering realities to be pretty sure that any untested and novel scheme isn't going to end exactly
>> how the people who pitched it said it would.  Mozilla's experience with this will definitely be an interesting datapoint, but
>> it's not clear how well that will extrapolate to the more general case or the users that Tim indicated concern for yet.
>>
>>    Ron
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb