You could try a lower bufsize and also changing to the ultrafast preset. Also you should test it locally to see if srt is adding the delay, I’m guessing srt at 100ms latency is useless anyways.
Thanks for the response.
As I wrote, I get perfectly low latency decoding the srt protocol using ffplay to the screen.
I can also receive the stream and convert it locally to UDP with:
Ah, totally missed that you are talking about the decklink output delay
Did some experimentation with that a few years ago. Never got an acceptable delay. Piping from ffmpeg to bmdplay worked OK. I’ll see if I can find my notes from those tests tomorrow.
I was playing with a setup similar than this. The setup you are testing can be done using obs just for comparison. Obs support srt also. And you can use Obs with a BM board as output. You can encode sdi (BM) to srt with ffmpeg and decode with obs using srt://xxx.xxx.xxx.xxx:port?mode=listener in a media source settings. Also you have a slider for the network buffer adjust. (Typically 2Mbyte buffer for a local lan application) Of course, any sdi conversion adds latency over the path. You can expect typically about 57 milliseconds for a Decklink minirecorder. But The latency you report (4 sec.) seems excessive. You must be sure that such latency is not related to the network. SRT is an udp transport. First check that the network is not introducing an excessive buffer. Low cost routers are not good with UDP. Also, the ffmpeg options “-bufsize 10M” in the encoder side and "-probesize 120048 " in the decoder side modify latency. But sometimes you need to trade delay versus stability. In the receiver side, the buffer size changes the playback start moment. I suggest you try obs for decoder side because by this way you can isolate potential problems related with the ffmpeg (ffplay) bm module compilation. Good luck.
Thanks macbab,
It’s not network latency, I think it is something with ffmpeg and decklink because ffplay is playing same stream in less than a sec delay and it is not related with srt I tried TCP and others.
I think it is ffmpeg to decklink buffer which is 4 seconds by default that we have to control.
I said : < I suggest you try obs for decoder side because by this way you can isolate potential problems related with the ffmpeg (ffplay) bm module compilation.>
If you try this way, then you can be sure that ffmpeg is the problem. Why i insist ? Because if your latency using this way is much lower, you can use the same ffmpeg compilation that OBS provide.
One year ago, i was using srt decoding receiving with obs and never i had such latency.
