Chrome 69 में मीडिया अपडेट

François Beaufort

• Chrome, AV1 वीडियो को डिकोड करने की सुविधा देता है.
• EME की मदद से, एन्क्रिप्शन की कौनसी स्कीम इस्तेमाल की जा सकती हैं, इस बारे में क्वेरी करने की सुविधा अब उपलब्ध है.
• वेब डेवलपर, यह पता लगाने के लिए एक्सपेरिमेंट कर सकते हैं कि किसी खास एचडीसीपी नीति को लागू किया जा सकता है या नहीं.
• मीडिया सोर्स एक्सटेंशन अब बफ़र की गई रेंज और अवधि की वैल्यू के लिए पीटीएस का इस्तेमाल करते हैं.
• Android Go के उपयोगकर्ता, डाउनलोड किए गए ऑडियो, वीडियो, और इमेज को Chrome में खोल सकते हैं.
• MSE का इस्तेमाल करने वाले मीडिया एलिमेंट के लिए, रोके गए इवेंट हटा दिए जाते हैं.

AV1 वीडियो डीकोडर

Chromestatus ट्रैकर | Chromium में मौजूद गड़बड़ी

EME: एन्क्रिप्शन स्कीम के लिए सहायता के बारे में क्वेरी करना

कुछ प्लैटफ़ॉर्म या पासकोड सिस्टम सिर्फ़ CENC मोड के साथ काम करते हैं, जबकि कुछ सिर्फ़ CBCS मोड के साथ काम करते हैं. कुछ लोग दोनों तरीकों का इस्तेमाल कर सकते हैं. एन्क्रिप्शन की ये दोनों स्कीम एक साथ काम नहीं करतीं. इसलिए, वेब डेवलपर को यह तय करना होगा कि कौनसा कॉन्टेंट दिखाना है.

"पहचाने गए" एन्क्रिप्शन स्कीम के साथ काम करने वाले प्लैटफ़ॉर्म की जांच करने के लिए, यह तय करने से बचने के लिए कि वे किस प्लैटफ़ॉर्म पर हैं, MediaKeySystemMediaCapability डिक्शनरी में एक नई encryptionScheme कुंजी जोड़ी गई है. इससे वेबसाइटों को यह तय करने की अनुमति मिलती है कि एन्क्रिप्ट किए गए मीडिया एक्सटेंशन (ईएमई) में किस एन्क्रिप्शन स्कीम का इस्तेमाल किया जा सकता है.

नई encryptionScheme कुंजी, इनमें से कोई एक वैल्यू हो सकती है:

• 'cenc' एईएस-सीटीआर मोड में पूरा सैंपल और वीडियो एनएएल सबसैंपल एन्क्रिप्शन.
• 'cbcs' एईएस-सीबीसी मोड में, वीडियो के कुछ हिस्से को एन्क्रिप्ट (सुरक्षित) करने के लिए एनएएल पैटर्न का इस्तेमाल करना.

अगर इस बारे में नहीं बताया गया है, तो इसका मतलब है कि एन्क्रिप्शन की कोई भी स्कीम इस्तेमाल की जा सकती है. ध्यान दें कि साफ़ की गई कुंजी हमेशा 'cenc' स्कीम के साथ काम करती है.

नीचे दिए गए उदाहरण में, अलग-अलग एन्क्रिप्शन स्कीम वाले दो कॉन्फ़िगरेशन के लिए क्वेरी करने का तरीका बताया गया है. इस मामले में, सिर्फ़ एक विकल्प चुना जाएगा.

await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [
    {
      label: 'configuration using the "cenc" encryption scheme',
      videoCapabilities: [{
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cenc'
      }],
      audioCapabilities: [{
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cenc'
      }],
      initDataTypes: ['keyids']
    },
    {
      label: 'configuration using the "cbcs" encryption scheme',
      videoCapabilities: [{
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cbcs'
      }],
      audioCapabilities: [{
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cbcs'
      }],
      initDataTypes: ['keyids']
    },
  ]);

नीचे दिए गए उदाहरण में, दो अलग-अलग एन्क्रिप्शन स्कीम वाले सिर्फ़ एक कॉन्फ़िगरेशन के बारे में क्वेरी की गई है. ऐसे में, Chrome ऐसे किसी भी कैपेबिलिटी ऑब्जेक्ट को खारिज कर देगा जिस पर काम नहीं किया जा सकता. इसलिए, इकट्ठा किए गए कॉन्फ़िगरेशन में, एन्क्रिप्शन का एक या दोनों स्कीम शामिल हो सकते हैं.

