就在前几天，我发布关于我无法实时转码多轨视频的问题，-rc-lookahead 最终成为了解决方案。然而，这是在录制相当静态的信号时，当每个捕获卡接收到更复杂的信号时，我仍然无法使用该帖子中提到的任何命令进行实时转码。
命令：
ffmpeg -y `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 3440x1440 -framerate 100 `
-pixel_format nv12 -i video="Video (Pro Capture)":audio="ADAT (3+4) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 3840x2160 -framerate 60 `
-pixel_format nv12 -i video="AVerMedia HD Capture GC573 1":audio="SPDIF/ADAT (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 1920x1080 -framerate 60 `
-pixel_format yuv420p -i video="Game Capture HD60 Pro (Video) (#01)":audio="Game Capture HD60 Pro (Audio) (#01)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -i audio="Analog (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -i audio="ADAT (5+6) (RME Fireface UC)" `
-c:v h264_nvenc -preset: llhp -pix_fmt nv12 -rc-lookahead 100 -b:v 288M -minrate 288M -maxrate 288M -bufsize 288M `
-c:a aac -ar 44100 -b:a 384k -vsync 1 -max_muxing_queue_size 9999 `
-map 0:0,0:1 -map 0:1 -map 1:0,1:1 -map 1:1 -map 2:0,2:1 -map 2:1 -map 3 -map 4 `
C:\Users\djcim\Videos\FFmpeg\FFmpeg.ts
目标是同时同步录制所有源，为了简单起见，此命令中缺少我用于同步的许多选项。最重要的是，上述命令不会实时转码。录制以大约 0.5 倍速开始，慢慢爬升至 1 倍速，但一旦达到 0.9-0.95 倍速，它就会停止上升，最终我的系统内存（32GB）饱和，导致帧丢失、转码速度甚至更差，以及系统总体运行缓慢。我不确定我的系统内存实际上被填满了多少，因为每个输入只有 2GB 的缓冲区，总共应该在 11GB 左右……但我离题了。
将每个输入与其自己的输出分开似乎没有帮助。如果我删除任何一个源，即使只是链接到其中一个视频流的音频流，我也可以在一分钟内实现实时转码。如果我删除其中一个视频源，我会在 10 秒内实现实时转码。如果我将视频比特率降低到 1M，我也可以在 1 分钟内实现实时转码，尽管你会认为这比删除其中一个较小的音频源的效果更大。
因此，您可能会认为我的系统中某个地方存在瓶颈，但实际上并没有明显的瓶颈。CPU 和驱动器使用率低于 30%，而我的 GPU 编码器使用率低于 70%。此外，如果我将每个输入/输出分离到其自己的 Powershell/FFmpeg 实例，但仍同时/同时运行它们，则所有内容都会实时转码，基本上是即时的，这似乎可以排除硬件瓶颈。这可能只是 FFmpeg 的限制吗？或者有没有可以解决这个问题的选项？
对此事的任何见解都将不胜感激。