中国のビデオカメラとTCP：バグまたは機能？

MKDの管理職の地位の奪取、および公共の混乱を「とかす」必要性に関連して、ビデオ監視システムを徐々に構築しています。

もちろん、資金調達は最小限であり、計画は壮大であるため、すべてが牧草地から収集されます。

詳細は少し後で説明しますが、ここに私が多くのことを経験させた興味深いバグの1つがあります。



だから、それはすべて小さなもので始まりました-シンプルなドームカメラ、最もひどいものは「 IPとドームのみを使用する 」という原則に基づいて撮影されました。 その後、ソフトウェアの検索プロセスが開始されました（別の投稿のトピックは、再び後でなります）...最後に、1つのチャネルのMacroscopで修正されました。 数ヶ月でしたが、食べ物や飲み物を頼むことはありませんでした。



そして今ではすべてが機能しているように見えますが、どういうわけか定期的にクラッシュします。 パーセント、ネットワーク、ソフトウェア、火星の天気など、すべてに罪を犯しました...ログによるサポートは、カメラが定期的に落ちることを示しています。



更新



はい、より多くのカメラを購入しましたが、品質と価格はずっと高くなりました。 異なる週の3つの美しい日に怠inessを克服した後、すべてが1階にマウントされ、コンピューターに持ち込まれ、接続されました。 そして、ソフトウェア列挙の2回目の反復が行われたため、カメラがより大きく、より人道的になり、インターフェースがより便利になりました... 2回目の列挙の後、AxxonNextが立っています。 はい、遅れのみが新しいレベルに達しました。TCPを有効にすると、カメラは5〜10分ごとにほぼ同期して低下します。 そして、UDPを保持していると、何がわからないのでアーティファクトが上昇します。



私はバケツでこの主題について不平を言い、 maxlapshinを取り、これはファームウェアが独自の努力によって作成された中国のカメラの安定したバグであると言います：クライアントにすくいの時間がなければ、ゴミはストリームに入ります。 アリルアーで販売されていたため、問題を徹底的に解決しようとすることにしました。 私はさまざまな言葉で何度もバグを説明しようとしましたが、私たちはどちらも英語が望まれるものが多いため、「コードを表示する」だけでよいことに気付きました。

発掘の第一段階：理由を見つける

そのため、まずtcpdumpを使用して、崖の状況を待ちます。 少し待って、5分で3枚も釣れました。 何が起こったのかを理解するには？ 150万パケットのストリーム...そもそも、1台のカメラだけを残してフィルタリングします。 次に、Ctrl + F => tcp.flags.syn == 1 =>再接続の開始点を見つけ、そこからスクロールして、何が起こったかを理解します...







コンピューターの一部で接続が閉じられたことがわかります...これより前に、Win = 11460、Win = 10200、Win = 8940が混乱しているだけです。つまり、クライアントには実際に時間がありません。 停止停止停止。 どうして間に合わないの？ AMD Phenom II X6 1100T？ いいえ、変です。 IO？ したがって、別のディスクに記録し、棚に休まなかった。 そして、たとえば視聴に依存するでしょう-しかし、存在しません...一般的に、私たちは少し高くスクロールします：







ですから、文字通り一瞬前に、彼らは一般的にZeroWindowに去りました。 正確には時間がありません。 しかし、なぜ崖ですか？！ 下にスクロールして、別の崖を見て......







したがって、ZeroWindowを最大2.5秒間観察します-ゲートにまったく登りません。 下にスクロールすると、理解し始めているようです：









見てみると、TCPスタックの動作が非常に悪く（カメラ？おそらく...）、その後RTPストリームが迷いました-ある時点で、DynamicRTP-Type-96ではなく、RTSP Continuationが進みました。



結論として、シミュレーションに必要なのは、RTPストリームを要求し、それを少し引き出してからsleep（）を実行し、ストリームが中断するかどうかを確認することだけです。

フランケンシュタインのパーツを見つける

テストピースをすばやく投げる必要がある場合はどうしますか？ スクリプト言語、既製のライブラリのセットを使用して、すべてを一緒に作り上げてください。 Googleに乗り込みます。 Python + ONVIF。 腐った。 Ruby + ONVIF。 ああ、 ruby-onvif-clientがあります 。 OK ストリームURLがキャッチされました。 すばらしいですが、プロトコル：.. UDP、HTTP、TCP ...結果は1つです-素晴らしい、onvifを使用してURLをキャッチする方法を学びました。



カール？ 噛みません。 さて、Ruby + RTSP ...ほら、ライブラリがあります。 彼にURLを噛ませてください。 Basicのみでログインを試みます。 もう少しグーグル。 残念。 次に、1つの方法が残っています-ファイルです。 私たちは、熱い鉄ではんだ付けし 、途中でカットの魔法のボリュームを誓います（「正直な」再帰を正しく行う方法を教えてくれるので、リターンとイールドは正しく機能しますか？機能の説明から必要なことをどのように推測できますか？正しく...それを取り除くのは簡単です彼女-そして、よりきれいなコード、および絹のような髪）。



