वेब ऑडियो, वीडियो अपने-आप चलने की नीति, और गेम

Tom Greenaway

सितंबर 2017 में, हमने Chrome में ऑडियो को मैनेज करने के तरीके में होने वाले बदलाव का एलान किया था. यह बदलाव, कॉन्टेंट के अपने-आप चलने से जुड़ी नीति के तहत किया गया था. नीति में यह बदलाव, मई 2018 में Chrome 66 के स्टेबल वर्शन के साथ रिलीज़ किया गया था.

वेब ऑडियो डेवलपमेंट कम्यूनिटी से मिले सुझावों के बाद, हमने अपने-आप चलने वाले विज्ञापनों से जुड़ी नीति के वेब ऑडियो सेक्शन को रिलीज़ करने में देरी की है. इससे डेवलपर को अपनी वेबसाइटों को अपडेट करने के लिए ज़्यादा समय मिलेगा. हमने वेब ऑडियो के लिए बनी नीति को लागू करने के तरीके में भी कुछ बदलाव किए हैं. इससे, उन वेबसाइटों की संख्या कम हो जाएगी जिन्हें अपने कोड में बदलाव करना होगा. खास तौर पर, वेब गेम को. इससे हमारे उपयोगकर्ताओं को बेहतर अनुभव मिलेगा.

नीति में यह बदलाव, दिसंबर 2018 में Chrome 71 के साथ रोल आउट किया जाएगा.

नीति में हुए बदलाव का क्या असर होगा?

अपने-आप चलने वाले कॉन्टेंट को ऐसा कॉन्टेंट कहा जाता है जो वेबपेज लोड होने के साथ ही चलने लगता है. जिन वेबसाइटों के लिए कॉन्टेंट अपने-आप चलने की सुविधा चालू है उनके लिए, यह बदलाव डिफ़ॉल्ट रूप से वीडियो चलाने से रोक देगा. ज़्यादातर मामलों में, प्लेबैक फिर से शुरू हो जाएगा. हालांकि, कुछ मामलों में कोड में थोड़ा बदलाव करना पड़ सकता है. खास तौर पर, डेवलपर को ऐसा कोड जोड़ना होगा जो उपयोगकर्ता के वेबपेज से इंटरैक्ट करने पर, कॉन्टेंट को फिर से शुरू कर सके.

हालांकि, अगर उपयोगकर्ता किसी ऐसे पेज पर पहुंचता है जिस पर वीडियो अपने-आप चलने की सुविधा चालू है और वह उस पेज पर उसी ऑरिजिन के किसी पेज से पहुंचा है, तो उस कॉन्टेंट को कभी ब्लॉक नहीं किया जाएगा. ज़्यादा जानकारी वाले उदाहरणों के लिए, वीडियो अपने-आप चलने की नीति के बारे में हमारी पिछली ब्लॉग पोस्ट पढ़ें.

इसके अलावा, हमने उपयोगकर्ताओं के पिछले व्यवहार से सीखने के लिए, ऑडियो अपने-आप चलने वाली वेबसाइटों के बारे में जानकारी जोड़ी है. जब उपयोगकर्ता किसी वेबसाइट पर आने के दौरान, ज़्यादातर समय सात सेकंड से ज़्यादा तक ऑडियो चलाते हैं, तब हम इसका पता लगाते हैं. साथ ही, उस वेबसाइट के लिए ऑटोप्ले की सुविधा चालू करते हैं.

हम ऐसा एक इंडेक्स की मदद से करते हैं, जिसे किसी डिवाइस पर हर Chrome प्रोफ़ाइल के हिसाब से स्थानीय तौर पर सेव किया जाता है. यह इंडेक्स, सभी डिवाइसों पर सिंक नहीं होता और इसे सिर्फ़ उपयोगकर्ता के उन आंकड़ों के हिस्से के तौर पर शेयर किया जाता है जिनमें उनकी पहचान ज़ाहिर नहीं की जाती. हम इस इंडेक्स को मीडिया एंगेजमेंट इंडेक्स (एमईआई) कहते हैं. इसे chrome://media-engagement पर जाकर देखा जा सकता है.

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

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