await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [{
    videoCapabilities: [
      { // A video capability using the "cenc" encryption scheme
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cenc'
      },
      { // A video capability using the "cbcs" encryption scheme
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cbcs'
      },
    ],
    audioCapabilities: [
      { // An audio capability using the "cenc" encryption scheme
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cenc'
      },
      { // An audio capability using the "cbcs" encryption scheme
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cbcs'
      },
    ],
    initDataTypes: ['keyids']
  }]);

लागू करने का इंटेंट | Chromestatus ट्रैकर | Chromium बग

EME: HDCP नीति की जांच

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

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

HDCP नीति की जांच करने वाला एपीआई, mediaKeys.getStatusForPolicy() को कॉल करके काम करता है. इसके लिए, minHdcpVersion कुंजी और मान्य वैल्यू वाला ऑब्जेक्ट होना ज़रूरी है. अगर एचडीसीपी, बताए गए वर्शन में उपलब्ध है, तो रिटर्न किए गए प्रॉमिस का हल, 'usable' के MediaKeyStatus के साथ होता है. ऐसा न होने पर, प्रोमिस MediaKeyStatus की अन्य गड़बड़ी वैल्यू के साथ रिज़ॉल्व होता है, जैसे कि 'output-restricted' या 'output-downscaled'. अगर पासकोड सिस्टम, एचडीसीपी नीति की जांच की सुविधा के साथ काम नहीं करता है (जैसे, क्लियर पासकोड सिस्टम), तो वादा अस्वीकार कर दिया जाता है.

खास जानकारी के तौर पर, फ़िलहाल एपीआई इस तरह काम करता है. HDCP के सभी वर्शन आज़माने के लिए, आधिकारिक सैंपल देखें.

const config = [{
  videoCapabilities: [{
    contentType: 'video/webm; codecs="vp09.00.10.08"',
    robustness: 'SW_SECURE_DECODE' // Widevine L3
  }]
}];

navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
.then(mediaKeySystemAccess => mediaKeySystemAccess.createMediaKeys())
.then(mediaKeys => {

  // Get status for HDCP 2.2
  return mediaKeys.getStatusForPolicy({ minHdcpVersion: '2.2' })
  .then(status => {
    if (status !== 'usable')
      return Promise.reject(status);

    console.log('HDCP 2.2 can be enforced.');
    // TODO: Fetch high resolution protected content...
  });
})
.catch(error => {
  // TODO: Fallback to fetch license or stream low-resolution content...
});

ऑरिजिन ट्रायल के लिए उपलब्ध

वेब डेवलपर से सुझाव, शिकायत या राय पाने के लिए, हमने पहले ही डेस्कटॉप (ChromeOS, Linux, Mac, और Windows) के लिए Chrome 69 में एचडीसीपी नीति की जांच करने वाले एपीआई की सुविधा जोड़ी है.

यह ट्रायल नवंबर 2018 में खत्म हो गया.

प्रयोग करने का इंटेंट | Chromestatus ट्रैकर | Chromium बग

एमएसई के पीटीएस/डीटीएस से जुड़ी शर्तें

अब मीडिया सोर्स एक्सटेंशन (एमएसई) में, डिकोड टाइम स्टैंप (डीटीएस) इंटरवल के बजाय, प्रज़ेंटेशन टाइम स्टैंप (पीटीएस) इंटरवल के हिसाब से, बफ़र की गई रेंज और अवधि की वैल्यू रिपोर्ट की जाती हैं.

एमएसई के नए होने पर, Chrome में इसे लागू करने की जांच WebM और MP3 के साथ-साथ कुछ मीडिया स्ट्रीम फ़ॉर्मैट के लिए की गई थी. इनमें पीटीएस और डीटीएस के बीच कोई अंतर नहीं था. यह तब तक ठीक से काम कर रहा था, जब तक ISO BMFF (यानी MP4) जोड़ा नहीं गया था. इस कंटेनर में, अक्सर प्रज़ेंटेशन और डिकोड करने के समय की स्ट्रीम का क्रम अलग-अलग होता है. उदाहरण के लिए, H.264 जैसे कोडेक के लिए, डीटीएस और पीटीएस अलग-अलग होते हैं. इस वजह से, Chrome ने आम तौर पर थोड़ी सी ही, बफ़र की गई रेंज और अवधि की वैल्यू, उम्मीद से अलग बताई. यह नई सुविधा, Chrome 69 में धीरे-धीरे रोल आउट की जाएगी. साथ ही, एमएसई को एमएसई स्पेसिफ़िकेशन के मुताबिक लागू किया जाएगा.

