🅿️ 🙍🏽 📹 ロシア語のGUI、またはVKS端末で自分で行う 🚊 👂🏾 💃🏻

ロシアのビデオ会議システム（VKS）用のC ++ GUIの開発経験。最新のテクノロジーと認証要件の統合。開発の主要な「レーキ」とそれらを回避する方法。GUIとロシアのバレエの共通点は何ですか。

ビデオ会議システムのユーザーが最初に目にするのはインターフェースです。そして、ほとんどの場合、システムを判断するのはその外観と機能性です。不便または広大なインターフェイスでは、高いシステムパフォーマンスまたは幅広い機能を評価できません。技術的には、「美しい」システムは、魅力的で安定した動作シェルで包まれるべきです。したがって、国内のVKSシステムの開発の開始時に、この瞬間がすぐに考慮されました。

ロシアのテレビ会議システムのユーザーは誰ですか？

2020年の春以降、本格的なVKSシステムを開発することの妥当性に関する質問への回答が明らかになりました。当局、商業企業、病院、学校は、一定レベルの生産性とセキュリティを備えた最新のコミュニケーション手段を必要としています。 Zoomで話すことはできますが、本格的な商談やマネージャーの運用会議に使用する価値はありますか？

ロシア企業のさまざまな仕事のために、国内のテレビ会議システムを作成することが必要になりました。また、ソフトウェアだけでなく、本格的なハードウェアで構成されるシステム。世界的に有名なベンダーの中で、少なくとも5社が多機能テレビ会議システムを提供しています。しかしロシアでは、輸入代替の概念が徐々に機能し始めています。さらに、多くの人にとってセキュリティの問題は製品の原産国よりも重要になり、現在の為替レートでの価格は最後の場所ではありません。そして、インターフェースの「美しさ」は、ゼロから開発することは非常に現実的であることがわかりました。

起動時のGUI

最新のインターフェースの主な要件は、実装のスピード、最新の外観、完全な使いやすさです。したがって、グラフィカルユーザーインターフェイス（GUI）の開発者の最初のタスクは、ビデオ会議用のソフトウェア機能の明確な定義でした。

GUIの観点から、次の要件が策定されました。

発信ビデオ/音声通話を行う;
着信を受け入れる/拒否します。
カスタム時間間隔で着信コールに自動応答します。
通話中と通話外の両方で2つのオーディオデバイス（ヘッドセット/スピーカーフォン）を切り替えます。
通話中と通話外の両方でマイクとカメラをオン/オフにします。
通話中のDTMFダイヤル。
ターミナルでの会議集会;
PTZカメラの管理、PTZプリセットとそのアプリケーションの保存。
複数の異なるウィンドウにビデオを出力する機能。
マウス、キーボード、リモコンを制御します。
Webインターフェースから端末をリモート制御する機能。

この関数のリストを使用すると、さまざまな方法でインターフェースの開発の問題を解決できます。さらに、特定のタイプの実装の選択は、プログラミング言語のタイプの制限（たとえば、Javaは、認証の理由、CSS / HTML-機能性に応じて断固として適切ではなかった）、開発者の専門化、およびタイミングの影響を受けました。まとめると、C ++とQt5フレームワークの使用を優先して選択されました。たとえば、より最近のQMLテクノロジーでは、任意のOpenGLコンテキストを使用してビデオをレンダリングすることができず、これはVKS端末のToRに応じて必要でした。

迅速かつ効率的に

最初のGUIプロトタイプはQtのソフトフォン用に作成され、多くのオープンソースライブラリを使用しました。たとえば、SIPプロトコルの場合、eXosip / oSIPライブラリ、ビデオとオーディオのエンコード/デコードにはffmpeg、オーディオデバイスの操作にはPortAudioが使用されました。このソフトフォンはLinux、Windows、MacOSで動作し、実際のデバイスではなくテクノロジーのデモンストレーターでした。

その後、抽象的なソフトフォンが実際のテレビ電話プロジェクトに変換され、そのソフトウェアの最初のバージョンが開始の2か月後に作成されているはずです。このような短期間でこの問題を解決するために、電話ソフトウェアはモジュールに分割され、能力に応じて複数の開発者グループに分散されました。このようなプロセスの編成は、テレビ電話プロジェクトを迅速かつ効率的に開発するのに役立ちました。

コアとフロント

統合し、既存のプロジェクトの他のデバイスで既存のGUI開発を使用できるようにするために、共通コードベースは、GUIバックエンドまたはGUIコアモジュールという別のモジュールにあります。また、デバイスごとに異なる直接表現は、個別のGUIフロントモジュールに実装されます。

