[FFmpeg-user] FFmpeg single threaded bottleneck

[Carl Eugen Hoyos]

Am Do., 14. Mai 2020 um 21:50 Uhr schrieb Gabriel Balaich
<roderrooder at gmail.com>:
>
> So just read a question on stack exchange in-which someone was experiencing
> something similar to me, it looked like the issue may have been the audio
> codec being used was limited to one thread for processing, here is the
> question:
> https://video.stackexchange.com/questions/15996/ffmpeg-encoding-and-core-usage

There is no multi-threaded audio encoding.

> So I decided to remove every audio device / stream from a command for
> testing:
> ffmpeg -y `
> -thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M
> -video_size 3440x1440 -framerate 100 `
> -pixel_format nv12 -i video="Video (00 Pro Capture HDMI 4K+)" `
> -map 0 -c:v h264_nvenc -preset: hp -r 100 -rc-lookahead 200 -pix_fmt nv12
> -b:v 288M -minrate 288M `
> -maxrate 288M -bufsize 288M -an `
> -vsync 1 -max_muxing_queue_size 9999 `
> C:\Users\gabri\Videos\MW1.ts `
> -map 0 -c:v h264_nvenc -preset: hp -r 100 -rc-lookahead 200 -pix_fmt nv12
> -b:v 288M -minrate 288M `
> -maxrate 288M -bufsize 288M -an `
> -vsync 1 -max_muxing_queue_size 9999 `
> C:\Users\gabri\Videos\MW2.ts `
> -map 0 -c:v h264_nvenc -preset: hp -r 100 -rc-lookahead 200 -pix_fmt nv12
> -b:v 288M -minrate 288M `
> -maxrate 288M -bufsize 288M -an `
> -vsync 1 -max_muxing_queue_size 9999 `
> C:\Users\gabri\Videos\MW3.ts `
> -map 0 -c:v h264_nvenc -preset: hp -r 100 -rc-lookahead 200 -pix_fmt nv12
> -b:v 288M -minrate 288M `
> -maxrate 288M -bufsize 288M -an `
> -vsync 1 -max_muxing_queue_size 9999 `
> C:\Users\gabri\Videos\MW4.ts
>
> 3440x1440 at 100FPS is essentially 4K60 in terms of bandwidth, so with the
> above command, I am essentially encoding 16K60 in real-time (see attached
> log for full output). For a second I thought I may have found the issue,
> that being that the audio processing is being limited to one thread...
> Alas, that same thread on my processor that seems to be getting most of the
> processing load on the commands with audio streams included is still
> getting most of the processing load without the audio streams included,
> albeit to a lesser extent:

Is the issue you see only reproducible with dshow input or also with testsrc2
input?

I suspect there will always be a bottleneck in a load situation like above
but it may be interesting to narrow it down.

Carl Eugen