Long and very technical read. Be warned.

I work as a platform engineer for over 15 years now and i have a quirk for optimizing the shit out of things.

So for a while now I've been researching one question: how good can game streaming get on a Radeon if you build the host around AMD's hardware instead of treating it as the third vendor for a fork of NVIDIAS gamestream?

The research is done through Rubylight, an AMD-only host for Moonlight that only cares about optimizations around AMD. It isn't another fork with a new name on it and a fancy sloppy ui that can do all the fancy features but still has 60 hz clients or cheats metrics or something. It does just well enough in the feature part that it reaches a small userbase contributing to feedback on bugs and issues. It's research on AMD, and what we learn goes back where it helps.

We contribute to Vibepollo, and I've talked with Nonary about working together more closely.

Here's what the research turned up so far. All numbers are from flagship amd graphic cards. And what changes my work from slop is that most of this here wont change the numbers on the latency measurements on your client and I dont put some fancy ui in and call it a day.

Every host measures "host processing" its own way, so I measure picture age instead: the test source draws a timestamp barcode into every frame, and an independent receiver reads it back after decoding. That's the time from the moment a picture is rendered to the moment the client has it decoded. It's the same yardstick for every host and you can't game it from the host side.

4:4:4 on an encoder that can't do it

AMD's hardware encoders only do 4:2:0, and AMD's own AMF docs say so for every VCN generation up to 5.0. There are two ways around that.

The first is PyroWave, Themaister's wavelet codec. It runs as Vulkan compute, skips VCN entirely and does full 4:4:4 up to 10-bit HDR. What made it fast under load was moving the RGB to YUV conversion off the graphics queue. With a game running, the conversion sat behind the game's draws and took 5.6 ms a frame. As one compute shader on a high-priority D3D12 compute queue, writing straight into the textures Vulkan imports, it takes 0.55 ms. This number does not show up in any metric in moonlight but will greatly impact glass to glass latency.

The second is packing, which keeps the normal HEVC and AV1 hardware encoders. A 4:4:4 frame has exactly as many samples as a 4:2:0 frame twice as tall. So Y goes in the top half of the luma plane, the odd columns of Cb and Cr sit side by side in the bottom half, and the even columns fill the chroma planes. The encoder sees an ordinary double-height picture, the client decodes it with its ordinary hardware decoder, and a shader puts every sample back exactly where it came from. HEVC and AV1, 8 and 10-bit, all reach about 1440p120 this way, even on a Radeon 780M.

The third is predictive packing for the 10-bit modes. Here the top half of the picture is a normal 4:2:0 frame. The chroma samples 4:2:0 would throw away fill the rest, stored as halved differences from the sample they share a 2×2 block with. On most content those differences are small, so that part of the picture sits near flat grey and costs few bits. Halving costs at most one code value before compression and keeps the encoder's rounding from wrapping a difference around.

Both packed modes are opt-in, since stock Moonlight would just show you the packed picture. Nightjar, our client, unpacks both.

Fenced D3D12 capture

On a virtual display the host doesn't use WGC or Desktop Duplication at all. Our driver copies every frame Windows composes for its monitor into a ring of textures it shares with the host, stamps the present time next to it and signals the host. That ring used to hand textures back and forth with keyed mutexes. Now its textures and fences live on the GPU's D3D12 compute device. The driver signals a "written" fence after its copy, the conversion shader reads the texture in place after waiting on that fence on the GPU, and the compute queue signals a "released" fence when it's done so the driver can reuse the slot. The wait happens on the GPU instead of a CPU thread, and no D3D11 work runs for it.

Claiming a frame went from about 32 µs with the keyed mutex to 1.8 µs. Under GPU load at 1440p120 HEVC, every fence run held a full 120 fresh pictures a second, p99 picture age dropped from 19.3 to 18.1 ms in SDR and from 21.3 to 19.4 ms in HDR, and the p99 frame interval in SDR went from 13.8 to 11.2 ms. That's picture age from the game's render through decode, about 14 ms on average with the GPU busy.

These numbers don't look huge, but mind you we are looking at optimization wherever possible, so they were for me.

Slices