हालांकि, इस अधिकार के हमेशा उपलब्ध रहने की कोई गारंटी नहीं है. अगर उपयोगकर्ता का व्यवहार बदलता है, जैसे कि कई बार विज़िट करने के दौरान, सात सेकंड के थ्रेशोल्ड के अंदर ऑडियो चलाना बंद करना या टैब बंद करना – तो हम वेबसाइट से अपने-आप वीडियो चलने की सुविधा हटा देते हैं.

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

ध्यान दें कि iframe को उपयोगकर्ता के इंटरैक्शन के बिना अपने-आप चलने का अधिकार सिर्फ़ तब मिल सकता है, जब iframe को एम्बेड करने वाला पैरंट वेबपेज उस अधिकार को दिए गए iframe पर लागू करता हो.

कम्यूनिटी की मदद करने के लिए, बदलाव को कुछ समय के लिए रोकना

जब Chrome के स्टैबल चैनल में यह बदलाव हुआ, तब वेब ऑडियो डेवलपर कम्यूनिटी ने इस पर ध्यान दिया. खास तौर पर, इस कम्यूनिटी के वेब गेम डेवलपर और WebRTC डेवलपर ने इस पर ध्यान दिया.

कम्यूनिटी से मिले सुझावों के मुताबिक, इस बदलाव से कई वेब गेम और वेब ऑडियो पर बुरा असर पड़ेगा. खास तौर पर, जिन साइटों को अपडेट नहीं किया गया है वे अब उपयोगकर्ताओं के लिए ऑडियो नहीं चला पाएंगी. इसलिए, हमारी टीम ने इस बदलाव को थोड़ी देर के लिए रोकने का फ़ैसला लिया, ताकि वेब ऑडियो डेवलपर को अपनी वेबसाइटों को अपडेट करने के लिए ज़्यादा समय मिल सके.

इसके अलावा, हमने इस समय का इस्तेमाल इन कामों के लिए किया:

  • गंभीरता से इस बात पर विचार करें कि नीति में किया गया यह बदलाव सही था या नहीं.
  • ऐसे तरीके खोजें जिनसे ऑडियो वाली उन वेबसाइटों की संख्या कम की जा सके जिन पर इस बदलाव का असर पड़ेगा.

पहले मामले में, हमने यह फ़ैसला लिया कि नीति में बदलाव करना ज़रूरी है, ताकि हमारे ज़्यादातर उपयोगकर्ताओं को बेहतर अनुभव मिल सके. नीति में हुए इस बदलाव से किस समस्या को हल किया जा रहा है, इस बारे में ज़्यादा जानकारी के लिए इस लेख के अगले सेक्शन को पढ़ें.

बाद वाले मामले के लिए, हमने वेब ऑडियो के लिए लागू करने के तरीके में बदलाव किया है. इससे उन वेबसाइटों की संख्या कम हो जाएगी जिन पर मूल रूप से असर पड़ा था. हमने जिन साइटों के बारे में जाना था कि वे इस बदलाव की वजह से काम नहीं कर रही हैं उनमें से 80% से ज़्यादा साइटें अपने-आप काम करने लगेंगी. इनमें से कई साइटों को वेब गेम डेवलपमेंट कम्यूनिटी ने उदाहरण के तौर पर दिया था. इन उदाहरण वाली साइटों का विश्लेषण और जांच यहां देखी जा सकती है. इस नए बदलाव के बारे में ज़्यादा जानकारी नीचे दी गई है.

हमने WebRTC ऐप्लिकेशन के साथ काम करने के लिए भी एक बदलाव किया है. कैप्चर सेशन चालू होने पर, वीडियो अपने-आप चलने की अनुमति होगी.

इस बदलाव का मकसद, उपयोगकर्ताओं के व्यवहार से जुड़ी कौनसी समस्या हल करना है?

