🙋🏼 🚢 🔐 रूसी में जीयूआई, या वीकेएस टर्मिनल खुद करते हैं 🤰🏾 👊🏻 💃

रूसी वीडियोकांफ्रेंसिंग सिस्टम (VKS) के लिए C ++ GUI विकसित करने का अनुभव। आधुनिक प्रौद्योगिकी और प्रमाणन आवश्यकताओं का संश्लेषण। विकास का मुख्य "रेक" और उनके चारों ओर पाने के तरीके। जीयूआई और रूसी बैले क्या आम है।

वीडियोकॉनफ्रेंसिंग सिस्टम का उपयोगकर्ता जो पहली चीज देखता है, वह इंटरफ़ेस है। और ज्यादातर मामलों में, यह अपनी उपस्थिति और कार्यक्षमता से है कि वे सिस्टम का न्याय करते हैं। एक असुविधाजनक या फैलाव वाला इंटरफ़ेस उच्च सिस्टम प्रदर्शन या विस्तृत कार्यक्षमता या तो मूल्यांकन करने की अनुमति नहीं देगा। तकनीकी रूप से, एक "सुंदर" प्रणाली को एक आकर्षक और स्थिर कामकाजी खोल में लपेटा जाना चाहिए। इसलिए, घरेलू वीकेएस प्रणाली के विकास की शुरुआत में, इस क्षण को तुरंत ध्यान में रखा गया।

रूसी वीडियोकांफ्रेंसिंग प्रणाली का उपयोगकर्ता कौन होगा?

2020 के वसंत के बाद से, एक पूर्ण विकसित वीकेएस-प्रणाली को विकसित करने की सलाह के सवाल का जवाब स्पष्ट हो गया है। अधिकारियों, वाणिज्यिक कंपनियों, अस्पतालों और स्कूलों को एक निश्चित स्तर की उत्पादकता और सुरक्षा के साथ संचार के आधुनिक साधनों की आवश्यकता होती है। आप ज़ूम में बात कर सकते हैं, लेकिन क्या यह गंभीर वाणिज्यिक वार्ता या प्रबंधकों की एक परिचालन बैठक के लिए उपयोग करने के लिए लायक है?

रूसी कंपनियों के विभिन्न कार्यों के लिए, घरेलू वीडियोकांफ्रेंसिंग प्रणाली बनाना आवश्यक हो गया। इसके अलावा, एक प्रणाली जिसमें न केवल एक सॉफ्टवेयर घटक शामिल है, बल्कि एक पूर्ण हार्डवेयर भी है। विश्व प्रसिद्ध विक्रेताओं के बीच, कम से कम 5 कंपनियां बहुक्रियाशील वीडियोकांफ्रेंसिंग सिस्टम प्रदान करती हैं। लेकिन रूस में, आयात प्रतिस्थापन की अवधारणा धीरे-धीरे काम करना शुरू कर रही है। साथ ही, उत्पाद की उत्पत्ति के देश की तुलना में कई के लिए सुरक्षा मुद्दे अधिक महत्वपूर्ण हो गए हैं, और वर्तमान विनिमय दरों पर कीमत अंतिम स्थान पर नहीं है। और इंटरफ़ेस का "सौंदर्य" खरोंच से विकसित करने के लिए काफी यथार्थवादी निकला।

शुरू पर जीयूआई

आधुनिक इंटरफेस के लिए मुख्य आवश्यकताएं कार्यान्वयन की गति, अप-टू-डेट उपस्थिति और पूर्ण प्रयोज्य हैं। इस प्रकार, ग्राफिकल यूजर इंटरफेस (जीयूआई) के डेवलपर्स का पहला कार्य वीडियोकांफ्रेंसिंग के लिए सॉफ्टवेयर कार्यक्षमता की स्पष्ट परिभाषा था।

जीयूआई के दृष्टिकोण से, निम्नलिखित आवश्यकताओं को तैयार किया गया था:

