GUI dalam bahasa Rusia, atau terminal VKS melakukannya sendiri

Pengalaman dalam mengembangkan C ++ GUI untuk sistem konferensi video Rusia (VKS). Sintesis teknologi modern dan persyaratan sertifikasi. "Rake" utama pengembangan dan cara untuk menyiasatinya. Apa kesamaan GUI dan balet Rusia?

Hal pertama yang dilihat oleh pengguna sistem konferensi video adalah antarmuka. Dan dalam banyak kasus, mereka menilai sistem dan fungsinya. Antarmuka yang tidak nyaman atau luas tidak akan memungkinkan untuk mengevaluasi kinerja sistem yang tinggi atau fungsionalitas yang luas. Secara teknis, sistem "cantik" harus dibungkus dengan cangkang kerja yang menarik dan stabil. Oleh karena itu, pada awal pengembangan sistem VKS domestik, momen ini segera diperhitungkan.

gambar

Siapa yang akan menjadi pengguna sistem konferensi video Rusia?


Sejak musim semi tahun 2020, jawaban atas pertanyaan tentang kelayakan pengembangan sistem VKS penuh menjadi jelas. Pejabat, perusahaan komersial, rumah sakit dan sekolah membutuhkan sarana komunikasi modern dengan tingkat produktivitas dan keamanan tertentu. Anda dapat berbicara dalam Zoom, tetapi apakah itu layak untuk digunakan untuk negosiasi komersial yang serius atau rapat manajer operasional?

Untuk berbagai tugas perusahaan Rusia, menjadi perlu untuk membuat sistem VKS domestik. Selain itu, suatu sistem tidak hanya terdiri dari komponen perangkat lunak, tetapi juga perangkat keras lengkap. Di antara vendor terkenal di dunia, setidaknya 5 perusahaan menawarkan sistem konferensi video multifungsi. Namun di Rusia, konsep substitusi impor secara bertahap mulai bekerja. Plus, masalah keamanan bagi banyak orang telah menjadi lebih penting daripada negara asal produk, dan harga dengan nilai tukar saat ini tidak di tempat terakhir. Dan "keindahan" antarmuka ternyata cukup realistis untuk dikembangkan dari awal.

GUI saat memulai


Persyaratan utama untuk antarmuka modern adalah kecepatan implementasi, penampilan terkini dan kegunaan penuh. Dengan demikian, tugas pertama pengembang antarmuka pengguna grafis (GUI) adalah definisi yang jelas tentang fungsi perangkat lunak untuk konferensi video.

Dari sudut pandang GUI, persyaratan berikut dirumuskan:

  • Melakukan panggilan video / audio keluar;
  • Terima / tolak panggilan masuk;
  • Jawab otomatis panggilan masuk pada interval waktu khusus;
  • Beralih di antara dua perangkat audio (headset / speakerphone) selama dan di luar panggilan;
  • Hidupkan / matikan mikrofon dan kamera selama dan di luar panggilan;
  • Panggilan DTMF saat panggilan berlangsung;
  • Pertemuan konferensi di terminal;
  • Manajemen kamera PTZ, menyimpan preset PTZ dan aplikasinya;
  • Kemampuan untuk menghasilkan video ke beberapa jendela yang berbeda;
  • Kontrol mouse, keyboard, remote control;
  • Kemampuan untuk mengontrol terminal dari jarak jauh dari antarmuka Web.

Daftar fungsi ini memungkinkan Anda untuk memecahkan masalah pengembangan antarmuka dengan berbagai cara. Selain itu, pilihan jenis implementasi tertentu dipengaruhi oleh keterbatasan jenis bahasa pemrograman (misalnya, Java secara kategoris tidak cocok untuk alasan sertifikasi, CSS / HTML - sesuai dengan fungsinya), spesialisasi pengembang, dan pemilihan waktu. Secara kolektif, pilihan dibuat untuk C ++ dan penggunaan kerangka Qt5, karena, misalnya, teknologi QML yang lebih modern tidak memungkinkan rendering video menggunakan konteks OpenGL yang sewenang-wenang, dan ini diperlukan menurut ToR untuk terminal VKS.

gambar

