From e6e3b20af8ef73e9f3faeaa4afdba991421bd591 Mon Sep 17 00:00:00 2001 From: ninya9k Date: Sat, 3 Jul 2021 09:15:48 +0000 Subject: [PATCH] mention eventual connection refusal bug --- README.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/README.md b/README.md index d37ce3d..a895d6e 100644 --- a/README.md +++ b/README.md @@ -40,9 +40,8 @@ This works on Linux, and should work on macOS and Windows with some tweaking. Lo * AFAIK the FFmpeg command in `stream.sh` only works on Linux, change it for other OSs * Slow (if videojs is enabled). Using videojs is slower because you have to make many separate GET requests, without it you only need to make one. If you lower the HLS segment size to something like 2 seconds, you get very low latency without videojs (smallest i've got is 3 seconds) but with videojs the stream becomes unwatchable because of the overhead of each GET request you have to make. The stream delay is >30 seconds with videojs and >3 seconds without it. Hopefully this will decrease when congestion control gets into Tor: https://youtu.be/watch?v=zQDbfHSjbnI. ([This article](https://www.martin-riedl.de/2020/04/17/using-ffmpeg-as-a-hls-streaming-server-part-8-reducing-delay/) explains what causes HLS to have latency.) * Slow chat (uses meta refresh); will be better once websockets is implemented (only with JavaScript enabled though) - - * Doesn't use low-latency HLS +* There's a bug that causes the server after having run for a while to refuse to respond to any more requests. I don't know why it happens, it's probably something to do with `/stream.mp4` or `concatenate.py`. ## How it works