ब्राउज़र, उपयोगकर्ता को साउंड मैनेज करने में मदद नहीं करते. जब उपयोगकर्ता किसी वेबपेज को खोलते हैं और उन्हें ऐसी आवाज़ सुनाई देती है जिसकी उन्हें उम्मीद नहीं थी या जो उन्हें पसंद नहीं है, तो उन्हें खराब उपयोगकर्ता अनुभव मिलता है. हम इस समस्या को हल करने की कोशिश कर रहे हैं. उपयोगकर्ता अपने ब्राउज़र पर कॉन्टेंट अपने-आप चलने की सुविधा नहीं चाहते, क्योंकि इससे अनचाहा शोर होता है.

हालांकि, कभी-कभी उपयोगकर्ता चाहते हैं कि कॉन्टेंट अपने-आप चलना शुरू हो जाए. साथ ही, Chrome में ब्लॉक किए गए ऑटोप्ले की एक बड़ी संख्या को बाद में उपयोगकर्ता चलाता है.

इसलिए, हमारा मानना है कि उपयोगकर्ताओं से सीखकर और हर वेबसाइट के हिसाब से उनके इंटेंट का अनुमान लगाकर, हम उपयोगकर्ताओं को बेहतरीन अनुभव दे सकते हैं. अगर उपयोगकर्ता किसी वेबसाइट से कॉन्टेंट चलाने की अनुमति देते हैं, तो हम आने वाले समय में उस साइट का कॉन्टेंट अपने-आप चला देंगे. इसके उलट, अगर उपयोगकर्ता किसी वेबसाइट से कॉन्टेंट अपने-आप चलने की सुविधा बंद करते हैं, तो हम उस कॉन्टेंट के लिए डिफ़ॉल्ट रूप से, अपने-आप चलने की सुविधा बंद कर देंगे.

कम्यूनिटी ने एक ऐसा सुझाव दिया है जिसमें ऑटोप्ले को रोकने के बजाय, किसी टैब के ऑडियो को म्यूट करने का विकल्प दिया गया है. हालांकि, हमारा मानना है कि वीडियो अपने-आप चलने की सुविधा को रोकना बेहतर है, ताकि वेबसाइट को पता चल सके कि वीडियो अपने-आप चलने की सुविधा ब्लॉक कर दी गई है. इससे वेबसाइट डेवलपर को इस पर कार्रवाई करने में मदद मिलेगी. उदाहरण के लिए, कुछ डेवलपर सिर्फ़ ऑडियो को म्यूट करना चाहते हैं, जबकि अन्य डेवलपर चाह सकते हैं कि जब तक उपयोगकर्ता कॉन्टेंट के साथ सक्रिय तौर पर जुड़ा न हो, तब तक ऑडियो कॉन्टेंट को रोक दिया जाए. ऐसा न करने पर, हो सकता है कि उपयोगकर्ता को ऑडियो का कुछ हिस्सा न सुनाई दे.

वेब गेम डेवलपर की मदद के लिए नए बदलाव

डेवलपर, ऑडियो चलाने के लिए दो तरह के ऑब्जेक्ट बनाकर, वेब ऑडियो एपीआई का इस्तेमाल आम तौर पर करते हैं:

  • AudioContext
  • और AudioNodes, जो किसी संदर्भ से जुड़े होते हैं

वेब ऑडियो डेवलपर, ऑडियो चलाने के लिए AudioContext बनाएंगे. ऑटोप्ले की नीति के तहत, AudioContext अपने-आप निलंबित होने के बाद, ऑडियो को फिर से शुरू करने के लिए, उपयोगकर्ता को टैब के साथ इंटरैक्ट करने के बाद, इस ऑब्जेक्ट पर resume() फ़ंक्शन को कॉल करना होगा:

    const context = new AudioContext();

    // Setup an audio graph with AudioNodes and schedule playback.
    ...

    // Resume AudioContext playback when user clicks a button on the page.
    document.querySelector('button').addEventListener('click', function() {
      context.resume().then(() => {
        console.log('AudioContext playback resumed successfully');
      });
    });

कई इंटरफ़ेस, AudioNode से इनहेरिट होते हैं. इनमें से एक AudioScheduledSourceNode इंटरफ़ेस है. AudioScheduledSourceNode इंटरफ़ेस को लागू करने वाले AudioNode को आम तौर पर सोर्स नोड कहा जाता है. जैसे, AudioBufferSourceNode, ConstantSourceNode, और OscillatorNode. सोर्स नोड, start() तरीके को लागू करते हैं.

