私はストリーム処理なしでRTMPストリームを再生リストファイル保存（HLS）としてキャプチャするためにFFMPEGを使用しています。ただコピーするだけです。この設定のおかげで、メモリとCPU消費が30％以下の状態で数十のプロセス（最大80まで試み）を実行できました。
これは私のコマンドです：
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で停止解除されます。
FFMPEG プロセスを 20 個実行すると損失率は約 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 &