neko icon indicating copy to clipboard operation
neko copied to clipboard

[Question] How to deal with low upload bandwidth?

Open mattboy9921 opened this issue 3 years ago • 8 comments

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.

mattboy9921 avatar Jan 20 '22 17:01 mattboy9921

There are three solutions to your problem.

  1. 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.

  2. 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.

  3. 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.

mbattista avatar Jan 21 '22 09:01 mbattista

You can also lower the screen resolution from the GUI.

yesBad avatar Jan 21 '22 10:01 yesBad

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.

mbattista avatar Jan 21 '22 11:01 mbattista

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?

mattboy9921 avatar Jan 21 '22 14:01 mattboy9921

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_<NUMBERS> (inbound-rtp)): Screenshot_20220123_200054

mbattista avatar Jan 23 '22 19:01 mbattista

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?

mattboy9921 avatar Jan 23 '22 20:01 mattboy9921

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.

mbattista avatar Jan 27 '22 21:01 mbattista

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.

image

mattboy9921 avatar Jan 27 '22 22:01 mattboy9921