ब्राउज़र आपके WebRTC एप्लिकेशन में ध्वनि को म्यूट करते हैं। बंद करो क्या?

WebRTC तकनीक (आवाज और वीडियो कॉल) अच्छा है क्योंकि यह सीधे वेब में बनाया गया है, जो निश्चित रूप से WebRTC के लिए एकदम सही है। हालाँकि, कभी-कभी वेब काफी परेशानी वाला होता है जब वेबआरटीसी को ब्राउज़र का उपयोग करने के लिए सामान्य आवश्यकताओं के लिए काउंटर चलाने की आवश्यकता होती है। अंतिम उदाहरण ऑडियो / वीडियो का ऑटो-प्ले (इसके बाद "ऑटोप्ले" के रूप में जाना जाता है), जब कई उपयोगकर्ता अचानक ध्वनि खो देते हैं। WebrtcHacks - Dag-Inge Aas के पूर्व लेखक ने व्यक्तिगत रूप से इस समस्या का सामना किया है। नीचे उनके विचार हैं: ऑटोप्ले के संदर्भ में ब्राउज़रों से क्या उम्मीद की जाए, क्रोम 66+ में नवीनतम परिवर्तन, साथ ही इन प्रतिबंधों के साथ रहने के तरीके के बारे में कुछ सुझाव दिए गए हैं।


ब्राउज़र्स ईविल को सुनना नहीं चाहते हैं, इसलिए किसी भी मीडिया में ऑटो-प्ले राजनेता ध्वनि बंद कर देते हैं। यह WebRTC अनुप्रयोगों के लिए एक समस्या हो सकती है।

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

फिलहाल, बग ने लगभग सभी लोकप्रिय वेबआरटीसी खिलाड़ियों को प्रभावित किया है। यह मज़ेदार है, लेकिन ऐसा लगता है कि मीटिंग के लिए Google और Chromebox से मिलना भी प्रभावित होता है।

सभी बुराइयों की जड़: ऑटोप्ले नीतियों में परिवर्तन। इस पोस्ट में मैं नवाचारों के बारे में बात करूँगा, कि वे कैसे वेबआरटीसी से संबंधित हैं और अपने अनुप्रयोगों में इससे कैसे निपटें।


वर्ष की त्रुटि: अनकवर्ड एरर: ऑडियो कॉन्टेक्स्ट को शुरू करने की अनुमति नहीं थी। पृष्ठ पर एक उपयोगकर्ता के इशारे के बाद इसे फिर से शुरू (या निर्मित) किया जाना चाहिए। https://goo.gl/7K7WLu

परिवर्तन

यह सब 2007 में शुरू हुआ, जब iPhone और iOS दिखाई दिए। यदि आपने पूर्व में iOS के लिए Safari के साथ काम किया है, तो आपने देखा होगा कि साउंड के साथ <ऑडियो> और <वीडियो> तत्वों को चलाने के लिए Safari को उपयोगकर्ता की भागीदारी की आवश्यकता है। बाद में जब आईओएस 10 ने वीडियो तत्वों को स्वचालित रूप से चलाने की अनुमति दी, लेकिन ध्वनि के बिना यह आवश्यकता थोड़ी कम हो गई। यह WebRTC के लिए एक समस्या बन गया है <video> तत्व को मीडिया स्ट्रीम "देखना" और "सुनना" चाहिए। WebRTC के संदर्भ में, ध्वनि के बिना वीडियो को स्वचालित रूप से शुरू करने की अनुमति देना बेकार है, क्योंकि वीडियो कॉल के दौरान आपको डिफ़ॉल्ट रूप से वार्ताकारों को सुनना होगा, और ऐसा करने के लिए "प्ले" दबाएं नहीं। जैसा कि यह हो सकता है, कुछ वेबआरटीसी डेवलपर्स आईओएस के लिए सफारी में शामिल थे, क्योंकि प्लेटफॉर्म ने हाल तक वेबआरटीसी का समर्थन नहीं किया था। IOS 11 से पहले।

आईओएस के लिए वीडियो कॉल के नवीनतम (उस समय) कार्यशील कार्यान्वयन का परीक्षण करने पर मुझे पहली बार बग का सामना करना पड़ा। मेरे आश्चर्य करने के लिए, इसने काम करना बंद कर दिया, जबकि मैं अकेला नहीं था। Github उपयोगकर्ता kylemcdonald ने iOS पर एक getUserMedia बग की सूचना दी । समाधान? वीडियो तत्व में एक नया playinline गुण जोड़ें, जो वीडियो को ध्वनि के साथ खेलने की अनुमति देता है। दुर्भाग्य से, डेवलपर्स ने सफारी में ऑटोप्ले को बदलने के बारे में मूल पोस्ट में WebRTC का उल्लेख नहीं किया है, लेकिन उन्होंने रिलीज से पहले भी वेबआरटीसी के बारे में अलग से लिखा था । लेख में मीडियास्ट्रीम और ऑडियो प्लेबैक के बारे में निम्नलिखित कहा गया है:

