Hacker Remix

Show HN: 30ms latency screen sharing in Rust

353 points by Sean-Der 10 months ago | 69 comments

Sean-Der 10 months ago

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

slashink 10 months ago

Hey Sean, we both worked at Twitch Video but I left just as you were joining. I currently work on the Discord video stack and am somewhat curious about how you imagine Discord leveraging WHIP/WHEP. Do you see it as a way for these clients to broadcast outwards to services like Twitch or more as an interoperability tool?

Sean-Der 10 months ago

Users what to send WHIP into discord. The lack of control on screen sharing today is frustrating. Users want to capture via another tool and control bitrate/resolution.

Most Broadcast Box users tell me that’s their reason for switching off discord.

———

With WHEP I want to see easier co-streaming. I should be able to connect a room to my OBS instance and everyone’s video auto show up.

I don’t have this figured out yet. Would love your opinion and feedback. Wanna comment on the doc or would love to talk 1:1 ! siobud.com/meeting

eggsome 10 months ago

What's the plan for Wayland compatibility? For a little while I was able to share a single app - but not the full desktop. Now I can't share anything from Ubuntu 24.04 when using Wayland :(

palata 10 months ago

I had to tweak a few things to make it work on my Alpine Linux. This tutorial helped a lot: https://github.com/emersion/xdg-desktop-portal-wlr/wiki/%22I...

Sean-Der 10 months ago

Another things that is in this realm. I am adding native co-streaming/conferencing to OBS [0]. OBS can send WebRTC, next I want to make receiving work well.

Between that and Simulcast I hope to make real-time video dramatically cheaper and easier

[0] https://docs.google.com/document/d/1Ed2Evze1ZJHY-1f4tYzqNZfx...

ta988 10 months ago

This would be fabulous, thank you so much for working on that. What kind of latency does dual encoding (on client then on receiver again) adds? Are there codecs that can have multiple streams on the same image (as in zones of independent streams on the video surface)?

Sean-Der 10 months ago

It definitely adds latency, not enough to be a bad experience.

We have vdo.ninja today and Twitch's Stream Together. Those both do the 'dual encoding' and it is a good enough experience that users are doing it!

xeonmc 10 months ago

Is it possible to extend OBS into a p2p video chat client?

Sean-Der 10 months ago

I don't believe it is possible today, but I am working on it! It would be great for users trying to co-stream.

I created OBS2Browser[0] that is a good first step in the direction.

[0] https://github.com/Sean-Der/OBS2Browser

makapuf 10 months ago

Great things are accomplished by spite programming! https://hackaday.com/2018/01/03/spite-thrift-and-the-virtues...

cchance 10 months ago

Question, 30ms latency sounds amazing but how does it actually compare to "the standard" sharing tools for desktops, like do you know what the latency on say MSRDP is as comparison or VNC?

Sean-Der 10 months ago

I doubt the protocol itself makes a big difference. I bet you can get 30ms with VNC. The difference with BitWHIP.

* Can play WebRTC in browser. That makes things easier to use.

* simpler/hackable software. BitWHIP is simple and uses nvenc etc… if you use nvenc with VNC I bet you can get the same experience

kiririn 10 months ago

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

Sean-Der 10 months ago

Excited to hear what you think! If there is anything I can change/improve tell me and will make it better :)

eigenvalue 10 months ago

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

mintplant 10 months ago

Looks like you need libclang for the ffmpeg bindings.

warkdarrior 10 months ago

Looks like the install script is incomplete and fails to check for and install all prerequisites.

Sean-Der 10 months ago

Sorry about that! I will continue working on improving it.

I am also going to drop the 7z usage. Powershell has unzip built in

daghamm 10 months ago

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?

mijoharas 10 months ago

I was also wondering if anyone could chime in on advantages of using just.

I'm familiar with makefiles, is there a particular advantage to using just over makefiles or is it personal preference? (which is a totally valid answer! I'm just wondering if I'm missing something)

aerzen 10 months ago

I think that the appeal of just is that it is simpler than make. It is not checking timestamps of files, but executes a DAG of tasks unconditionally.

mijoharas 10 months ago

