Latency of ffmpeg mpegts output to Decklink




I´m working with the set protocol for transporting video over internet. ( 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.