Re: [rtcweb] Plan for MTI video codec?

Ted Hardie <ted.ietf@gmail.com> Thu, 23 October 2014 15:56 UTC

Return-Path: <ted.ietf@gmail.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 C1F731ACD41 for <rtcweb@ietfa.amsl.com>; Thu, 23 Oct 2014 08:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 UvuwFFS-jZgt for <rtcweb@ietfa.amsl.com>; Thu, 23 Oct 2014 08:56:37 -0700 (PDT)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E051ACD18 for <rtcweb@ietf.org>; Thu, 23 Oct 2014 08:56:20 -0700 (PDT)
Received: by mail-ig0-f175.google.com with SMTP id uq10so3115226igb.2 for <rtcweb@ietf.org>; Thu, 23 Oct 2014 08:56:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vhAOEEtfLo51YoaC+bN65o/8iTYvOQjPtOfLyMF1Jas=; b=nB4MHL36r+hFcS8k2BWs07clse69YH5qpZ6SlQoUxw81XvJMSzR7LWAKeT1Z400RLN Hlb5nGTH8yREP4dz4IsCLfJ/bZLxjPIsEguHnfjBG5OPtYv5dLIbx25x7xlDMiNL5gt+ 819xGULTPrb6zp9Ng+0rnZwvS0o8BzHV7iTa1aM2p3d9AqjiRh0GBwrnHbhIchct8hiG D5Y9QiPxB5ot8hm9J7kK2ln1lE3PE9zmZozTOh+5AjiQ14t7cQlvxRrkaSP1G/CCo/IY 9o4SGxjJkIiRmmpjJrKDaSZ1KbKLCxKHa4uBgpqRzDlxxRFpoYK4l2xaaVcuCHmpq5md lmRw==
MIME-Version: 1.0
X-Received: by 10.43.90.198 with SMTP id bj6mr11297314icc.4.1414079779604; Thu, 23 Oct 2014 08:56:19 -0700 (PDT)
Received: by 10.43.3.4 with HTTP; Thu, 23 Oct 2014 08:56:19 -0700 (PDT)
In-Reply-To: <E36D1A4AE0B6AA4091F1728D584A6AD24007E125@fmsmsx118.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> <E36D1A4AE0B6AA4091F1728D584A6AD24007E125@fmsmsx118.amr.corp.intel.com>
Date: Thu, 23 Oct 2014 08:56:19 -0700
Message-ID: <CA+9kkMAQrxWUuWVPZ84DrRUT7R4_6b4q++XKhm6EqcpNztL=WQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: "Cavigioli, Chris" <chris.cavigioli@intel.com>
Content-Type: multipart/alternative; boundary=bcaec5196bddf291130506191a6f
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PYQ4jph76wZo2xGRrdDrAeUze7Y
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: Thu, 23 Oct 2014 15:56:42 -0000

On Thu, Oct 23, 2014 at 3:15 AM, Cavigioli, Chris <chris.cavigioli@intel.com
> wrote:

>  The GSMA white paper has been published.  Download a copy here:
> http://www.gsma.com/newsroom/webrtc-codecs-draft-v1-3/
>

​Note that this document claims to be confidential.  It's not clear to me
to whom, but IETF working groups are ​not limited in membership, so sharing
it with a working group is similar to making a public statement of its
availability.  Are you sure that this is the intent of the GSMA?


>
> Note: Transcoding can be avoided by negotiating optional codecs and
> finding a matching pair.  The GSMA white paper doesn’t focus on that case,
> but instead specifically highlights the scenario where a pure WebRTC
> endpoint is communicating with a pure 3GPP LTE VoLTE/ViLTE IMS endpoint,
> assuming each endpoint ONLY has access to the MTI codecs in its respective
> domain.
>

​While WebRTC has re-affirmed multiple times that a mandatory-to-implement
codec is an important strategy for avoiding interoperability failure, the
negotiation of mutually acceptable codecs is far more fundamental.  You
don't get a lot of list traffic on it because it is a given.

For clients which expect to interoperate with telephony systems, the
inclusion of other codecs that assist with that interoperation would be a
far more natural strategy than relying on transcoding.  There's been
discussion of which those might be already, and we can have more.

But please realize that there is a broad variety of client use cases here
and that not all of them are in the realm of telephony.  For those, the
handheld device is not really an "IMS endpoint", it is a mobile
platform--and the choice of what to include there is not limited to the
mandatory to implement IMS codecs in any way of which I am aware.

​regards,

Ted Hardie
/wearing no hat at the moment.​





> In that case, the network is responsible to transcode between (Opus or
> G.711, <WebRTC MTI video codec TBD>) and (AMR or AMR-WB, H.264).
>
>
>
> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Cavigioli,
> Chris
> *Sent:* Sunday, October 19, 2014 6:20 PM
> *To:* Harald Alvestrand; Bernard Aboba
>
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] Plan for MTI video codec?
>
>
>
> 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 <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
>
>