• मीडियास्ट्रीम का उपयोग करने वाला मीडिया स्वचालित रूप से खेलेगा यदि वेबपेज पहले से ही कैमरा / माइक्रोफोन का उपयोग करता है;
• MediaStream का उपयोग करने वाला मीडिया स्वचालित रूप से तब बजाएगा जब वेबपृष्ठ पहले से ही ध्वनि चला रहा हो। ध्वनि प्लेबैक शुरू करने के लिए, उपयोगकर्ता की भागीदारी अभी भी आवश्यक है।

इसलिए, इस दस्तावेज़ में playinline का उल्लेख नहीं है, लेकिन यदि आप दो घोषणाओं को जोड़ते हैं, तो आप समझ सकते हैं कि IOS पर सफारी में WebRTC एप्लिकेशन को कैसे काम किया जाए।

ऑटोप्ले आखिर क्यों सीमित है?

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

उसके बाद GIF आया। जीआईएफ <img> के अंदर सिर्फ एनिमेशन हैं, इसलिए उन्हें उपयोगकर्ता की "अनुमति" की आवश्यकता नहीं थी। हालांकि, वे मोबाइल इंटरनेट उपयोगकर्ताओं के लिए कठिन और इसलिए दर्दनाक हो सकते हैं। वीडियो ट्रैफ़िक को बढ़ाता है, लेकिन डाउनलोड करने के लिए सहमति की आवश्यकता होती है - इसलिए वेबपृष्ठ GIF का उपयोग करना जारी रखते हैं। IOS 10 में सब कुछ बदल गया जब सफारी ने ध्वनि को बंद करने के साथ ऑटोप्ले को सक्षम किया। तब से, लोड ऑप्टिमाइज़ेशन अनुमत वीडियो और गुमनामी में तीन मिनट के GIF के प्रस्थान का मामला है।

डेस्कटॉप ब्राउज़रों में ऑटोप्ले सीमा

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

हालाँकि, Chrome अचानक मूल मीडिया जुड़ाव सूचकांक (MEI) में बदल गया।

मीडिया एंगेजमेंट इंडेक्स (MEI)

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


क्रोम आंतरिक पृष्ठ से स्क्रीनशॉट: // मीडिया-सगाई / (स्रोत: Developers.google.com/web/updates/2017/09/autoplay-policy-changes )

न केवल <ऑडियो> और <वीडियो>

यह पता चला कि नई नीतियों ने न केवल <ऑडियो> और <वीडियो> टैग प्रभावित किए हैं। WebRTC के लिए एक लोकप्रिय UX पैटर्न उपयोगकर्ता को माइक्रोफ़ोन वॉल्यूम स्तर दिखाने के लिए है । ऐसा करने के लिए, ध्वनि का विश्लेषण ऑडियोकोटेक्स्ट के माध्यम से किया जाता है , जो मीडियास्ट्रीम लेता है और हिस्टोग्राम के रूप में इसके संकेत को आउटपुट करता है। इस मामले में, ध्वनि नहीं बजती है , लेकिन फिर भी ऑडियो विश्लेषण ऑडियोकॉन्टेक्ट के कारण अवरुद्ध हो जाता है, जो सिद्धांत रूप में, आपको ध्वनि को आउटपुट करने की अनुमति देता है।

माइक्रोफोन टेस्ट उदाहरण

इस समस्या की सूचना सबसे पहले दिसंबर में वेबकिट बग ट्रैकर में दी गई थी , और छह दिन बाद वेबकिट में एक सुधार आया । सुधार? यदि ऑडियो पहले से ही ऑडियो और वीडियो प्राप्त कर रहा है, तो AudioContext को ब्लॉक न करें।

तो आप अभी भी इस लेख को क्यों पढ़ रहे हैं? यह पता चला कि क्रोम ने सफारी जैसी ही गलती की थी । हालाँकि इसने कई WebRTC सेवाओं को प्रभावित किया है, Google इस बारे में चुप है। WebRTC पर ऑटोप्ले के प्रभाव के बारे में सार्वजनिक बयान देने के लिए उन्हें प्राप्त करने के कई प्रयास किए गए हैं, लेकिन अभी तक ऐसा नहीं हुआ है।

