Screen Sharing

[Frooxius]

Hello everyone!

I've got another exciting prerelease test for you - screen sharing support! Resonite will support sharing you screen and streaming custom video without having to setup custom networking.

However before releasing this to public, I'd like a bunch of users to give this a try and polish it up in case it explodes anything or introduces potential issues.

There's still more work to be done, but it should be in a state where you can start playing with it and helping get this into a polished state.

ScreenSharingShowcase.mp4

Build Version

2026.7.23.998

WARNING: READ BEFORE YOU TEST

This is a brand new feature and not fully finished, which allows your desktop to be seen under some circumstances.

There are potential security issues - test at your own risk and only with users where you don't mind them potentially seeing your screen when they're not supposed to.

BY PARTICIPATING IN THE TESTING YOU TAKE RESPONSIBILITY FOR ANY SECURITY AND PRIVACY ISSUES THAT MIGHT OCCUR AND DO SO AT YOUR OWN RISK

That said, I've implemented a number of safety mechanisms and did some initial testing, but as with any new code, there can be issues - this is why we do the testing before this hits main!

What is being tested

This build adds screen sharing & custom video sharing functionality to Resonite. We need to make sure they work properly. There are two ways this can be done:

• Sharing Desktop Directly
  • Simplest way to do this, but only works on Windows
  • Go to Desktop tab on dash
  • Open context menu (T on desktop or whichever button opens context menu in VR)
  • Select desktop you want to stream
  • Click "Share Screen"
  • Configure the stream & start
• Custom video stream - you use OBS to stream to local RTMP endpoint and Resonite will take care of the rest
  • There's a new facet on dash "Stream Custom Video"
  • Clicking this button will spawn a video stream in the world
  • The URL of the video stream is a local endpoint you can stream to with custom software (e.g. OBS)
    • In OBS, use "Custom Stream" and put in the URL
    • The sub-path must be put as the stream key NOT part of the URL
    • Use H264 & AAC codecs

Other testing notes

• WorldPermissions has a new permission "AllowVideoStreaming"
  • This will copy AllowSpawningObjects on load, but you can disable it afterwards
• Config.json DisableDesktop should be respected by the desktop streaming - but not custom video stream
• Currently the video streaming interface is cannibalized video player - it will be replaced with a dedicated one
• The host is one who relays all the stream data - they need to have enough bandwidth to do so

Avoiding data corruption & issues

• DO NOT save your worlds - this modifies the permission system and can introduce issues
  • Save a copy instead
• Use -NeverSaveDash to avoid your dash getting messed up - the build will add new facet to it

How to test

The testing is done on prerelease branch.

• On Steam, switch to the prerelease branch and make sure the build updates before you run it
• Make sure your build version matches the one at the top of this message

What to test

• Test the streaming functionality
• Try streaming desktop (if on Windows) - with/without audio
• Try streaming custom things with OBS and other software
• Try streaming on a headless host
• Try both Windows & Linux if you can
• Try users joining and leaving in middle of streams
• Try streaming with audio and without

What to watch out for

• Streams not working
• Streams having unusual issues (other than typical video stream issues - a rare freeze here and then is ok)
• Issues with configuration/UI
• Issues with permissions not being respected
• Bandwidth usage - especially on host - watch out for bandwidth being saturated
• Streams not cleaning up after being removed
• Video / Audio sync for desktop streaming
  • Is it consistently behind/ahead?
  • Is it inconsistent?
• Processes not cleaning up (FFmpeg / MediaMTX)
• Networking breaking
  • This adds new mechanism for networking, which can introduce other issues
• Security issues
  • There's new security mechanisms to allow Desktop texture to exist in world only when explicitly created and only while a token is granted
  • Try breaking these mechanisms if you can!

What NOT to test & report

• Issues due to host not having enough bandwidth for the stream
  • If there's 10 Mbps stream with 5 users and the host only has 10 Mbps upload, it will not stream smoothly no matter what we do
• Issues with the default interface - it will be replaced with a proper one
• Streams freezing now and then and resuming shortly after
  • If it's rare enough, it's okay, it can happen
• Generally things that do not involve this system - any existing unrelated bugs with components and other systems.
  -- If you're unsure, try to replicate the issue on the main build and see if it also occurs - if it also happens there, just report it as normal bug

If you find something that got broken

• Create a GitHub issue for a pre-release bug: https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/new?template=prerelease-bug-report.yml
• Include clear description of who was streaming and where
• Make sure to include the log both from you and the host
• Please include host's bandwidth info
• Please include description of what happened. Be succinct, but exact.

If you find that stuff works okay

Please report it too and include details on what you generally tested, so we know things are okay. You don't need to make a new issue for this - just a comment in this Discussion is fine.

This lets us know that a bunch of stuff was tested and get better confidence that stuff won't break with release and the the system is reasonably secure.

How long will testing go for?

This depends on how much is broken. There's no set date, but we'll test at least until next week!

[eth0fox]