आउटगोइंग वीडियो / ऑडियो कॉल करना;
इनकमिंग कॉल स्वीकार / अस्वीकार;
ऑटो एक कस्टम समय अंतराल पर एक इनकमिंग कॉल का जवाब देता है;
कॉल के दौरान और बाहर दोनों ऑडियो उपकरणों (हेडसेट / स्पीकरफोन) के बीच स्विच करें;
कॉल के दौरान और उसके बाहर माइक्रोफ़ोन और कैमरा चालू / बंद करना;
कॉल के दौरान डीटीएमएफ डायल करना;
टर्मिनल पर सम्मेलन का आयोजन;
पीटीजेड कैमरों का प्रबंधन, पीटीजेड प्रीसेट और उनके आवेदन को सहेजना;
कई अलग-अलग खिड़कियों में वीडियो आउटपुट करने की क्षमता;
नियंत्रण माउस, कीबोर्ड, रिमोट कंट्रोल;
वेब इंटरफ़ेस से टर्मिनल को दूरस्थ रूप से नियंत्रित करने की क्षमता।

कार्यों की यह सूची आपको विभिन्न तरीकों से एक इंटरफ़ेस विकसित करने की समस्या को हल करने की अनुमति देती है। इसके अलावा, एक विशिष्ट प्रकार के कार्यान्वयन का विकल्प प्रोग्रामिंग भाषाओं के प्रकार की सीमाओं से प्रभावित था (उदाहरण के लिए, जावा स्पष्ट रूप से प्रमाणन कारणों, सीएसएस / एचटीएमएल के लिए उपयुक्त नहीं था - कार्यक्षमता के अनुसार), डेवलपर्स की विशेषज्ञता और समय। सामूहिक रूप से, चुनाव C ++ के पक्ष में किया गया था और Qt5 ढांचे के उपयोग के बाद से, उदाहरण के लिए, अधिक आधुनिक QML तकनीक एक मनमाने ढंग से OpenGL संदर्भ का उपयोग करके वीडियो प्रदान करने की अनुमति नहीं देती है, और वीकेएस टर्मिनलों के लिए TOR के अनुसार यह आवश्यक था।

जल्दी और कुशलता से

पहले GUI प्रोटोटाइप Qt के सॉफ्टफ़ोन के लिए बनाया गया था और कई ओपन सोर्स लाइब्रेरीज़ का इस्तेमाल किया। उदाहरण के लिए, SIP प्रोटोकॉल के लिए, eXosip / oSIP लाइब्रेरी का उपयोग किया गया था, जो ऑडियो डिवाइसेस - पोर्टऑडियो के साथ काम करने के लिए वीडियो और ऑडियो - ffmpeg को एन्कोडिंग / डिकोड करने के लिए उपयोग किया गया था। यह सॉफ्टफोन लिनक्स, विंडोज, मैकओएस के तहत काम करता था और यह एक प्रौद्योगिकी प्रदर्शक था, न कि वास्तविक डिवाइस।

बाद में, एक अमूर्त सॉफ्टफ़ोन को एक वास्तविक वीडियोफ़ोन परियोजना में बदल दिया गया था, और इसके लिए सॉफ्टवेयर का पहला संस्करण शुरू होने के 2 महीने बाद बनाया जाना चाहिए था। इतने कम समय में इस समस्या को हल करने के लिए, फोन सॉफ्टवेयर को मॉड्यूल में विभाजित किया गया और दक्षताओं के अनुसार डेवलपर्स के कई समूहों में वितरित किया गया। प्रक्रिया के इस तरह के एक संगठन ने वीडियोफ़ोन प्रोजेक्ट को जल्दी और कुशलतापूर्वक विकसित करने में मदद की।

कोर और सामने

एकीकरण और वर्तमान परियोजना से अन्य उपकरणों में मौजूदा जीयूआई-विकास का उपयोग करने की संभावना के लिए, सामान्य कोड आधार एक अलग मॉड्यूल में है - जीयूआई बैकएंड या जीयूआई कोर मॉड्यूल। और सीधे अभ्यावेदन, जो अलग-अलग उपकरणों के लिए अलग-अलग हैं, अलग-अलग GUI फ्रंट मॉड्यूल में लागू होते हैं।

