Why is my remote Klipper camera stream buffering so badly?

Oct 19, 2026 Last reply: 3 hours ago 4 Replies

First reply

SparkHarbor_1954

This kind of stuttering when using a remote connection like Tailscale is almost always down to how the camera stream is being compressed and the bitrate being used. When you're local, the latency is minimal, and your network handles the high-quality stream easily. But when you…

Read the full reply

Got my Voron setup running with Klipper and everything seems fine locally. The camera stream shows up perfectly on the Pi dashboard when I'm sitting in the workshop. It's a good, clear feed, and the frame rate is solid right here at home.



But I try to pull the feed up from my phone when I'm out, and it just stutters. It buffers every few seconds, and sometimes the video freezes entirely for a few seconds before catching up. I've alredy checked the Wi-Fi signal strength at the printer end, and that seems fine.



I'm using Tailscale to hop onto my home network for viewing, and the camera is plugged into the Pi's USB port. Has anyone dealt with this specific kind of remote latency? Is there some specific compression or encoding setting I need to tweak to make the stream work smoothly when I am not on my local network?


This kind of stuttering when using a remote connection like Tailscale is almost always down to how the camera stream is being compressed and the bitrate being used. When you're local, the latency is minimal, and your network handles the high-quality stream easily. But when you hop out and go thru the Tailscale VPN, you're adding extra hops and potential bottlenecks, so the video stream needs to be lighter. If you're using the standard Pi camera setup, you probly aren't pushing the camera enough to encode the feed efficiently for remote viewing. The quick fix is usually to lower the desired bitrate in the camera settings. You don't want the video quality to look terrible, but you defintely want the packet size to be manageable across the VPN. Try dialing it back 30-40 percent from what you have set for local viewing and see if that smooths out the stuttering.

If reducing the bitrate doesn't help, then the encoding itself might be inefficient. Sometimes, if the camera is set to a very high-quality, uncompressed, or highly complex encoding like raw MJPEG, the sheer volume of data overwhelms the tunnel, especially if your Tailscale connection is slightly strained. Look into forcing the stream to a modern H.264 or H.265 codec. These compress the video much harder while maintaining acceptable quality. It's less about your overall Wi-Fi signal strength and more about the throughput and stability of the connection when it's routed through the VPN. Lowering the bitrate or switching the encoding method is the way to make sure the data packets are small enough to hop across the network without dropping or

I'm skeptical that the stuttering is almost always about the bitrate, even though I get why you say that. While dropping the video quality is a common fix, I've seen this happen even with moderate bitrates when the network itself is shaky. Tailscale routes everthing, but if there's just some background packet loss somewhere in the chain, the stream will still hiccup. You might need to look deeper than just the camera settings and check the actual network interface stats on the Pi itself to see if there is any evidence of dropped data packets.

Same symptom here and the culprit ended up being my home upload speed, not anything on the phone side. Download was fast but the outgoing pipe was narrow, and the camera feed was trying to shove more out than the line could handle. What made the difference for me was running a speed test on the Pi itself while watching the stream from a coffee shop. Once I saw the real upload number, everything clicked. Check what your line can acutally push out before touching any encoder settings, because the local feed will always look great and hide this completly.

I remember when we used these setups, it wasn't as smooth as it is now. When you get stuttering that isn't just low bandwidth, it's often about jitter—the inconsistent timing of the data packets. A shaky connection might be fine for a slow stream, but real-time video is sensitive to that uneven arrival time. Maybe you should look at how the Pi is serving the stream, not just the quality settings. Sometimes, changing the underlying network protocol, say moving from a TCP stream to something like UDP, can help smooth out the video if the packet loss is minor but continuous. It puts the burden of reassembly on the client, but it keeps the flow going better.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required