[rtcweb] Is there room for a compromise?

John Leslie <john@jlc.net> Mon, 16 December 2013 17:08 UTC

Return-Path: <john@jlc.net>
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 221AE1AE073 for <rtcweb@ietfa.amsl.com>; Mon, 16 Dec 2013 09:08:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level:
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] 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 YCylVqPM45Fi for <rtcweb@ietfa.amsl.com>; Mon, 16 Dec 2013 09:08:26 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E188F1AE079 for <rtcweb@ietf.org>; Mon, 16 Dec 2013 09:08:23 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id E7A85C94BE; Mon, 16 Dec 2013 12:08:20 -0500 (EST)
Date: Mon, 16 Dec 2013 12:08:20 -0500
From: John Leslie <john@jlc.net>
To: cowwoc <cowwoc@bbs.darktech.org>
Message-ID: <20131216170820.GD82971@verdi>
References: <CAMwTW+g6q0gRbdioEkw8aUjpBY1s=V=sHbPNXaebFbhr6WihJQ@mail.gmail.com> <CABcZeBNx5wpKDgd6TgA9U3_nxEKXdCsXpo8Kp663yQ6e_iN9vQ@mail.gmail.com> <20131215075757.GB3245@audi.shelbyville.oz> <52AE54F8.5070300@bbs.darktech.org> <CABcZeBNqE25O+BNLboXDrJ1ypp26uRAw8ehwtyor9gJccpuzGw@mail.gmail.com> <52AE759C.7020209@bbs.darktech.org> <CABcZeBMjTGs41t7y=xvaLdn4i63HxC2YQUkrd-itq=VkuKvpTA@mail.gmail.com> <52AE9129.8090702@bbs.darktech.org> <CABcZeBPOxqa2YQxOrTp9sVF-tQrpg-Kn=CbazBXOx_9dajhUZA@mail.gmail.com> <52AE9E0C.9060707@bbs.darktech.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <52AE9E0C.9060707@bbs.darktech.org>
User-Agent: Mutt/1.4.1i
Cc: rtcweb@ietf.org
Subject: [rtcweb] Is there room for a compromise?
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: Mon, 16 Dec 2013 17:08:30 -0000

cowwoc <cowwoc@bbs.darktech.org> wrote:
> 
> [a bunch of stuff better not repeated...]
> 
> This is why I favor the "Must implement two of [VP8, H.264, older 
> codec]" option. Companies who need high-end video can fallback on 
> transcoders. Companies who want to avoid IPR issues can fallback on 
> older codecs...

   The straw-poll results so far indicate we're headed for No-MTI. :^(

   (For the record, this is Acceptable to me.)

   No-MTI means we wait for the market to sort things out, and
hopefully add a single MTI once things are sorted out (if any of us
live that long).

   In the meantime, there will surely be H.264 islands and VP8 islands.

   Very importantly, there will arise transcoding services to bridge
between them. I am hopeful (but not optimistic) that these transcoding
services can add "only" 60 milliseconds of delay. That will be good
enough for many uses.

   BTW, I'm certain these transcoding services will arise -- I only
fear that they will instead add 100-200 milliseconds of delay, which
is NOT good enough for real-time conferencing.

   Fortunately, there will also be browsers that support both codecs;
and those will likely be the winners in the market -- though it will
be interesting to see what happens when they get sued for IPR issues...

   BTW, this is why I intend to support SHOULDs for both H.264 and VP8
if we fail to agree on something as MTI.

   This "two of [VP8, H.264, older codec]" appears to be the viable
compromise: it gives us usable-if-unattractive video with a minimum
of dependencies which might otherwise scuttle actual deployment. If
we actually must wait for transcoding services to arise, deployment
might take entirely too long.

   So I ask -- what is driving the No votes on [... older codec]?

   If it is "I don't want to look at unattractive video," what can
we do to assure you that you won't have to?

   If it is "I don't want to spend any time implementing it," are you
truly on the critical path to deployment of WebRTC?

   If it is something else, can you at least _tell_ us why?

   Unless we can make progress on this sort of question, I fear we
will have to declare defeat on the MTI question shortly after the
straw poll closes.

> If the peers are compatible, there is no need for transcoding or
> older codecs.

   (Please don't forget that so long as _one_ endpoint supports both
H.264 and VP8, the peers _are_ compatible. This can work to make
either "two of" or no-MTI acceptable.)

--
John Leslie <john@jlc.net>