そして再び喜び、rtsp_clientは機能します。 2番目のウィンドウでtcpdumpを開きます...くそー！ ONVIFのIが要求しました：protocol =>“ TCP”。 一体何だ、なぜUDPなのか？



あなたの手にはんだごて...ハ！ UDPはlib/rtsp/client.rb@request_transportに固定されています。 そこで、同じ爪/ TCPでそこにはんだ付けします。 私たちは始めます-それは落ちます。 なんで？ どこへ？ ええ、client_portが必要です... TCPの場合、どのclient_portですか？ 554にない場合は、rtp_portをハードコードします。したがって、サーバーにはIPが必要です-ハードコード。 Opaは、「bind（）」ではポート554に移動するルートではない、と言うことはできません。 論理的です。 それで、なぜですか？ まあ...それはRTPにあります::レシーバー ... init_socketをモードで見る：TCP and wonder-なぜ彼はレシーバーにTCPServerが必要なのですか？ 何かが正しくありません。 明らかに、TCPで明示的にデバッグしている人はいませんでした。



ロジックを理解しようとして数分後、警戒眼は壁がないことに気付きました。

トランスポート：RTP / AVP / TCP;ユニキャスト;宛先= 172.28.1.199;ソース= 172.28.1.95;インターリーブ= 0-1

さあ...何がインターリーブされていますか？ Google：rtp interleaved => Wikipedia =>「interleaved」ページで検索=>はい！ そのため、RTPとRTSPは同じ接続で動作します！



私のタスクのために私は本当に編集したくない、または率直にしたくないので、rtspライブラリを捨てます-ここでは明らかに良い方法でアーキテクチャをやり直す必要があります。

アメーバを育てる

したがって、再びゼロになります。rtspがあります。//カメラのurl。それをマージし、接続中のドレイン中に再生する必要があります...停止します！ 最初は。 URLがあります。 カメラがあります。 バグを再現するタスクがあります。 なぜONVIFが必要なのですか？ RTSPを選ぶ理由 答えをリクエストしてダウンロードするだけです。



すぐに言ってやった。 DESCRIBE？ そして、なぜそれが必要なのか...最初にセットアップ、セッションを取得する場所、そして彼女とプレイするだけです。



最初の経験は、彼がここで承認さえ必要としないことを示しました。

いいね！ すぐに撮影された最初のパンケーキ： 単純なスクリプトがバグを完全に再現しました-スリープ後（） 'そしてストリームは突然鳴りました。



ただし、TCPウィンドウを操作するには、TCP_WINDOW_CLAMPを設定できる必要があります。 このために、setsockopt TOを実行する必要がありますが、ソケットを作成した後に接続します。

そして、ルーブルでそれを行う方法は？ ええと... Googleを調査しています...空です。 ソースを調べます-init_inetsock_internal ...イチジクがあります！ まず、rsock_socket（）を作成し、すぐにrsock_connect（）を作成します。 くそー



さて、私はまだカットが本当に好きではありません。 2分でpythonに書き換え、setsockoptを追加します。 RTPパケット番号の分析を追加します。



分析の結果：情報量は、初期ウィンドウのサイズ、カメラが正常に送信する前にカメラがどれだけ壊れるかに応じて変化します。 しかし、彼は結果を要約し、売り手にバグレポートを書いて、彼らが開発者にファームウェアを渡すようにしました。



私は落ち着いていただろうが、 maxlapshinはどうにかこのバグと一緒に暮らすことができるかどうか尋ねた。 そして、これには追加の発掘が必要でした。

原則として、それと一緒に暮らす方法は？

1）障害を追跡し、自分で再接続できます

2）フローが中断するのを待たずに、自分のラグを追跡できます（方法はわかりませんが、できます）。

3）ストリームとの同期を復元しようとすることができます。



したがって、レイズコールではなく再接続コールを使用し、RTPパケットの数の違いによって損失を分析します。 ポイント1で処理すると、損失は約1500〜1800 RTPパケット（1秒あたり約600パケットのスリープ（））です。



スリープ直後に再接続します（）。 結果はまったく同じです。



検索方法 "$ \ x00"による再同期を維持します-それはうんざりします。 検索方法「$ \ x00 [LEN] {len bytes} $ \ x00」を使用して再同期を維持します-安定して動作し、損失は再接続よりも1.5倍少なくなります。 ただし、最も重要なことは、TCP接続が失敗しないことです。つまり、TCPウィンドウと受信バッファーの適応アルゴリズムは引き続き機能します。 その結果、接続の開始時に1-2の障害が発生した後、ストリームは単に中断を停止します。sleep（）は定期的にクライアントを落ち着かせ、ストリームは落ちません。



結果として得られるテストスクリプトは、コードの品質で輝きませんが、概念実証の機能を完全に実行します。



