Re: [rtcweb] Plan for MTI video codec?

Ted Hardie <ted.ietf@gmail.com> Tue, 21 October 2014 14:45 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 0C0721A700B for <rtcweb@ietfa.amsl.com>; Tue, 21 Oct 2014 07:45:39 -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 ViMZrUnJ6pyW for <rtcweb@ietfa.amsl.com>; Tue, 21 Oct 2014 07:45:34 -0700 (PDT)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5DD1A86ED for <rtcweb@ietf.org>; Tue, 21 Oct 2014 07:45:33 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id x19so758316ier.2 for <rtcweb@ietf.org>; Tue, 21 Oct 2014 07:45:33 -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=XeS7cNB8YRDMnjLRDpnHGZtC4KxKGf2lU0H4SWDF0Xk=; b=HgrkXXW6fNWx7iK4et/NBCkj7BkvcBVI4N/oeRbKX23k2K9ijXiXn/r1bUU+6L0NWz 6RG5gL31WdDH0pr1NpGOWLQzEvirt4UEsRGoMuyR3dsa0U5kSOEM7yepOo1UDWSRTLc+ hV6rKgzUYN+/hXXp6Fla/qgpgVcz1iOzcCZU2x2qDU3iA5coPx3jRH8YneTzZS86/A7C pyUsN+2Yng+Om1iNmz94DBYtddEKln6bWXhvVy+lJ8fQzN4uTceejlDmbfWT0O5w7++w Nh30Y+OelxLfWV6RnzYOqQfgHtv7Q10fnUvsKjXGFYPggAHpapOqQLfyfZIE9v1EBlT0 G9pQ==
MIME-Version: 1.0
X-Received: by 10.107.31.202 with SMTP id f193mr37956246iof.16.1413902733176; Tue, 21 Oct 2014 07:45:33 -0700 (PDT)
Received: by 10.43.3.4 with HTTP; Tue, 21 Oct 2014 07:45:32 -0700 (PDT)
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B263123@FR712WXCHMBA11.zeu.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> <949EF20990823C4C85C18D59AA11AD8B263123@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Tue, 21 Oct 2014 07:45:32 -0700
Message-ID: <CA+9kkMDLuZQn3iaNACT8fD8v9ZF7jkpk9Wy+LbFdivPab84V6g@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary=001a1140cac02877a00505efe220
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uhQAsMwDBs0ferbZ-J8yHIYwl1k
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 14:45:40 -0000

I would appreciate folks moving off the question of whether the video codec
discussion should be part of the agenda could change the topic.

thanks,

Ted

On Tue, Oct 21, 2014 at 2:08 AM, DRAGE, Keith (Keith) <
keith.drage@alcatel-lucent.com> wrote:

>  With respect to audio codecs I was replying to a question from the
> previous message in the thread. But...
>
> The MTI discussion does not close the door on any codec, as any codec can
> be supported, just not mandatory to implement.
>
> Your argument to eliminate H.264 only applies if you can either eliminate
> interworking with the rest of the world or you can persuade all those
> legacy devices to remove H.264 and use something else, which in my view is
> totally impractical.
>
> MTI might persuade usage of that codec, but it will only do that if the
> MTI codec actually supports end to end communication of the required video
> capabilities. Neither VP8 or H.264 fit all those requirements.
>
> Keith
>
>  ------------------------------
> *From:* Justin Uberti [mailto:juberti@google.com]
> *Sent:* 20 October 2014 23:29
> *To:* DRAGE, Keith (Keith)
> *Cc:* Andrew Allen; chris.cavigioli@intel.com; harald@alvestrand.no;
> bernard.aboba@gmail.com; rtcweb@ietf.org
>
> *Subject:* Re: [rtcweb] Plan for MTI video codec?
>
>  From the subject "Plan for MTI video codec", I thought this discussion
> was about video codecs, not AMR interop.
>
>  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> 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] *On Behalf Of *Andrew
>> Allen
>> *Sent:* 20 October 2014 14:52
>> *To:* chris.cavigioli@intel.com; harald@alvestrand.no;
>> bernard.aboba@gmail.com
>>
>> *Cc:* 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]
>> *Sent*: Sunday, October 19, 2014 09:20 PM Eastern Standard Time
>> *To*: Harald Alvestrand <harald@alvestrand.no>no>; Bernard Aboba <
>> bernard.aboba@gmail.com>
>> *Cc*: rtcweb@ietf.org <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] *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 mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>