सोर्स नोड, आम तौर पर गेम में चलने वाले अलग-अलग ऑडियो स्निपेट दिखाते हैं. उदाहरण के लिए: जब कोई प्लेयर सिक्का इकट्ठा करता है, तब जो आवाज़ सुनाई देती है या मौजूदा स्टेज में चलने वाला बैकग्राउंड संगीत. जब भी गेम के लिए इनमें से किसी भी आवाज़ की ज़रूरत होगी, तो गेम डेवलपर सोर्स नोड पर start() फ़ंक्शन को कॉल कर सकते हैं.

वेब गेम में इस सामान्य पैटर्न का पता चलने के बाद, हमने अपने लागू करने के तरीके में इन बदलावों को शामिल करने का फ़ैसला लिया:

AudioContext दो शर्तें पूरी होने पर अपने-आप फिर से शुरू हो जाएगा:

  • उपयोगकर्ता ने किसी पेज से इंटरैक्ट किया हो.
  • सोर्स नोड के start() तरीके को कॉल किया जाता है.

इस बदलाव की वजह से, ज़्यादातर वेब गेम अब उपयोगकर्ता के गेम खेलने पर अपना ऑडियो फिर से शुरू कर देंगे.

वेब को आगे बढ़ाना

वेब प्लैटफ़ॉर्म को बेहतर बनाने के लिए, कभी-कभी ऐसे बदलाव करने पड़ते हैं जिनकी वजह से, प्लैटफ़ॉर्म के साथ काम करने वाले टूल काम नहीं कर पाते. माफ़ करें, ऑडियो अपने-आप चलने की सुविधा को लागू करना मुश्किल है. यह बदलावों की इस कैटगरी में आता है. हालांकि, यह बदलाव करना ज़रूरी है, ताकि यह पक्का किया जा सके कि वेब पर कोई रुकावट न आए या वह अपनी नई सुविधाओं को न खो दे.

हालांकि, हम समझते हैं कि कई वजहों से, वेबसाइटों में सुधारों को लागू करना हमेशा आसान नहीं होता:

  • हो सकता है कि वेब डेवलपर किसी नए प्रोजेक्ट पर फ़ोकस कर रहे हों और पुरानी वेबसाइट को तुरंत मैनेज न कर पा रहे हों.
  • हो सकता है कि वेब गेम पोर्टल के पास, अपने कैटलॉग में गेम लागू करने का कंट्रोल न हो. साथ ही, पब्लिशर के लिए सैकड़ों या हज़ारों गेम को अपडेट करना समय और पैसे की बर्बादी हो सकती है.
  • ऐसा हो सकता है कि कुछ वेबसाइटें बहुत पुरानी हों और किसी वजह से अब उनका रखरखाव न किया जा रहा हो. हालांकि, उन्हें अब भी ऐतिहासिक मकसद से होस्ट किया जा रहा हो.

यहां एक छोटा JavaScript कोड स्निपेट दिया गया है, जो नए AudioContext ऑब्जेक्ट बनाने पर रोक लगाता है. साथ ही, जब उपयोगकर्ता अलग-अलग तरह के इंटरैक्शन करता है, तो इन ऑब्जेक्ट के 'फिर से शुरू करें' फ़ंक्शन को अपने-आप ट्रिगर करेगा. इस कोड को आपके वेबपेज में किसी भी AudioContext ऑब्जेक्ट को बनाने से पहले चलाया जाना चाहिए. उदाहरण के लिए, इस कोड को अपने वेबपेज के टैग में जोड़ा जा सकता है:

(function () {
  // An array of all contexts to resume on the page
  const audioContextList = [];

  // An array of various user interaction events we should listen for
  const userInputEventNames = [
    'click',
    'contextmenu',
    'auxclick',
    'dblclick',
    'mousedown',
    'mouseup',
    'pointerup',
    'touchend',
    'keydown',
    'keyup',
  ];

  // A proxy object to intercept AudioContexts and
  // add them to the array for tracking and resuming later
  self.AudioContext = new Proxy(self.AudioContext, {
    construct(target, args) {
      const result = new target(...args);
      audioContextList.push(result);
      return result;
    },
  });

  // To resume all AudioContexts being tracked
  function resumeAllContexts(event) {
    let count = 0;

    audioContextList.forEach(context => {
      if (context.state !== 'running') {
        context.resume();
      } else {
        count++;
      }
    });

    // If all the AudioContexts have now resumed then we
    // unbind all the event listeners from the page to prevent
    // unnecessary resume attempts
    if (count == audioContextList.length) {
      userInputEventNames.forEach(eventName => {
        document.removeEventListener(eventName, resumeAllContexts);
      });
    }
  }

  // We bind the resume function for each user interaction
  // event on the page
  userInputEventNames.forEach(eventName => {
    document.addEventListener(eventName, resumeAllContexts);
  });
})();

ध्यान दें कि यह कोड स्निपेट, iframe में इंस्टैंशिएट किए गए AudioContexts को फिर से शुरू करने में तब तक मदद नहीं करेगा, जब तक कि इस कोड स्निपेट को iframe के कॉन्टेंट के दायरे में शामिल नहीं किया जाता.

अपने उपयोगकर्ताओं को बेहतर सेवाएं देना

नीति में हुए बदलाव के साथ-साथ, हम उपयोगकर्ताओं के लिए एक सुविधा भी पेश कर रहे हैं. इसकी मदद से, वे वीडियो अपने-आप चलने की नीति को बंद कर सकते हैं. ऐसा उन मामलों में किया जा सकता है जहां ऑटोमैटिक लर्निंग की सुविधा उम्मीद के मुताबिक काम नहीं कर रही है या इस बदलाव की वजह से वेबसाइटें काम नहीं कर रही हैं. यह बदलाव, Chrome 71 में नई नीति के साथ रोल आउट किया जाएगा. इसे साउंड सेटिंग में देखा जा सकता है. जिन साइटों पर उपयोगकर्ता को वीडियो अपने-आप चलने की अनुमति देनी है उन्हें अनुमति वाली सूची में जोड़ा जा सकता है.

नए उपयोगकर्ताओं के लिए एमईआई कैसे बनाया जाता है?

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

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

पहले से मौजूद साइट की सूची, मैन्युअल तरीके से चुनी जाने के बजाय, एल्गोरिदम के हिसाब से जनरेट की जाती है. इसमें किसी भी वेबसाइट को शामिल किया जा सकता है. साइटों को सूची में तब जोड़ा जाता है, जब उस साइट पर आने वाले ज़रूरी उपयोगकर्ता उस साइट पर वीडियो अपने-आप चलने की अनुमति देते हैं. यह थ्रेशोल्ड प्रतिशत पर आधारित होता है, ताकि बड़ी साइटों को फ़ायदा न मिले.

सेहत को ध्यान में रखकर काम करना

हमने इस नीति के पीछे की फ़ैसला लेने की प्रोसेस और डिज़ाइन के बारे में ज़्यादा जानकारी देने के लिए, नया दस्तावेज़ पोस्ट किया है. साथ ही, पहले से डाली गई साइट की सूची कैसे काम करती है, इस बारे में भी नया दस्तावेज़ उपलब्ध कराया गया है.

हम हमेशा अपने उपयोगकर्ताओं को प्राथमिकता देते हैं. हालांकि, हम वेब डेवलपमेंट कम्यूनिटी को भी निराश नहीं करना चाहते. कभी-कभी ब्राउज़र होने का मतलब है कि इन दोनों लक्ष्यों को ध्यान से संतुलित करना होगा. हमारा मानना है कि नीति को लागू करने के तरीके में किए गए बदलावों और वेब ऑडियो डेवलपर को अपना कोड अपडेट करने के लिए दिए गए अतिरिक्त समय की मदद से, हम Chrome 71 में यह संतुलन हासिल कर पाएंगे.

सुझाव/राय दें या शिकायत करें