[FFmpeg-user] Autolaunch FFMPEG when network traffic detected

Anthony Griffiths neuronetv at gmail.com
Fri Jul 20 15:46:44 EEST 2018


On Fri, Jul 20, 2018 at 11:55 AM, yannickb <ybarbeaux+ffmpeg at gmail.com>
wrote:

> Hi,
>
> I am trying to build a *headless encoder* that would *autostart* streaming
> with *ffmpeg* as soon as it receives a stream on a given port (let's say a
> MPEG-TS stream on UDP/3000) and output it to a blackmagic SDI output.
> I don't mind if some packets are lost before ffmpeg is triggered.
> I would also like ffmpeg to stop when the stream ends.
>
> I have thought about various possibilities:
>
> 1- Using *port-knocking* (knockd) to trigger ffmpeg when the right ports
> combination is detected. The problem is that the devices that generates the
> incoming stream are hardware encoders so they cannot knock pre-defined
> ports
> before sending traffic. One solution could be to use the trigger
> sequence=3000:udp,3000:udp,3000:udp
> That could work but how would it stop ffmpeg automatically?
>
> 2- *Monitor syslog* and detect iptables log on the given port (like
> fail2ban)
>
> In both cases, my log files might get huge if all my UDP streaming traffic
> is logged, I might play with the iptables burst option to limit logging.
>
> 3- I was suggested to use *xinetd* (formerly inetd), the super-server that
> can launch services when traffic is detected on given port. At first, it
> seems like the perfect solution and it almost worked.
> In this configuration, the port is in use by the xinetd daemon so ffmpeg
> cannot use it as an input directly :
> /ffmpeg -i udp://localhost:3000 (...)
> -> [udp @ 0x1de60a0] bind failed: Address already in use
> udp://localhost:3000: Input/output error/
>
> indeed, /netstat -naptu/ returns:
> / udp 0 0 0.0.0.0:3000 0.0.0.0:*  xinetd/
>
> After some research, I found out that xinetd redirects the captured traffic
> to stdout. So, the script launched by xinetd must look like :
> /cat - | /usr/local/bin/ffmpeg -re -i pipe:0 (...)/
>
> it almost works but the image is garbled and ffmpeg outputs many errors
> (error while decoding MB 67 26, bytestream -6, PES packet size mismatch, co
> located POCs unavailable, Invalid data found when processing input, ...)
>
> I'm sure the UDP stream itself is not the problem : when I stop xinetd and
> launch ffmpeg manually it works perfectly:
>  /ffmpeg -i udp://localhost:3000?fifo_size=1000000 -muxdelay 30
> -muxpreload
> 30 -maxrate 4096 -bufsize 10000k -pix_fmt uyvy422 -s 720x576 -r 25000/1000
> -c:a pcm_s16le -ar 48000 -ac 2 -f decklink 'DeckLink SDI 4K'/
> So I guess the xinetd pipe must be the problem. Does the pipe with ffmpeg
> needs a kind of rate control or something like that? Anyone has ever tried
> that?
>
> Any other clue or solution would be really appreciated.
>
> Thank you
> _______________________________________________
>

this can be achieved using monit. Monit's job is to watch a log file and it
can trigger a command when it sees a particular string in the log. I use
monit to restart a live ffmpeg stream whenever it goes down.

>


More information about the ffmpeg-user mailing list