I've been using the following command to capture video with ffmpeg for the past two months using my Blackmagic Intensity Pro 4K capture card:

ffmpeg -bm_v210 1 -rtbufsize 1500M -threads 4 -f decklink -i "Intensity Pro 4K@20" -c:a copy -c:v prores -profile:v 1 movie1.mov

This has been fine although occasionally I get a "Decklink input buffer overrun!" error, in which case I have to restart the capture.

However, starting yesterday, I am getting a "Desklink input buffer overrun!" error every time.

[decklink @ 0000000002552cc0] Decklink input buffer overrun!bitrate=479405.2kbits/s speed=0.849x
    Last message repeated 1 times
[decklink @ 0000000002552cc0] Decklink input buffer overrun!bitrate=480001.5kbits/s speed=0.842x
    Last message repeated 8 times
[decklink @ 0000000002552cc0] Decklink input buffer overrun!bitrate=480685.0kbits/s speed=0.842x
    Last message repeated 15 times

So it looks like my SSD is no longer fast enough to write the data-- but why? It worked fine for the past two months.

I'm capturing onto a Sandisk Extreme Pro SSD (960 GB). The drive only has 10GB of data on it. I manually ran TRIM just a moment ago, but that didn't help. The SanDisk SSD Dashboard shows it has "99%" life remaining.

I have also disabled OneDrive, Dropbox, and all other software I could find that might write to the system during capture.

  • Replace movie1.mov with -map 0 -f null - to see if it's disk-related. Note: no file will be saved, so this is just for testing purposes.
    – Gyan
    Commented Apr 19, 2017 at 16:49
  • @Mulvya When I make the replacement, I get the same error. What does that mean? Commented Apr 19, 2017 at 16:58
  • More info: When I capture to dnxhr (hq) instead of prores (lt), even though the dnxhr bitrate is ~850000 kbit/sec vs ~450000 kbit/sec for prores, dnxhr works, but not prores. Commented Apr 19, 2017 at 17:21
  • What's your ffmpeg version?
    – Gyan
    Commented Apr 19, 2017 at 17:32
  • 3.2.0. Can't use the builds of 3.2.2 or 3.2.4 because the "enable_decklink" flag isn't turned on so the capture card doesn't work. Commented Apr 19, 2017 at 17:49

1 Answer 1


Since it also happens with -f null, but not with another Codec, the CPU load during the capture is a possible explanation. You did not mention it in your question. Is there any specific reason to use -threads 4? Try raising that number or omit the parameter.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.