Re: [rtcweb] Plan for MTI video codec?

["Cavigioli, Chris" <[e-mail]>]

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:[e-mail]] On Behalf Of Cavigioli, Chris
Sent: Sunday, October 19, 2014 6:20 PM
To: Harald Alvestrand; Bernard Aboba
Cc: [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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> wrote:
On 16 October 2014 14:17, Matthew Kaufman <[e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[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<http://sg.linkedin.com/agouaillard>
·

_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb



--
Jonathan Rosenberg, Ph.D.
[e-mail]<mailto:[e-mail]>
http://www.jdrosen.net

_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________

rtcweb mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/rtcweb


--

Surveillance is pervasive. Go Dark.

_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb