[FFmpeg-user] Autolaunch FFMPEG when network traffic detected

[Yannick Barbeaux]

Thank you Anthony.
How do you fill the log file? With iptables? Could you give me an example ?
(I guess you use the limit and burst options to avoid geting huge log
files?)


On 20 July 2018 at 14:46, Anthony Griffiths <neuronetv at gmail.com> wrote:

> 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.
>
> >
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>