oh very nice! i guess my putting off of upgrading desktopbuddy to a version that actually works has finally paid off by it being a native feature now :p (well, it's prerelease, so i guess, soon™ rather)

the host needing to relay all traffic is understandable, but slightly concerning - i could imagine the situation where connected to a friends session and they only have, say 50mbps up, but you have a server somewhere with a 1G symm connection? i wonder, given that rtmp+mediamtx streaming is already a common setup for doing this previously, how feasible would it be to allow users to specify a 'relay' server separate from the host. kind of the opposite of the custom stream feature. of course, i could imagine this """""just""""" being a setting to specify a separate server host, but if it requires significant changes we can live with it.

potentially, and i assume you've already thought about this, but another work around would be to make receiving the stream opt in?

[Frooxius]

I'm considering adding a mode where we'd allow running the stream through a dedicated server instead (so we'd host MediaMTX instances on our infra), but that would have to be a paid feature for supporters, because that's going to cost money on our end.

With the architecture, it wouldn't be that difficult to add, it would just direct it to different endpoints + need some orchestration & authentication.

Biggest issue would just be server costs that we'd need to cover.

[polyjitter]

Would this potential feature also allow us to use our own MediaMTX instances? I'm running a personal one that I'd want to use!

[Frooxius]

If you have your own MediaMTX instance, you can already use that - the Resonite video player will play streams from those.

[polyjitter]

I moreso meant whether the desktop feature would allow me to press a button to stream seamlessly to my MediaMTX instance when the new UI is out, but I do get your point :)

[DevL0rd]

mah desktop buddy mod needed the same tbh. without adding a CDN there is no good way to avoid having to stream to everyone. so desktopbudy has frustum culling to only stream to people in front of it and watching it. and it works on linux now. but nowww we has components built it. maybe someday we wont need desktop buddy for actually controllting the shared content o.0??

Anyways nice. love yah froox. thanks for the bits :3

[polyjitter]

Is the in-world version of the screenshare using the same capture as the desktop dashboard locally? One of the things i like the best in DesktopBuddy is that it's nearly zero-latency locally for the streaming user, so it can be seamlessly used as a second screen for things like playing games while inside of Resonite.

[epicEaston197]

From what I can tell the stream in world is just using the stream that everyone else sees

[Frooxius]

@polyjitter It is for the user doing the streaming, so should have very low latency.

For everyone else it'll be video stream and will have latency.

[DevL0rd]

nice desktop buddy style :3 just add input and such so I can stop working on Desktopbuddy XD

This is gonna be siiiiick

[Frooxius]

Please follow the post instructions to report bugs.

[davidheiserca]

I want to test screen sharing. I think I'm following directions, but I don't see the Desktop Sharing option the way it is demonstrated in the "Frooxius" video of 3 weeks ago.

[ProbablePrime]

Are you on the prerelease branch?

See "How to test" for instructions to swap to it if you are not.

[davidheiserca]

Ah. That fixed it. I missed that part.

[davidheiserca]

Suggestion:

The instructions explain two modes; Sharing and Streaming. The bit about selecting the Prerelease branch applies to both modes, but it's buried in the Streaming mode section.

.Sharing Mode
.Streaming Mode
. . . .Select Prerelease

I suggest putting that right at the top.

.Select Prerelease
.Sharing Mode
.Streaming Mode

[Frooxius]

@davidheiserca We intentionally do not put it at the top, because we expect you to read through the info to understand what's being tested before you jump into the actual build.

If you're just looking to jump into the build without reading the instructions, please wait for this to release to stable branch first.

This is testing of potentially unstable and insecure feature, so reading the instructions is not optional.

[davidheiserca]

Sorry. I'm probably the oldest person in Resonite and not very smart.

I read through the instructions carefully and understood the risks. The Prerelease section seemed to relate to Streaming, not Sharing. I wasn't interested in Streaming.

[Frooxius]

2026.7.23.998 [PRE-RELEASE]
Got a prerelease update for the screen sharing! This doesn't affect the main build, only the testing branch.

If you'd like to help test, you can find more here: #6860

Fixes:

• Fixed default positioning of video stream facet preset (reported by @u1f98a, issue Screen Sharing Facet appears on top of streaming camera button #6862)
• Fixed spectator permissions having video streaming permission on by default (reported by @Qualium, @decoybird, issue I am able to spawn out a video stream with "Spectator" permissions #6868)
• Fixed direct desktop streaming not working on non-Nvidia cards (based on report by @u1f98a, @reddneko, @scrongbongle, polyjitter, Raidriar, @Bredo, issue Screensharing always tries to use NVENC, even on systems where it's not available #6864)
• Various bugfixes to starting up MediaMTX server (but needs more)

[RueShejn]

Just tested this build with @AegisTheWolf @Zyro1331 and it seems that the networking for the streams dosent connect/send any video or sound
zyro is gonna try to get some detailed logs on a clean client

the streams seem to work fine client side, as in we can all see our own stream locally but anyone else in the session cant

[epicEaston197]

Yeah it's been like that since the first release

[Zyro1331]

I've done some testing by myself but I seem to experience two different failure modes on my end each time I attempt to start a desktop stream with two local clients in a world.

Oftentimes I'll see one user receive the "Stream Offline" message which I presume means that it managed to properly acquire the video feed from MediaMTX, but something on the Streamer's end isn't working such as ffmpeg not properly broadcasting the display to MediaMTX. The other behavior I've observed is the clients failing to connect entirely and getting struck with a checkerboard instead of any displayed messages. So essentially the same behaviors that are observed in #6866

Will update with logs provided from all clients once I stop having strange technical difficulties.*
_{*I'm having an unrelated problem where my logs keep getting cut-off like the engine is not closing cleanly. This problem is currently making it difficult to provide clean logs of the described issue(s).}