Hi everyone, I'm attempting to use ffmpeg as a DIY baby audio monitor. Although I have a working prototype, there is a delay that gets progressively greater. The lag is of a few seconds in the beginning, but it reaches a few minutes after several hours.
My set-up is: - Raspberry Pi 2B with a USB microphone is the streaming server - My client is usually VLC running on Android or on a computer elsewhere in the house - I only have one client at a time, - but clients are different, depending on who watches the child (so the solution to stream directly to a specific IP is not suitable) - All the devices are in the same network - ffmpeg is started by another process with these parameters: ffmpeg -re -f alsa -i plughw:1,0 -vn -acodec libmp3lame -b:a 8k -ac 1 -ar 22050 -f mp3 - The parent process continuously reads stdout and exposes the chunks over HTTP. This makes it convenient, as the stream can be played in a browser too. The tool that does it is micstream: https://github.com/BlackLight/micstream/blob/main/micstream/server.py I've tried tweaking the ffmpeg parameters and have gotten some small improvements, by reducing the bit-rate, for example. However, I believe the approach needs to be reviewed, because the delays still pile up over time. Hypotheses I've had: 1. The client has a buffer of its own However, VLC allows me to set the cache size by specifying a duration, which is currently at 1000ms. I tried lower values too, but there was no noticeable difference. 2. The hardware is not fast enough I doubt it because next to the RasPi 2B streaming the microphone, I have a RasPi ZeroW that streams video from a camera - it is very smooth, and the delay is ~1s even after weeks of uptime. Further, if I inspect what ffmpeg writes to stdout, the text at the bottom says `size= 343273kB time=97:38:43.52 bitrate= 8.0kbits/s speed= 1x`, which I suppose means that encoding in real-time works well. 3. The network itself Although both RasPis mentioned above work over Wi-Fi and are in a remote part of the house - the video stream works reliably. Also, if I disable the video, audio still lags. Moreover, if I modify ffmpeg parameters to stream directly to another address over RTP: `ffmpeg -re -f alsa -i plughw:1,0 -vn -acodec libmp3lame -b:a 8k -ac 1 -ar 22050 -f rtp rtp://192.168.1.10:5002` and on 192.168.1.10 (the receiver, not the same system as the streamer) I run netcat to see what I'm getting `nc -u -l 5002` - I do see small chunks of what appears to be mp3 headers and some payload arriving at regular intervals, and there are no periods where these datagrams stop arriving. I am wondering what else I could try to establish the root cause of the problem and reduce the delays. Perhaps the culprit is `micstream`, I'd be happy to replace it with something else that is known to work better. However, on the Internet I found references to `ffserver` which is not available anymore, while tutorials I've found for Apache and nginx are tailored for video streaming. Is the scenario I described feasible at all? What troubleshooting steps could I try? Best wishes to everyone, and I look forward to your feedback, Alex _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