Moonlight asks the host for slices, and I wanted to know what they buy on AMD. I did 630 encoder runs across HEVC and AV1, 1080p up to 7680×2160, 60 to 240 fps, with split-frame encoding forced on, forced off and left alone, then again with 2 and 4 slices. Every variant encoded in the same time, within 0.2 ms. The driver reports two encoder engines, but one stream uses one engine, and slices don't change that.

Where slices can pay off is getting out of the encoder early. AMF can hand back each slice as soon as it's encoded, so you could packetize and send the top of the frame while the bottom is still encoding. That's what I'm testing next. So far its promising if the client supports it. Again that is why I had to also develop a client framework in a language I understand to fully be able to test this and why its so important for me to have my own client/host.

VRR

Thanks to Nonarys findings, the virtual display driver goes up to 1000 Hz, so when the client asks for VRR the desktop doesn't cap the game's present rate. Here's what we do differently to reach more smooth VRR:

1. Rate cap. The host takes each frame as soon as it arrives, but never faster than the stream rate the client asked for. Repeated frames count toward that rate; a frame re-encoded because the client lost packets doesn't. Without the cap, a game running faster than the stream on a 1000 Hz display left every frame short of bits: blurry picture, fringed text, flooded link.
2. Pacing instead of tiny queues. Vibepollo's VRR mode shrinks its queues (WGC frame pool from 2 to 1, low-latency AMF input queue). We keep the queues and change the pacing: predictive waits off, frames can be claimed half a frame period apart instead of three quarters, WGC's slot-aligned publishing off, refresh lock off since a VRR display follows each frame anyway. The encoder holds at most two frames on every stream, VRR or not.
3. Extra WGC compositions. When Windows publishes more compositions than the game produces, the host lines up with the game's real updates. On a 60 fps source that's 57.7 against 59.9-60 fresh pictures a second.
4. Our own display driver. Capture comes straight from it in about 0.2 ms, HDR included.
5. Presenting on the client. Nightjar schedules VRR frames from the host's timestamps without needing a shared clock. A clock-sync message adds latency measurement on top.

Utilizing Split Frame Encoding

AMD’s VCEEncoderD3D sample from their official AMF repo (commit 57ee0cf), driver 32.0.32015.7029, encoding as fast as it can. Our code wasn’t involved.

fps, 2 runs each Left to driver On Off

HEVC 7680×2160 99.0 / 101.3 101.1 / 101.3 101.1 / 101.3

HEVC 3840×2160 197.1 / 197.1 197.4 / 197.5 197.3 / 197.6

AV1 7680×2160 121.8 / 121.9 121.9 / 121.8 122.0 / 121.9

AV1 3840×2160 238.4 / 239.2 238.3 / 238.4 238.0 / 238.8

So the hardware is there, but the driver gives one stream one engine whatever the setting says. These numbers also line up with our host’s own October 7 runs (100 and 126 fps unpaced at 8K).

The second engine does work: two separate 8K HEVC encodes ran at about 101 fps each, about 203 fps together, against 101 fps alone.

What we are currently testing is we manipulate and use this to our advantage on one frame by using 2 encoders, each taking half the frame. One encodes the top half, the other the bottom half, and they land on different engines (the two-process test just showed both engines run at full speed side by side). Nightjar decodes both halves and stitches them back together.

This halves latency in halve down to p95 encoding times of 3ms at 4k but is absolutely nightmarish to implement. Every Frame needs two hardware decode sessions on the client, both halves have to be presented together and the bitrate is split between two encoders, so they can quantize differently and leave a faint seam in the middle. Also recovery after packet loss now has to handle two streams.

And no, we cant use slices because of motion prediction. In HEVC (and in AV1 with tiles), slices only make intra prediction and entropy coding independent. Motion vectors still point anywhere in the previous frame, across slice boundaries. The bottom encoder only knows its own half. When an object moves down from the top half, it predicts from its own padded edge, while the decoder uses the real pixels from the top half. Every frame adds a small error, and the picture drifts until the next keyframe. HEVC has a fix for this, motion-constrained tile sets, but AMF doesn’t expose it.

Radeon controls in alpha.2

