Latency of ffmpeg mpegts output to Decklink

Hi,

I´m working with the set protocol for transporting video over internet. (https://github.com/Haivision/srt)And so far things looks good.

I can encode a decklink stream:
ffmpeg -err_detect explode -f decklink -i ‘DeckLink Quad (8)’ -fflags nobuffer -vcodec libx264 -preset veryfast -tune zerolatency -b:v 10M -maxrate 10M -bufsize 10M -f mpegts - | ~/srt/srt-live-transmit -v “file://con” “srt://:5506?mode=listener&latency=100”

And play it back on another machine with very low latency over the internet:
./ffplay -probesize 120048 -i “srt://xx.xx.xx.xx:5506?tlpktdrop=1”

But as soon as I try to decode it to a decklink output on the same machine as the one I test replay on, I get a 4sec latency.

Here´s my decoding:
ffmpeg -i “srt://xx.xx.xx.xx:5506?rcvlatency=100” -probesize 120048 -pix_fmt uyvy422 -f decklink ‘DeckLink Quad (7)’

Plan is to stream from CasparCG, but right now I´m just using a separate machine until I know it´s working.

Does anyone know where the 4 sec buffer comes from?

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.

Hi Hreinnbeck,

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:

srt-live-transmit srt://xx.xx.xx.xx:5506 udp://:5001

and again gain, if I playback the UDP stream with:

ffplay -probesize 120048 -i “udp://:5501”

things plays perfectly with low latency (sub 500ms)

But if I take the same UDP stream and send it to a decklink output with:

ffmpeg -i “udp://xx.xx.xx.xx:5501” -probesize 120048 -pix_fmt uyvy422 -f decklink ‘DeckLink Quad (7)’

the UDP->Decklink adds 4 sec latency.
I´ve tried all sorts of buffers and -fflags nobuffer etc, but haven´t found where the latency is added.

Ah, totally missed that you are talking about the decklink output delay :smiley:

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.

1 Like

Hi hreinnbeck
Any update on your previous notes with BMD and ffmpeg?
Thank you in advance for your response.

Phillip

Hi, anyone know how to reduce this stream to decklink delay ?

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.

With -analyzeduration 1 getting stream on decklink with in 2 seconds before it was 4 - 5 seconds

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.

I’ll try OBS for decoding
Thanks

Privacy Policy   Terms of Service