Chrome 47 WebRTC: मीडिया रिकॉर्डिंग, सुरक्षित स्रोत और प्रॉक्सी हैंडलिंग

सैम डटन

Chrome 47 में WebRTC को बेहतर बनाने के लिए कई अहम बदलाव और अपडेट शामिल हैं.

अपने वेब ऐप्लिकेशन से वीडियो रिकॉर्ड करें

MediaStreamRecorder API, लंबे समय से 2500 से ज़्यादा स्टार के साथ, Chromium.org का सबसे लोकप्रिय अनुरोध रहा है. प्रयोग के तौर पर उपलब्ध वेब प्लैटफ़ॉर्म की सुविधाओं को फ़्लैग करने के बाद, अब Chrome में मीडिया रिकॉर्डिंग को जोड़ा गया है. हालांकि, यह फ़िलहाल सिर्फ़ डेस्कटॉप के लिए उपलब्ध है. इससे, वीडियो को रिकॉर्ड करके चलाया जा सकता है या उसे डाउनलोड किया जा सकता है. WebRTC सैंपल डेटा स्टोर करने की सुविधा का एक डेमो दिया गया है. आपको discuss-webrtc एलान से, इस बारे में ज़्यादा जानकारी मिल सकती है. स्क्रीन कैप्चर से वीडियो रिकॉर्ड करने के लिए, Chrome ऐप्लिकेशन का एक सैंपल github.com/niklasenbom/RecordingApp पर उपलब्ध है. ये हाल ही में लागू किए गए हैं और फिर भी गड़बड़ियों को दूर करना पड़ सकता है: अगर आपको कोई समस्या आती है, तो कृपया डेटा स्टोर करने की जगह पर समस्याएं दर्ज करें.

WebRTC GitHub सैंपल डेटा स्टोर पर MediaRecorder डेमो का स्क्रीनशॉट

ऑडियो आउटपुट डिवाइस चुनना

MediaDevices.enumerateDevices() रिलीज़ कर दी गई है. ज़्यादा जानकारी के लिए, Chromium की समस्या 504280 पर जाएं. MediaStreamTrack.getSources() पर पहले से मौजूद ऑडियो इनपुट और वीडियो इनपुट डिवाइसों के साथ-साथ, अब ऑडियो आउटपुट डिवाइसों की गिनती की जा सकती है. यह अपडेट पढ़कर, इसे इस्तेमाल करने के तरीके के बारे में ज़्यादा जानकारी मिल सकती है.

Windows पर डिवाइस सहायता

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

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

प्रॉक्सी हैंडलिंग

अगर कोई लोकल प्रॉक्सी सर्वर कॉन्फ़िगर किया गया है, तो Chrome 47 में एक नई प्राथमिकता जोड़ी गई है. इससे WebRTC ट्रैफ़िक को लोकल प्रॉक्सी सर्वर के ज़रिए भेजने की सुविधा मिलती है. वीपीएन की मदद से ब्राउज़ करने वाले कुछ लोगों के लिए यह ज़रूरी है. इसका मतलब है कि WebRTC ऐप्लिकेशन को सिर्फ़ प्रॉक्सी आईपी पता दिखेगा. ध्यान रखें कि इससे ऐप्लिकेशन की परफ़ॉर्मेंस पर बुरा असर पड़ेगा और यह तब तक काम नहीं करेगा, जब तक कि ऐप्लिकेशन टर्न/टीसीपी या ICE-TCP का इस्तेमाल नहीं करता. इस प्राथमिकता के लिए यूज़र इंटरफ़ेस (यूआई) देने के लिए, जल्द ही WebRTC नेटवर्क लिमिटर एक्सटेंशन का नया वर्शन देखें. WebRTC के लिए अगला क्या है में, आईपी पते 'लीकेज' के बारे में ज़्यादा जानकारी उपलब्ध है.

WebRTC नेटवर्क लिमिटर Chrome एक्सटेंशन

...कई और चीज़ें

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

हम Chrome 47 की समयसीमा में, DTLS 1.2 के लिए धीरे-धीरे सहायता उपलब्ध कराएंगे.

हालांकि, इस रिलीज़ में VP9 और H.264 दोनों ही काम नहीं करते, लेकिन इन पर काम जारी है. हमें उम्मीद है कि हम Chrome 48 में VP9 और H.264 के शुरुआती वर्शन (फ़्लैग के पीछे) के लिए काम करेंगे.

जनहित में जारी घोषणाओं की जानकारी

  • Chrome 47 और उसके बाद वाले वर्शन में, getUserMedia() अनुरोधों को सिर्फ़ सुरक्षित ऑरिजिन से अनुमति दी जा सकती है: एचटीटीपीएस या localhost.
  • आरटीपी डेटा चैनल का सपोर्ट हटा दिया गया है. आरटीपी डेटा चैनलों का इस्तेमाल करने वाले बाकी ऐप्लिकेशन को, स्टैंडर्ड डेटा चैनलों का इस्तेमाल करना चाहिए.

सभी रिलीज़ की तरह ही, हम डेवलपर को कैनरी, डेव, और बीटा चैनल पर Chrome आज़माने और किसी भी समस्या का पता चलने पर रिपोर्ट करने के लिए बढ़ावा देते हैं. हमें मिलने वाली सहायता अमूल्य है. गड़बड़ी की अच्छी रिपोर्ट दर्ज करने के बारे में जानकारी पाने के लिए, कृपया WebRTC से जुड़ी गड़बड़ी का पेज देखें.

डेमो

ज़्यादा जानें