जीयूआई-मॉड्यूल की यह वास्तुकला लाभप्रद रूप से बदल गई और वांछित परिणाम के लिए प्रेरित हुई: वीकेएस सिस्टम के नए घटकों के लिए इंटरफेस का विकास स्वयं अपेक्षाकृत तेज और उच्च गुणवत्ता वाला हो गया है। आखिरकार, अब वीकेएस टर्मिनलों के लिए इंटरफेस को स्क्रैच से दोबारा लिखने की आवश्यकता नहीं थी।

पीड़ा और विजय

किसी भी सॉफ्टवेयर को बनाने के तरीके पर, स्वाभाविक रूप से, कठिनाइयों और समस्याएं हैं। वीडियोकांफ्रेंसिंग के लिए एक जीयूआई बनाना कोई अपवाद नहीं था। सिस्टम के विशिष्ट उद्देश्य के बावजूद, उन्हें किसी भी कमांड में दोहराया जा सकता है। विकास पथ पर कठिनाइयाँ और जीतें सहकर्मियों के लिए दिलचस्प हैं, और शायद वे हमारे "रेक" के बिना प्रभावी समाधानों का संकेत देंगे।

हमेशा के लिए स्थिरता

ऐतिहासिक रूप से, विभिन्न प्रकार के वीकेएस टर्मिनलों के लिए जीयूआई के विकास के दौरान उत्पन्न हुई पहली पहली दिलचस्प समस्या थी स्थिरता, यानी सभी मॉड्यूल की समन्वित स्थिति। ऑपरेशन के दौरान, जीयूआई कई अन्य मॉड्यूल के साथ बातचीत करता है: हार्डवेयर के साथ बातचीत करने के लिए एक मॉड्यूल, एक कॉल प्रबंधन सबसिस्टम, एक मीडिया प्रोसेसिंग मॉड्यूल (एमसीयू), और एक उपयोगकर्ता इंटरैक्शन सबसिस्टम।

प्रारंभ में, जीयूआई ने इन सभी मॉड्यूल के साथ स्वतंत्र रूप से काम किया, अर्थात, यह एक ही समय में 2 अलग-अलग मॉड्यूल के लिए अनुरोध भेज सकता है। यह गलत निकला और कभी-कभी समस्याएं पैदा हुईं, क्योंकि ये मॉड्यूल खुद स्वतंत्र नहीं थे और एक-दूसरे के साथ सक्रिय रूप से बातचीत करते थे। समस्या का समाधान एक विशेष कार्य योजना का निर्माण था, जिसने सभी मॉड्यूल के भीतर अनुरोधों का सख्ती से अनुक्रमिक निष्पादन सुनिश्चित किया।

जोड़ने में 2 कठिनाइयां थीं: सबसे पहले, कुछ (लेकिन सभी नहीं) अनुरोधों को एक प्रतिक्रिया की आवश्यकता होती है, जिसकी प्रत्याशा में टर्मिनल वास्तव में एक असंगत स्थिति में है, इसलिए अन्य अनुरोधों को निष्पादित नहीं किया जा सकता है। हालांकि, प्रतिक्रियाओं के लिए प्रतीक्षा करते समय उपयोगकर्ता इंटरफ़ेस को अवरुद्ध करना भी अवांछनीय है। दूसरी बात, जीयूआई मॉड्यूल से अनुरोधों के साथ-साथ जीयूआई के लिए मॉड्यूल से अनुरोध, अपने स्वयं के थ्रेड्स में आते हैं, जीयूआई से अलग, लेकिन जीयूआई को अपने धागे में सभी राज्य परिवर्तनों को लागू करना चाहिए (कुछ कार्यों के लिए क्यूटी को इसकी आवश्यकता है, लेकिन कुछ मामलों में, यह थ्रेड सिंक्रोनाइज़ेशन सुनिश्चित करने में अनावश्यक कठिनाइयों से बचा जाता है)।

