私たちは自分の手でエラーを修正するか、「誰も揺さぶらない」バグを修正します

最近、TCPストリーミングカメラのバグの波をすでに提起しましたが、それを中国に独占的に転がしました。 そして問題ははるかに広いです。 私自身は、問題を解決しました。苦労してファームウェアを修正しました。



では、このバグについて詳しく説明します。

簡単にバグについて

ツリー上の思考の以前の広がりを読んでいない人のために、そして単に問題を形式化するために、私は簡単にバグ自体を書きます。

カメラがあります。 あなたはそれを置き、接続し、監視します-そしてすべてがうまくいきます。 ここでしばらく放置し、ビデオアーティファクトの視聴を開始します（さまざまな理由により、パケットが失われます）。 あなたはああ言う！ カメラをUDPからTCPに切り替えます（そこで失われるべきではありません！）。 そして、あなたはより興味深い画像を観察します-うらやましい規則性で、接続は単に消えます。 同時に、ネットワークは整然としており、損失は見えず、何も見えません-しかし、カメラは定期的に落ちます...

外観の性質

そのため、RTSP経由でネットワークにストリームをブロードキャストする特定のカメラがあります。

ブロードキャストはUDP上で実行でき、各ネットワークパケットは自給自足（多かれ少なかれ）です。 いずれかのパッケージが消えたり、注文が破損したりする場合は、いつでもプロトコルとその他すべての準備ができている必要があります。 このプロトコルは、お客様向けにも設計されています。

ブロードキャストはTCPを介して実行できます。 TCPは配信を保証するストリーミングプロトコルであるため、（理論的には）パケットに分割されず、各フレームのラベルとその長さがプロトコルに追加されます。 これにより、TCPをUDPとして想像することができます。マーカー、長さを読み取り、その後、目的のバイト長=>パケットを受信した後、読み取りを行うと、タスクは前のものに削減されます。

ただし、いくつかのニュアンスがあります。カメラとクライアント間のチャネルがカメラによって作成されたストリームよりも薄い場合、UDPパケットがそれ自体で単純に消えると、TCPが再起動します。 発信パケットはカメラのメモリに蓄積され始めます。 したがって、ある時点で、カメラのメモリは終了します。

これを防ぐために、サーバー側のすべてのメーカーは、送信ホールに収まらない場合、何らかの方法でデータを破棄します。

しかし、この破棄は正しく行う必要があります-UDPパケットで完全に失われた場合、TCPではパケットが任意の瞬間にフリーズします。 そしてここから、すべての悪の根源であるまさに魔法が始まります。



最も有名なオープンソースRTSPストリーマーはLive555サーバーです。

何らかの形で、それはサイドラインで使用されるカメラメーカーの他の多くの派生物の根底にあります。



TCPを介してパケットを送信する教科書の実装を考えてみましょう。これは、元の形式の場所でもカメラに残っています。



sendRTPOverTCP関数を見てください。送信は「 直接 」実装されます。 パッケージの開始ラベル「$」を送信します。 次のバイトでチャネル番号を送信します。 次に、長さを形成し、次の2バイトを送信します。 最後に、パケット全体を送信します（1つのsend（） 'ohmでUDPに送信されます）。



各送信は、データが送信されたことを確認します（ソケットは非ブロックモードなので、送信できるもののみが送信されます）。 send（）が元のパケット長（エラー）を返さなかった場合、送信機能を終了します。 パッケージをドロップしています。

落ちますか？ いや！



そのため、まず、1つのパケットの送信は4つの個別のsend（）で構成されます。 そして、それらのいずれかのエラー、すべての残りは呼び出されません。 つまり、$のみが送信され、それ以上送信されないことが判明する場合があります。 または、$とチャネル番号は移動しますが、長さは移動しません。 または、チャネル番号と長さは$になりますが、パケット自体はそうではありません。 または...



send（）は、非ブロッキングモードで送信バッファーにコピー/送信されたパケットを送信しようとします。 送信バッファーに入った、または送信バッファーに入ったバイト数を返します。 繰り返しますが、送信バッファに送信されたバイト数または送信バッファに送信されたバイト数です。



したがって、パケットの半分も送信できることがわかります。 または、長さの半分...結果として、1つのパケットが完全に送信されないため、送信されたストリームが破損します。 単純に必要な長さの$ +チャネル+長さ+ package_を読む単純なクライアントは、これらの場所で壊れます-長さが最も変化します、またはパッケージ全体を読んだ後、それ以上の$はありません（そこに記載されているよりも多く読んだため）。



ある時点で、バグに気づき、「修正」されました。 最近の実装を見てみましょう。送信は4つではなく2つのステップで行われ、最初にパッケージプレフィックスが収集され、次にパッケージ自体が送信されます。 さらに、送信は特別な関数sendDataOverTCPによって実行されます 。これにより、パッケージ全体の送信、および送信に問題があったかどうかが保証されます。



うまくいきませんでした。 なぜだろうか？



