Chrome की मीडिया क्षमताओं को वर्शन 75 में अपडेट किया गया था. इस लेख में, हम उन नई सुविधाओं के बारे में बताएंगे जिनमें ये शामिल हैं:
- यह अनुमान लगाना कि एन्क्रिप्ट किए गए मीडिया के लिए, प्लेबैक आसानी से होगा या नहीं और क्या बैटरी की खपत कम होगी.
- वीडियो एलिमेंट के
playsInlineएट्रिब्यूट से जुड़े संकेत के साथ काम करना.
एन्क्रिप्ट (सुरक्षित) किया गया मीडिया: डिकोड करने की जानकारी
Chrome 66 के बाद से, वेब डेवलपर डिकोडिंग की जानकारी का इस्तेमाल कर सकते हैं. इससे वे ब्राउज़र से, डिवाइस पर कॉन्टेंट को साफ़ तौर पर डिकोड करने की क्षमता के बारे में जानकारी पा सकते हैं. यह जानकारी, कोडेक, प्रोफ़ाइल, रिज़ॉल्यूशन, बिटरेट वगैरह जैसी जानकारी के आधार पर मिलती है. इससे यह पता चलता है कि ब्राउज़र के रिकॉर्ड किए गए पिछले वीडियो चलाने के आंकड़ों के आधार पर, वीडियो चलाने में आसानी होगी या नहीं और क्या वीडियो चलाने के लिए ज़्यादा बैटरी खर्च होगी.
डिकोडिंग की जानकारी को परिभाषित करने वाले Media Capabilities API की खास बातों को एन्क्रिप्ट (सुरक्षित) किए गए मीडिया कॉन्फ़िगरेशन को मैनेज करने के लिए भी अपडेट किया गया है. ऐसा इसलिए किया गया है, ताकि एन्क्रिप्ट (सुरक्षित) किए गए मीडिया (ईएमई) का इस्तेमाल करने वाली वेबसाइटें सबसे सही मीडिया स्ट्रीम चुन सकें.
खास जानकारी के तौर पर, यहां बताया गया है कि EME के लिए डिकोडिंग की जानकारी कैसे काम करती है. आधिकारिक सैंपल आज़माएं.
const encryptedMediaConfig = {
type: 'media-source', // or 'file'
video: {
contentType: 'video/webm; codecs="vp09.00.10.08"',
width: 1920,
height: 1080,
bitrate: 2646242, // number of bits used to encode a second of video
framerate: '25' // number of frames used in one second
},
keySystemConfiguration: {
keySystem: 'com.widevine.alpha',
videoRobustness: 'SW_SECURE_DECODE' // Widevine L3
}
};
navigator.mediaCapabilities.decodingInfo(encryptedMediaConfig).then(result => {
if (!result.supported) {
console.log('Argh! This encrypted media configuration is not supported.');
return;
}
if (!result.keySystemAccess) {
console.log('Argh! Encrypted media support is not available.')
return;
}
console.log('This encrypted media configuration is supported.');
console.log('Playback should be' +
(result.smooth ? '' : ' NOT') + ' smooth and' +
(result.powerEfficient ? '' : ' NOT') + ' power efficient.');
// TODO: Use `result.keySystemAccess.createMediaKeys()` to setup EME playback.
});
ईएमई वाले वीडियो चलाने के लिए, डिकोड करने और रेंडर करने के खास कोड पाथ का इस्तेमाल किया जाता है. इसका मतलब है कि साफ़ तौर पर वीडियो चलाने की तुलना में, ईएमई वाले वीडियो चलाने के लिए अलग कोडेक का इस्तेमाल किया जाता है और परफ़ॉर्मेंस भी अलग होती है. इसलिए, navigator.mediaCapabilities.decodingInfo() को पास किए गए मीडिया कॉन्फ़िगरेशन ऑब्जेक्ट में एक नई keySystemConfiguration कुंजी सेट की जानी चाहिए. इस कुंजी की वैल्यू, एक डिक्शनरी होती है. इसमें जान-पहचाने EME टाइप की कई वैल्यू होती हैं. यह EME के requestMediaKeySystemAccess() को दिए गए इनपुट को दोहराता है. हालांकि, इसमें एक बड़ा अंतर है: requestMediaKeySystemAccess() को दिए गए इनपुट के क्रम को एक ही वैल्यू में बदल दिया जाता है. ऐसा तब किया जाता है, जब क्रम का मकसद requestMediaKeySystemAccess() को वह सबसेट चुनना हो जिस पर वह काम करता है.
डिकोडिंग की जानकारी में, ऑडियो और वीडियो स्ट्रीम के एक जोड़े के लिए, कॉलर के लिए कोई फ़ैसला लिए बिना, सहायता की क्वालिटी (सुविधा और बिजली की खपत) के बारे में बताया जाता है. कॉल करने वाले लोगों को अब भी मीडिया कॉन्फ़िगरेशन ऑर्डर करने होंगे, जैसे कि वे requestMediaKeySystemAccess() के साथ करते हैं. अब वे खुद ही सूची में शामिल होते हैं.
navigator.mediaCapabilities.decodingInfo() ऐसा प्रॉमिस देता है जो तीन बूलियन वाले ऑब्जेक्ट के साथ एसिंक्रोनस तरीके से हल होता है: supported, smooth, और powerEfficient. हालांकि, जब कोईkeySystemConfiguration बटन सेट होता है और
supported true होता है, तब भी keySystemAccess नाम का एक औरMediaKeySystemAccess ऑब्जेक्ट भी दिखाया जाता है. इसका इस्तेमाल, कुछ मीडिया कुंजियों का अनुरोध करने और एन्क्रिप्ट (सुरक्षित) किए गए मीडिया को चलाने के लिए किया जा सकता है. यहां एक उदाहरण दिया गया है:
// Like rMSKA(), orderedMediaConfigs is ordered from most to least wanted.
const capabilitiesPromises = orderedMediaConfigs.map(mediaConfig =>
navigator.mediaCapabilities.decodingInfo(mediaConfig)
);
// Assume this app wants a supported and smooth media playback.
let bestConfig = null;
for await (const result of capabilitiesPromises) {
if (result.supported && result.smooth) {
bestConfig = result;
break;
}
}
if (bestConfig) {
const mediaKeys = await bestConfig.keySystemAccess.createMediaKeys();
// TODO: rest of EME path as-is
} else {
// Argh! No smooth configs found.
// TODO: Maybe choose the lowest resolution and framerate available.
}
ध्यान दें कि एन्क्रिप्ट किए गए मीडिया की जानकारी को डिकोड करने के लिए, एचटीटीपीएस ज़रूरी है.
साथ ही, ध्यान रखें कि यह requestMediaKeySystemAccess() की तरह ही Android और ChromeOS पर भी उपयोगकर्ता के अनुरोध को ट्रिगर कर सकता है. हालांकि, एन्क्रिप्ट (सुरक्षित) किए गए मीडिया को चलाने की सुविधा सेटअप करने के लिए ज़्यादा कॉल की ज़रूरत होने के बावजूद, यह requestMediaKeySystemAccess() से ज़्यादा प्रॉम्प्ट नहीं दिखाएगा.
एक्सपेरिमेंट करने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
HTMLVideoElement.playsInline
Chrome अब playsInline बूलियन एट्रिब्यूट के साथ काम करता है. अगर यह एट्रिब्यूट मौजूद है, तो इससे ब्राउज़र को यह पता चलता है कि वीडियो को डिफ़ॉल्ट रूप से दस्तावेज़ में "इनलाइन" दिखाया जाना चाहिए. साथ ही, यह एलिमेंट के वीडियो चलाने की जगह तक ही सीमित होना चाहिए.
इसी तरह Safari में, iPhone पर वीडियो एलिमेंट अपने-आप फ़ुलस्क्रीन मोड में नहीं जाते. हालांकि, इस हिंट की मदद से, कुछ एम्बेडर अपने वीडियो को अपने-आप फ़ुलस्क्रीन मोड में चलाने की सुविधा दे सकते हैं. वेब डेवलपर, ज़रूरत पड़ने पर इस सुविधा से ऑप्ट-आउट करने के लिए इसका इस्तेमाल कर सकते हैं.
<video playsinline></video>
Android और डेस्कटॉप पर Chrome, अपने-आप फ़ुलस्क्रीन मोड में नहीं खुलता. इसलिए, playsInline वीडियो एलिमेंट एट्रिब्यूट के लिए दिए गए हिंट का इस्तेमाल नहीं किया जाता.