s が他の主流プレーヤー (vlc など) とは異なることがわかりました。 ) 比較すると、最初の表示時間は遅延がほとんどなく最速です。使用されるプル ソースは香港衛星テレビのライブ ブロードキャスト ソースです: rtmp://live.hkstv.hk.lxdns.com/live/hks## ＃。 2018-03-27 更新:
コードを一部変更したところバグが発生し、非常に迷惑です。最近、一部のネットユーザーからのカスタマイズされた HTTP ヘッダーの追加機能のリクエストに応えて、送信機能を修正して、Nginx の HTTP フレームワークのフィルター インターフェイスを導入しようとしましたが、それでも失敗したため、単純かつ大雑把に抽出しました。最後のフィルター モジュールと header_filter モジュールを削除しました。 Nginx の公式安定バージョンである nginx-1.12.2 は、github でのコンパイルに使用されます。その結果、一部のネチズンは今日、コンパイルできなかったと報告しました。確認したところ、私が nginx-rtmp-module を修正して以来使用している nginx-1.11.10 に、見つからなかったマクロが追加されていたことが判明しました。 、ネチズンが使用するバージョンが低かっただけでコンパイルできませんでしたが、修正されました。
2018-03-29 更新:
数日前、一部のネチズンは、nginx-1.13.1 以降のバージョンを使用して nginx-http-flv-module でコンパイルする場合、次のように報告しました。 flv.js はプル ストリームの再生に失敗します。2018 年 3 月 25 日のアップデートを参照してください。この問題は、最初にストリームをプッシュしてから再生する際にも発生します。この問題は簡単に修正できます。Nginx の最新バージョンと少し古いバージョン (nginx-1.11.10) がテストされています。
2018-04-05 の記録:
今回は更新ではありません:) 昨日、一部のネチズンが、flv.js を使用してプッシュ ストリームを再生すると再生できないと報告しました。 nginx-http-flv - モジュールにまた問題があると思いました。私はそれを自分でテストし、最新の nginx-1.13.10 でコンパイルしました。プッシュおよびプル ストリームの再生には問題ありませんでした。また、公式の安定版でもコンパイルしました。 nginx-1.12.2 をインストールしても問題はありませんでしたが、夕方に何が問題になったかを確認する準備をしていたときに、あるネチズンが、テストによると、ブラウザーが flv.js の数を制限していると報告しました。 1 つのブラウザでは 6 つの flv.js しか開くことができませんでした。今日の正午に Firefox を使用してテストしましたが、その後、7 つ目の flv.js を再生できませんでした。このことから、nginx-http-flv-module に問題がないことが確認できます。ただし、これは非常に重要な情報です。flv.js の再生をサポートするブラウザの数には制限があり、Chrome と Firefox は両方とも 6 に制限されています。他のブラウザはテストされていません。
2018-04-06更新:
以前の統計データにはhttp-flvライブブロードキャストの受理件数と出力が含まれていませんでしたが、追加されました。 flv.js のサポートが安定しました。以下は、flv.js を使用して再生するスクリーンショットです。
ある商用メーカーは、ビデオ ソースが純粋な場合にこの問題を報告しました。どのような再生方法を使用してもビデオの再生接続には問題ありませんが、デバッグの結果、純粋なオーディオの判定ロジックにバグがあることが判明し、nginx- が発生しました。 http-flv-module がオーディオおよびビデオ データを送信するインターフェースで無限ループする問題を修正しました。
2018-04-14 更新:
昨日、一部のネチズンが、gop_cache オプションがオンになっていると、プッシュ ストリーミングによってメモリ リークが発生することが判明したと報告しました。プッシュフローがオフになっているときに解放されない問題は、メモリが原因で修正されました。また、ネットユーザーからのフィードバックによると、マルチプロセス モードの on_connect および on_play コマンドに問題があるため、修正されるまで当面はこれら 2 つのコマンドをマルチプロセス モードで使用しないでください。
2018-04-15 更新:
ある商用メーカーは、ランダム フラッシュ テスト中にメモリが増加し続けると報告し、デバッグ中にメモリ リークが発生した可能性があると報告しました。夜に実際にメモリリークが発生していることを確認しました。原因は ngx_http_request_t 構造体のメモリプールが解放されていないことによるもので、修正されました。
2018-04-21 更新:
一部のネチズンは、マルチプロセス モードでは認証操作に on_play が使用されるが、プッシュ時にはローカル リレー (受け付けるサブプロセス) が使用されると報告しました。プッシュ (他の子プロセスにストリームをプッシュする) によって、on_play 認証も実行されますが、認証は以前に実行されているため、これは不合理です (ただし、実際にはバグではありません)。 nginx-http-flv-module はローカル リレーの on_play 操作を削除しましたが、on_play が何に使用されるかは関係ありませんが、ローカル リレーが on_play 操作を実行しないことを考慮すると、変更されたコードは比較的単純であり、回復は簡単です。簡単なので、一時的にこのように変更します。さらに、netizen @qqzzzx によって報告されたストレス テストのクラッシュの問題は部分的に修正されました。残りの問題は、ストレス テスト グループが切断された後にメモリ リークが発生することです。修正後は github に更新されます。
2018-04-25 更新:
ストレス テストのクラッシュ問題が修正され、過剰な CPU 使用率の可能性がある問題も解決されました。ストレス テストは 1 回以上行われました。時間 (srs -Bench 独自のテスト ビデオ、500 HTTP-FLV および 200 RTMP)、まだ問題は見つかっていません。バグの報告を歓迎します。
2018-05-12 更新:
一部のネチズンは、gop_cache オプションをオンにすると、場合によってはストレス テストで大量のメモリを消費する可能性があると報告しました。メモリ リークがあるかどうかはわかりません。ストレステストは何度も再現できないとネチズンは、ストレステストツールとサーバーが同じホスト上にない場合は再現しやすいと指摘した。確かに、この方法でストレス テストを再現するのは簡単ですが、メモリ消費量が比較的大きい場合は、ストレス テストを停止してから再度ストレス テストを実行しても、メモリの同時実行数は増加しません。メモリリークの問題ではないことを確認します。ソースコードを何度も確認した結果、GOP を送信するときに GOP データが一度に送信リング配列に入れられたため、Nginx は非同期でノンブロッキングであるため、実際にはリング配列からネットワークにデータを送信していないのではないかと推測しました。 (たとえば、サーバーとクライアント間のネットワーク帯域幅が不十分な場合)、割り当てられたメモリはすぐに再利用できず、GOP が実際に送信された後、割り当てられたメモリは (メモリ プール内で) 解放されなくなります。接続とは関係がなく、構成構造のみが関係します)。後続のデータ送信は一度に送信される GOP データとは異なり、リサイクルされたメモリを完全には使用できず、大部分がアイドル状態になります。次に、独自の独立したメモリ プールを使用するように gop キャッシュ モジュールを変更し、GOP の送信後にこのメモリ プールを解放します。
2018-05-14 更新:
2018-05-12 更新で導入されたメモリ リークのバグを修正しました。コードは長い間理解できず、すぐに問題が発生しました。条件
が変更されました。高いバージョンの gcc コンパイル プロジェクトが失敗するバグを修正しました (オンラインで確認しました。gcc-7.x.x は、特定のコンパイル オプションを追加するときにスイッチ ケースが失敗したかどうかをチェックします) が、非常に高いバージョンの gcc を持っていません。そのため、まだ発見されていないコンパイルエラーがいくつかある可能性があり、現在ネチズンからの返信を待っています。
2018-05-16 更新:
日中、gcc-7.2.0 をコンパイルしてインストールしたところ、コンパイルのフォールスルー警告 (Nginx コンパイルのエラーとみなされます) がすべて見つかりました。オプション)。バグが修正されました。
2018-05-18 の記録:
これは更新ではありません。2018 年 5 月 12 日の更新では、ストレス テスト中に gop_cache オプションをオンにすることが特殊になると思います。 (使用したツールは srs-bench です) 今夜ログを確認したところ、前回の推測が主な原因ではないことがわかりました。ログから、chunk_size 設定項目が設定で指定されていない場合、つまり、サーバーが Set Chunk Size プロトコル制御メッセージを送信した後、Nginx は常に 128 バイトのデータを受信することがわかります。 、クライアント クライアントが Set Chunk Size プロトコル制御メッセージに応答しなかったため、サーバーは以前の 128 バイトを使用し続け、最悪の場合、nginx-http-flv-module がパッケージ化するためにメモリを割り当てます。 128 バイトのデータをパックするために非常に多くのバイトの領域 (4096 RTMP ヘッダーの最大サイズ) を使用すると、32 倍のデータが無駄になります。比較テストには ffmpeg を使用します。ffmpeg は Set Chunk Size プロトコル制御メッセージに応答するため、メモリの無駄が発生しません。 SRS (Simple-RTMP-Server) の作成者に問題が送信されました。時間があるときに、nginx-http-flv-module によるこの例外の処理を更新します。
2018-05-20 更新:
一部のケースで特にメモリ消費が発生する問題は修正されました。消費量がまだ非常に多い場合は、前述の 2 番目の理由が原因である可能性があります。上記の原因。
2018-06-14 更新:
ネットユーザーから報告された、一定期間実行した後の ngx_stat_active パラメーターの値が正しくないことが原因であることが判明した問題を修正しました。減算演算が繰り返される問題は修正されており、通常の関数の使用には影響しません。
2018-06-19 に更新:
nginx-rtmp-module のいくつかのプル リクエストのバグ修正を同期しました。基本的に、それらは大きな修正はありません。さらに、fmp4 を直接プッシュする機能が nginx-http-flv-module に追加されました。今夜、MSE (Media Source Extensions、現在 iOS の Safari ではサポートされていません) をサポートするブラウザに純粋なビデオ fmp4 を直接プッシュする機能が実装されました。 ) を再生すると、音声が後で追加されます。
2018-06-25更新:
fmp4をプッシュする基本機能はほぼ完成しました。一部のネチズンが JSON 形式で stat をサポートする PR をプッシュしました。私が試してみたところ、小さなバグも修正されました。
2018-06-29 更新:
2 つのメーカーが RTMP を正式に商用化した (gop_cache をオンにする) という事実を考慮して、stat 内の元の rtmp 情報を http-flv に変更します。 HTTP-FLV (gop_cache が有効になっていない場合)、マイルストーン バージョン 1.2.4 がリリースされました。
2018-07-09 更新:
3 つの小さなバグを修正しました。DASH 機能をオンにすると、ファイルから読み取られたデータが 0 であるために無限ループが発生する可能性があり、XML を修復しました。メソッド nginx-http-flv-module のバージョン番号が統計に表示されない問題 (ネット民からの PR); HEAD リクエストが flv_live の場所を設定していない場合に 405 (メソッドが許可されていません) を返すバグを修正#