「保証」送信のアルゴリズム：非ブロッキングソケットでsend（）を実行します。 エラーが返された場合、ソケットをブロッキングに切り替え、ブロッキングモードで送信します。 次に、ソケットを非ブロッキングに戻し、エラーが発生したことを報告します。



もう一度：間違いを見つけましたか？ それだけですか？ ;）



だから、主な間違い：最初のsend（）はすでに何かを送信しました！ したがって、ブロッキングモードでsend（）を実行すると、パケットの先頭が再送信されます。



2つの出荷があります。 そして、最初は、forceSendToSucceed == Falseを渡しますが、何かを渡すこともできます。 ナルピマー、3バイト-$、パケット番号、長さの下位バイト。 その後、エラー、データは送信されず、次のパケットが送信され、その$は長さの高いバイトのようになります...



バグは永遠ですか？ いや！ 12月13日、バグは「修正」されました。 これが最終バージョンです。



彼らはすべてを提供したようです：何もしなかった場合、エラーを返し、パッケージは完全にはなくなりません。 何かが起こった場合、ブロッキングモードで残りの部分のみを送信する前に、残りが完全になくなった場合、成功を返します。 したがって、パケットデータの次のステップの送信が実行されます。 そして、すべてが「良い」です。



さて、何が悪いのでしょうか？ そして、これは次のとおりです。パッケージは常にブロックモードで全体を残します。 したがって、1つのクライアントへの送信に関する問題により、カメラに接続されているすべてのクライアントにブレーキがかかります。

また、送信パケットに少なくとも1バイトが入っても、sendPacket（）は何もドロップしません。 そして、誰もパケットサイズを揃えていないため、送信バッファのサイズと送信パケットの多重度は等しくないため、送信の問題がある場合、パケットドロップの状況はまったくないことがわかります...



まあ、少なくともフローは壊れません。 それもありがとう。 主なことは、この時間中にOOMをキャッチしないことです。 それはただビデオが遅れ始めるだろう...



言い換えれば、Live555の最終的な解決策は間違っていると思います...



正しい解決策（そして非常に簡単です！）読者の関心を温めるために次回説明します:) [upd： next time ]

配布エリア

そのため、バグは広まっています。 上記のLive555コードで見たエラーはすべて異常ではありません。これらはネットワークで作業するすべてのプログラマーによって繰り返される標準エラーです。



中国のカメラの海でバグが見られます。 Live555に基づくものだけではありません。 このバグはD-Linkカメラで見られました。 このバグは、さまざまなブランドのカメラで見られました（これは、いつものように、中国メーカーのさまざまなモジュールに基づいています）。



問題が発生する可能性は、カメラの解像度とビットレートが高くなると高くなります。 彼が長い間気付かなかったのはこのためです。最近、カメラの価格に対する解像度の比率が大幅に増加し始めており、FullHDおよびより厚いカメラが求められています。 そして、中国人の価格のおかげで、彼らが最も頻繁に気づき始めるのは彼らです。 いつものように、中国人は罪を犯し始めます...間違いはまったく中国人以外のプログラマーによってなされました。

診断

カメラと監視ソフトウェアがある場合-しばらくの間、TCPモードでテストするために切り替えます。 安定した接続にもかかわらず、切断が観察される場合、または不安定な接続で、ビデオ全体または通常のビデオアーティファクトではなく、ソフトウェアがクラッシュまたは接続を失う場合、クライアントとカメラにバグがあります。



カメラにのみ杖を付けるには、スクリプトを使用します 。

膝に装着されるため、エンドユーザー向けではありません。



スクリプトの開始時に、次のパラメーターが設定されます。host-IPカメラ、url-直接必要なトラックへのストリームURLのフルパス。 非標準ポートを使用すると、ポートをオーバーライドできます。



パラメータダンプを使用すると、RTPストリームをビデオに書き込むことができ、同じmplayerで視聴できます。 dumprawを使用すると、rawストリームをそのまま書き込むことができます。



ビートレートを上げるには、行112のコメントを解除します（「time.sleep（st）」を使用）。 176行目で、ストリーム回復モードを選択できる場合。 Falseの場合、ストリームは再同期され、Trueの場合、完全な再接続が実行されます。 これにより、時差を推定できます。

治療方法

バグがあります。 それは非常に広まっていますが、最近出現し始めました-このバグで大量の鉄がすでに野生になっています。 この場合の適切な治療方法は？



私の個人的な意見：治療は二国間であるべきです。 同時に、新しいハードウェアにバグがなく、既存のカメラのファームウェアを更新できるように、カメラのファームウェアを編集する必要があります。



ただし、顧客は、フローが故障する可能性がある状態で生活できる必要があります。 ストリーム障害=超過=>次のパケット全体の始まりを探しているだけです。 本質的に、これは状況をUDPに減らし、パケットドロップの整合性のみがアプリケーションに送られます。