समाधान पाया गया था और दो भागों से मिलकर बना था। सबसे पहले, अन्य मॉड्यूल से सभी अनुरोधों / प्रतिक्रियाओं को क्यूई सिग्नल-स्लॉट तंत्र का उपयोग करके क्यूआरआईडॉटेक्शन के साथ संयोजन के रूप में जीयूआई स्ट्रीम पर पुनर्निर्देशित किया गया था, अर्थात, वैश्विक क्यूएप्लिकेशन इवेंट लूप का उपयोग करके। फिर, सभी अनुरोधों के निरंतर प्रसंस्करण को सुनिश्चित करने के लिए, एक संक्रमण प्रणाली को अपनी कतार और प्रसंस्करण चक्र (ट्रांज़िशनलूप) के साथ विकसित किया गया था।

इस प्रकार, जब उपयोगकर्ता GUI में कुछ कार्रवाई बटन दबाता है (उदाहरण के लिए, कॉल बटन), तो एक संबंधित संक्रमण बनाया जाता है, जिसे संक्रमण कतार में रखा जाता है। उसके बाद, संक्रमण प्रसंस्करण चक्र के लिए एक संकेत उत्पन्न होता है। ट्रांज़िशनलूप, एक संकेत प्राप्त करने पर, यह देखने के लिए देखता है कि क्या अब कोई प्रगति है। यदि है, तो वर्तमान संक्रमण के पूरा होने की प्रतीक्षा जारी है; यदि नहीं, तो अगला संक्रमण संक्रमण कतार से पुनर्प्राप्त किया जाता है और लॉन्च किया जाता है। जब एक ही सिग्नल का उपयोग करके दूसरे ट्रांज़िशनलूप मॉड्यूल से प्रतिक्रिया प्राप्त की जाती है, तो वर्तमान संक्रमण के पूरा होने की सूचना दी जाती है और ट्रांज़िशनलूप कतार से अगला संक्रमण शुरू कर सकता है।

यहां महत्वपूर्ण बात यह है कि सभी संक्रमण प्रसंस्करण एक जीयूआई धागे में किया जाता है। यह क्यूइटेडकोनेक्शन वेरिएंट में क्यूटी सिग्नल-स्लॉट तंत्र के उपयोग से सुनिश्चित किया जाता है, जिसमें प्रत्येक सिग्नल के लिए एक घटना उत्पन्न होती है और एप्लिकेशन के मुख्य ईवेंटलूप में रखी जाती है।

ओपन-पॉवर कम-पावर हार्डवेयर पर प्रदान करता है

एक और कठिनाई जो हमें निपटनी थी वह थी वीडियो रेंडर करने की समस्या। Qt OpenGL को एक विशेष QOpenGLWidget वर्ग और संबंधित सहायक वर्गों के लिए प्रदान करता है, जो मूल रूप से वीडियो प्रदान करने के लिए उपयोग किया जाता था। रेंडरिंग (डीकोड किए गए वीडियो फ्रेम) का डेटा मीडिया प्रोसेसिंग मॉड्यूल (MCU) द्वारा प्रदान किया जाता है, जो अन्य बातों के अलावा, वीडियो स्ट्रीम (GPU पर) के हार्डवेयर डिकोडिंग को लागू करता है। कम-शक्ति वाले प्रोसेसर पर, FullHD वीडियो का प्रतिपादन "धीमा" हो रहा था। प्रत्यक्ष समाधान प्रोसेसर को बदलने के लिए था, लेकिन इसके लिए वीडियोकॉनफ्रेंसिंग प्रणाली के पहले से ही तैयार घटकों के गंभीर प्रसंस्करण की आवश्यकता होगी और उपकरणों की लागत में वृद्धि होगी। इसलिए, समस्या को हल करने के लिए और अधिक सुंदर तरीके खोजने के लिए पूरी प्रतिपादन प्रक्रिया का सावधानीपूर्वक विश्लेषण किया गया।