My first thought was that that was dropping one of the main features of make.

On reflection though, the timestamp dependant part isn't really something used much nowadays apart from compiling C.

It'd be cool if it was an opt-in feature for just files so that it could actually function as a replacement for make in all cases.

I went looking in the docs and found this[0] which I'd missed last time I looked into justfiles.

[0] https://github.com/casey/just?tab=readme-ov-file#what-are-th...

daghamm 10 months ago

I don't really buy his justification that ".PHONY: xxx" is hard to remember so we should have a completly new tool instead.

Make has its issues, but it also has two big advantages: it's simple and everyone already have it.

IshKebab 10 months ago

Everyone already has it... on Linux and Mac. It's pretty rare for it to be available on Windows.

That said I kind of agree. I like the idea of `just` but it does seem like they have just created a complicated DSL.

I think it is better to just write your infra scripting in a real language. I generally use Deno or Rust itself and a thin wrapper that `cargo run`'s it. Using Rust eliminates a dependency.

mort96 10 months ago

Anyone who's halfway serious about software development on Windows surely has make there too, and it's not like non-developers are the target audience for 'just' scripts

IshKebab 10 months ago

> Anyone who's halfway serious about software development on Windows surely has make there too

Not even remotely. I know it might be hard to imagine if you only program on Linux/Mac but there's a whole world out there that isn't built on janky shell scripts and Makefiles. If you use C# or Java or Visual C++ or Qt on Windows it's pretty unlikely that you'd have Make. It's kind of a pain to install and you don't need it.

krageon 10 months ago

Literally zero of the hundreds of devs I know that do software development on windows have make installed. Why would they? It's not usual in the space at all, that's msbuild

galdosdi 10 months ago

I agree, and even more strongly: you don't even need to remember .PHONY as long as your target names don't overlap with actual filenames, which is usually easy.

In fact, I didn't even know about .PHONY and have used make for a long time. That's what's great about it, even if you stick to the most basic features make is incredibly easy and straightforward. Dare I say, it "just" works lol.

I hate the proliferation of new tools that are the same as a tool that's been around for 20 years and is no different in any significant way except being trendy. Just unnecessary entropy. Our job is to manage and reduce, not maximize entropy.

dijit 10 months ago

> it's simple and everyone already have it.

Not always, Go programmers for example often forget that they need C build-tools for their platform to get Make.

It's also just about the furthest thing from simple, the language is nasty so people just use it as an executor, which is a lot of tooling for such a simple use-case.

Arnavion 10 months ago

Also this:

>The explicit list of phony targets, written separately from the recipe definitions, also introduces the risk of accidentally defining a new non-phony target.

... seems to think the only way to define phony targets is:

    .PHONY: foo bar
    foo:
       ...
    bar:
       ...

... which has the problem that bar's definition is distant from its declaration as a phony target. But this form is equivalent and doesn't have that problem:

    .PHONY: foo
    foo:
       ...
    .PHONY: bar
    bar:
       ...

This ability to declare dependencies of a target over multiple definitions isn't even unique to `.PHONY`.

daghamm 10 months ago

Wouldn't a shell script work just as well than?

I'm not against new better tooling, but I also want to keep my dev machine reasonably clean.

IshKebab 10 months ago

Shell scripts don't work well on Windows.

hughesjj 10 months ago

Even powershell sometimes with execution policies

galdosdi 10 months ago

I would just use WSL then, if native windows dev tooling is such a shit show

mharrig1 10 months ago

I recently switched my (small) company over to using just files within our codebases and it's been going over very well thus far.

We're building a set of apps that need to run on Linux, MacOS, and Windows so having a consistent solution for each is better than shell scripting and I personally have never felt great about make and it's weirdness.

It also helps that we have a pretty big monorepo so that anyone can bounce from one app to another and `just run` to use any of them, no matter the platform.

Either way the justification for me came from COSMIC[0].

[0] https://github.com/pop-os/cosmic-epoch/blob/master/justfile

Sean-Der 10 months ago

John did all the work on this.

Just is nice as a Windows user. When I started committing everything worked really well already. Editing the just stuff also is really easy. Much nicer to read then scripts I think