On Wed, Nov 12, 2025 at 5:34 PM Devin Heitmueller < [email protected]> wrote:
> Hi Ramon, > > On Tue, Nov 11, 2025 at 2:02 PM ramon via ffmpeg-user > <[email protected]> wrote: > > My question is whether there is any way to clear the input buffer at the > > moment the SRT client connects, or any way to at least prevent the > bitrate > > exceeds the muxrate during the first few moments, which some clients do > not > > accept. > > The truth is that the SRT support in ffmpeg is really not that robust > for production use. It's great for a quick/dirty command line to test > something out, but for the use cases you're describing I would suggest > having ffmpeg output to a UDP port (e.g. udp://227.1.1.1:4001), and > then use a tool such as the command line srt-live-transmit to pick up > the feed and make it available via SRT. This will avoid all the > buffering issues you're describing (as the SRT output is now > completely disconnected from servicing the input). > > Devin > > -- > Devin Heitmueller, Senior Software Engineer > LTN Global Communications > o: +1 (301) 363-1001 > w: https://ltnglobal.com e: [email protected] Thaks Devin, The idea is good and works perfectly, avoiding the bitrate overflow problem for a few moments. Finally I use a combination of ffmpeg + srt-live-tranmit. The only thing is that I had to force the UDP multicast link to localhost because with the default interface I was losing packets. ffmeg -f decklink -i "DeckLink SDI (1)" ... [CBR h264 encoder] ... -f mpegts udp://@239.1.1.1:1234?local_addr=127.0.0.1&pkt_size=1316 srt-live-transmit udp://@239.1.1.1:1234?adapter=127.0.0.1 srt://..... _______________________________________________ ffmpeg-user mailing list -- [email protected] To unsubscribe send an email to [email protected]
