Re: [rtcweb] Plan for MTI video codec?

Ron <ron@debian.org> Mon, 20 October 2014 02:18 UTC

Return-Path: <ron@debian.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 88E281A1ABB for <rtcweb@ietfa.amsl.com>; Sun, 19 Oct 2014 19:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 u3Z75S8jkPKb for <rtcweb@ietfa.amsl.com>; Sun, 19 Oct 2014 19:18:49 -0700 (PDT)
Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id 831E41A1AA8 for <rtcweb@ietf.org>; Sun, 19 Oct 2014 19:18:49 -0700 (PDT)
Received: from ppp14-2-4-184.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.4.184]) by ipmail04.adl6.internode.on.net with ESMTP; 20 Oct 2014 12:48:48 +1030
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 51FC9FFE82 for <rtcweb@ietf.org>; Mon, 20 Oct 2014 12:48:46 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kMqmixpo1ahF for <rtcweb@ietf.org>; Mon, 20 Oct 2014 12:48:45 +1030 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 656A6FFC07 for <rtcweb@ietf.org>; Mon, 20 Oct 2014 12:48:45 +1030 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 5229780470; Mon, 20 Oct 2014 12:48:45 +1030 (ACDT)
Date: Mon, 20 Oct 2014 12:48:45 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20141020021845.GC8092@hex.shelbyville.oz>
References: <544035DE.8000606@matthew.at> <CABkgnnUNgWaauS6-nZ5fcExjsMPy4ZGPXaahduzA39=iqh9+fQ@mail.gmail.com> <D5D11F2B-9E32-4932-A601-F1D7FD50C706@gmail.com> <544117FB.6050706@alvestrand.no> <CAHgZEq6GTk5ei+LLpWPM5povpieompD66VU9F+u7--WJVgapaQ@mail.gmail.com> <CA+23+fGWnWd0QEeCmZ=6BmJkPrUVW6cZ0jwmXA+fM88=_+_NWw@mail.gmail.com> <CAOW+2dugTtfLhk0VuJOk7OPEonGBApMjY93EZocH90RbX6X22w@mail.gmail.com> <54442128.6070009@alvestrand.no> <CAOW+2dt8j2VwmpeQ3qaCNOKNgrGz95Sp_ROq=FO9sNm7M2EX2w@mail.gmail.com> <E36D1A4AE0B6AA4091F1728D584A6AD2400622F1@ORSMSX158.amr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <E36D1A4AE0B6AA4091F1728D584A6AD2400622F1@ORSMSX158.amr.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qBv6dHchvI_CCH-0e-NajAh0UdM
Subject: Re: [rtcweb] Plan for MTI video 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: Mon, 20 Oct 2014 02:18:51 -0000

On Mon, Oct 20, 2014 at 01:20:04AM +0000, Cavigioli, Chris wrote:
> This is a complex topic with many network factors in play.  LTE
> operators in 3GPP seek UE delays (TS + TR) around 150 ms.  Adding OPUS
> – AMR transcoding in the network imposes an additional 211.5 ms on top
> of that, just for audio.  Optionally using AMR in WebRTC, those 211.5
> ms can be eliminated, delivering a superior end-user experience.

That seems like LTE's problem, not ours.

If you start with a codec like Opus where the maximum native frame
size is 60ms and manage to engineer a solution that blows that out
to near 400ms, we'd certainly have to applaud your, uh, innovation.


> CONCLUSION:  regardless of MTI codec choices in WebRTC, to provide a
> good WebRTC – LTE interop experience, emerging WebRTC systems must
> accommodate MTI codecs already deployed in the LTE domain and in
> mobile operating systems, namely AMR/AMR-WB and H.264.

You conclude that since LTE sucks, WebRTC ought to suck too?  That
seems like a strange direction to move in.  150ms is already ample
delay on its own to create a horrible user experience.  The aim of
WebRTC was to create a standard solution that doesn't suck.  If
LTE thinks it won't be able to compete with that, but considers
interoperating with it to be important, maybe it's time LTE thought
more about deploying a codec that's actually up to the job than
about protecting the royalty revenues of its voting group ...

If 150ms is your idea of a "superior end-user experience", then
maybe people who want a satisfactory user experience will simply
avoid using LTE at all, and then this won't be a problem for them,
or us, at all.

  Just sayin'