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

If "things will improve" means a non royalty-polluted codec then I agree.
Until that no MTI codec, because WebRTC is for the web, not for the
Industry.
On 7 Nov 2014 17:07, "cowwoc" <cowwoc@bbs.darktech.org> wrote:

> 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:rtcweb-bounces@ietf.org] On Behalf Of Ron
>>> Sent: den 6 november 2014 22:59
>>> To: rtcweb@ietf.org
>>> 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 <ron@debian.org> 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 <tim@phonefromhere.com>
>>>>>>
>>>>> 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
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>