我使用 FFMPEG 将 RTMP 流捕获为 HLS（保存播放列表文件），没有任何流处理，只是复制它。由于这样的设置，我能够运行数十个进程（我最多尝试过 80 个），内存和 CPU 消耗不超过 30%。
这是我的命令：
ffmpeg -i <RTMP__STREAM_URL> -hls_init_time 10 -hls_time 10 -hls_list_size 0 -f hls -strftime 1 -hls_segment_filename '%H-%M-%S-%s.ts' -hls_flags split_by_time -codec:v copy -codec:a copy ./play$(date -d "today" +"%M%S-%s").m3u8
不幸的是，随着进程数量的增加，我开始丢失一些 HLS 段（HLS 由播放列表文件和组成该文件的段组成）。例如，HLS 从 0:00 到 0:40 播放正常，但随后在 0:40 冻结 10 秒（我的片段有 10 秒长）并在 0:50 解冻。
当运行 20 个 FFMPEG 进程时，丢失率约为 5%，当运行 80 个进程时，丢失率接近 50%。
我正在使用 Ubuntu 22.x 和各种机器类型在 AWS EC2 实例上执行这些基准测试。无论机器类型如何，错误的频率都保持不变，因此我认为它与 CPU 或内存无关。
我怀疑这与 I/O 和文件写入（EC2 或 Ubuntu 设置）有关。
有任何想法吗？
答案1
解决了。
事实证明，这与资源或任何性能无关。视频冻结是因为进程覆盖了彼此的片段。
显然，毫秒精度的时间戳不够独特。我通过为每个进程添加一个随机生成的值来解决这个问题，然后将其用于文件名中。当然，如果我为每个进程使用不同的目录，也可以达到同样的效果。
即使有 100 个进程，以下命令也能完美运行：
ffmpeg -i <RTMP_STREAM_URL> -hls_init_time 10 -hls_time 10 -hls_list_size 0 -f hls -strftime 1 -hls_segment_filename $(rand)'%H-%M-%S-%s.ts' -hls_flags split_by_time -codec:v copy -codec:a copy play_$(rand)_$(date -d "today" +"%M%S-%s").m3u8 </dev/null >/dev/null 2>&1 &