games-on-whales/wolf

Fork 0

mirror of https://github.com/games-on-whales/wolf.git synced 2026-10-15 21:12:08 +00:00

[GH-ISSUE #515] Feature Request: PyroWave encoder #312

New issue

Open

opened 2026-10-15 12:59:33 +00:00 by bsakaguchi · 7 comments

bsakaguchi commented

2026-10-15 12:59:33 +00:00

Owner

Originally created by @bscubed on GitHub (Sep 26, 2026).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/515

PyroWave is a relatively new video codec built specifically for game streaming, utilizing extremely fast encodes/decodes that result in unparalleled latency and video quality at the cost of much higher bandwidth requirements. The project recommends this for local game streaming over an Ethernet-hardwired LAN.

Despite its costs, many game streaming services are now supporting this new codec, including Valve's remote play most recently. But there are also some Sunshine forks such as Solarflare that have supported this codec for a few months now.

Moonlight doesn't support decoding this codec yet, but a fork known as Aurora allows for PyroWave decoding. And I'm sure it's only a matter of time before it's added to Moonlight as well.

I believe this would be an amazing addition to Wolf for users who primarily stream on Ethernet-connected LAN. I would benefit from it immensely as I have a completely headless server running in a mini rack in my closet that runs Wolf for game streaming and I'd love to benefit from the quality and latency upgrades provided by PyroWave, but I'd need to install Solarflare or stream from Steam Remote Play which would be difficult considering my headless configuration.

I'm working on enabling it myself on a local checkout of this repo, but let me know if you think this is something that would be beneficial to have upstream in this repo and I'll work on opening up a PR for it.

Originally created by @bscubed on GitHub (Sep 26, 2026). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/515 [PyroWave](https://github.com/Themaister/pyrowave) is a relatively new video codec built specifically for game streaming, utilizing extremely fast encodes/decodes that result in unparalleled latency and video quality at the cost of much higher bandwidth requirements. The project recommends this for local game streaming over an Ethernet-hardwired LAN. Despite its costs, many game streaming services are now supporting this new codec, including [Valve's remote play most recently](https://steamcommunity.com/groups/homestream/discussions/0/564794422009744473). But there are also some Sunshine forks such as [Solarflare](https://github.com/Koloses/Solarflare) that have supported this codec for a few months now. Moonlight doesn't support decoding this codec yet, but a fork known as [Aurora](https://github.com/Koloses/aurora-qt) allows for PyroWave decoding. And I'm sure it's only a matter of time before it's added to Moonlight as well. I believe this would be an amazing addition to Wolf for users who primarily stream on Ethernet-connected LAN. I would benefit from it immensely as I have a completely headless server running in a mini rack in my closet that runs Wolf for game streaming and I'd love to benefit from the quality and latency upgrades provided by PyroWave, but I'd need to install Solarflare or stream from Steam Remote Play which would be difficult considering my headless configuration. I'm working on enabling it myself on a local checkout of this repo, but let me know if you think this is something that would be beneficial to have upstream in this repo and I'll work on opening up a PR for it.

bsakaguchi commented

2026-10-15 12:59:34 +00:00

Author

Owner

@bscubed commented on GitHub (Sep 27, 2026):

Update: Initial results seem to be promising:

Encode/decode time seems to line up with estimated metrics from PyroWave (~0.10ms)

@bscubed commented on GitHub (Sep 27, 2026): Update: Initial results seem to be promising: <img width="2560" height="1440" alt="Image" src="https://github.com/user-attachments/assets/ed8b3c5a-2cc6-4eb4-95bc-4f420ef32aee" /> Encode/decode time seems to line up with estimated metrics from PyroWave (~0.10ms)

bsakaguchi commented

2026-10-15 12:59:34 +00:00

Author

Owner

@Hukuma1 commented on GitHub (Sep 27, 2026):

I was curious how the latency claims stack up against current encoders and got this:

Not sure how accurate it is, but still nice to see nonetheless. I guess for those of us running Wolf -> Moonlight to our Nvidia Shield with gigabit this would be neat to test.

@Hukuma1 commented on GitHub (Sep 27, 2026): I was curious how the latency claims stack up against current encoders and got this: <img width="684" height="453" alt="Image" src="https://github.com/user-attachments/assets/0de8bd89-5d61-4368-b10e-8eb5686617e6" /> Not sure how accurate it is, but still nice to see nonetheless. I guess for those of us running Wolf -> Moonlight to our Nvidia Shield with gigabit this would be neat to test.

bsakaguchi commented

2026-10-15 12:59:34 +00:00

Author

Owner

@bscubed commented on GitHub (Sep 28, 2026):

I've been doing some tests on my WIP local builds a bit and I'm not sure if it's how Aurora calculates decode time or if 4K + less powerful hardware (Steam Deck) is taking a bigger toll than I thought, but in real life tests (streaming from my headless host PC to my Steam Deck on a 4K TV), I'm seeing ~1ms decode time which is much more than PyroWave's advertised 0.2ms encode AND decode times. Should be seeing around 0.1ms here, but that seems like more of an Aurora client thing and maybe presentation time is taking up most of this value, no way to tell really so I'm not too worried about it. Wolf's logs report around a 0.1ms encode time at 4k so that's doing its job correctly.

It's still miles quicker than the other current codec options. In my (honestly limited) testing using PyroWave, I'm seeing around ~2.11ms round-trip latency from frame generation on the host GPU to being presented on the streamed TV. That's about 10ms less on average for me, or 83% lower latency. It helps that PyroWave doesn't rely on queuing the previous frame in order to diff the next frame.

That being said, I am running at the default 850Mbps bandwidth for 4K@120Hz, which is pushing the boundary of most 1Gbps Ethernet-wired networks. That's a lot, and if I wasn't wired up for 2.5Gbps I'd probably be pushing my local network to its limits, but luckily it seems to perform pretty well when lowering the bandwidth to a more reasonable level like 600ish.

Here are some comparisons with the Aurora debug information:

PyroWave	HEVC (H.265)

I'm not sure why PyroWave's output is darker, HDR and YUV 4:4:4 were both disabled for these tests, but you get the point.

If you'd like to test this for yourself, feel free to build and deploy from my forked repo. I've worked out most of the performance issues but it does still crash sometimes. Not sure if that's an Aurora decoding issue or a Wolf + PyroWave encoding issue yet, but looking into it.

@bscubed commented on GitHub (Sep 28, 2026): I've been doing some tests on my WIP local builds a bit and I'm not sure if it's how Aurora calculates decode time or if 4K + less powerful hardware (Steam Deck) is taking a bigger toll than I thought, but in real life tests (streaming from my headless host PC to my Steam Deck on a 4K TV), I'm seeing ~1ms decode time which is much more than PyroWave's advertised 0.2ms *encode **AND** decode* times. Should be seeing around 0.1ms here, but that seems like more of an Aurora client thing and maybe presentation time is taking up most of this value, no way to tell really so I'm not too worried about it. Wolf's logs report around a 0.1ms encode time at 4k so that's doing its job correctly. It's still miles quicker than the other current codec options. In my (honestly limited) testing using PyroWave, I'm seeing around ~2.11ms round-trip latency from frame generation on the host GPU to being presented on the streamed TV. That's about 10ms less on average for me, or 83% lower latency. It helps that PyroWave doesn't rely on queuing the previous frame in order to diff the next frame. That being said, I am running at the default 850Mbps bandwidth for 4K@120Hz, which is pushing the boundary of most 1Gbps Ethernet-wired networks. That's a lot, and if I wasn't wired up for 2.5Gbps I'd probably be pushing my local network to its limits, but luckily it seems to perform pretty well when lowering the bandwidth to a more reasonable level like 600ish. Here are some comparisons with the Aurora debug information: | PyroWave | HEVC (H.265) | |---|---| | <img width="3840" height="2160" alt="Image" src="https://github.com/user-attachments/assets/e884fb08-bf3d-4160-8041-d48418c1cfbb" /> | <img width="3840" height="2160" alt="Image" src="https://github.com/user-attachments/assets/41c71973-6f3f-4843-87f8-d84572c3673b" /> | I'm not sure why PyroWave's output is darker, HDR and YUV 4:4:4 were both disabled for these tests, but you get the point. If you'd like to test this for yourself, feel free to build and deploy from [my forked repo](https://github.com/bscubed/wolf). I've worked out most of the performance issues but it does still crash sometimes. Not sure if that's an Aurora decoding issue or a Wolf + PyroWave encoding issue yet, but looking into it.

bsakaguchi commented

2026-10-15 12:59:34 +00:00

Author

Owner

@ABeltramo commented on GitHub (Sep 29, 2026):

I've taken a look at your fork and I like that this can be a fairly clean addition of basically adding a Gstreamer plugin for encoding with PyroWave, plus just the necessary changes in the Moonlight protocol so that a client can pick that up. I also very much like that this should work across all GPU vendors OOB (hopefully).

The only downside is that it's not supported by any "official" Moonlight client, but maybe it's a chicken and egg situation, I'll checkout what's the latest on the Discord server.. In the meantime, I'd be happy to work on bringing this to Wolf. Would you like to start a PR?

@ABeltramo commented on GitHub (Sep 29, 2026): I've taken a look at your fork and I like that this can be a fairly clean addition of basically adding a Gstreamer plugin for encoding with PyroWave, plus just the necessary changes in the Moonlight protocol so that a client can pick that up. I also very much like that this should work across all GPU vendors OOB (hopefully). The only downside is that it's not supported by any "official" Moonlight client, but maybe it's a chicken and egg situation, I'll checkout what's the latest on the Discord server.. In the meantime, I'd be happy to work on bringing this to Wolf. Would you like to start a PR?

bsakaguchi commented

2026-10-15 12:59:34 +00:00

Author

Owner

@bscubed commented on GitHub (Sep 29, 2026):

Yep, tried to keep what it broadcasts consistent with what Aurora expects since that's the direction other Moonlight-compatible servers are heading but of course who knows if Moonlight will implement this or if it'll consume it the same way. Happy to keep the PR up until we have a better idea and it should be fairly easy to update if need be.

@bscubed commented on GitHub (Sep 29, 2026): Yep, tried to keep what it broadcasts consistent with what Aurora expects since that's the direction other Moonlight-compatible servers are heading but of course who knows if Moonlight will implement this or if it'll consume it the same way. Happy to keep the PR up until we have a better idea and it should be fairly easy to update if need be.

bsakaguchi commented

2026-10-15 12:59:34 +00:00

Author

Owner

@ABeltramo commented on GitHub (Sep 29, 2026):

I don't see a Pull Request open from your fork, or am I missing something? 😅

I'd like to start a PR so that we can review the actual code and collaborate on how to merge this into mainline Wolf

@ABeltramo commented on GitHub (Sep 29, 2026): I don't see a Pull Request open from your fork, or am I missing something? 😅 I'd like to start a PR so that we can review the actual code and collaborate on how to merge this into mainline Wolf

bsakaguchi commented

2026-10-15 12:59:34 +00:00

Author

Owner

@bscubed commented on GitHub (Sep 29, 2026):

Yeah sorry, sent that while I was in the process of writing up the PR description but got pulled away by work. It's up now

@bscubed commented on GitHub (Sep 29, 2026): Yeah sorry, sent that while I was in the process of writing up the PR description but got pulled away by work. It's up now