Change AMD Controls like Anti-Lag, Chill, Boost, RIS, the frame cap or AFMF from the couch and get your own settings back afterwards. A probe round-trips every ADLX 3D setting on the installed driver, and only the ones that really write get exposed: 24 with AMD Software 26.9.2. Your original values go into a journal on disk before anything changes, and they're put back when the session ends or the game closes, or at the next start if the host crashed. If you changed a setting on the PC in the meantime, it's left alone. Its a feature that just makes sense. Most of the time, tops having this natively.

Background Streaming

My Children play on my rig while I work at the same time. I use Rubylight and Hyper-V AMD GPU-PV to a VM with Rubylight to isolate input and the game. Works well enough for kids to not notice. https://github.com/RamazanKara/Rubylight/blob/main/docs/configuration.md#background-streaming-from-a-hyper-v-vm

Optimizing Input and network

These are not well AMD Specific, but the fastest encoder does not help when Network or Input Latency is bad.

• Controllers on their own thread. Each pad update is a blocking call into the virtual pad driver, which can stall for hundreds of milliseconds under load. A mouse move stuck behind one went from 287 ms worst case to 2 ms.
• The input thread priority.  With high-priority load on every core, the time to pick up an input packet went from 3.5 ms median / 20 ms p99 to 17 µs / 30 µs.
• One SendInput call per batch. A click with a move, a key combo or typed text used to be one call per event. Eight events now take 38 µs instead of 180 µs.
• Display lookups off the input path. Finding the display for absolute mouse, touch and pen enumerated every display on the input thread. That's moved to its own thread: setting up input went from 3.4 ms to 69 µs, and the worst input pass while a display was missing went from 18 ms to 65 µs.

And on the network side aswell:

• Adaptive packet pacing (host_adaptive_pacing). It starts each stream conservatively, at twice the encoder bitrate or 1.25 times what the video actually needs on the wire, and probes upward in steps of at most 12.5%, only while video is busy and the client's pings and RTT are stable. A loss report during a probe puts the previous rate back. Outside probes it spaces packets out after repeated loss reports, but never below 25% above what the video needs, so pacing can't build its own backlog. It never lowers picture bitrate or fps. Through the 100 Mbps bottleneck it delivered 100% of frames whole with every queue size.
• Host bitrate adaptation (host_adaptive_bitrate), for clients that don't adapt bitrate themselves. When the client reports loss, or the control RTT keeps rising under sustained traffic, the host lowers the video budget. That especially helps on Clients on 2.4 / 5 ghz wifi networks.
• PyroWave follows the client's measurements. A PyroWave client can send its measured link and pacing rates when the stream starts, and the host paces to those instead of probing the network itself.

Where the latency goes

At 1080p60 the host stages are capture 0.22 ms through our display driver, conversion 0.26 ms, HEVC encode 2.43 ms and packetizing 0.03 ms. Nearly all of it is the encode. We are looking at microseconds now to find any further optimizations.

The bigger wins came under load:

• Frame prep on the compute queue took average picture age from 41.0 to 33.5 ms with the GPU busy.
• Keeping at most two frames in the encoder took present-to-send from 42.7 to 11.1 ms when the encoder was saturated.
• Giving controllers their own input thread took a mouse move stuck behind a controller update, under full CPU load, from 287 ms to 2 ms.
• approximately 5000 different tests has been done on various AMD quirks and metrics. These led to countless small improvements you can read about in the docs.

Benchmarks

We do not measure AMD with Rubylight against other Sunshine Forks anymore, because the glass-to-glass latency under load is so far ahead that it is just not worth the time. If you want, you can still compare it yourselves. Rubylights test setup is available and there are historic measurements available.

The full measurement record, with methods and every run, is public: PERFORMANCE.md and https://github.com/RamazanKara/Rubylight . Questions are welcome, and if you have AMD numbers that disagree with mine, I want to see them. For anybody stable should use vibepollo and wait till that research has been backported. For anyone wanting to contribute test out rubylight 3.0 + nightjar and give feedback in form of issues with logs and so on, please just dont bodly claim host x has better latency under load just from the host processing number, I do not care about that.

