- From: Chris M <spectralcodec@gmail.com>
- Date: Fri, 29 Jun 2018 12:14:25 -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: <CAC5DTwFHi8wToiA9Bk+-RLNY-OmEvcGBOPmksCFXLocS4_k0fQ@mail.gmail.com>
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! Chris 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