3

Windows 上の ffmpeg によって (DirectShow を使用して) キャプチャされたシステム オーディオを、ストリーミング MP3 ファイルとしてブラウザーに出力する小さな nodeJS サーバーを作成しました。オーディオは、バッファリングを最小限に抑えて、またはバッファリングなしで、可能な限りライブである必要があり、オーディオの「スキップ」効果は完全に許容されます。

HTML5 オーディオ タグを使用して Chrome でオーディオを再生すると、低遅延の LAN 接続で約 8 ～ 10 秒の遅延が発生します。これはクライアント側のバッファではないかと考え、クライアント側で Flash MP3 プレーヤーを使用したところ、遅延が 2 ～ 3 秒に短縮されました。

現在、バッファリングはサーバー側で行われているようです。NodeJS の response.write のドキュメントには、データがカーネル バッファーに書き込まれることが記載されています。クライアントが常に最新の音声データを取得できるように、バッファリングを完全に回避するか、少なくともバッファリングを回避するにはどうすればよいですか? 「ドレイン」イベントを処理して常にライブデータをプッシュするための戦略は?

request オブジェクトでは、setNoDelay(true)を使用して Nagle のアルゴリズムの使用を回避しました。以下は、生成された ffmpeg プロセスがデータを発行するときにデータがどのように書き込まれるかのスニペットです。

var clients = []; //List of client connections currently being served
ffmpeg.stdout.on('data', function(data) {
    for(var i = 0; i < clients.length; i++){
        clients[i].res.write(data);
    }
});
4

1 に答える 1

1

遅延/バッファリングが発生する場所がいくつかあります。

  1. DirectShow キャプチャ (~100ms 程度)
  2. FFMPEG MPEG エンコーディング バッファ (構成に応じて 1 ～ 10 秒)
  3. ネットワークの書き込みと送信 (セットアップではほぼ 0)
  4. クライアント側のバッファリング (ご覧のとおり、クライアントによって異なります。ほとんどのクライアントは、デコードのために最大 2 秒間バッファリングします)

確認する必要があるバッファは、FFMPEG エンコーディング用のバッファであると思われます。FFMPEG の実行時に入力形式が明示的に構成されていることを確認することで、これを減らすことができました。また、最初のビットは間違いなく遅延するため、エンコードのためにデータの最初のチャンクをドロップするようにしてください。

これを行うと、遅延が 1 ～ 2 秒であることがわかります。少なくとも、それは私が同様の設定で得ているものです。

于 2012-10-27T02:48:03.667 に答える