Dengan cepat dan efisien


Prototipe GUI pertama dibuat untuk softphone Qt dan menggunakan banyak pustaka sumber terbuka. Misalnya, untuk protokol SIP, perpustakaan eXosip / oSIP digunakan, untuk meng-encode / mendekodekan video dan audio - ffmpeg, untuk bekerja dengan perangkat audio - PortAudio. Softphone ini bekerja di Linux, Windows, MacOS dan merupakan demonstrator teknologi, dan bukan perangkat nyata.

Kemudian, softphone abstrak diubah menjadi proyek videophone nyata, dan versi pertama dari perangkat lunak itu seharusnya dibuat 2 bulan setelah dimulainya. Untuk mengatasi masalah ini dalam waktu yang singkat, perangkat lunak telepon dibagi menjadi beberapa modul dan didistribusikan di antara beberapa kelompok pengembang sesuai dengan kompetensi. Organisasi proses semacam itu membantu mengembangkan proyek videophone dengan cepat dan efisien.

Inti dan depan


Untuk penyatuan dan kemungkinan menggunakan pengembangan GUI yang ada di perangkat lain dari proyek yang ada, basis kode umum adalah dalam modul terpisah - backend GUI, atau modul inti GUI. Dan representasi langsung, yang berbeda untuk perangkat yang berbeda, menerapkan dalam modul depan GUI terpisah.

Arsitektur dari modul-GUI ini ternyata menguntungkan dan menghasilkan hasil yang diinginkan: pengembangan antarmuka untuk komponen-komponen baru dari sistem VKS itu sendiri telah menjadi relatif cepat dan berkualitas tinggi. Lagi pula, sekarang antarmuka untuk terminal VKS tidak perlu ditulis ulang dari awal.

Siksaan dan Kemenangan


Dalam perjalanan membuat perangkat lunak apa pun, tentu saja, ada kesulitan dan masalah. Membuat GUI untuk konferensi video tidak terkecuali. Terlepas dari tujuan spesifik sistem, mereka dapat diulang dalam perintah apa pun. Kesulitan dan kemenangan di jalur pengembangan menarik bagi kolega, dan mungkin mereka akan memberikan solusi yang efektif tanpa "menyapu" kita.

Konsistensi selamanya


Secara historis, masalah menarik pertama yang muncul selama pengembangan GUI untuk berbagai jenis terminal VKS adalah masalah konsistensi, yaitu, keadaan terkoordinasi dari semua modul. Selama operasi, GUI berinteraksi dengan beberapa modul lain: modul untuk berinteraksi dengan perangkat keras, subsistem manajemen panggilan, modul pemrosesan media (MCU), dan subsistem interaksi pengguna.

gambar

Pada awalnya, GUI bekerja dengan semua modul ini sebagai independen, yaitu, ia dapat mengirim permintaan ke 2 modul yang berbeda secara bersamaan. Ini ternyata salah dan kadang-kadang menyebabkan masalah, karena modul-modul ini sendiri tidak independen dan saling berinteraksi secara aktif. Solusi untuk masalah ini adalah pembuatan skema kerja khusus, yang memastikan eksekusi permintaan secara sekuensial dalam semua modul.

Ada 2 kesulitan yang ditambahkan: pertama, beberapa (tetapi tidak semua) permintaan memerlukan respons, untuk mengantisipasi terminal, pada kenyataannya, dalam keadaan tidak konsisten, sehingga permintaan lainnya tidak dapat dilakukan. Namun, memblokir antarmuka pengguna sambil menunggu tanggapan juga tidak diinginkan. Kedua, respons terhadap permintaan GUI dari modul, serta permintaan dari modul ke GUI, datang di utasnya sendiri, berbeda dari GUI, tetapi GUI harus menerapkan semua perubahan status di utasnya (untuk beberapa tindakan Qt memerlukan ini, tetapi dalam dalam beberapa kasus, ini menghindari kesulitan yang tidak perlu dalam memastikan sinkronisasi utas).

