Re: [rtcweb] Transcoding

[John Leslie <[e-mail]>]

Cavigioli, Chris <[e-mail]> wrote:
> 
> Yes, transcoding consumes significant compute resources, draws power
> and generates heat.

   All true...

> 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.

   Not sure what "speech frame buffer delays" means; but yes, transcoding
introduces video delays.

> 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.

   Those latencies really shouldn't be blamed on transcoding.

> In speakerphone configurations, you add extra delay for acoustic echo
> cancellation.

   Agreed that echo-cancellation adds delay -- but again, that shouldn't
be blamed on transcoding. (BTW, I'm not a fan of echo-cancellation in
best-effort-Internet telephony.)

> Then you add the latencies going in the return path. Before you know
> it, you have significantly noticeable mouth-to-ear latencies.

  Agreed it's really easy to get noticeable mouth-to-ear latency.

> 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.

   I have experienced such latencies. It's really painful. But recall
that there was useful earth-to-moon conferencing -- so I don't think
we should forbid such latencies: it feels like an application-level
consideration.

> Imagine you are a service provider.

   That's easy! ;^)

> If WebRTC becomes widespread, then service providers will need to
> invest capex to purchase & maintain transcoders to support "free"
> calls.

   Actually, we don't need to...

> Does this make financial business sense?

   In some cases, yes. In the other cases, we let someone else do the
investing.

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

   Not if there are a majority of cases where delay is no worse than
the PSTN.

> 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.

   Yes!!!

> 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

   Exactly!

> from a constrained list of mandatory codecs.

   Good lord no! We should never limit the choice to MTI 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.

   (I don't get it... Why would any sane engineer want to go _there_?

--
John Leslie <[e-mail]>