Re: [rtcweb] Plan for MTI video codec?

Justin Uberti <juberti@google.com> Mon, 20 October 2014 05:52 UTC

Return-Path: <juberti@google.com>
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 806191A6F7E for <rtcweb@ietfa.amsl.com>; Sun, 19 Oct 2014 22:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.388
X-Spam-Level:
X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_SUMOF=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 5lpCNtMPL3ii for <rtcweb@ietfa.amsl.com>; Sun, 19 Oct 2014 22:52:35 -0700 (PDT)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4935B1A1B05 for <rtcweb@ietf.org>; Sun, 19 Oct 2014 22:52:35 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id lf12so3009474vcb.17 for <rtcweb@ietf.org>; Sun, 19 Oct 2014 22:52:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FKnERibP7BJ8eyphcrrYjFkSTHFdcy48BXn1mNg/fUo=; b=V3YJiwlObqM6nkduTQc9zNmh6eWEeyh5ynrSYOuxqXZBNAp+5CywNXYzCjQXqIhyXJ azESekYIW/7eBwoYhbbk1U+7i85C7RPVwf3ie/f37Huoi3cqKSCDF1CCkcKfdM8XCpjS eD9LAh4eAKve1iE6a8NF+PbnJlZxqLQG6bzf3TtOR5GQl4O0pZd/6MvEHHcn7YxyZwf+ QNVdFx05O3Cv88tJ8kHM65bMEnog6rJrrDcp3ZhRgwZLyRk051Zqxn6WmYyeIOyv8FIc mgKJr+wid0y0OR7btS3ckvhws1YkJqdJ6EkbXGXcJPRL/+9WGdqw1GyoU18nSPLsYu1s wYqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FKnERibP7BJ8eyphcrrYjFkSTHFdcy48BXn1mNg/fUo=; b=m0fqGTyzJ+HCbtr2JbaSKgjvTw/At7ib6lbJ6arK8lXpm8ihj5AOZgX7BuEkPTcos7 JSRO2Nk3ENpqikzZWxXnuHB5ptcTOto85dSgrP49mmXwtvtIlOPdTVnkVlPUt5Yj8Gb0 1L34YCxi8deCtJcQ3iM7zn/HJfrswLiA7fCa7wVLkNmTsLJND4X1MEwHF7f3DEwTt8BD nH6v4r00ACenDJYZgkUZ78m4UtxGetG/nKixe70gUePJGtnmifVeGJr+YJAMXhotghVe G6sgucEj9xhIFV06ssBoUpJrydRVHnkCBs5mKCbEy43/5fufnkm7K1R2FvkK14i35GzB /svg==
X-Gm-Message-State: ALoCoQmSrFfQutreIHNu5qYFnw1nIjdzWILLKUreUiGCRZjlfEa0fBgmrSHkX57ZzIbUX8H3Vx5e
X-Received: by 10.220.77.196 with SMTP id h4mr21217613vck.14.1413784354216; Sun, 19 Oct 2014 22:52:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.237.130 with HTTP; Sun, 19 Oct 2014 22:52:14 -0700 (PDT)
In-Reply-To: <E36D1A4AE0B6AA4091F1728D584A6AD2400622F1@ORSMSX158.amr.corp.intel.com>
References: <CAGTXFp-HVJDwd86207PNM2QVYO4Z_K4WF-KarnRs1fb7nvy4zA@mail.gmail.com> <CA+9kkMDfES8gpi0-PTXpCnQHjFYUSF2r44TNzH5B4UfDGo8PtA@mail.gmail.com> <CAGTXFp8O-7ACksk3v3f=KjCkcDb4e8G=t-e=EJ1503vt7TkpCQ@mail.gmail.com> <CAGTXFp867AMUZ_fEKxG9uAoR1H1AirVHi3-ayJ=KTQk9L+C7+g@mail.gmail.com> <CA+9kkMAZufR7gUrwkS7Tf5GOfg+ZtsZWGcn-8YLCvnmYnTgfFw@mail.gmail.com> <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>
From: Justin Uberti <juberti@google.com>
Date: Sun, 19 Oct 2014 22:52:14 -0700
Message-ID: <CAOJ7v-13gaoqXQOH6KD9fK9C_fKSpoO4HpfNEmVanh0hTRpn9A@mail.gmail.com>
To: "Cavigioli, Chris" <chris.cavigioli@intel.com>
Content-Type: multipart/alternative; boundary=047d7b3a911c391d580505d4529a
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/g_wj-eIg7FTjmPQ5MjSyYI7M7ec
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 05:52:39 -0000

