[FFmpeg-user] Fwd: Understanding/preventing buffer overruns

[Marton Balint]

On Mon, 20 Jul 2020, Simon Roberts wrote:

> [...snip, mostly successful scenario describing simultaneous recording
> of four video channels...]
>
>> But... I get almost continuous buffer overruns after about a minute.
>> Can someone tell me where to start learning about how I might fix this
>> (I presume it can't be good that it's doing this even though the
>> output seems to be OK, right?)
> [...snip...]
>> Here's a sample of the messages during recording (which also repeat
>> essentially continuously)
>>
>> [decklink @ 0x55b2249e8580] Decklink input buffer overrun!
>>     Last message repeated 1 times
>> [decklink @ 0x55b2249a4040] Decklink input buffer overrun!944kB
>> time=00:00:52.30 bitrate=549308.8kbits/s dup=35 drop=4048 speed=0.999x
>> [decklink @ 0x55b2249e8580] Decklink input buffer overrun!
>>     Last message repeated 13 times
>
> Poking around, it seems the universal answer to all questions of this
> kind is "your computer can't handle the workload". However, I'm
> absolutely certain this is not the case for me since if I run a single
> ffmpeg process to capture these four video plus four audio channels, I
> get high rates of buffer overrun reports, but, if I run five *separate
> but simultaneous* ffmpeg processes, each one capturing/compressing a
> single video stream, and a fifth that captures the audio (which is
> actually coming from a four channel USB device), the recordings
> proceed at 1x, with no buffer overruns, and no complaints of any kind
> at the default logging level. Also, the CPU load during this
> five-ffmpegs-at-once totals just about one-half the total available
> CPU power of the machine.

Output IO speed can also limit the ability of the process to read the 
input fast enough.

>
> The only real downside to this approach that I perceive is that I have
> a tiny (perhaps one or two frames??) synchronization error between the
> relative files, but it seems to indicate that perhaps ffmpeg's
> internal buffer management might either allow control that I don't
> know about that would fix this (I'd love to hear about it if this is
> the case) or that there is a significant opportunity for improving the
> tool in respect of higher performance modern machines and this kind of
> capture (I'm only capturing standard 1080/30p and increasingly it
> seems that 4K is growing in popularity.)

1-2 frames difference is unavoidable, even if you capture multiple inputs 
in the same process, syncrhronized capture is not guaranteed at all.

>
> So, to that end, I now have two new questions (unless someone can tell me how to
> tune the buffers or whatever and make this work well as a single process)
>
> 1) how would I report this to the developers (the ffmpeg-devel list
> seems to say that it's for discussion of development, not for
> reporting issues/bugs/rfes)?

This is mailing list is the right place. Or trac.ffmpeg.org if you are 
confident this is a bug (I think it is not).

>
> 2) What pointers for how I might be able to participate in trying to
> work on the improvement?

Complete command line you are using and the console output is a good 
start.

>
> On the latter, I have to admit that it's a longshot as, a) it's been
> 25 years since I wrote any
> C++ (I still code, but other languages), b) I would have to start
> understanding this software from the ground up which would likely take
> ages, and c) I have severely limited time that is "spare".

As we all.

Regards,
Marton