Re: [rtcweb] confirming sense of the room: mti codec

Randell Jesup <randell-ietf@jesup.org> Tue, 09 December 2014 03:19 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587341A00EA for <rtcweb@ietfa.amsl.com>; Mon, 8 Dec 2014 19:19:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrKqxLZIwToS for <rtcweb@ietfa.amsl.com>; Mon, 8 Dec 2014 19:19:10 -0800 (PST)
Received: from relay.mailchannels.net (nov-007-i568.relay.mailchannels.net [46.232.183.122]) by ietfa.amsl.com (Postfix) with ESMTP id 816C41A0187 for <rtcweb@ietf.org>; Mon, 8 Dec 2014 19:19:07 -0800 (PST)
X-Sender-Id: wwwh|x-authuser|randell@jesup.org
Received: from r2-chicago.webserversystems.com (ip-10-204-4-183.us-west-2.compute.internal [10.204.4.183]) by relay.mailchannels.net (Postfix) with ESMTPA id 0D56F120530 for <rtcweb@ietf.org>; Tue, 9 Dec 2014 03:19:02 +0000 (UTC)
X-Sender-Id: wwwh|x-authuser|randell@jesup.org
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.245.17.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.2); Tue, 09 Dec 2014 03:19:03 GMT
X-MC-Relay: Neutral
X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org
X-MailChannels-Auth-Id: wwwh
X-MC-Loop-Signature: 1418095143248:745308746
X-MC-Ingress-Time: 1418095143248
Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:58136 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <randell-ietf@jesup.org>) id 1XyBKI-0005Iy-1B for rtcweb@ietf.org; Mon, 08 Dec 2014 21:19:02 -0600
Message-ID: <54866A1A.5050502@jesup.org>
Date: Mon, 08 Dec 2014 22:18:50 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <54820E74.90201@mozilla.com> <5485E627.5050706@jesup.org> <CALiegfn0AH+2FKXJ2b3JWob-pETdD8fXS-OM0iq8p+txdq+mSQ@mail.gmail.com> <21E818AE-0F44-4BA1-AA59-8322C982446E@apple.com>
In-Reply-To: <21E818AE-0F44-4BA1-AA59-8322C982446E@apple.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-AuthUser: randell@jesup.org
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IJk0Fg5relA2Ukjul3WnMvKy84c
Subject: Re: [rtcweb] confirming sense of the room: mti codec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Dec 2014 03:19:14 -0000

On 12/8/2014 8:19 PM, David Singer wrote:
>> On Dec 8, 2014, at 10:00 , Iñaki Baz Castillo <ibc@aliax.net> wrote:
>>
>> 2014-12-08 18:55 GMT+01:00 Randell Jesup <randell-ietf@jesup.org>rg>:
>>> +1 - it's by no means my preferred solution, but it's one I can live with,
>>> and better than the alternative of the status-quo - no MTI at all.  If it
>>> wasn't for OpenH264, my answer would be different.
>>>
>>> I can't see adopting H.264 as sole MTI, and I can't see that we'd get
>>> consensus to adopt VP8 as sole MTI.
>> There was a much better solution:
>>
>> - Don't make VP8 nor H264 MTI.
>> - So for now no MTI video codec.
>> - And a W3C compromise: First video codec 100% royalty free would
>> become MTI in WebRTC.

And engender endless further discussions about what is "100% royalty 
free".  I'll note that even MPEG-LA deciding to RF baseline H.264 
doesn't mean it's 100% royalty-free (witness Nokia's lawsuits). You can 
never say "100%" with royalties/patents unless something is so old every 
possible patent has expired - and you're still not really safe on your 
encoder even then, unless you use an old, published encoder largely 
unchanged.  I hear we haven't boiled the Indian Ocean yet.... ;-)

>> Things would be exactly as they are now, but at least we avoid a
>> "MUST" that will be ignored by 50% of the market.
> That would be more honest, indeed. It is effectively where we are going to be.  And it offers a carrot in the right direction.
>
> I am curious to know how many of the people supporting the proposed position actually would implement both encode and decode of both codecs?  This follows from comments on this thread that people who feel they fall into a different category are asking others to solve their problem.
>
> So, rather than +1, please say “I would expect to implement both” (non-binding, of course) — it would be a more useful thing to see, I think.

Easy for me.  Mozilla has already implemented both, and have been 
shipping them for months.

> Another possible choice:
>
> * admit that we already have possible non-interoperability (WebRTC-compatible Endpoints that choose differently), and that anyone who doesn’t want to do both will say that this what they are making (as was suggested):  simply delete the requirement or definitions for WebRTC User-agent and Device. Nothing stops those that want to from implementing both, without or without the mandate.  I don’t think this would make any material difference to what happens, but it makes the spec and reality a little closer.
>
>
>
> Finally, I wonder, what would it be like if we actually tried to get closer to interop: ALL endpoints — anything that can operate at one end of a WebRTC session, be it device, UA, gateway, compatible-endpoint, whatever — must be able to decode (actually, offer to receive) both, and must be able to encode at least one?  I’d have to think about the consequences of doing decode-only, but it’s a loss less work than a decent encoder, for a start. This would result in interop if people actually did it.

That option was floated when we did the survey.  I rated it above many 
others myself (though not as good as vp8-only).  IIRC it didn't do well; 
too many people in the A and not B or B and not A camps.

-- 
Randell Jesup -- rjesup a t mozilla d o t com