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 -- Sent from: http://www.ffmpeg-archive.org/ _______________________________________________ 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".