Looks like someone wants to have not just one, but two MTI codec
discussions...

On Sun, Oct 19, 2014 at 6:20 PM, Cavigioli, Chris <chris.cavigioli@intel.com
> wrote:

>  Harald said:
>
> “We made the mistake of having an MTI discussion previously with not
> enough details on that subject…”
>
>
>
> We didn’t have quantitative data earlier for a data-driven decision.
> Future Web – LTE interop is important.  A group of us in GSMA have been
> looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based
> voice/video/messaging), specifically looking at user experience impact of
> latency introduced by added in-network transcoding.  GSMA has approved the
> whitepaper and it is being prepared for public distribution.
>
>
>
> WebRTC – LTE transcoding is now MANDATORY because of “WebRTC Audio Codec
> and Processing Requirements”.
> http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio
> codecs in WebRTC and in LTE are dissimilar.  Thus, REGARDLESS of the video
> codecs, there is already a significant degradation imposed on Web – LTE
> links if only MTI codecs are used.  The only systems to avoid this are
> those which implement OPTIONAL audio codecs to be transcoder-free with
> LTE.  The same can apply for video codecs.
>
>
>
> The GSMA whitepaper refers to:
>
> 1.     Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to by
> 3GPP SA4 in August 2014.  To paraphrase, performance objectives for maximum
> VoLTE device delays in error and jitter free conditions and AMR speech
> codec operation, the sum of the UE delays in sending and receiving
> directions (TS + TR) should be ≤ 150ms. If this performance objective
> cannot be met, the sum of the UE delays in sending and receiving directions
> (TS + TR) shall in any case be ≤ 190ms.
>
> 2.     OPUS – AMR transcoding adds an additional 211.5 ms
> implementation-agnostic (TS + TR) delay, including 40 ms for jitter
> buffer and 40 ms for discontinuous reception (DRX).
>
> 3.     To put these numbers in perspective, it is in general desirable to
> minimize UE delays to ensure low enough end-to-end delays and hence a good
> conversational experience.  Increasing delay causes people to double-talk
> making conversations increasingly frustrating.  Guidance to stay below 400
> ms maximum one-way delay is found in ITU-T Recommendation G.114 and the
> computational E-model is in ITU-T Recommendation G.107.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> POSITION:  To be clear, several Intel SoCs launched at MWC this year for
> smartphones and tablets support both VP8 and H.264 hardware encode and
> decode – so Intel is codec-neutral in this MTI debate.  Additionally, Intel
> has high-performance solutions for transcoding.  However, we wish to inform
> the industry, with quantitative data, about impact to end-user experience
> of mandating such transcoding so IETF can make a data-driven decision on
> video codecs as well as reflect on the impact of already having mandated
> transcoding on the audio side.
>
>
>
> Chris Cavigioli
>
> Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile
> and Communications Group (MCG)
>
> +1 (415) 254-4545 mobile
>
> +1 (408) 653-8348 desk
>
> +1 (408) 884-2400 fax
>
> This e-mail may contain confidential and privileged material for the sole
> use of the intended recipient(s).  Any review or distribution by others is
> strictly prohibited. If you are not the intended recipient, please contact
> the sender and delete all copies.
>
>
>
> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Bernard
> Aboba
> *Sent:* Sunday, October 19, 2014 2:29 PM
> *To:* Harald Alvestrand
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] Plan for MTI video codec?
>
>
>
> Harald said:
>
>
>
> "Bernard,
>
>
> I think this is, to a large degree, codec independent.
>
> We have demonstrated interoperability on VP8 between Firefox and Chrome,
> and usage of various mechanisms for congestion control and repair of packet
> loss being applied in live services.
>
> So it can't be all bad....."
>
>
>
> [BA]  I agree that the lack of interoperability is largely "codec
> independent":   that is, implementations based on different mechanisms for
> congestion control, repair, etc. will exhibit interoperability problems,
> regardless of the codec chosen.   The real test for RTCWEB will be to move
> beyond "interoperability of implementations sharing source code"  to
> "interoperability of independent implementations, based on open standards".
>
>
>
>
> On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
> On 10/19/2014 05:43 PM, Bernard Aboba wrote:
>
>  "And its one of the issues holding up wider adoption of the technology"
>
>
>
> [BA] Specifying an MTI encoder/decoder is not sufficient for
> interoperability.  It is also necessary to specify the transport in enough
> detail to allow independent implementations that interoperate well enough
> to be usable in a wide variety of scenarios, including wireless networks
> where loss is commonly experienced.
>
>
> Bernard,
>
> I think this is, to a large degree, codec independent.
>
> We have demonstrated interoperability on VP8 between Firefox and Chrome,
> and usage of various mechanisms for congestion control and repair of packet
> loss being applied in live services.
>
> So it can't be all bad.....
>
>
>
>
>
>
> We made the mistake of having an MTI discussion previously with not enough
> details on that subject, particularly with respect to H.264.
> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.
>
>
>
> So if we are to have the discussion again, it should occur in the context
> of detailed specifications and interoperability reports.
>
>
>
>
>
>
>
>
>
>
>
> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <jdrosen@jdrosen.net>
> wrote:
>
> I'm in favor of taking another run at this.
>
>
>
> The working group has repeatedly said that an MTI codec is something we
> need to produce. And its one of the issues holding up wider adoption of the
> technology (not the only one for sure).
>
>
>
> And things have changed since the last meeting, a year ago now (November
> in Vancouver). Cisco's open264 plugin shipped and now just recently is
> integrated into Firefox. iOS8 shipped with APIs for H264. There are other
> things worth noting. Will this change the minds of everyone? Surely not.
> Will it sway enough for us to achieve rough consensus? Maybe. IMHO - worth
> finding out.
>
>
>
> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <
> agouaillard@gmail.com> wrote:
>
> +1 to not having MTI codec discussion unless some progress has been made
> on VP8 at MPEG. Any news on that? I'm sharing harald's  feeling that there
> was no change on the members position.
>
>
>
> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
> On 10/17/2014 12:02 AM, Bernard Aboba wrote:
>
> One thing we could do instead of wasting time on MTI is to actually make
> progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could
> actually interoperate regardless of the codec.
>
>
> The big argument for an MTI is actually the one stated in -overview: It
> guards against interoperability failure.
>
> I would like to have an ecosystem where one can field a box, connect it to
> everything else, and run well for *some* level of "well" - and I would
> prefer that ecosystem to be one where it's possible to field the box
> without making prior arrangements with anyone about licenses.
>
> This argument hasn't changed one whit since last time we discussed it. And
> I don't see much movement on the specifics of the proposals either.
>
> We'll have to interoperate well with the codecs we field. So using some
> time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't
> finished either. There's one sentence that needs to be removed.)
>
> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd
> prefer to re-discuss based on the knowledge that some significant players
> have actually changed their minds.
>
> At the moment, I don't see signs that any of the poll respondents have
> said "I have changed my mind".
>
> Harald
>
>
>
>
>
>  On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
> On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
> And that's because something substantive has changed, or simply because
> wasting the WG time on this again is more entertaining than actually
> finishing a specification that can be independently implemented by all
> browser vendors? (A specification that we are nowhere near having, as far
> as
> I can tell)
>
> Personally, I've found the reprieve from this fight refreshing.  And
> it would appear that we've made some real progress as a result.  I'd
> suggest that if we don't have new information, we continue to spend
> our time productively.  If we can't find topics to occupy our meeting
> agenda time, then maybe we can free an agenda slot.
>
> _______________________________________________
> 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
>
>
>
>
>
> --
>
> Alex. Gouaillard, PhD, PhD, MBA
>
>
> ------------------------------------------------------------------------------------
>
> CTO - Temasys Communications, S'pore / Mountain View
>
> President - CoSMo Software, Cambridge, MA
>
>
> ------------------------------------------------------------------------------------
>
> sg.linkedin.com/agouaillard
>
> ·
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
>
> --
>
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
>
>
> _______________________________________________
> 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
>
>
>
> --
>
> Surveillance is pervasive. Go Dark.
>
>
> _______________________________________________
> 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
>
>