Show HN: 30ms latency screen sharing in Rust

I wrote this to solve a few things I cared about.

* I want to show people that native WebRTC players can be a thing. I hope this encourages hangouts/discord/$x to implement WHIP and WHEP it would let people do so much more

* I wanted to make low latency sharing easier. I saw the need for this working on adding WebRTC to OBS and Broadcast Box[0]

* I wanted to show devs what a great ecosystem exists for WebRTC. Lots of great implementations in different languages.

* Was a bit of a ‘frustration project’. I saw a company claiming only their proprietary protocol can do latency this low. So I thought ‘screw you I will make an open source version!’

[0] https://github.com/glimesh/broadcast-box

As someone who setup a discord streaming like service to use alongside Mumble, this is very exciting. I couldn’t get anything involving webrtc working reliably, but the only broadcasting clients I found were web browsers and OBS, so I am interested to see how this compares!

What I eventually settled on was https://github.com/Edward-Wu/srt-live-server with OBS and VLC player, which gives robust streaming at high bitrate 4k60, but latency is only 1-2 seconds

Couldn't get it to work in Windows 11. Was able to run the just install script only after editing it to use the full path to the 7zip binary. Said it installed correctly, but then when I try to do `just run play whip` I got this:

  cargo:rustc-cfg=feature="ffmpeg_7_0"
  cargo:ffmpeg_7_0=true

  --- stderr
  cl : Command line warning D9035 : option 'o' has been deprecated and will be removed in a future release
  thread 'main' panicked at C:\Users\jeffr\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bindgen-0.69.4\lib.rs:622:31:
  Unable to find libclang: "couldn't find any valid shared libraries matching: ['clang.dll', 'libclang.dll'], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: [])"
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

What is the reason for using "just" here?

I understand people have their tooling preferences, but this looks like something that build.rs or a plain makefile could have handled?

Ooh, I’ve been looking for a good solution for this for years. Currently I use Parsec, but it’s closed source and not compatible with direct streaming from OBS etc. I’ll definitely check this out.

Always a bit sceprical when it comes to latency claims, especially in the sub 100ms space, but screen sharing 1-1 or video ingest should be a great use case for WebRTC

WebRTC is a great technology, but it still suffers from a scaling problem that is harder to resolve. On top of that, the protocol itself does not define things like adaptive bitrate switching or stalling recovery

Curious to hear what you think of some (proprietary) options for low latency playback like LLHLS LLDASH, WebRTC or HESP

I wrote a blog post about how numbers like "30ms latency" are thrown around called "How to lie about latency": https://www.obe.tv/how-to-lie-about-latency/

It's left as an exercise to the reader which methods of lying are being used in this case.

Amazing work! The most I could achieve is ~40ms of video streams, although it was over a cellular network from a drone. But 30ms is a new milestone! I will see if I can repurpose this and test out a real-time video stream from a robot if I get some spare time.

I don't get what it does, exactly? This doesn't seem to be an OBS alternative (judging by the description), but… I mean, isn't it exactly the same as just running OBS directly?

mostly glues two libraries? ffmpeg from capture, play and whip?

How does this compare with Moonlight?

Can this be used as remote desktop?

Why is the 30ms significant?

vdo.ninja is another excellent alternative but I'll definitely check this out!