そして今、ついに、タイトルで尋ねられた質問に来ました。

これはバグですか、それとも機能ですか？

私の個人的な意見は、接続を完全に切断するよりも本当に優れています。接続には多数のRTPパケットが存在するため、問題なく失われたボリュームを測定できます。

チャネルがネットワーク帯域幅よりも薄い場合-損失が増加するため、5秒以上にわたって損失を検出します-穏やかにチャネルの厚さについて不平を言うことができます（低品質で再接続する、ケーブルを変更する、原子力発電所を爆破する、またはその他の対応方法この問題）; 問題が、何らかの理由でレシーバーが単にレーキアウトする時間がないことである場合-再同期動作=幸福。 UDPアプローチとTCPアプローチの利点を同時に組み合わせて利用できます。何かが完全に悪い場合、断片が失われます。 それ以外の場合、再送信は自動的に行われ、問題は発生しません。



まず、ファームウェアのどのようなバグについて話しましょう...しかし、バグは簡単です。send（somedata、somelen）は、エラーの場合は<0を返し、エラーが発生した場合はバイト数を返します。 そして、すべての初心者ネットワーク開発者のお気に入りの間違い：send（somedata、somelen）はsomelenよりも少ない何かを返すことができます-それはバッファに収まりませんでした。



これが処理されない場合、somedataからのテールは単に失われます-送信されず、破棄されません。

修正方法

この方法で修正するには、配信されていない部分を記憶し、この残りのsend（）がすべてをすべて送信するまで、送信を停止する必要があります。 その後、_next_パケットの送信を開始する必要があります（バッファが常にビジーだったパケットを破棄します）。 次に、TCPとUDPの混合の動作を取得しますが、クライアントがパケットの境界と魔法の再同期を行う必要はありません。



メーカーがこのバグを修正してくれることを願っています。しばらくすると、中国のカメラ用のすべての中国語ファームウェアは、1回の中断とtmなしで正常に動作します。

喜びの源：LIVE555ジュラ紀

サポート macroscopは、LIVE555が2011年に発表されたという事実に馬鹿げた不注意を抱きました。そのため、binwalk + dd + mountを使用して、ファームウェアの内部を調べました。 rtsp_streamerと真実、2011年から。

live.2013.10.09.tar.gzとlive.2014.02.19.19.tar.gzの2つのバージョンの差分を調べました。

diff --git a/liveMedia/RTPInterface.cpp b/liveMedia/RTPInterface.cpp index d45e5a8..3d88d55 100644 --- a/liveMedia/RTPInterface.cpp +++ b/liveMedia/RTPInterface.cpp @@ -324,19 +325,23 @@ Boolean RTPInterface::sendRTPorRTCPPacketOverTCP(u_int8_t* packet, unsigned p } Boolean RTPInterface::sendDataOverTCP(int socketNum, u_int8_t const* data, unsigned dataSize, Bool - if (send(socketNum, (char const*)data, dataSize, 0/*flags*/) != (int)dataSize) { - // The TCP send() failed. - - if (forceSendToSucceed && envir().getErrno() == EAGAIN) { - // The OS's TCP send buffer has filled up (because the stream's bitrate has exceeded the cap + int sendResult = send(socketNum, (char const*)data, dataSize, 0/*flags*/); + if (sendResult < (int)dataSize) { + // The TCP send() failed - at least partially. + + unsigned numBytesSentSoFar = sendResult < 0 ? 0 : (unsigned)sendResult; + if (numBytesSentSoFar > 0 || (forceSendToSucceed && envir().getErrno() == EAGAIN)) { + // The OS's TCP send buffer has filled up (because the stream's bitrate has exceeded + // the capacity of the TCP connection!). // Force this data write to succeed, by blocking if necessary until it does: + unsigned numBytesRemainingToSend = dataSize - numBytesSentSoFar; #ifdef DEBUG_SEND - fprintf(stderr, "sendDataOverTCP: resending %d-byte send (blocking)\n", dataSize); fflush(st + fprintf(stderr, "sendDataOverTCP: resending %d-byte send (blocking)\n", numBytesRemainingToS #endif makeSocketBlocking(socketNum); - Boolean sendSuccess = send(socketNum, (char const*)data, dataSize, 0/*flags*/) == (int)dataS + sendResult = send(socketNum, (char const*)(&data[numBytesSentSoFar]), numBytesRemainingToSen makeSocketNonBlocking(socketNum); - return sendSuccess; + return sendResult == (int)numBytesRemainingToSend; } return False; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これはchangelog.txtからの切り抜きです：

2013.12.04:

- Updated the "sendDataOverTCP()" function (in "RTPInterface.cpp") to allow for the possibility of

one of the "send()" calls partially succeeding - ie, writing some, but not all, of its data.

- Fixed a couple of minor bugs. (Thanks to "maksqwe1ukr.net".)



? . , LIVE555 .



, -- topsee; MontaVista. , .