Open mattboy9921 opened 2 years ago
There are three solutions to your problem.
Lower the bandwidth / resolution of the stream. The bandwidth can be controlled with NEKO_VIDEO_BITRATE
. The default value is 3500kb/s but can be lowered for a more fitting bandwidth. I would lower the screen resolution to 720p via the NEKO_SCREEN
value (e.g. 1280x720@30
) but as Admin you can also change the resolution on the fly.
You can also stream the video /audio stream to a remote restreamer (e.g. youtube /twitch/your VPS). Viewers of the remote cannot interact with neko any more, but could still watch it. NEKO_BROADCAST_URL
is the parameter, if you want to set it at startup. But you can change it later in as an admin.
You could host neko on an external cloud / VPS. neko runs surprisingly well on old or low end machines.
If you want I can add some example configurations for 1. and 2. later.
You can also lower the screen resolution from the GUI.
You can also lower the screen resolution from the GUI.
I am unsure if you want to imply that changing the screen resolution will lower the bandwidth consumption. Just to make sure, I want to say that the bandwidth is only affected by the NEKO_VIDEO_BITRATE / NEKO_AUDIO_BITRATE / NEKO_VIDEO / NEKO_AUDIO parameter. Lowering the resolution will not change the target-bitrate.
So I had tried experimenting with the bitrate, lowering it to 1000, then 500 and even 100 yet it does not seem to look any different. 100 should surely look horrible. I am not sure if there is a spot in the log I can check to see if it applies? I have put it under environment
and it is just written as NEKO_VIDEO_BITRATE: 500
. Is that the right way to do it?
I tested it today. It really seems that the default VP8 pipeline overshoots the bitrate for the sake of quality.
Can you try the following docker-config.yml
which will use H264
instead of VP8
:
version: "3.4"
Services:
neko:
image: "m1k1o/neko:google-chrome"
restart: "unless-stopped"
shm_size: "2gb"
ports:
- "8080:8080"
- "52000-52100:52000-52100/udp"
cap_add:
- SYS_ADMIN
environment:
NEKO_SCREEN: 1280x720@30
NEKO_MAX_FPS: 0
NEKO_VP8: false
NEKO_H264: true
NEKO_VIDEO_BITRATE: 1000
NEKO_PASSWORD: neko
NEKO_PASSWORD_ADMIN: admin
NEKO_EPR: 52000-52100
With this config my chrome://webrtc-internals/
looked like this (under Stats graphs for RTCInboundRTPVideoStream_
I just tried these settings and got decent results. For a small watch party (maybe 3 or so people) I think it would be adequate. I was able to load up to 8 before seeing major spikes on the upload and things got pretty crummy on the stream.
One question I have: is the stream smart enough to know if someone opens multiple tabs to the same site, will it use just one stream or does each get its own?
Every tab should create a new stream with video and sound, so yes one person with multiple tabs could take all your bandwidth.
I can only say should right now, since I did not test it. But the other tab should join the Session with the same username and password and will start streaming.
It was weird because what I experienced was a steady climb in the bandwidth usage, then with just one more client it suddenly spiked and everything jammed up.
I run a homelab and decided Neko was a great addition. I wanted to use it to have a watch party with friends. Unfortunately, I underestimated the bandwidth required per watcher and realized even with 2-3 people, it quickly grinds to a halt. The real issue is that my upload bandwidth is limited to 10 mbps from the ISP.
My only idea is what if Neko could split into a two server system? The actual browser and video encoding can exist on my local homelab and send a single stream to a lightweight VPS with a high bandwidth connection that can then branch out to every watcher. I'm not sure the proper terminology to explain this idea so I am unsure if it exists in some form.
Any input on this would be greatly appreciated. Other than my bandwidth problem, I love Neko and really just want it to work well in my environment.