Re: [rtcweb] Plan for MTI video codec?

[Ron <[e-mail]>]

On Mon, Oct 20, 2014 at 01:20:04AM +0000, Cavigioli, Chris wrote:
> 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.

That seems like LTE's problem, not ours.

If you start with a codec like Opus where the maximum native frame
size is 60ms and manage to engineer a solution that blows that out
to near 400ms, we'd certainly have to applaud your, uh, innovation.


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

You conclude that since LTE sucks, WebRTC ought to suck too?  That
seems like a strange direction to move in.  150ms is already ample
delay on its own to create a horrible user experience.  The aim of
WebRTC was to create a standard solution that doesn't suck.  If
LTE thinks it won't be able to compete with that, but considers
interoperating with it to be important, maybe it's time LTE thought
more about deploying a codec that's actually up to the job than
about protecting the royalty revenues of its voting group ...

If 150ms is your idea of a "superior end-user experience", then
maybe people who want a satisfactory user experience will simply
avoid using LTE at all, and then this won't be a problem for them,
or us, at all.

  Just sayin'