Re: [rtcweb] Transcoding

Yes, transcoding consumes significant compute resources, draws power and generates heat.  With good technology, that can be somewhat mitigated, but even if you had the world's largest supercomputer on the head of a pin, transcoding introduces speech frame buffer delays that are irreducible.  Add to those codec latencies, another set of latencies for jitter buffer in the receiver side and then also another jitter buffer in the network for the transcoder's receiver side ... then add extra buffer delays when audio and video don't sync up and you slip to the next timeslot.  In speakerphone configurations, you add extra delay for acoustic echo cancellation.  Then you add the latencies going in the return path.  Before you know it, you have significantly noticeable mouth-to-ear latencies.  Once these the round-trip delay gets to a certain level, people begin to double-talk and it makes a conversational dialog very difficult, especially when you have a multiparty call to discuss a contentious topic.

Imagine you are a service provider.  If WebRTC becomes widespread, then service providers will need to invest capex to purchase & maintain transcoders to support "free" calls.  Does this make financial business sense?

Will WebRTC gain a reputation for poor user experience due to round-trip delay?

We may argue about H.264 and VP8 today, but in the blink of an eye, we'll be arguing about H.265 and VP9 ... but wait ... there will still be H.264 and VP8 infrastructure and devices out there.  So you can either chose to transcode an ever-growing list of evolving codecs ... or better ... use OFFER/ANSWER to negotiate transcoder-free operation so that each session will narrow-down to a common codec for all participants from a constrained list of mandatory codecs.  Thus WebRTC systems must support both VP8 and H.264 today, then also VP9 and H.265 in the future ... as well as the voice channel with Opus, G.711, AMR, AMR-WB and probably eventually also EVS, G.722, etc.

Chris Cavigioli
Intel Corp, Marketing & Product Planning, Graphics/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 cb.list6
Sent: Sunday, January 12, 2014 1:13 PM
To: John Leslie
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Transcoding

On Jan 12, 2014 12:56 PM, "John Leslie" <john@jlc.net<mailto:john@jlc.net>> wrote:
>
> Karl Stahl <karl.stahl@intertex.se<mailto:karl.stahl@intertex.se>> wrote:
> >
> > [1] Transcoding VP8 ?> H.264 is very CPU intensive. Chrome with VP8 on old
> > laptops with 1 core 1.5 Ghz x86 is not even usable. Core i5 CPU is fine.
> >
> > Even the master of transcoding, ACME Packet/Oracle said at the last WebRTC
> > conference that they will not support transcoding, leaving that to others
> > real heavy DSP cabinets.
>
>    (I will write an analysis _after_ the straw poll closes; but it looks
> like that analysis will state we should consider transcoding as an
> alternative to one-or-more MTI codecs.)
>
>    Transcoding _seems_ to be almost universally rejected; but this is
> the first clear description of _why_ it's rejected.
>
>    Clearly, some hardware that we'd like to see participating in webRTC
> isn't capable of transcoding at line speed. Thus, I fully agree that we
> should reject transcoding as a requirement for _all_ webRTC devices.
>
>    But other hardware will surely be capable of transcoding at line speed.
> It might be painful, but we _could_ specify a "negotiate transcoding"
> function which decided that one end does all the transcoding -- or that
> a middleman does all the transcoding.
>
>    (Of course, part of the pain is the transcoding delay -- but IMHO
> folks are pretty tolerant of lip-sync mismatch of several hundred
> milliseconds: it's the mismatch of one second or more which is
> unbearable.)
>
>    It appears _very_ likely that several browsers will support both
> H.264 and VP8 natively; and others will be able to specify a low-
> latecy middleman. Thus, we can hope for the normal case to be no
> obvious transcoding delay...
>
>    You may flame at will...
>

I am not a codec expert.

But, it is worth noting that transcoding, to the best of my knowledge, substantially reduces quality. Any compression creates an approximation. Transcoding is an approximation of an approximation, which leads to bad quality.  So it is expensive, complex, and poor quality.

CB
> --
> John Leslie <john@jlc.net<mailto:john@jlc.net>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org<mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb