Re: [rtcweb] Plan for MTI video codec?

Harald Alvestrand <harald@alvestrand.no> Tue, 21 October 2014 05:55 UTC

Return-Path: <harald@alvestrand.no>
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 B2E211ACE70 for <rtcweb@ietfa.amsl.com>; Mon, 20 Oct 2014 22:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.909
X-Spam-Level:
X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=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 zpdb6eiZi_2c for <rtcweb@ietfa.amsl.com>; Mon, 20 Oct 2014 22:55:16 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4188D1AD040 for <rtcweb@ietf.org>; Mon, 20 Oct 2014 22:55:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0C0EB7C0ADB; Tue, 21 Oct 2014 07:55:15 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAHn2A4BMn-M; Tue, 21 Oct 2014 07:55:10 +0200 (CEST)
Received: from [10.121.43.50] (65.129-14-84.ripe.coltfrance.com [84.14.129.65]) by mork.alvestrand.no (Postfix) with ESMTPSA id BEC617C04EB; Tue, 21 Oct 2014 07:55:09 +0200 (CEST)
Message-ID: <5445F53C.8000109@alvestrand.no>
Date: Tue, 21 Oct 2014 07:55:08 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Justin Uberti <juberti@google.com>, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
References: <E36D1A4AE0B6AA4091F1728D584A6AD2400622F1@ORSMSX158.amr.corp.intel.com> <BBF5DDFE515C3946BC18D733B20DAD2339941A25@XMB122CNC.rim.net> <949EF20990823C4C85C18D59AA11AD8B2627F1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CAOJ7v-0CrYEXspFU+urB-STkuD=P4jjkBOmfEWVhP_uJuQtFeA@mail.gmail.com>
In-Reply-To: <CAOJ7v-0CrYEXspFU+urB-STkuD=P4jjkBOmfEWVhP_uJuQtFeA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------090605080105020700040302"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vt3SdCnrcPGsfstbDT9dZCPDkz8
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: Tue, 21 Oct 2014 05:55:22 -0000

On 10/21/2014 12:29 AM, Justin Uberti wrote:
> From the subject "Plan for MTI video codec", I thought this discussion
> was about video codecs, not AMR interop.

All discussions branch, but I strongly recommend changing the subject
line when changing the subject.

The discussion is supposed to be managed by the WG chairs; since they
have not spoken up on this thread at all, I must assume that they do not
wish to constrain the discussion at this time.

>
> An astute observer might take note of the fact that our inability to
> close the door on H.264 is providing an opportunity to other
> royalty-bearing codecs that want to join the party.
>
> On Mon, Oct 20, 2014 at 7:34 AM, DRAGE, Keith (Keith)
> <keith.drage@alcatel-lucent.com
> <mailto:keith.drage@alcatel-lucent.com>> wrote:
>
>     The scenario where you might want to transcode the audio codec is
>     where you have wideband audio in both the OPUS and the AMR, and
>     you believe by transcoding you can achieve a wideband quality,
>     rather than falling back to G.711. And for interworking between
>     3GPP devices that are not using webRTC, the audio will still be
>     AMR or AMR-WB or EVC, not OPUS.
>      
>     But audio transcoding is not particularly a concern for me. It is
>     trying where possible to avoid video transcoding.
>      
>     Keith
>
>         ------------------------------------------------------------------------
>         *From:* rtcweb [mailto:rtcweb-bounces@ietf.org
>         <mailto:rtcweb-bounces@ietf.org>] *On Behalf Of *Andrew Allen
>         *Sent:* 20 October 2014 14:52
>         *To:* chris.cavigioli@intel.com
>         <mailto:chris.cavigioli@intel.com>; harald@alvestrand.no
>         <mailto:harald@alvestrand.no>; bernard.aboba@gmail.com
>         <mailto:bernard.aboba@gmail.com>
>
>         *Cc:* rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>         *Subject:* Re: [rtcweb] Plan for MTI video codec?
>
>
>         Chris
>
>         What is the scenario that dictates the need for direct
>         transcoding between OPUS and AMR?
>
>         All RTCweb clients MUST support OPUS so for Web browsers on
>         mobile LTE devices OPUS can be negotiated with non mobile
>         RTCweb devices end to end.
>
>         My expectation is that for mobile devices the RTCweb client
>         will also have access to the embedded AMR codec so mobile
>         RTCweb devices can interoperate using AMR with non-RTCweb
>         enabled mobile IMS devices that support AMR.
>
>         For interoperation between non mobile RTCweb devices and
>         mobile non RTCweb IMS devices the non mobile RTCweb device can
>         use G.711 to the transcoder for transcoding to AMR on the
>         other side. While not ideal this will be no worse than non
>         mobile RTCweb devices interoperating with circuit switched
>         only mobile devices which will be forced to interoperate via
>         the PSTN.
>
>         As RTCweb becomes universal on mobile devices I expect that
>         support for OPUS will become native and mobile IMS devices
>         will also be able to use OPUS even when operating without the
>         use of the browser (i.e. in non RTCweb mode) for better
>         interoperation with non-mobile RTCweb devices.
>
>         The lifetime of most mobile devices is 2 years or less so this
>         is likely to be mainly a short term transition issue only.
>
>         Andrew
>          
>         *From*: Cavigioli, Chris [mailto:chris.cavigioli@intel.com
>         <mailto:chris.cavigioli@intel.com>]
>         *Sent*: Sunday, October 19, 2014 09:20 PM Eastern Standard Time
>         *To*: Harald Alvestrand <harald@alvestrand.no
>         <mailto:harald@alvestrand.no>>; Bernard Aboba
>         <bernard.aboba@gmail.com <mailto:bernard.aboba@gmail.com>>
>         *Cc*: rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>         <rtcweb@ietf.org <mailto: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 (T_S + T_R ) should be ≤ 150ms. If this performance
>         objective cannot be met, the sum of the UE delays in sending
>         and receiving directions (T_S + T_R ) shall in any case be ≤
>         190ms.
>
>         2.     OPUS – AMR transcoding adds an additional 211.5 ms
>         implementation-agnostic (T_S + T_R ) 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 (T_S + T_R ) 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 <tel:%2B1%20%28415%29%20254-4545> mobile
>
>         +1 (408) 653-8348 <tel:%2B1%20%28408%29%20653-8348> desk
>
>         +1 (408) 884-2400 <tel:%2B1%20%28408%29%20884-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
>         <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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:martin.thomson@gmail.com>>
>         wrote:
>
>         On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at
>         <mailto: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 <mailto:rtcweb@ietf.org>
>         https://www.ietf.org/mailman/listinfo/rtcweb
>
>         _______________________________________________
>         rtcweb mailing list
>         rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>         https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>         _______________________________________________
>         rtcweb mailing list
>         rtcweb@ietf.org <mailto: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 <http://sg.linkedin.com/agouaillard>
>
>         ·          
>
>
>         _______________________________________________
>         rtcweb mailing list
>         rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>         https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>          
>
>         -- 
>
>         Jonathan Rosenberg, Ph.D.
>         jdrosen@jdrosen.net <mailto:jdrosen@jdrosen.net>
>         http://www.jdrosen.net
>
>
>         _______________________________________________
>         rtcweb mailing list
>         rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>         https://www.ietf.org/mailman/listinfo/rtcweb
>
>          
>
>          
>
>         _______________________________________________
>
>         rtcweb mailing list
>
>         rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>
>         https://www.ietf.org/mailman/listinfo/rtcweb
>
>          
>
>         -- 
>
>         Surveillance is pervasive. Go Dark.
>
>
>         _______________________________________________
>         rtcweb mailing list
>         rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>         https://www.ietf.org/mailman/listinfo/rtcweb
>
>          
>
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>


-- 
Surveillance is pervasive. Go Dark.