raspi / kaukosohva Goto Github PK

View Code? Open in Web Editor NEW

43.0 7.0 3.0 123 KB

Play games remotely with Linux

Shell 100.00%

linux games remote gaming stream streaming hacktoberfest game-stream game-streaming game-streaming-server

kaukosohva's Introduction

kaukosohva

Play games remotely with Linux.

Current state

This is proof of concept prototype for technical users.

Architecture

Main problems TODO

Lower the latency for streaming
- Minimize streaming buffer(s)
- Tune h264 parameters for lowest latency
- Tune RTP parameters for lowest latency
- Constant or variable bitrate (CBR or VBR)?

FAQ

Why h264?
- Because GPU encoding/decoding hardware acceleration
Why h264 over RTP?
- Because it's a standard - https://tools.ietf.org/html/rfc6184
Why multicast?
- Eliminates need for extra server software as kernel sends host's stream to everyone connected to the VPN automatically
Why GStreamer?
- Lots of tuning options
- Lots of plugins
- Debugger - https://gstreamer.freedesktop.org/documentation/tutorials/basic/debugging-tools.html
- View latency issues in the pipeline - https://www.flathub.org/apps/details/org.freedesktop.GstDebugViewer
Does it matter who hosts VPN (WireGuard)?
- Who has the most bandwidth and stable connection is recommended

See

host directory for how to host a game
remote-player directory for how to connect to a host as a remote player

Research

Not tested yet

If h264 over RTP multicast doesn't pan out there's still many things to try with GStreamer:

Drop multicast and stream to UDP port in a remote player's machine (this limits player count)
Try h264 inside MPEG-TS container over multicast
Try GStreamer's RTSP server if the host doesn't have enough upload bandwidth for all players there's RTSP proxies like rtsp-simple-server
RTMP
SRT
and others

Tested, didn't work

ffmpeg, mpv, vlc
- too many buffers
- 1000-4000 ms+ latency even locally

kaukosohva's People

Contributors

Stargazers

Watchers

Forkers

7oxicshadow vaslabs leichenlager

kaukosohva's Issues

[Suggestion] Encoding OpenGL/Vulkan render output directly from the game

This could potentially reduce lag later on (if X render lag is too high). Vulkan via layers would be easier to hook into, compared to OpenGL. Of course, if the delay that X causes is insignificant then it will do :)

Consider adding a comment section in the sender-audio.sh on how to select a specific sound card...

Managed to get chance for another brief play around with this at the weekend.

At the moment the soundcard is set to:

ASOURCE="autoaudiosrc"

But this has the problem that it can select the wrong soundcard if you have more than one. (I have 1 soundcard for game audio and a usb sound card for microphone/voice audio when using discord)

In the end we used the following command to list the available cards:

pactl list | grep -A2 'Source #' | grep 'Name: ' | cut -d" " -f2

and then changed the ASOURCE to the following:

ASOURCE="pulsesrc device=alsa_output.pci-0000_00_1f.3.analog-stereo.monitor"

I am not sure if this is the correct way of doing it but it did work so I am assuming it is :)

Figure out NVENC CBR GStreamer parameters

Clues:

AMD hardware encoding/decoding

I don't currently own any AMD hardware so if someone figures out working hardware encoding/decoding parameters, it would be great.

Kaukosohva using wireguard over LAN gives bad performance. Caused by MTU?

During my testing over LAN if I specify my LAN adapter directly the streaming seems to work fine but if I use wireguard over my LAN I appeared to be getting many dropped frames on the client causing the screen to be grey a lot of the time...

After reading on the internet about wireguard and dropped packets I came across a post about wireguard and MTU. Someone with an unstable wireguard connection discovered that manually setting the MTU for the wireguard interface dramatically increased stability.

I can confirm (for me at least) that setting the HOST and CLIENT to MTU = 1500 on the wireguard interface fixed the issue for me and wireguard acts just the same as if i was using the real network interface over LAN.

I have not been able to test over an internet connection so I can not confirm if this is even an issue as I believe WAN traffic uses a lower MTU than LAN anyway but its worth posting here incase others are having similar issues.