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 <[email protected]> wrote: > On Fri, Jul 20, 2018 at 11:55 AM, yannickb <[email protected]> > 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 > [email protected] > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". > _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
