- From: Chris M <spectralcodec@gmail.com>
- Date: Wed, 20 Jun 2018 10:44:32 -0700
- To: Mondain <mondain@gmail.com>
- Cc: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, MartÃn Varela <martin@callstats.io>, WebRTC WG <public-webrtc@w3.org>
- Message-ID: <CAC5DTwHV2Xgss4SvnaTSAJmtuOmTxi8cZ+=47URbqtU+3vGvuQ@mail.gmail.com>
Hi Paul, I've been using WebRTC since mid 2015 for my remotely controlled robotics applications and have found that I typically get <200ms latency on a wireless LAN (1280x720@30fps, stereo) . There were some changes to Chrome around version 45 that created more latency especially after the stream runs for more than an hour continuously. I have stuck with using Chrome version 44 as a result and from time to time test the latest versions of Chrome to see if there have been any improvements to latency. I have also recompiled Chrome with tweaks to the jitter buffer settings with mixed results, nothing that helps much. It would be great to use the latest version of Chrome especially because now that it has the getStats() API but I need to have the lowest latency possible. Anyway, I wasn't necessarily looking for an answer, just suggesting that it would be nice to get even less latency than is currently possible even if the video smoothness and quality suffers a bit. Thanks, Chris p.s. My method of testing latency involves use of two phototransistors and an oscilloscope to ensure that I'm measuring the actual "glass-to-glass" latency. On Wed, Jun 20, 2018 at 10:18 AM, Mondain <mondain@gmail.com> wrote: > Chris, you've gotta quantify "ultra low latency" if you want real answers. > The STUN process alone per spec will be ~3 seconds to start off with > although I assume you mean after all the setup and handshaking. If you add > any FEC or transcoding, add more milliseconds on top of network latency. We > work hard on Red5 Pro to get and keep latency down, but its all about > trade-offs and in some scenarios we've seen 500 ms, which to me only > qualifies as "low latency". > > Regards, > Paul > > On Wed, Jun 20, 2018 at 9:52 AM Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> i would say that if you are remotely controlling a high speed dron, the >> details of the wall you just crashed with doesn't matter much 😂😂 >> >> BR >> Sergio >> >> >> El mié., 20 jun. 2018 14:52, MartÃn Varela <martin@callstats.io> >> escribió: >> >>> Chris, >>> just out of curiosity, what kind of latency-bound robotics >>> applications do you have in mind where quality wouldn't matter much? >>> Cheers, >>> MartÃn >>> >> >>> On Wed, Jun 20, 2018 at 1:26 PM, Sergio Garcia Murillo < >>> sergio.garcia.murillo@gmail.com> wrote: >>> >>>> in terms of implementation what would that imply? >>>> >>>> I would think that this could help to remove latency at the cost of >>>> reducing reliability/quality: >>>> >>>> -enable slice mode on codecs that support it so video decoding can >>>> happen before full frame is received. >>>> -turn off lip sync >>>> -turn off packet buffers and rtx/FEC >>>> >>>> some of them are easier than others >>>> >>>> best regards >>>> Sergio >>>> >>>> >>>> >>>> El mié., 20 jun. 2018 11:00, Chris M <spectralcodec@gmail.com> >>>> escribió: >>>> >>>>> I would love to see WebRTC have the ability to run in a " ultra low >>>>> latency" mode for remote control robotics applications even at the expense >>>>> of consistent video frame rate and video quality. >>>>> >>>>> Chris >>>>> >>>>> >>>
Received on Wednesday, 20 June 2018 17:44:58 UTC