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
_______________________________________________
ffmpeg-user mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