GUIモジュールのこのアーキテクチャは有利であることがわかり、望ましい結果につながりました。VKSシステム自体の新しいコンポーネント用のインターフェースの開発は、比較的高速で高品質になりました。結局のところ、今ではVKS端末のインターフェイスをゼロから書き直す必要はありません。

苦痛と勝利

ソフトウェアを作成する途中で、当然、困難と問題があります。テレビ会議用のGUIの作成も例外ではありませんでした。システムの特定の目的に関係なく、どのコマンドでも繰り返すことができます。開発の道の難しさと勝利は同僚にとって興味深いものであり、おそらく「レーキ」なしで効果的な解決策を促すでしょう。

永遠の一貫性

歴史的に、さまざまなタイプのVKS端末のGUIの開発中に発生した最初の興味深い問題は、一貫性の問題、つまりすべてのモジュールの調整された状態でした。操作中、GUIは他のいくつかのモジュールと対話します。ハードウェアと対話するためのモジュール、通話管理サブシステム、メディア処理モジュール（MCU）、およびユーザー対話サブシステムです。

最初、GUIはこれらすべてのモジュールを独立して機能しました。つまり、2つの異なるモジュールに同時にリクエストを送信できました。これらのモジュール自体は独立しておらず、積極的に相互に作用しているため、これは誤りであり、時には問題を引き起こすことが判明しました。この問題の解決策は、特別な作業計画を作成することでした。これにより、すべてのモジュール内で要求の厳密な順次実行が保証されました。

追加には2つの困難がありました。1つ目は、一部の（すべてではない）要求に応答が必要なため、実際には端末が不整合な状態にあるため、他の要求を実行できないことを想定しています。ただし、応答を待つ間にユーザーインターフェイスをブロックすることも望ましくありません。次に、モジュールからのGUIリクエストへの応答、およびモジュールからGUIへのリクエストは、GUIとは異なる独自のスレッドで送られますが、GUIはスレッド内のすべての状態変更を実装する必要があります（Qtでこれを必要とするアクションもありますが、場合によっては、これによりスレッドの同期を確保するための不必要な問題が回避されます。

ソリューションが見つかり、2つの部分で構成されていました。最初に、他のモジュールからのすべての要求/応答は、QueuedConnectionと共にQtシグナルスロットメカニズムを使用して、つまりグローバルQApplicationイベントループを使用して、GUIストリームにリダイレクトされました。次に、すべてのリクエストの一貫した処理を保証するために、独自のキューと処理サイクル（TransitionLoop）を備えたTransitionsシステムが開発されました。

したがって、ユーザーがGUIのアクションボタン（たとえば、呼び出しボタン）を押すと、対応する遷移が作成され、遷移キューに配置されます。その後、遷移処理サイクルの信号が生成されます。 TransitionLoopは、信号を受信すると、現在進行中の遷移があるかどうかを確認します。存在する場合、現在の遷移の完了を待機し続けます。そうでない場合は、次の遷移が遷移キューから取得されて起動されます。同じ信号を使用して別のTransitionLoopモジュールから応答を受信すると、現在の遷移の完了が通知され、TransitionLoopはキューから次の遷移を開始できます。

ここで重要なのは、すべての遷移処理がGUIスレッドで行われることです。これは、QueuedConnectionバリアントのQtシグナルスロットメカニズムを使用することで保証されます。QueuedConnectionバリアントでは、各シグナルに対してイベントが生成され、アプリケーションのメインのEventLoopに配置されます。

低電力ハードウェアでのOpenGLレンダリング

私たちが対処しなければならないもう1つの問題は、ビデオのレンダリングの問題でした。 Qtは、OpenGLレンダリングに特別なQOpenGLWidgetクラスと関連するヘルパークラスを提供します。これらは元々ビデオのレンダリングに使用されていました。レンダリング用のデータ（デコードされたビデオフレーム）自体は、メディア処理モジュール（MCU）によって提供されます。MCUは、とりわけ、ビデオストリームのハードウェアデコード（GPU上）を実装します。低電力プロセッサでは、FullHDビデオのレンダリングが「遅くなる」ことがわかりました。直接的な解決策はプロセッサを交換することでしたが、これにはビデオ会議システムのすでに完成したコンポーネントの深刻な処理が必要であり、デバイス自体のコストが増加します。したがって、レンダリングプロセス全体を注意深く分析して、問題を解決するためのより美しい方法を見つけました。

標準のOpenGLレンダリングとハードウェアデコードでは、次のことが行われます。エンコードされたビデオのデータはネットワークから取得され、RAMに格納されます。RAMからのこのデータはGPUのビデオメモリに転送され、そこでデコードされます。そして、エンコードされたデータよりもかなり大きなボリュームのデコードされたデータが再びRAMに転送される。次に、レンダリングコードが機能し、このデータをRAMからGPUに直接転送してレンダリングします。したがって、かなり大量のデータがメモリバスを介して前後にポンプで送られ、バスはこれを実行できません。

