日々勉強しているITの知識をまとめています。rtmp-moduleを利用して高ビットレート長時間映像配信を実現したい。hls配信で目指した。最初はどうしても長時間のエンコードができず途中で止まってしまう状況だったが、下記のようにサーバの設定を少しずつ変え、またエンコーダ設定も変えながら改善を重ねた結果エンコーダが止まる事はなくなった。残念ながら、ちょっとした映像が止まったりという状況の改善までは至らなかった。Pingでもロスが確認できる時間帯があるので、ロスがあるとどうしても瞬間的な停止などにいたってしまう。hls配信にくらべ、rtmp配信にすると送信状況はかなり改善される事も分かった。インターネット回線が光フレッツ隼でもPingロスが出る。うちの会社は比較的田舎にあるので、この地域のインターネット環境に引っ張られるわけではなく、他の地域でも同程度起こる事だと思う。Nginxサーバを設置して映像配信を始めたら、予期せぬ切断が出るようになった。今のところ高ビットレート2500Kbpsだと2時間おきくらい発生する。低ビットレート368Kbpsにしても同程度の頻度で発生していた。バッファを持たせれば切断に強くなるんじゃないかと思うのだけど、情報が少ない。バッファ設定は2つの場所でできそうだけど、どちらの機能がどうなのかが良く分からない。原因の究明OBS特定バッファサイズの調整このサイトが一番マニュアル的に信頼があるのかなhttps://jp9000.github.io/OBS/settings/encodingsettings.html他の、日本語サイトに書いてある通り、画質向上に役立つらしい。動きが激しい時に、ビットレートが上がってしまうからそれをならすために利用するけど、リアルタイム性が失われるからあまりお勧めされてない。Guide特定バッファサイズの調整は、インターネットの信頼性向上につながるかもしれない。situations.予期せぬ切断に特定バッファサイズを使用にチェックを入れて動作させたところ、低ビットレートの切断しない時間は長くなった。18時間程度切断せず低ビットレートに状況の改善はみられるものの、まだ切断が発生する。遅延配信を設定するhttps://jp9000.github.io/OBS/settings/advancedsettings.htmlネットワークに衝撃(障害)があった時にそれを最小限に抑える調整ができる。最終手段的な感じで書かれてる。一応配信続けてるけど、同じエンコーダでやっているので一度停止する。推測すると、エンコーダから通信を開始して、サーバからackが返って来ないって事かな。低ビットレートの時はいいけど、高ビットレートになるとこの現象は起きやすくなる。高ビットレートでもバッファサイズを大きくすると、この現象は起きにくくなるが、完全にはなくならない。違うけどLinuxのTCP受信バッファ溢れと輻輳制御の話nginxサーバのTCP受信バッファが溢れた問題クライアントからの再送も重なり、結果的にnginxサーバが慢性的なバッファフルによる輻輳状態に陥り、パケットをぼろぼろ落とすという現象が発生していたようです。ウィンドウサイズを小さくする事で、ackを早め早めに返す。ackをロスしても、再送量を少なくさせる事で、ackロスを重ねた時に復帰しやすくするという考え方。デフォルトの1/10で設定するとどうか。この設定をする事により、スループットは落ちてしまうはずだが、速度自体は必要十分出ているので。状況変わらずなので、上記と逆。nginxとの通信でウィンドウサイズを大きくする事で、できるだけackが返る量を少なくしてみる。再送の際には負荷がかかるが、ウィンドウサイズが大きいのでackが返るまでのデータ量も多く効率を上げる事でスループットが上がる。125000遅延配信有効にする20s今度はOBSがハングアップする。「obs32.exeは動作を停止しました。」3時間くらいごとに起こる。25000遅延配信有効にする20s配信3時間ほどで停止。Nginxは動き続けてるけど、エンコーダがNginxから切断されたと判断。that.もし、切断したとしてもサーバがちゃんと切断を判別し、すぐにエンコーダが再接続してくれれば大きな問題は出ないのではないか。切れた時の特徴として、エンコーダは切断されていて、再度接続しようとしても接続できない。0.0.0.0:1935つまり、切れたことになっていないって事。command).指定した秒数の間、音声、映像がこなければサーバ側で切断と判定する。再試行の遅延10sバッファを15sストックして、映像と音声が10s来なかったら切断として判断し、エンコーダからの再接続を受け付ける。正解に一歩近づいたかもしれない。エンコーダは動き続けてる。3時間を過ぎたあたりで1回切断があった。それを再接続できるようになった。これは設定による想定内だけど、残念なのは、映像受信クライアント側で一度受信し直さなければならなかったこと。できれば、エンコーダが切断しても、受信側では何が起こったのか分からないように処理を継続したい。無事再接続でき、エンコーダはずっと動き続ける。後は、映像受信クライアントに気づかせないで再接続できるようになればパーフェクト。組み合わせ設定5(切れてもいいや、すぐに再接続されて映像受信クライアントで映像が止まらなければ)組み合わせ4で問題が出たのはエンコーダ側の遅延配信が問題なのではないか?再接続された時に遅延配信設定が悪さをし、なかなか映像が送られず、サーバ側に映像がない空白時間が増えすぎて、結果としてクライアントで映像を見ていると途切れてしまうのではないか。(仮定)という事から、遅延配信設定を無効にする。再試行の遅延10s配信遅延設定は関係なかったかもしれない。エンコーダは動き続けているが、映像受信クライアントでは映像が止まってしまった。現在VideoJSでweb受信していたのだが、m3u8を直接受信できるwebクライアント(Egdeとか、スマホ系ブラウザとか)で受信すると、プレーヤが停止することなく受信できるようなった。映像受信中にコマが停止したりする事があった。エンコーダが再接続する時には受信クライアント側で映像が止まってしまうのが問題。work.特に、遅延配信有効にして、カットオフポイントも入れておくと、エンコーダが再接続した時に変な動きにならないかも。切断された時も、誰もそれが起こった時に逃さないって表現になっているし。チェックを入れておくと、切断し、エンコーダが再接続した時に正しい再接続ポイントで接続してくれるので、映像受信者は切断に気づかず配信が可能なはず。組み合わせ設定6(切れてもいいや、すぐに再接続されて映像受信クライアントで映像が止まらなければ)とりあえず、設定項目を洗って、下記の組み合わせが良いというところまできた。受信側に切断を気づかせたくない。そのためのバッファの長さなどを少しずつ変えてベストを探る。再試行の遅延7s映像受信クライアントにてm3u8に直接アクセスする。nginx側でも、ある程度バッファを持つ30s映像、音声のパケットが届かない時間を5s続けたら切断とみなし、切断する。何と、これで解決した。OBSでキーフレームを4sにしたところ、全く切れなくなった。低ビットレートでも、バッファなどを設定しない標準状態だと、やはり時々切れる事がある。その時のネットワーク状態がどのような状態か、Ping試験をし続けロスを調べた。TTL=52要求がタイムアウトしました。要求がタイムアウトしました。TTL=52要求がタイムアウトしました。要求がタイムアウトしました。要求がタイムアウトしました。TTL=52要求がタイムアウトしました。要求がタイムアウトしました。要求がタイムアウトしました。要求がタイムアウトしました。Themegraphy。