मानक ओपनजीएल रेंडरिंग और हार्डवेयर डिकोडिंग के साथ, निम्न होता है: एन्कोडेड वीडियो वाला डेटा नेटवर्क से आता है, यह रैम में संग्रहीत होता है, फिर रैम से यह डेटा GPU पर वीडियो मेमोरी में स्थानांतरित किया जाता है, जहां यह डिकोड किया जाता है। फिर, एन्कोडेड डेटा की तुलना में काफी बड़ी मात्रा में डिकोड किए गए डेटा को फिर से रैम में स्थानांतरित किया जाता है। इसके बाद, एक रेंडरिंग कोड प्ले में आता है, जो इस डेटा को रैम से वापस GPU पर सीधे रेंडर करने के लिए ट्रांसफर करता है। इस प्रकार, बल्कि बड़ी मात्रा में डेटा को मेमोरी बस के माध्यम से आगे और पीछे पंप किया जाता है, और बस ऐसा नहीं कर सकता है।

ओपनजीएल के आधुनिक संस्करणों में, विशेष एक्सटेंशन हैं जो आपको उन डेटा को निर्दिष्ट करने की अनुमति देते हैं जो पहले से ही GPU मेमोरी में हैं, और मुख्य रैम में डेटा नहीं, हमेशा की तरह। इस तंत्र ने GPU से RAM तक हार्डवेयर डिकोड्ड फ्रेम के डेटा की गति को छोड़ दिया, और फिर वापस। इस प्रकार, कम-शक्ति वाले प्रोसेसर पर प्रतिपादन की समस्या लगभग हल हो गई थी।

एक अन्य प्रमुख समस्या Qt में समर्थित OpenGL संदर्भों की थी। वे आपको आवश्यक OpenGL एक्सटेंशन का उपयोग करने की अनुमति नहीं देते हैं, अर्थात, आप इस विकल्प के साथ QOpenGLWidget का उपयोग नहीं कर सकते। समाधान एक नियमित QWidget का उपयोग करना था, लेकिन Qt रेंडरिंग पाइपलाइन को बंद कर दिया। ऐसा अवसर Qt में मौजूद है। हालांकि, यहां एक सवाल उठता है, क्योंकि इस विकल्प में जीयूआई इस विजेट के क्षेत्र में सभी प्रतिपादन के लिए पूरी तरह से जिम्मेदार है, क्यूटी हमारी मदद नहीं करता है। यह वीडियो प्रदर्शित करने के लिए सामान्य है, लेकिन वीडियो के शीर्ष पर विजेट का उपयोग करने के लिए, नियमित क्यूटी टूल का उपयोग नहीं किया जा सकता है, उदाहरण के लिए, वीडियो के शीर्ष पर एक अतिरिक्त पॉप-अप मेनू प्रदर्शित किया जाना चाहिए।

इस समस्या को निम्नानुसार हल किया गया था: मौजूदा विजेट से, इसकी छवि प्राप्त की जाती है (QWidget के पास इसके लिए एक हड़पने की विधि) है, जिसके परिणामस्वरूप छवि को OpenGL बनावट में बदल दिया जाता है और बाद में OpenGL उपकरण का उपयोग करके वीडियो के शीर्ष पर प्रदान किया जाता है। उपयुक्त वातावरण को जोड़कर, एक सार्वभौमिक तंत्र लागू किया गया जिसका उपयोग किसी भी मानक विजेट को इस तरह के गैर-मानक तरीके से वीडियो के शीर्ष पर प्रदर्शित करने के लिए किया जा सकता है।

कियोस्क और विगेट्स

"कियोस्क" मोड में यूजर इंटरफेस के टुकड़े को प्रदर्शित करने और वितरित करने का कार्य एक आसान नहीं था। वीकेएस टर्मिनल 2 मोड में काम कर सकता है - विंडो मोड, यानी ऑपरेटिंग सिस्टम के डेस्कटॉप वातावरण में किसी भी अन्य विंडो एप्लिकेशन की तरह, और "कियोस्क मोड" (यानी, ऑपरेटिंग सिस्टम केवल एक एप्लीकेशन को ग्राफिकल इंटरफेस के साथ चलाता है - VKST - और कोई वातावरण नहीं है डेस्कटॉप)।

