Re: Low latency video in WebRTC

Yeah Chrome and all browsers in-general have been "fun" to keep compatible;
been in the WebRTC game since 2013; fondly remember the weekly moving
targets for support during development. Sub half second is quite good and
probably qualifies as ultra-low, in our case we put a server in the middle,
no P2P. I find your means of glass to glass testing interesting!

Best of luck with your bots!

On Wed, Jun 20, 2018 at 10:44 AM Chris M <spectralcodec@gmail.com> wrote:

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