[FFmpeg-user] Autolaunch FFMPEG when network traffic detected
neuronetv at gmail.com
Mon Jul 23 12:50:33 EEST 2018
need more info.
what do you mean exactly when you say "as soon as it receives a
stream".. Please give more details of your whole setup ie: the
operating system yr using and more.
On Fri, Jul 20, 2018 at 2:24 PM, Yannick Barbeaux <ybarbeaux at gmail.com> wrote:
> 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
> 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>
>> > Hi,
>> > I am trying to build a *headless encoder* that would *autostart*
>> > with *ffmpeg* as soon as it receives a stream on a given port (let's say
>> > 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
>> > 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
>> > 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
>> > 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
>> > 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,
>> > located POCs unavailable, Invalid data found when processing input, ...)
>> > I'm sure the UDP stream itself is not the problem : when I stop xinetd
>> > 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
>> > -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
>> > 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
>> To unsubscribe, visit link above, or email
>> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
More information about the ffmpeg-user