しかし、次にこのLinuxで実行されているソフトウェアは何でしょうか？ 存在しないバグを見つけることに関するクールなdatacompboyの記事がいくつかありますが 、まだ情報は散在していますが、一般的な状況は次のとおりです。
悲しい現実は、非常に多くの場合、このソフトウェアは最良の方法とはほど遠いものです。 ファームウェアの作成者がTCPを介したデータ損失のスキルを習得しているため、路上に設置されているほとんどのカメラは、サーバーまでの距離が長いため、非常に影響を受けていると言えば十分です。
この状況をファームウェアで修正し、Rustに賭けることにしました。
労働条件
行うべきことがいくつかあります。SDKの並べ替え、ハードウェアをセットアップするコードの記述、H264フレームの取得、ネットワークへの送信。 いくつかの些細なこと、特にIPカメラに展開してすべてをデバッグするのがいかに簡単で単純かを考慮してください。 さて、残りの些細なこと：このコードをRustで書くことにしました。
実験としての錆は、その驚くべき特性のために選ばれました。コンパイル時間は、ランタイムの不足とともにメモリの完全性を保証します。 これは、メモリの割り当てを制御する可能性を期待できることを意味します。これは、リソースのtight迫を考えると非常に重要です。
Go、Erlang、またはいくつかのJava / C＃が機能しないのはなぜですか？ IPカメラには8メガバイトのフラッシュドライブと128メガバイトのメモリがあり、その半分はビデオのニーズに応じてカーネルから取得されるためです。 さまざまなカメラが存在することは明らかですが、不必要にコストを引き上げないように、常に最小限の処理を試みます。 1台のカメラで、64メガバイトのフラッシュドライブを見ました。もちろん、そこを回ることができますが、非常に小さなフラッシュドライブで十分です。
だから、3000ルーブルの安価なカメラで通常の写真を見る：
# free total used free shared buffers cached Mem: 60128 17376 42752 0 2708 4416 -/+ buffers/cache: 10252 49876 Swap: 0 0 0 # cat /proc/cpuinfo Processor : ARM926EJ-S rev 5 (v5l) BogoMIPS : 218.72 Features : swp half thumb fastmult edsp java CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part : 0x926 CPU revision : 5 Hardware : hi3518 Revision : 0000 Serial : 0000000000000000
このような状況では、お粗末な書面によるソフトウェアはすでに3〜4の接続で非常に苦しみ始めています。 IPカメラを使用する際の黄金律：一般に、複数の接続（または各品質ごとに2つ）を行わないようにします。これは、カメラへの狭いチャネルだけでなく、IPカメラの4番目のクライアントがしばしば不可能にするためです最初の3つのビュー。 今後、私たちと50人のクライアントに問題はなかったと言えます。
カメラはどうですか
先に進む前に、現在の段階で使用しているカメラデバイスについて少しお話しします。
SPIフラッシュドライブはカメラにはんだ付けされています。 これは、一部のロッカーがそれ自体をBIOSにフラッシュしているものと同じフラッシュドライブです。 このSPIフラッシュドライブの内容の読み取り、ティックによるピックアップ、書き込み（運が良ければ）が可能です。プロセッサはデータをメモリから読み取り、実行します。 フラッシュドライブがSPIではなく、NANDである場合は、すべてがより複雑になります。ダニを捕まえられないように、より責任が必要です。
フラッシュドライブの最初はubootです。 このブートローダーは、カメラだけでなく、ルーターや電話など、ほぼすべての組み込みデバイスで使用されます。 すなわち ほとんどの場合、Windowsのコピーよりも多くのコピーが世界中にあると主張できます。
Ubootにはオープンソースがありますが、特定のハードウェアに固有のデータが保存されます。 XM製のカメラからHikvision製のカメラにUSBフラッシュドライブをコピーすると、ubootでも起動しない可能性が高くなります。
すなわち すでにこの段階で、有名なカメラの登録、それらの経理を維持するエキサイティングなプロセスがあります。これは、注文したものを正確に送信する隣人の驚くべき能力によって促進される非常にクールです。 良い例として、特定のモデルと特性のカメラを提供するために3年間契約を結んだ顧客（国の最大の全国オペレーター）からの最近の話を引用できます。
しかし、大丈夫です、これはすべて解決された問題です。
そして、Linuxカーネルがあります。 考えられるすべてのカメラに対して1つのコアを組み立ててから、モジュールを接続するだけで済むとしたら、それは非常に簡単です。 いいえ、できません。したがって、チップセットのバージョンが異なると、異なるカーネルが必要になります。2.xy、3.xyの場合はどうしてですか。 閉じられたモジュールはカーネルに送られるためです。 どこかで考えつくことができますが、それでもすべてを統一することはできません。
その後、通常の世帯のビルドルートが続きます。 すべてはここの人々のようなものです。
次に、i2cを介してハードウェアを構成する（場合によっては）トリッキーなスクリプトを実行し、正しいモジュールをダウンロードして、特別に作成されたソフトウェアを起動する必要があります。
ビデオキャプチャー
ビデオキャプチャには多くの鉄のトレーニングがあります。 onvif仕様とIPカメラSDKのマニュアルを読むと、多くの共通点を見ることができます-ソフトウェアインターフェイスはほとんどのハードウェアの一般的な構造を反映しており、ビデオはセンサーから取得され、少し処理された後、エンコーダー（もちろんハードウェア）にプッシュされ、ソフトウェアで取得できますメモリ内の特定の場所からの既製のH264 NALユニット。 基本的なシナリオでは、ユーザー管理、設定、およびある種のネットワークプロトコルを添付するだけです。 本格的なカメラの場合、あらゆる種類の大量カスタマイズメカニズム（ディスカバリ、onvif、psiaなど）と分析のサポートが必要です。
そして、Rustはどうですか
それはさびたストリーマーです。 bindgenを使用してSDKコードから自動生成された安全でないコードの束、libcへのパッチされたバインディング（アップストリームでパッチを埋めようとします）、tokioにRTSPを実装します。 通常のブラウザでカメラのビデオを視聴する機会はすでにあります。これは、ActiveXのインストールを必ず必要とする中国のカメラでは実現不可能な贅沢です。
アーラン後の構造は非常に珍しいです。結局のところ、プロセスやメッセージはなく、チャネルがあり、それらによってすべてが少し異なります。 上で書いたように、正しい組織で現代的に書かれたコードは、パフォーマンスを低下させることなく、2〜3クライアントではなく、50以上のクライアントにビデオを配信することを可能にします。
重要なポイント：開発中に、単一のセグメンテーション違反はまだ発生していません。 Rustは、原則として、悪いことを見たことがある良い白髪の人々が書くように書くようにするという永続的な感覚があります。 だから今のところ、私はすべてが好きです。
8月中に、ベースラインシナリオに従って作業を完了する計画があるため、調査に参加している聴衆に質問があります。 さて、生じた質問をしてください。