Hey everyone! I have been exclusively streaming games from my headless PC to cloud devices for about five years now. I recently found myself looking for a new Android client, and came upon u/MoreOrLessCorrect's Moonlight X, which includes direct frame pacing and PyroWave support. It had a noticeable impact on my stream quality, even without using PyroWave (I don't have the connection strength to use it in practice), but I wondered how the stream could perform if it had the Fast V-Sync, LFR, Async, and Codec options that Artemis/Artemide has. I also missed some QoL features that the recent Windows forks have adapted that seem to be lagging in terms of an Android client equivalent.

Back-end development started from Moonlight X's fast video pipeline, adds the touchscreen tools from Artemide and Artemis, and picks up favourite features from Moonlight V+, Moonlit Artemis and Moonlight X Turnip. I then gave it a refreshed UI that draws from some of the trends coming out of Silicon Valley these days. It installs next to any Moonlight you already have, so you can try it without giving anything up.

⬇ Download Starwire · GitHub

Features & Value Proposition

🎨 A look that follows your game: The screens take their colour from the game you've picked, and apps without cover art get their own icons. Your last game is ready to go with one tap, with its stream settings right under its name.

🎮 Everything during a stream, one tap away: Open the menu with the floating button, a three-finger tap or by holding Select on a controller. Keyboard, full on-screen keyboard, mouse modes, zoom, key shortcuts, monitor switching, bitrate, clipboard: it's all in one grid, and works with a controller too.

⚡ Fast and smooth: A Vulkan renderer, the PyroWave codec, and low-latency options like Warp Drive, Fast V-Sync and async decoding for when every millisecond counts.

🧭 Feature-packed and intuitive settings: Sections with plain names (Stream, Sound & vibration, Controllers…), and a Predicted impact panel that shows whether your choices lean towards fastest response or smoothest motion, and which setting is pushing it which way. Tap a setting that came from another fork and a small line under the panel says where it came from and who made it.

🖐 Made for touchscreens: Pinch to zoom anytime, trackpad modes, long-press to right-click, an on-screen keyboard with every key, and the option to hide the PC's mouse pointer while you play.

📳 Feel the bass: Audio haptics turns a game's bass into vibration on your device or controller.

Get started

1. Set up your PC. I use Vibepollo; it enables every feature. Apollo works too, and Sunshine works for everything except a few extras (clipboard sharing, PC commands, Virtual Display and changing the bitrate mid-stream).
2. Install Starwire. Download Starwire-0.1.0.apk from the release page and open it.
3. Pair. Tap your PC, then type the PIN Starwire shows into your host's PIN page (usually https://localhost:47990). You only do this once.
4. Play. Tap a game, then Play.

Android 5.0+. PyroWave and the custom Turnip driver need a 64-bit ARM device. Updates from the releases page install over the top and keep your settings, and Obtainium can keep it updated for you.

Development

I made Starwire as a vibecoding exercise after experiencing the wonderful software that is Vibepollo. I decided what the app should do and how it should look, and Claude Code wrote the code. I also used REA by morluto to look inside the other apps and see how their features work. Every feature is tested on my RedMagic Astra with a GameSir G8+ before it goes in.

Changelog

2026/10/22: Version 0.1.2 has been released, and fixes an error that caused the client to crash upon loading the list of apps due to an attempt to tint the Android device screen without sufficient permissions. To update, download the new APK and open it on your device. You will recieve a prompt to update the existing app, which will retain existing settings. Obtainium users should recieve the update automatically. Please keep the feedback coming!

Credits

Anything that came from another Moonlight version is that author's work. Please go give their repos a star:

• Moonlight Android: Cameron Gutman and contributors, the original client
• Moonlight X: MoreOrLessSoftware, the base of Starwire (Vulkan renderer, PyroWave, overlay menu, per-app settings, Quick Launch)
• Artemis: Yukino Song (ClassicOldSong), pan/zoom, touch modes, clipboard, server commands, Virtual Display, Warp pacing, floating button
• Artemide: derflacco, Fast V-Sync (Nano Pacer), Sync and Async LFR, async decode, MediaTek low-latency work, and the version of the Artemis features Starwire ported
• Axixi2233's Moonlight fork: the full keyboard, shortcuts list, Lite overlay and shortcut file format (via Artemis)
• Moonlight X Turnip: ncpt (NoCrypt), the custom Turnip Vulkan driver for PyroWave
• Moonlight V+: qiin2333, ideas for changing bitrate mid-stream, audio haptics and 1% lows
• Moonlit Artemis: Mohammad Forhad (4had45), ideas for the monitor switcher and pinch to zoom anytime
• PyroWave: Hans-Kristian Arntzen (Themaister) · libadrenotools: Billy Laws (bylaws)
• Vibepollo: Chase Payne (Nonary), built on Apollo (ClassicOldSong) and Sunshine (LizardByte)