Solusinya ditemukan dan terdiri dari dua bagian. Pertama, semua permintaan / tanggapan dari modul lain dialihkan ke aliran GUI menggunakan mekanisme slot sinyal Qt bersama dengan QueuedConnection, yaitu, menggunakan loop acara global QApplication. Kemudian, untuk memastikan pemrosesan yang konsisten dari semua permintaan, sistem Transisi dikembangkan dengan siklus antrian dan pemrosesan sendiri (TransitionLoop).

Jadi, ketika pengguna menekan beberapa tombol aksi dalam GUI (misalnya, tombol panggil), Transisi yang sesuai dibuat, yang ditempatkan di antrian transisi. Setelah itu, sinyal dihasilkan untuk siklus pemrosesan transisi. TransitionLoop, setelah menerima sinyal, melihat apakah ada transisi yang sedang berlangsung sekarang. Jika ada, maka menunggu penyelesaian transisi saat ini berlanjut; jika tidak, Transisi berikutnya diambil dari antrian transisi dan diluncurkan. Ketika respons diterima dari modul TransitionLoop lain menggunakan sinyal yang sama, penyelesaian transisi saat ini diberitahukan dan TransitionLoop dapat memulai transisi berikutnya dari antrian.

Yang penting di sini adalah bahwa semua pemrosesan transisi dilakukan dalam utas GUI. Ini dipastikan dengan menggunakan mekanisme slot sinyal Qt dalam varian QueuedConnection, di mana suatu peristiwa dihasilkan untuk setiap sinyal dan ditempatkan di EventLoop utama aplikasi.

Render OpenGL pada perangkat keras berdaya rendah


Kesulitan lain yang harus kami hadapi adalah masalah rendering video. Qt menyediakan untuk rendering OpenGL kelas QOpenGLWidget khusus dan kelas pembantu terkait, yang awalnya digunakan untuk rendering video. Data untuk rendering (frame video yang didekodekan) sendiri disediakan oleh modul pemrosesan media (MCU), yang, antara lain, mengimplementasikan decoding perangkat keras dari aliran video (pada GPU). Pada prosesor berdaya rendah, "memperlambat" rendering video FullHD ditemukan. Solusi langsung adalah mengganti prosesor, tetapi ini akan membutuhkan pemrosesan serius dari komponen yang sudah jadi dari sistem konferensi video dan akan meningkatkan biaya perangkat itu sendiri. Oleh karena itu, seluruh proses rendering dianalisis dengan cermat untuk menemukan cara yang lebih indah untuk menyelesaikan masalah.

Dengan render OpenGL standar dan penguraian perangkat keras, terjadi hal berikut: data dengan video yang disandikan berasal dari jaringan, data itu disimpan dalam RAM, kemudian data dari RAM ini ditransfer ke memori video pada GPU, di mana itu diterjemahkan. Kemudian, data yang didekodekan memiliki volume yang jauh lebih besar daripada data yang disandikan ditransfer lagi ke RAM. Selanjutnya, kode rendering ikut berperan, yang mentransfer data ini dari RAM kembali ke GPU secara langsung untuk rendering. Dengan demikian, sejumlah besar data dipompa bolak-balik melalui bus memori, dan bus tidak bisa melakukan ini.

Dalam OpenGL versi modern, ada ekstensi khusus yang memungkinkan Anda menentukan untuk merender data yang sudah ada dalam memori GPU, dan bukan data dalam RAM utama, seperti biasa. Mekanisme ini mengecualikan pergerakan data frame yang didekodekan perangkat keras dari GPU ke RAM, dan kemudian kembali. Dengan demikian, masalah rendering pada prosesor daya rendah hampir diselesaikan.

gambar

Masalah besar lainnya adalah konteks OpenGL yang didukung di Qt. Mereka tidak memungkinkan Anda untuk menggunakan ekstensi OpenGL yang diperlukan, yaitu, Anda tidak dapat menggunakan QOpenGLWidget dengan opsi ini. Solusinya adalah dengan menggunakan QWidget biasa, tetapi mematikan pipa rendering Qt. Peluang seperti itu ada di Qt. Namun, muncul pertanyaan di sini, karena dalam opsi ini GUI bertanggung jawab penuh atas semua perenderan di area widget ini, Qt tidak membantu kami. Ini normal untuk menampilkan video, tetapi untuk menggunakan widget di atas video, alat Qt biasa tidak dapat digunakan, karena, misalnya, menu pop-up tambahan harus ditampilkan di atas video.

