Re: [rtcweb] Plan for MTI video codec?

[Justin Uberti <[e-mail]>]

>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) <
[e-mail]> 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:[e-mail]] *On Behalf Of *Andrew
> Allen
> *Sent:* 20 October 2014 14:52
> *To:* [e-mail]; [e-mail];
> [e-mail]
>
> *Cc:* [e-mail]
> *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:[e-mail]]
> *Sent*: Sunday, October 19, 2014 09:20 PM Eastern Standard Time
> *To*: Harald Alvestrand <[e-mail]>; Bernard Aboba <
> [e-mail]>
> *Cc*: [e-mail] <[e-mail]>
> *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)
>
> [phone] mobile
>
> [phone] desk
>
> [phone] 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:[e-mail]] *On Behalf Of *Bernard
> Aboba
> *Sent:* Sunday, October 19, 2014 2:29 PM
> *To:* Harald Alvestrand
> *Cc:* [e-mail]
> *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 <[e-mail]>
> 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 <[e-mail]>
> 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 <
> [e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> wrote:
>
> On 16 October 2014 14:17, Matthew Kaufman <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
>
> --
>
> Jonathan Rosenberg, Ph.D.
> [e-mail]
> http://www.jdrosen.net
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
>
> _______________________________________________
>
> rtcweb mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --
>
> Surveillance is pervasive. Go Dark.
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>