इस बदलाव का असर MediaSource.duration (इस वजह से HTMLMediaElement.duration), SourceBuffer.buffered (इस वजह से HTMLMediaElement.buffered), और SourceBuffer.remove(start, end) पर पड़ेगा.

अगर आपको नहीं पता कि बफ़र की गई रेंज और अवधि की वैल्यू को रिपोर्ट करने के लिए किस तरीके का इस्तेमाल किया जाता है, तो इंटरनल chrome://media-internals पेज पर जाएं और लॉग में "ChunkDemuxer: buffering by PTS" या "ChunkDemuxer: buffering by DTS" खोजें.

इंटिग्रेशन करने का मकसद | Chromium में मौजूद गड़बड़ी

Android Go पर मीडिया व्यू इंटेंट को मैनेज करना

Android Go, Android का एक हल्का वर्शन है. इसे कम सुविधाओं वाले स्मार्टफ़ोन के लिए डिज़ाइन किया गया है. इसलिए, यह ज़रूरी नहीं है कि यह कुछ मीडिया देखने वाले ऐप्लिकेशन के साथ शिप हो. उदाहरण के लिए, अगर कोई उपयोगकर्ता डाउनलोड किया गया वीडियो खोलने की कोशिश करता है, तो उसके पास उस इंटेंट को मैनेज करने के लिए कोई ऐप्लिकेशन नहीं होगा.

इसे ठीक करने के लिए, Android Go पर Chrome 69 अब मीडिया देखने के इंटेंट को सुनता है, ताकि उपयोगकर्ता डाउनलोड किए गए ऑडियो, वीडियो, और इमेज देख सकें. दूसरे शब्दों में, यह उन ऐप्लिकेशन की जगह लेता है जो वीडियो देखने की सुविधा नहीं देते.

ध्यान दें कि Chrome की यह सुविधा, Android O और उसके बाद के वर्शन वाले उन सभी Android डिवाइसों पर चालू होती है जिनमें 1 जीबी या उससे कम रैम हो.

Chromium में गड़बड़ी

MSE का इस्तेमाल करके, मीडिया एलिमेंट के लिए "रोके गए" इवेंट हटाना

अगर मीडिया डेटा डाउनलोड करने में करीब तीन सेकंड लगते हैं, तो मीडिया एलिमेंट पर "रोका गया" इवेंट ट्रिगर होता है. मीडिया सोर्स एक्सटेंशन (एमएसई) का इस्तेमाल करने पर, वेब ऐप्लिकेशन डाउनलोड को मैनेज करता है और मीडिया एलिमेंट को इसकी प्रोग्रेस की जानकारी नहीं होती. इस वजह से, Chrome गलत समय पर "रोका गया" इवेंट दिखाता था. ऐसा तब होता था, जब वेबसाइट ने पिछले तीन सेकंड में SourceBuffer.appendBuffer() के साथ नए मीडिया डेटा चंक नहीं जोड़े थे.

वेबसाइटें कम फ़्रीक्वेंसी पर, डेटा के बड़े हिस्से को जोड़ने का फ़ैसला ले सकती हैं. इसलिए, यह बफ़र करने की परफ़ॉर्मेंस के बारे में काम का सिग्नल नहीं है. MSE का इस्तेमाल करके मीडिया एलिमेंट के लिए "रोका गया" इवेंट हटाने से, भ्रम की स्थिति खत्म हो जाती है. साथ ही, Chrome को MSE स्पेसिफ़िकेशन के मुताबिक ज़्यादा बेहतर बनाया जा सकता है. ध्यान दें कि एमएसई का इस्तेमाल न करने वाले मीडिया एलिमेंट, "स्टॉल" इवेंट को उसी तरह जनरेट करते रहेंगे जिस तरह आज करते हैं.

इस्तेमाल बंद करने और हटाने का मकसद | Chromestatus ट्रैकर | Chromium बग