W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2018

Re: Low latency video in WebRTC

From: Chris M <spectralcodec@gmail.com>
Date: Fri, 29 Jun 2018 12:14:25 -0700
Message-ID: <CAC5DTwFHi8wToiA9Bk+-RLNY-OmEvcGBOPmksCFXLocS4_k0fQ@mail.gmail.com>
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>
I've recently been wondering if perhaps using WebRTC in the browser is not
the best method of streaming HD video for my robotics application.  I have
seen some references in the forum to running a "native" WebRTC app but
would that still require a signalling server?  Or maybe there is an
alternative to WebRTC altogether that would be better suited for doing
low-latency LAN based point to point HD streaming.  I remember trying to
use VLC, Gstreamer, ffmpeg a while back but the latency was way too much.
Any suggestions would be appreciated!


On Wed, Jun 20, 2018 at 11:25 AM Mondain <mondain@gmail.com> wrote:

> 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
Received on Friday, 29 June 2018 19:14:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:42 UTC