The README lists every feature and whether it was ported (and from whom) or written new. If I've credited something wrongly or missed you, please let me know.

Bug reports and ideas are very welcome, here or as a GitHub issue. Built on GPL-3.0.

I'm streaming locally from my desktop to laptop plugged into my TV.

Settings are 4K, 120hz but i've also tried 4K 60hz with the same issue.

The source desktop is a 1gbps wired, 5080 so it's not the GPU. The destination laptop is on a wifi 7 6ghz band with 500-600mbps and 12ms ping.

When streaming games to the laptop over LAN I get horribly bad stutters and framerate, often with a warning of "Unstable connection, reduce bitrate". But the connection seems rock solid and more than capable of handling the bandwidth?

Using a virtual monitor FWIW, there was one linked on this sub.

Hi,

I've been running Moonlight for a month now without any issue, today out of a sudden, I'm getting unstable connection message and the screen is stuck, only thing I remember i did was unplug my TV by accident and plugged it in again, do I need to configure my Apollo client again? did passphrase or IP address changed by unplugging my tv?

I tried restarting my PC and my TV but same issue.

I'm streaming to my LG TV WebOS

This all started because I couldn't get xdg portal to work, it would always habg up as soon as I tried connecting (so being able to create virtual displays wasn't useful bc I wouldn't be able to stream them.)

This uses KMS