Masalah ini diselesaikan sebagai berikut: dari widget yang ada, gambarnya diperoleh (QWidget memiliki metode grab () untuk ini), gambar yang dihasilkan dikonversi ke tekstur OpenGL dan yang terakhir ditampilkan di atas video menggunakan alat OpenGL. Dengan menambahkan lingkungan yang sesuai, mekanisme universal diimplementasikan yang dapat digunakan untuk menampilkan widget standar di atas video dengan cara yang tidak standar.

Kios dan widget


Tugas mengelola tampilan dan mendistribusikan fragmen antarmuka pengguna dalam mode "kios" tidak mudah. Terminal VKS dapat beroperasi dalam 2 mode - mode jendela, yaitu, seperti aplikasi jendela lainnya di lingkungan desktop sistem operasi, dan "mode kios" (yaitu, sistem operasi hanya menjalankan satu aplikasi dengan antarmuka grafis - VKST - dan tidak ada lingkungan Desktop).

Dalam mode berjendela, semuanya relatif sederhana: jendela dikendalikan oleh pengelola jendela lingkungan desktop, aplikasi membuat jendela kedua jika perlu, dan pengguna mendistribusikan jendela pada layar sesuai kebutuhan. Tetapi dalam mode "kios", semuanya jauh lebih rumit, karena sistem tidak memiliki manajer jendela dan hanya ada satu jendela, dan pengguna tidak memiliki kemampuan untuk memindahkannya. Oleh karena itu, tugas untuk mendeteksi suatu peristiwa secara otomatis, misalnya, menghubungkan / memutuskan suatu tampilan, muncul. Ketika peristiwa ini terjadi, perlu untuk mengkonfigurasi tampilan secara otomatis dan menempatkan fragmen antarmuka pengguna dengan benar.

gambar

Jawabannya datang dari pustaka sistem LINUX Xrandr OS, yang bertanggung jawab untuk bekerja dengan display. Ada sangat sedikit dokumentasi di internet, jadi implementasinya dilakukan dengan menggunakan contoh-contoh dari Internet, termasuk dari Habr. Selain itu, perlu untuk membuat algoritma untuk mendistribusikan fragmen antarmuka di antara layar, serta mengintegrasikan dua jendela yang berbeda menjadi satu. Yang terakhir diimplementasikan sebagai berikut: apa yang windows dalam mode windowed, dalam mode "kios" adalah widget di dalam satu jendela besar, yang membentang lebih dari 2 layar (jika ada 2 dari mereka). Dalam hal ini, perlu untuk mengonfigurasi posisi display agar ruang virtual kontinu dibuat (ini dilakukan menggunakan perpustakaan XRandr), dan kemudian mengatur geometri widget internal di dalam satu jendela global sehinggasehingga semua orang tampil di layar mereka.

Kami menciptakan bahasa Rusia


Seluruh cara menciptakan sistem konferensi video Rusia terdiri dan terdiri dari banyak tahapan, dan GUI hanyalah puncak gunung es. Yang paling nyata dan bukan yang paling sulit. Namun, kerumitan solusi, kombinasi perangkat lunak dan perangkat keras dan komponen perangkat lunak, dan keinginan untuk membuat sistem yang "indah" secara teknis dan estetis menciptakan banyak kesulitan di sepanjang jalan. Tugas baru memunculkan solusi non-standar dan membantu menciptakan produk yang tidak malu untuk menunjukkan tidak hanya di Rusia tetapi juga di luar negeri.

Perkembangan Rusia telah lama membuktikan kinerja mereka, dan dalam cangkang yang indah dan daya saing. Peretasan hidup kami akan bermanfaat bagi semua orang yang terlibat serius dalam pengembangan GUI, dan kami berharap mereka akan membantu pengembang lain mempercepat dan menyederhanakan proses pembuatan shell modern untuk produk perangkat lunak Rusia yang baru. Kami percaya bahwa keputusan Rusia akan dihargai di dunia tidak kurang dari balet Rusia atau kaviar hitam.

All Articles