OpenGLの最新バージョンでは、通常のようにメインRAMのデータではなく、GPUメモリに既にあるデータをレンダリングするために指定できる特別な拡張機能があります。このメカニズムは、ハードウェアデコードされたフレームのデータのGPUからRAMへの移動、およびその後の移動を除外しました。したがって、低電力プロセッサでのレンダリングの問題はほぼ解決されました。

もう1つの大きな問題は、QtでサポートされるOpenGLコンテキストでした。必要なOpenGL拡張機能を使用することはできません。つまり、このオプションでQOpenGLWidgetを使用することはできません。解決策は、通常のQWidgetを使用することでしたが、Qtレンダリングパイプラインをオフにしました。そのような機会はQtに存在します。ただし、このオプションではGUIがこのウィジェットの領域でのすべてのレンダリングを完全に担当するため、Qtは私たちを助けません。これはビデオの表示では正常ですが、ウィジェットをビデオの上で使用する場合、通常のQtツールは使用できません。たとえば、追加のポップアップメニューをビデオの上に表示する必要があるためです。

この問題は次のように解決されました。既存のウィジェットから画像が取得され（QWidgetにはgrab（）メソッドがあります）、結果の画像はOpenGLテクスチャに変換され、後者はOpenGLツールを使用してビデオの上にレンダリングされます。適切な環境を追加することにより、このような非標準的な方法でビデオの上に標準ウィジェットを表示するために使用できるユニバーサルメカニズムが実装されました。

キオスクとウィジェット

「キオスク」モードでのユーザーインターフェイスの表示の管理とフラグメントの配布は、簡単な作業ではありませんでした。 VKS端末は、オペレーティングシステムのデスクトップ環境にある他のウィンドウアプリケーションと同様に、ウィンドウモードと「キオスクモード」の2つのモードで動作できます（つまり、オペレーティングシステムは、グラフィカルインターフェースを備えた1つのアプリケーションのみを実行します-VKST-環境なしデスクトップ）。

ウィンドウモードでは、すべてが比較的単純です。ウィンドウはデスクトップ環境のウィンドウマネージャーによって制御され、アプリケーションは必要に応じて2番目のウィンドウを作成し、ユーザーは必要に応じてディスプレイにウィンドウを分散します。ただし、「キオスク」モードでは、システムにウィンドウマネージャーがなく、ウィンドウは1つしか存在できず、ユーザーはウィンドウを移動することができないため、すべてがはるかに複雑になります。そのため、ディスプレイの接続/切断など、イベントを自動検出するタスクが登場しました。このイベントが発生した場合、ディスプレイを自動的に構成し、ユーザーインターフェイスのフラグメントを正しく配置する必要がありました。

答えは、ディスプレイの操作を担当するLINUX Xrandr OSシステムライブラリからのものです。インターネット上にはドキュメントがほとんどないため、Habrを含むインターネットの例を使用して実装が行われました。さらに、インターフェイスのフラグメントをディスプレイ間で分散するアルゴリズムを考案し、2つの異なるウィンドウを1つのウィンドウに統合する必要がありました。後者は次のように実装されました。ウィンドウモードのウィンドウとは何ですか。「キオスク」モードでは、1つの大きなウィンドウ内にウィジェットがあり、2つのディスプレイにまたがっています（2つのディスプレイがある場合）。この場合、連続仮想空間が作成されるようにディスプレイの位置を構成する必要があります（これはXRandrライブラリを使用して行われます）。次に、単一のグローバルウィンドウ内の内部ウィジェットのジオメトリを設定して、誰もがディスプレイに表示されるようにします。

ロシア語を作成します

ロシアのビデオ会議システムを作成する全体の方法は、多くの段階で構成されており、GUIは氷山の一角にすぎません。最も顕著であり、最も困難ではありません。しかし、ソリューションの複雑さ、ソフトウェアとハードウェアおよびソフトウェアコンポーネントの組み合わせ、および技術的かつ審美的に「美しい」システムを作りたいという願望が、その過程で多くの困難を生み出しました。新しいタスクは非標準のソリューションを生み出し、ロシアだけでなく海外でも見せることを恥ずかしくない製品の作成に役立ちました。

ロシアの発展は長い間、その業績を証明してきました。私たちのライフハックは、GUI開発に真剣に取り組んでいるすべての人に役立ちます。他の開発者が新しいロシアのソフトウェア製品用の最新のシェルを作成するプロセスを高速化および簡略化できるようになることを願っています。私たちは、ロシアの決定が世界中でロシアのバレエやブラックキャビア以上に評価されると信じています。

ロシア語のGUI、またはVKS端末で自分で行う