MEI मान परीक्षणों में हस्तक्षेप करते हैं

हम इस झंझट में कैसे पड़े? बेशक, हर उपयोगकर्ता को प्रभावित करने वाले Chrome 66 में परिवर्तन से पहले ही डेवलपर्स को AudioContext का परीक्षण करना था। और यहाँ MEI आता है; आप समझते हैं, पृष्ठ के साथ लगातार बातचीत आपको एक उच्च MEI देता है, क्रमशः, डेवलपर्स को बग से सामना करने की संभावना कम है, क्योंकि ऑडियो को लंबे समय तक खेलने और विश्लेषण करने की अनुमति दी गई है। और हां, गुप्त मोड मदद नहीं करता है, क्योंकि MEI को वहां गिना जाना जारी है। केवल Chrome को एक नए खाते के साथ लॉन्च करने से बग का पता चल जाएगा - एक ऐसा तथ्य जो अनुभवी Google QA इंजीनियर भी आसानी से भूल सकते हैं।

ब्राउज़र निर्माताओं को क्या करना चाहिए?

कोर कार्यक्षमता में परिवर्तन सही तरीके से लागू करना मुश्किल है। Chrome ने कई ऑटोप्ले नीति परिवर्तन जारी किए, लेकिन उनमें से कोई भी WebRTC या MediaStreams से संबंधित नहीं था। जाहिरा तौर पर, भूल गए अनुमतियां एपीआई अपडेट नहीं किए गए थे , इसलिए डेवलपर्स कस्टम क्रियाओं के अनुरोध का परीक्षण नहीं कर सकते हैं। वैकल्पिक रूप से, आप AudioContext को साउंड आउटपुट के लिए अनुमति दे सकते हैं यदि पेज पहले से ही कैमरा / माइक्रोफोन (सफारी के रूप में) के साथ काम करता है, लेकिन यह समाधान की तुलना में हैक की तरह दिखता है। और यह भी ध्वनि विश्लेषण के अन्य मामलों में मदद नहीं करेगा जब getUserMedia का उपयोग नहीं किया जाता है।

ब्राउज़र निर्माताओं के लिए एक प्रबलित ठोस समाधान MEI को प्रभावित करने के लिए मीडिया अनुमतियों को अनुमति देता है। यदि उपयोगकर्ता ने अपने कैमरे और माइक्रोफोन को लगातार एक्सेस दिया है, तो यह मानना ​​तर्कसंगत है कि वेब पेज पर अतिरिक्त कार्यों के बिना ध्वनि उत्पन्न करने के लिए पर्याप्त रूप से भरोसा किया जा सकता है और इस बात की परवाह किए बिना कि यह कैमरा / माइक्रोफोन के साथ काम करता है या नहीं। अंत में, उपयोगकर्ता का मानना ​​है कि आप उनके कैमरा और माइक्रोफोन को उनके ज्ञान के बिना लाखों लोगों के साथ साझा नहीं करेंगे। इस मामले में, इंटरफ़ेस साउंड बजाना कम से कम समस्याएं हैं।

कैसे अपने आवेदन में मदद करने के लिए

सौभाग्य से, आपकी मदद करने के लिए कुछ ट्रिक्स हैं। आईओएस के लिए सफारी में एक समस्या का सामना करने पर हमने कन्फेरे में क्या जोड़ा, इसकी एक सूची यहां दी गई है।

जोड़ा गया playinline

वीडियो में ध्वनि वापस करने के लिए, वीडियो तत्व में प्लेसीनलाइन विशेषता जोड़ें। यह विशेषता अच्छी तरह से प्रलेखित है, सफारी और क्रोम में काम करती है और अन्य ब्राउज़रों में इसका कोई दुष्प्रभाव नहीं है।

उपयोगकर्ता क्रियाएँ

एक ऑडियो विज़ुअलाइज़र को "ठीक" करने के लिए, बस एक कस्टम क्रिया जोड़ें। हम भाग्यशाली थे क्योंकि हम अपनी परीक्षण स्क्रीन पर बहुत सारे कदम जोड़ सकते थे (जोड़ सकते थे), जिससे उपयोगकर्ता की स्पष्ट भागीदारी हो सके। आप कम भाग्यशाली हो सकते हैं। जब तक Google इसे ठीक करने का ध्यान नहीं रखता, तब तक उपयोगकर्ता को शामिल करने के अलावा और कोई रास्ता नहीं है।

इंटरफ़ेस ध्वनियों को ठीक नहीं कर सकता

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

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