クライアント側のバグを修正するには、これらの各クライアントのサポートを拷問する必要があります。 macroscopは以前の投稿で既に購読解除されていて、おそらくこれを読んでください。 私は今、AxxonNextに完全に移動しました-彼らのサポートは通知されましたが、私は長い間このバグで彼らを苦しめてきました。 この問題に直面しているユーザー-チケットを作成し、ソフトウェアの製造元にそれぞれの措置を講じるようお願いします。 Erlyvideoは最近、フィードで障害が発生した後のスレッド回復のサポートを追加しました。



私のテストスクリプトに実装されている再同期コードを最適とは考えないでください。簡単に記述できます。 より正確なもの（より早く、より正確に再同期する）をより速く実装することは可能ですが、出発点としてだけでなく、概念実証としても最適です。



カメラの側面からバグを修正するために、私は連絡を取ったすべての人を拷問しようとしました。これらのモジュールから収集している中国の売り手に手紙を書きました。 他のベンダーに手紙を書きました。 私はカメラメーカーに書き込もうとしました。 私は、カメラの上に立っている組み込みLinuxのメーカーに書き込もうとしました。 私はhabrで書きました



残念ながら、結果はゼロです。私はバイポッドでは小さすぎます。 幸いなことに、 ipeye.ruで働くAndrei Syomochkin（deepweb）が私をノックしました。



IP EYEは、外部カメラとまったく同じモジュール-TopSee （TS38）のモジュールに基づいて、ビデオ録画と独自のカメラのクラウドベースのストレージを提供します。 これらは、これらのカメラのファームウェアのインターフェイスと機能を大幅に作り直しています。 しかし、私が理解しているように、元のファームウェアのソースコードはありません。必要なモジュールの収集、ソフトウェアの交換など、既存のカメラをソートします。 クラウドを提供するため、ほとんどのカメラはインターネットに直接接続します。 このようなリモートカメラを使用すると、UDPの使用はすでに不快になりつつあります。再送信の可能性は高すぎますが、チャネルの厚さは目にとっては十分です。 Erlyvideo（flussonicの意味で）は、サーバーレシーバーとして使用されます。 古いバージョンのflussonic（再同期なし）を使用すると、さまざまなカメラのロールオフの量が非常に大きくなります。 更新されたバージョン（再同期あり）を使用すると、再接続の回数が大幅に削減されます（ただし、損失の量は依然として不快です）。



気が散る。 Andreyは、スタンドで修正したストリーマーをテストすることを提案しました。したがって、 sigrandからソースを収集するよりもはるかに簡単にテストカメラにアクセスできました。

治療

残念ながら、現在の記事はすでに巨大なので、私が適用した治療法は先日別の記事で説明します。



要するに、ファームウェアをアンパックし、そこからストリーマーを入手し、悪い場所を探し、バイナリにパッチを当て、ファームウェアを再構築します。

ボーナスバグ

このバグに対処しているときに、Max Lapshin（@erlyvideo）は別の興味深いバグに遭遇しました。 カメラは全体的にきれいに見え、正しいバッファリング方法を適用しました。パケットがすぐに全体を離れない場合、バッファ内に残り、時間が近づくと送信されます。 まだ遅延されていないすべてのパケットは静かにドロップするため（$ /チャネル/サイズとパケット番号を含む全体がドロップされます）、UDPに似た美しいパケットドロップのように見えます。



このようなバッファリングメソッドの副作用は次のとおりです。TCPストリーム（GET_PARAMETERまたはOPTIONS）を通過するキープアライブ要求への応答は、サーバーが要求を受信するとすぐに送信されます。 すぐに。 リクエストを受け取る方法。 つまり、データパケットの途中でも答えが返ってきます。 したがって、ストリームを「現状のまま」-$ +パケット+長さ...でデコードし、$の代わりにRTSPを待つ場合-キープアライブを送信するたびに（30秒ごと、カメラがないと45秒後にカメラがストリームを中断するため）、ストリームが中断します-応答で〜100バイトのゴミが返され、ビデオにジャムが飛び出します。これは次のキーファイルで修正されます。



クライアントによるこのバグの処理はすでに複雑です。まずRTSPを探して分析（削除）する必要があります。\ r \ n \ r \ nを最初に探してから、$ +パケット+長さ+ビデオの残りを探します。 Flussonicの最新バージョンは、その方法をすでに知っています。

丸薬

修正の詳細（内容と方法）は後でなりますが、現時点では、カメラがTS38に基づいて構築されている場合は、TCPの問題が完全に解決された変更を加えたファームウェアを取得してインストールできます。



そこで、最新バージョン2.5.0.6の次のファームウェアを収集しました。

1. firmware_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110-TCPFIX.bin
2. firmware_TS38CD-ONVIF-P2P-V2.5.0.6_20140126121011-TCPFIX.bin
3. firmware_TS38HI-ONVIF-P2P-V2.5.0.6_20140126121444-TCPFIX.bin
4. firmware_TS38LM-ONVIF-P2P-V2.5.0.6_20140126121913-TCPFIX.bin
5. firmware_HI3518C-V4-ONVIF-V2.5.0.6_20140126124339-TCPFIX.bin

同じメーカーの他のモジュールの修正が突然必要になった場合は、コメントに書いてください。可能であれば表示します。