Re: [rtcweb] Plan for MTI video codec?
Leon Geyser <lgeyser@gmail.com> Thu, 23 October 2014 14:57 UTC
Return-Path: <lgeyser@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 89C0A1A9241 for <rtcweb@ietfa.amsl.com>; Thu, 23 Oct 2014 07:57:42 -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 GrOkkZQHeYvv for <rtcweb@ietfa.amsl.com>; Thu, 23 Oct 2014 07:57:38 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDA41A9238 for <rtcweb@ietf.org>; Thu, 23 Oct 2014 07:57:37 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id q5so943700wiv.2 for <rtcweb@ietf.org>; Thu, 23 Oct 2014 07:57:36 -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=/TwwLyEtF2fsbz+auQReYX72vdr0IofqbNGZHV0JYas=; b=DPaFDHIfASn70ZmOYQPVKLWQFYXmBjORbNoyYmhpxYe+fZAcOybCU3hHBo8J4/HYyV dz8YMCK89qKiHrIQi+0PxmAeftv+5AiEtcodvrFAlIIxYZzafokaAjp2qgiaGr6XPF1J w84GGe7Zy6ueg1KXFBjuD1A/RB1OKeB0SuC3/is065J35dk87zgTHS3JdlFaFY1S7+HI Oey1x7U8T0FBHDcl4qiS1l9++UHtYmAd58de3DN0K0o9X8gFemLrP9y/tidcA+6V52th F4IpyaLX/ySyy5kywCbNB9J/7RadYl2NDezYVRu5TRltmAodAg4/Wld9qgPas/YgrMU5 wQ/A==
MIME-Version: 1.0
X-Received: by 10.194.92.12 with SMTP id ci12mr6088903wjb.6.1414076256332; Thu, 23 Oct 2014 07:57:36 -0700 (PDT)
Received: by 10.194.95.194 with HTTP; Thu, 23 Oct 2014 07:57:35 -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 16:57:35 +0200
Message-ID: <CAGgHUiRFeN6Kb44U-OCo9Y1=yMH9U8-tXxLTqaS0S_wwmxxaDA@mail.gmail.com>
From: Leon Geyser <lgeyser@gmail.com>
To: "Cavigioli, Chris" <chris.cavigioli@intel.com>
Content-Type: multipart/alternative; boundary="047d7bfd08baf1b1590506184886"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DpKIWIUTcmCyPc_rzvuwE4V2H68
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 14:57:42 -0000
In section '6 Use Cases' it seems like there isn't any transcoding required between AMR-WB <-> EVS Can an AMR-WB decoder decode an EVS stream? On 23 October 2014 12:15, 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: 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. 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 > >
- [rtcweb] Plan for MTI video codec? Victor Pascual Avila
- Re: [rtcweb] Plan for MTI video codec? Victor Pascual Avila
- Re: [rtcweb] Plan for MTI video codec? Ted Hardie
- Re: [rtcweb] Plan for MTI video codec? Bernard Aboba
- Re: [rtcweb] Plan for MTI video codec? Matthew Kaufman
- Re: [rtcweb] Plan for MTI video codec? Martin Thomson
- Re: [rtcweb] Plan for MTI video codec? Peter Saint-Andre - &yet
- Re: [rtcweb] Plan for MTI video codec? Bernard Aboba
- Re: [rtcweb] Plan for MTI video codec? Cavigioli, Chris
- Re: [rtcweb] Plan for MTI video codec? Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Plan for MTI video codec? Roman Shpount
- Re: [rtcweb] Plan for MTI video codec? DRAGE, Keith (Keith)
- Re: [rtcweb] Plan for MTI video codec? Harald Alvestrand
- Re: [rtcweb] Plan for MTI video codec? Alexandre GOUAILLARD
- [rtcweb] VP8 in ISO (Re: Plan for MTI video codec… Harald Alvestrand
- Re: [rtcweb] VP8 in ISO (Re: Plan for MTI video c… Alexandre GOUAILLARD
- Re: [rtcweb] Plan for MTI video codec? Jonathan Rosenberg
- Re: [rtcweb] Plan for MTI video codec? Bernard Aboba
- Re: [rtcweb] Plan for MTI video codec? Alexandre GOUAILLARD
- Re: [rtcweb] Plan for MTI video codec? Watson Ladd
- Re: [rtcweb] Plan for MTI video codec? Jeremy Laurenson (jlaurens)
- Re: [rtcweb] Plan for MTI video codec? Jonathan Rosenberg
- Re: [rtcweb] Plan for MTI video codec? Alexandre GOUAILLARD
- [rtcweb] Scheduling a separate slot for MTI VC Di… Emil Ivov
- Re: [rtcweb] Plan for MTI video codec? Bernard Aboba
- Re: [rtcweb] Plan for MTI video codec? Harald Alvestrand
- Re: [rtcweb] Plan for MTI video codec? Bernard Aboba
- Re: [rtcweb] Plan for MTI video codec? Stephan Wenger
- Re: [rtcweb] Plan for MTI video codec? Cavigioli, Chris
- Re: [rtcweb] Plan for MTI video codec? Ron
- Re: [rtcweb] Plan for MTI video codec? Ca By
- Re: [rtcweb] Plan for MTI video codec? Justin Uberti
- Re: [rtcweb] Plan for MTI video codec? Victor Pascual
- Re: [rtcweb] Plan for MTI video codec? Cavigioli, Chris
- Re: [rtcweb] Plan for MTI video codec? Barry Dingle
- Re: [rtcweb] Plan for MTI video codec? DRAGE, Keith (Keith)
- Re: [rtcweb] Plan for MTI video codec? Martin Thomson
- Re: [rtcweb] Plan for MTI video codec? Andrew Allen
- Re: [rtcweb] Plan for MTI video codec? DRAGE, Keith (Keith)
- Re: [rtcweb] Plan for MTI video codec? Justin Uberti
- Re: [rtcweb] Plan for MTI video codec? Roman Shpount
- Re: [rtcweb] Plan for MTI video codec? Iñaki Baz Castillo
- Re: [rtcweb] Plan for MTI video codec? Barry Dingle
- Re: [rtcweb] Plan for MTI video codec? Bernard Aboba
- Re: [rtcweb] Plan for MTI video codec? Victor Pascual
- Re: [rtcweb] Plan for MTI video codec? Harald Alvestrand
- Re: [rtcweb] Plan for MTI video codec? Olle E. Johansson
- Re: [rtcweb] Plan for MTI video codec? DRAGE, Keith (Keith)
- Re: [rtcweb] Plan for MTI video codec? Ted Hardie
- Re: [rtcweb] Plan for MTI video codec? Stephan Wenger
- Re: [rtcweb] Plan for MTI video codec? Mohammed Raad
- Re: [rtcweb] Plan for MTI video codec? Cavigioli, Chris
- Re: [rtcweb] Plan for MTI video codec? Leon Geyser
- Re: [rtcweb] Plan for MTI video codec? Iñaki Baz Castillo
- Re: [rtcweb] Plan for MTI video codec? Ted Hardie
- Re: [rtcweb] Plan for MTI video codec? Stephan Wenger
- Re: [rtcweb] Plan for MTI video codec? Randell Jesup
- Re: [rtcweb] Plan for MTI video codec? Adam Roach
- Re: [rtcweb] Plan for MTI video codec? Cavigioli, Chris
- Re: [rtcweb] Plan for MTI video codec? Florian Weimer
- Re: [rtcweb] Plan for MTI video codec? markus.isomaki
- Re: [rtcweb] Plan for MTI video codec? Roman Shpount
- Re: [rtcweb] Plan for MTI video codec? Ron
- Re: [rtcweb] Plan for MTI video codec? markus.isomaki
- Re: [rtcweb] Plan for MTI video codec? Mohammed Raad
- Re: [rtcweb] Plan for MTI video codec? Ron