Streams are not terminated properly with ffmpeg

[jojo141185]

In conjunction with ffmpeg, I often encounter the problem that streams continue to run even though the client has disconnected or switched to another channel. This leads to many connections being blocked over time.
Inside the shell of the docker container in which stb-proxy is running you can see the multiple ffmpeg processes and have to kill them manually.
@Chris230291 Are you aware of this behavior? Is there a fix to cleanly detect that the client has terminated the connection?

[Chris230291]

Which ffmpeg command are you using?
I think when I tried setting the output format to hls this prevented the processes from being killed properly.
Also are you sure the processes are still running? Sometimes processes remain even after they have been properly killed. There was a discussion about this on stackoverflow I think.

[jojo141185]

The ffmpeg command I used when the problem occures was the default one:
ffmpeg -re -http_proxy <proxy> -timeout <timeout> -i <url> -map 0 -codec copy -f mpegts pipe:

I have since been able to analyze the problem a little deeper. The problem occurs only on very few channels of my provider and was always reproducible.
And yes, the ffmpeg processes were definitely still running after the client switched/quit. The stream remained visible in the webui dashboard and traffic was generated.

With your hint I read a bit into the parameter options of ffmpeg and found the following hint regarding the -re flag in the ffmpeg streaming guide: "My guess is you typically don't want to use this flag when streaming from a live device, ever."

After some trial and error, I got everything working with the following ffmpeg command:
ffmpeg -fflags -nobuffer -i <url> -codec copy -f mpegts pipe:

The ffmpeg process now always exits cleanly and at the same time the switching times have also shortened significantly. I had to remove the parameter -timeout , because otherwise it came to a loop playback.

I don't understand the exact background yet, but maybe it would be better to remove the -re flag from the standard ffmpeg command in the future.