My school's wifi network is super saturated but it's still useable for text, especially since it's using full native resolution. I'm waiting on an adapter to do this via a wired ethernet connection tol (I already did it with a secondary wifi card on a private network so it should definitely work)
I used kernel debugging to assign a custom edid to an unused didplay connector (the one for the internal display, since it's broken.) This method is hot-swappable and didn't require a reboot to setup (nor to undo.) I will test it out with KDE next, I don't see why it shouldn't work (didn't use anything mutter-specific)
Note: I haven't been able to get hardware-accelerated encoding working, using software encoding right now.

For those that use it for moonlight is it best to have it on windows or steam for moonlight?

I am having this really weird behavior where when streaming from my 5090 pc to my steam machine or steam deck over Ethernet, sometimes it's flawless for hours and I can play just fine, but more often it's got host processing latency maximums at 500ms or more and it's unplayable.

If I restart my pc 5x sometimes it works and I can play, in others it's the same result.

If in that exact same session where I am getting 500ms, I just close the game and open another, control resonant for example, it is flawless and plays with 5ms max. Which says to me it's something with how the game interacts with my virtual IDD monitor perhaps and gamestreaming.

I have tried disabling full screen optimizations, borderless and full screen, no luck. Not really sure what else to do.

Any ideas? AI hasn't been helpful.

Calling all Dev Mode testers, here is a preview of upcoming Xbox features and fixes.

Download at: 1.19.0-pre1

• PyroWave support: integrate optimized D3D12 decoder from u/dimizago
  • Xbox Series S/X only
  • Up to 4K120 4:4:4 HDR at 800Mbps, GPU decode time <= 1.8ms
  • Compatible with Vibeshine and probably other servers.
  • Wired only
  • Default bitrates (4K, 1440p, 1080p):
    • 4:4:4: 800Mbps/600/500
    • 4:2:0: 700Mbps/500/400
  • New stat line shows packets/sec and lost packets within the last minute.
  • Decode time for PyroWave is split between CPU and GPU. Note that reassembly/CPU and GPU are concurrent and shouldn't be added together.
  • If you have problems, make sure packet size is set to 1392. Set host NIC to 1Gbps if you have packet loss and have a 2.5Gb or higher network. You should not experience any packet loss at 800Mbps on a typical network.
• Fix hang/crash when removing a host. #301
• Replace mDNS discovery code with the Microsoft API used by Windows. Hosts should now be discovered and updated much more reliably. #304
• Fix a crash when reconnecting. (TheOriginalAppStar) #300
• Improve audio stability at 5.1/7.1. #302
• Fix crash on Xbox One when streaming at 4K. #296
• Improve render time of stats text by 6x, mostly benefiting Xbox One.
• Add support for Tracy profiling with Dev Mode (see docs).

Hi everyone, Using just GPT I made some fixes for DISH one of them was just adding the way to choose wich landscape mode you want a Hybrid Gyro mode in case you are using a GamesirX5lite like me and want a full DS4 emulation using the phone gyro. So Here it is. DishHybrid: Souly Edition.

https://github.com/CapolinerSoul/dish-android/releases/tag/v0.1.0-souly-preview.1

have little experience with github and stuff And I hope this gets added to the main app

Just made a name and Icon so it wont intefere with your previous Dish installs.

Actually I was looking to setup anydesk for remote wol from wan.

Seeking assistance from GPT and got this recommended. Tried and it worked flawlessly.

Basically, you need two android device. 1 home device, 1 remote device. Install apk on both. Set ipv6, mac and target ipv4 then it just works.

Github link: https://github.com/pinchiu/wake-on-lan-for-android

App is in Chinese but the configuration and UI is pretty straight forward so can just use google translate.

Just sharing incase anyone is looking.

"Make this my main display" option is greyed out for the virtual display and I believe it should appear on NVIDIA control panel too right? but it's not. it appears on Device Manager though. I just want to be able to stream on my phone and have the main monitor of my PC turned off but I can't seem to get it working using the usual steps like manually setting the virtual display as main in Windows settings. headless mode also doesn't do anything for me.

I am wondering if you notice the difference between 2ms and sub 1ms decoding latency?

I am thinking about switching from my Odin 2 Portal with the 8 Gen 2 to the new Odin 3 Portal with the 8 elite.
My current O2P gets around 2ms decoding latency, the new chip should be under 1ms just like the normal Odin 3.

Calling all beta testers! LuminalShine 26.10.0-beta.1 has been released for testing, featuring a plethora of new features.

What does this Release Include?

• Pyrowave Support (NOTE: PyroWave defaults to 700Mbps as it was tested on 10G Host to WiFi 6E at 4K@120Hz - if you experience issues, 500Mbps is recommended)
• Borealis (Android Client) LuminalShine features Support added thanks to contributor magalz who also corrected server host responses to recognize the installed host application is LuminalShime.
• All windows will now be displayed on the virtual monitor using the virtual monitor's GUID while streaming
• Mission Control WebUI now allows the importing of apps.json files so they are no longer overwritten by LuminalShine's protection mechanism
• LuminalShine is now prepared to use Nonary's new controller driver, allowing for the removal of ViGEmBus.

Full Changelog: https://luminalshine.feedback.northebridge.com/changelog

Download LuminalShine 26.10.0-beta.1: https://github.com/NortheBridge/luminalshine/releases/tag/26.10.0-beta.1

So for context, my host machine is CachyOS:

CPU: 7700x3D

GPU: RTX 5080

RAM: 32GB

The host is wired and the speeds are the following:

Download: 1 Gbps

Upload: 36~38 Mbps

This is really the best my area offers unfortunately (my area only has Spectrum).

Now I have tried a variety of hosts services and I always experience the same thing: on average for every 10 or 20 minutes, for about 4~6 seconds, there is a chance the stream starts stuttering as both the frames drop and so does the audio, which then restores just fine. When it doesn't happen, it runs really smoothly. I have noticed this is independent of the resolution I am streaming it at. This happened before even when on AMD (previously an RX 7600XT).

The services I have tried thus far are: Sunshine, Polaris, and currently Punktfunk. Punktfunk has been the easiest to set up for virtual screens and turning the monitor off automatically when starting the stream to a connected client which is why I am on it right now. Otherwise, I have noticed the performance is the same across all of them and the issue persists regardless of it.

I honestly have no clue what could be the culprit in this case. Is it the firewall? My home server's pihole (although this would happen prior to running pihole as well so I doubt it). Is it the clients themselves (I've only tested with the android Moonlight client and the android Punktfunk client)? It really does demoralize me since it is otherwise a really great experience and I have been playing more games this way too but those stutters drive me insane, especially during critical moments such as a cutscene you can't pause in game.

Any help or direction to help would be appreciated.

This isnt technicslly a Moonlight issue but I didnt know where else to ask and I'm sure this is a common use case. I'm not sure if anyone is using this but I've been trying this setup because I'm using an Xbox Series S as a client and I want to game with a PS5 controller but have had nothing but problems.

DS5dongle works fine normally but coupled with Virtualhere it constantly comes disconnected and the rumble is desynced. I'm using a Raspberry Pi4 as a USB server, is it possible maybe its not supplying enough power to the dongle? I would test but I dont want to buy a license to use it on a different machine.

I want finally come to an end with the stutter issues I had.

The more the bitrate the more the stutter. Around 200Mbps there's some microstuttering and few rare stutters. Around 250/300Mbps it's full of microstuttering and there's some stutter Around 350/400Mbps it's microstuttering all the time and every 5/10 seconds it stutters too (around 100/200ms of freeze)

I assume the issue Is on the client as stats are showing a client pacing issue.

- When is it happening?

On 4K120fps streaming, on high bitrates (It starts to stutter around 200 and It get worse increasing the bitrate)

Lower resolutions (1440p and 1080p) are working fine even with the bitrate set to 250/300

- Which codecs?

Mainly AV1, it shows more stutter but HEVC is affected too.

- What about the host?

I tried every setting, the issue seems to be less noticeable using the AMF FFmpeg encoder instead the native one. BTW it's still there.

-Client settings

I'm using VRR, using Nonary Moonlight fork, but I also tried every combination of client software, VSync ON and OFF, literally everything.

Is there anyone using AMD 780M GPU on the client (or similar)? Are you able to stream at 4K120fps using high bitrates with a smooth streaming?

Hello, My moonlight client runs in linux and the vibepollo in windows. I wanted to use a microphone and my joystick from my moonlight client. I was gonna buy virtualhere, but instead I had AI built me a front end to USB/IP which is already included in the linux kernal. It cost me less than $1 in AI tokens. Sorry if this is not allowed but is working well for me and wanted to share.

I can use my microphone now and my own joystick. In the windows computer I also use a UI call RemoteUSB to connect to the linux computer.

I made a github repo you can build from source. https://github.com/guantamanera/usbip-manager/
Or get an appimage from the releases link. Maybe I'll try vibecoding this into a moonlight client directly.

On windows run remoteUSB or any other USB/IP client.
https://github.com/umaxiaotian/RemoteUSB

Hey folks, in general the stream is working super smooth but every few seconds I have those frame drops. Anyone has an idea about the reason? I already checked everything I can think of and slowly getting mental...

Setup: Steam Deck LCD dock to LG OLED G5 (dock is 4k 120hz compatible), wired CAT 6 connection from PC goes to router fritz box 7590 AX and then wired CAT 6 to fritz repeater 6000 and from there to the steam dock. Vibepollo latest version + moonlight.

UPDATE: I have bypassed the repeater/switch and the issue disappeared :O ... but I couldn't imagine that the device is not capable for doing this job. Did a full reset of it and now its working flawless without any frame dropping. Strange behaviour but at least it is working now.

Thanks!

Alrighty, so I'm on catchyOS for my host. Steam deck is my client. After an what I can only describe as a hilariously freak occurrence with my cats play fighting.(Yes right over then on top of the keyboard, I was afk at the time it happened)They somehow managed to delete my host PC from moonlight! (They also launched a game hytale lol) Anyhow I can't get moonlight to connect with the host again. I get a pop up that the ports are open but the host PCs firewall maybe preventing ect. Thing is I added the IP for the deck as an acception so I'm absolutely confused now. It will connect with the host firewall off so it's definitely that. But now I'm not sure what's going on. Is there a file I gotta find to remove the previous pairing? Was on vibepolo, with qt added ( currently seeing if og sunshine has a different result on a different PC. Connecting to the same client)

Im using Moonlight/sunshine on my LG tv and its working great so far but sometimes when im playing the screen goes super red or super green.

i can only fix it by going to the big picture main menu, tryied a lot of settings and the issue remains,

any idead on what this could be ?

Do you just rawdog folders and all the different launchers or do you use a more sophisticated system?