विंडो मोड में, सब कुछ अपेक्षाकृत सरल है: विंडो को डेस्कटॉप वातावरण के विंडो मैनेजर द्वारा नियंत्रित किया जाता है, यदि आवश्यक हो, तो एप्लिकेशन एक दूसरी विंडो बनाता है, और उपयोगकर्ता डिस्प्ले पर खिड़कियों को आवश्यकतानुसार वितरित करता है। लेकिन "कियोस्क" मोड में, सब कुछ बहुत अधिक जटिल है, क्योंकि सिस्टम में एक विंडो प्रबंधक नहीं है और केवल एक विंडो हो सकती है, और उपयोगकर्ता के पास इसे स्थानांतरित करने की क्षमता नहीं है। इसलिए, स्वचालित रूप से किसी घटना का पता लगाने का कार्य, उदाहरण के लिए, किसी डिस्प्ले को कनेक्ट / डिस्कनेक्ट करना, दिखाई दिया। जब यह ईवेंट हुआ, तो डिस्प्ले को स्वचालित रूप से कॉन्फ़िगर करना और उन पर उपयोगकर्ता इंटरफ़ेस के टुकड़े को सही ढंग से रखना आवश्यक था।

उत्तर LINUX Xrandr OS सिस्टम लाइब्रेरी से आया है, जो डिस्प्ले के साथ काम करने के लिए जिम्मेदार है। इंटरनेट पर इस पर बहुत कम प्रलेखन है, इसलिए इंटरनेट से उदाहरणों का उपयोग करते हुए कार्यान्वयन किया गया था, जिसमें हबर भी शामिल है। इसके अलावा, डिस्प्ले के बीच इंटरफेस के टुकड़े को वितरित करने के लिए एक एल्गोरिथ्म के साथ आना आवश्यक था, साथ ही एक ही में दो अलग-अलग खिड़कियों को एकीकृत किया गया था। उत्तरार्द्ध निम्नानुसार लागू किया गया था: विंडो क्या हैं विंडो मोड में, "कियोस्क" मोड में एक बड़ी विंडो के अंदर विगेट्स हैं, जो 2 डिस्प्ले (यदि उनमें से 2 हैं) पर फैला है। इस मामले में, डिस्प्ले की स्थिति को कॉन्फ़िगर करना आवश्यक है ताकि एक निरंतर वर्चुअल स्पेस बनाया जाए (यह एक्सरेन्डर लाइब्रेरी का उपयोग करके किया जाता है), और फिर एकल वैश्विक विंडो के अंदर आंतरिक विजेट की ज्यामिति सेट करें ताकिताकि हर कोई उनके प्रदर्शन पर पहुंच जाए।

हम रूसी पैदा करते हैं

रूसी वीडियोकांफ्रेंसिंग प्रणाली बनाने का पूरा तरीका शामिल है और इसमें कई चरण शामिल हैं, और जीयूआई केवल हिमशैल का टिप है। सबसे अधिक ध्यान देने योग्य और सबसे कठिन नहीं। हालांकि, समाधान की जटिलता, सॉफ्टवेयर और हार्डवेयर और सॉफ्टवेयर घटकों के संयोजन, और तकनीकी और सौंदर्यवादी रूप से "सुंदर" प्रणाली बनाने की इच्छा ने रास्ते में कई कठिनाइयों का निर्माण किया। नए कार्यों ने गैर-मानक समाधानों को जन्म दिया और एक ऐसा उत्पाद बनाने में मदद की जो न केवल रूस में बल्कि विदेशों में भी शर्मिंदा है।

रूसी विकास ने लंबे समय तक अपने प्रदर्शन को साबित किया है, और एक सुंदर खोल और प्रतिस्पर्धा में। हमारा जीवन हैक उन सभी के लिए उपयोगी होगा जो जीयूआई विकास में गंभीर रूप से शामिल हैं, और हम आशा करते हैं कि वे अन्य डेवलपर्स को नए रूसी सॉफ्टवेयर उत्पादों के लिए आधुनिक गोले बनाने की प्रक्रिया को गति देने और सरल बनाने में मदद करेंगे। हमारा मानना है कि दुनिया में रूसी फैसलों का महत्व रूसी बैले या काले कैवियार से कम नहीं होगा।

रूसी में जीयूआई, या वीकेएस टर्मिनल खुद करते हैं