ईएमई? सीडीएम? DRM से? Cenc? IDK! आपको एक ब्राउज़र में अपना वीडियो प्लेयर बनाने की आवश्यकता है

इन सभी संक्षिप्तताओं का क्या मतलब है? अमेज़ॅन, स्काई और अन्य प्लेटफार्मों से वीडियो देखने और किसी भी प्रदाता से वीडियो देखने के लिए एक ओपन सोर्स प्लेयर विकसित करने में क्या लगता है? सेबास्टियन गोलसाच ने बताया कि होलीजस 2018 पाइटर सम्मेलन में वीडियो स्ट्रीमिंग प्रक्रिया कैसे होती है। उसकी रिपोर्ट के कट - वीडियो और अनुवाद के तहत।



सेबस्टियन गोलशेक वर्तमान में ड्यूश टेलीकॉम में एक डेवलपर है। उन्होंने लंबे समय तक जावा और पीएचपी के साथ काम किया, और फिर जेएस, पायथन और रस्ट पर स्विच किया। पिछले सात वर्षों से, वह Qivicon स्मार्ट होम के मालिकाना मंच पर काम कर रहे हैं।




वीडियो स्ट्रीमिंग के इतिहास के बारे में थोड़ा सा


सबसे पहले, आइए वेब के इतिहास को देखें, क्योंकि हम 25 वर्षों में क्विकटाइम से नेटफ्लिक्स पर चले गए हैं। यह सब 90 के दशक में शुरू हुआ जब Apple ने QuickTime का आविष्कार किया। इंटरनेट पर इसका उपयोग 1993-1994 में शुरू हुआ। उस समय, खिलाड़ी हार्डवेयर त्वरण (केवल प्रोसेसर संसाधनों का उपयोग करके) के बिना 156 × 116 पिक्सल के संकल्प और 10 एफपीएस की आवृत्ति के साथ वीडियो चला सकता था। यह प्रारूप 9600 बॉड डायल-अप कनेक्शन - 9600 बीपीएस पर केंद्रित था, जिसमें ओवरहेड जानकारी शामिल थी।

यह नेटस्केप ब्राउज़र का समय था। ब्राउज़र में वीडियो बहुत अच्छा नहीं लगा, क्योंकि यह वेब का मूल नहीं था। प्लेबैक के लिए, हमने अपने स्वयं के इंटरफ़ेस के साथ बाहरी सॉफ़्टवेयर (उसी QuickTime) का उपयोग किया, जिसे ब्राउज़र में एम्बेड किए गए टैग का उपयोग करके कल्पना की गई थी।



स्थिति थोड़ी बेहतर हो गई जब मैक्रोमेडिया ने शॉकवे प्लेयर (एडोब द्वारा मैक्रोमेडिया के अधिग्रहण के बाद, इसे एडोब फ्लैश प्लेयर के रूप में जाना जाता है) जारी किया। Shockwave Player का पहला संस्करण 1997 में जारी किया गया था, लेकिन वीडियो प्लेबैक इसमें केवल 2002 में दिखाई दिया।

उन्होंने Sorenson Spark उर्फ ​​H.263 कोडेक का उपयोग किया। यह छोटे प्रस्तावों और छोटे फ़ाइल आकार के लिए अनुकूलित किया गया है। इसका क्या मतलब है? उदाहरण के लिए, 43-सेकंड का एक वीडियो जिसका उपयोग शॉकवे प्लेयर का परीक्षण करने के लिए किया गया था, उसका वजन केवल 560 KB था। बेशक, इस गुणवत्ता में एक फिल्म देखना बहुत सुखद नहीं होगा, लेकिन तकनीक उस समय के लिए दिलचस्प थी। हालाँकि, जैसा कि क्विकटाइम के मामले में, शॉकवे प्लेयर को ब्राउज़र में काम करने के लिए, अतिरिक्त सॉफ्टवेयर की आवश्यकता थी। इस खिलाड़ी के पास बहुत सारे सुरक्षा मुद्दे थे, लेकिन सबसे महत्वपूर्ण बात यह है कि वीडियो अभी भी एक ब्राउज़र ऐड-ऑन था।

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



< Video/ > तत्व


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



<Video/> ब्लैक बॉक्स के बिल्कुल विपरीत है, और स्रोत कोड को देखना बहुत सरल है।



DRM से


हालाँकि, आप नेटफ्लिक्स के वीडियो पर सिर्फ राइट-क्लिक नहीं कर सकते हैं और "इस रूप में सहेजें" का चयन कर सकते हैं। इसका कारण DRM (डिजिटल प्रतिबंध प्रबंधन) है। यह कोई एकल तकनीक या एकल अनुप्रयोग नहीं है जो किसी भी कार्य को करता है। यह इस तरह की अवधारणाओं के लिए एक सामान्य शब्द है:

  • प्रमाणीकरण और उपयोगकर्ता एन्क्रिप्शन
  • सामग्री-आधारित एन्क्रिप्शन
  • अधिकारों और प्रतिबंधों के आवेदन की परिभाषा
  • प्रतिक्रिया और अद्यतन
  • आउटपुट नियंत्रण और लिंक सुरक्षा
  • घुसपैठियों की जांच और ट्रैकिंग
  • कुंजी और लाइसेंस प्रबंधन

यह समझने के लिए कि DRM क्या है, हमें इसके पारिस्थितिकी तंत्र का अध्ययन करने की आवश्यकता है, अर्थात यह पता लगाने के लिए कि कौन सी कंपनियां शामिल हैं। यह है:

  • सामग्री के मालिक पारिस्थितिकी तंत्र के शीर्ष पर हैं। उदाहरण के लिए, डिज्नी, एमजीएम या फीफा। ये कंपनियां सामग्री का उत्पादन करती हैं, और उनके पास इसके अधिकार हैं।
  • DRM Cores ऐसी कंपनियाँ हैं जो DRM तकनीक प्रदान करती हैं (उदाहरण के लिए, Google, Apple, Microsoft, आदि)। वर्तमान में, विभिन्न कंपनियों की लगभग 7-8 DRM प्रौद्योगिकियाँ हैं।
  • सेवा प्रदाता - सर्वर सॉफ़्टवेयर विकसित करें जो वीडियो को एन्क्रिप्ट करता है।
  • ब्राउज़र जो वास्तव में खिलाड़ी हैं।
  • सामग्री प्रदाता नेटफ्लिक्स, अमेज़ॅन, स्काई, आदि जैसी कंपनियां हैं। एक नियम के रूप में, वे सामग्री के अधिकार के मालिक नहीं हैं, वे इसे लाइसेंस और वितरित करते हैं।
  • चिप / डिवाइस विक्रेता पारिस्थितिकी तंत्र में भी शामिल हैं, क्योंकि DRM केवल सॉफ्टवेयर तकनीक नहीं है। कुछ कंपनियां (मुख्य रूप से चीनी) चिप्स विकसित कर रही हैं जो वीडियो को एन्कोड और डिकोड करती हैं।

क्या आपने कभी सोचा है कि किसी ब्राउज़र में नेटफ्लिक्स पर वीडियो देखने पर इसका रिज़ॉल्यूशन (SD) बहुत अधिक क्यों नहीं होता है, लेकिन यदि आप एक ही वीडियो को Apple टीवी या एंड्रॉइड टीवी बॉक्स पर देखते हैं, तो वही कंटेंट फुल एचडी या में खेला जाता है। 4K? इसके लिए डीआरएम भी जिम्मेदार हैं। तथ्य यह है कि निर्माता हमेशा समुद्री डाकू चोरी की सामग्री से डरते हैं। इसलिए, कम सुरक्षित वातावरण जिसमें वीडियो डिकोडिंग का प्रदर्शन किया जाता है, यह उपयोगकर्ता के लिए जितनी खराब गुणवत्ता दिखाई जाती है। उदाहरण के लिए, यदि डिकोडिंग को प्रोग्रामेटिक रूप से (उदाहरण के लिए, क्रोम या फ़ायरफ़ॉक्स में) किया जाता है, तो वीडियो को सबसे खराब गुणवत्ता में दिखाया गया है। ऐसे वातावरण में जहां डिकोडिंग के लिए हार्डवेयर क्षमताओं का उपयोग किया जाता है (उदाहरण के लिए, यदि एंड्रॉइड एक जीपीयू का उपयोग करता है), तो सामग्री की अवैध नकल की संभावनाएं कम हैं, और यहां प्लेबैक गुणवत्ता अधिक है। अंत में, सबसे सुरक्षित वातावरण पूरी तरह से हार्डवेयर (एप्पल टीवी या एंड्रॉइड टीवी बॉक्स) है, जहां सॉफ्टवेयर को शामिल किए बिना डिकोडिंग और प्लेबैक किया जाता है।



लेकिन अगर हम ब्राउज़रों के बारे में बात करते हैं, तो उनमें डिकोडिंग लगभग हमेशा सॉफ्टवेयर द्वारा किया जाता है। अलग-अलग ब्राउज़र DRM के लिए विभिन्न प्रणालियों का उपयोग करते हैं। क्रोम और फ़ायरफ़ॉक्स वाइडविइन का उपयोग करते हैं। यह कंपनी Google के स्वामित्व में है और अपने DRM अनुप्रयोगों को लाइसेंस देती है। इस प्रकार, डिकोडिंग के लिए, फ़ायरफ़ॉक्स Google से DRM लाइब्रेरी डाउनलोड करता है। ब्राउज़र में आप देख सकते हैं कि डाउनलोड कहाँ से आ रहा है।



Apple अपने फेयरप्ले सिस्टम का उपयोग करता है, जिसे कंपनी द्वारा पहला iPhone और iPad पेश किए जाने पर वापस बनाया गया था। Microsoft PlayReady नामक अपने स्वयं के विकास का भी उपयोग करता है, जिसे विंडोज में बनाया गया है। अन्य मामलों में, वाइड्विन का सबसे अधिक बार उपयोग किया जाता है। यह प्रणाली एक अनुप्रयोग के रूप में और एक हार्डवेयर समाधान के रूप में मौजूद है - चिप्स जो वीडियो को डिकोड करते हैं।

सीडीएम


संक्षिप्त नाम सीडीएम सामग्री डिक्रिप्शन मॉड्यूल के लिए है। यह सॉफ्टवेयर या हार्डवेयर का कुछ टुकड़ा है जो कई तरीकों से काम कर सकता है:

  • वीडियो को डिक्रिप्ट करें, जिसके बाद इसे ब्राउज़र में <वीडियो /> टैग का उपयोग करके प्रदान किया जाता है।
  • डिक्रिप्ट करें और वीडियो को डीकोड करें, और फिर वीडियो के कच्चे फ़्रेम को प्लेबैक के लिए ब्राउज़र में स्थानांतरित करें।
  • वीडियो को डिक्रिप्ट और डिकोड करें, और फिर GPU का उपयोग करके प्लेबैक के लिए वीडियो के कच्चे फ़्रेमों को स्थानांतरित करें।

GPU के समर्थन के बावजूद, दूसरा विकल्प सबसे अधिक बार उपयोग किया जाता है (कम से कम जब यह क्रोम और फ़ायरफ़ॉक्स की बात आती है)।

ब्राउज़र में डिकोडिंग और डिकोडिंग लेयर्स


तो यह सब एक साथ कैसे काम करता है? इसे समझने के लिए, ब्राउज़र में डिकोडिंग और डिक्रिप्शन परतों को देखें। वे में विभाजित हैं:

  • जावास्क्रिप्ट एप्लिकेशन - यह कंप्यूटर को बताता है कि मैं कौन सा वीडियो देखने जा रहा हूं।
  • एक ब्राउज़र एक खिलाड़ी है जो वीडियो सामग्री निभाता है।
  • सामग्री डिक्रिप्शन मॉड्यूल।
  • डिजिटल अधिकार प्रबंधन वीडियो डिकोडिंग के बारे में है (मैं बेहतर अंकन के साथ नहीं आ सका, इसलिए मैंने इसे कहा)।
  • विश्वसनीय रनटाइम।
  • इस स्थिति में, पहले दो घटक एक DRM प्लेयर हैं, सामग्री डिक्रिप्शन मॉड्यूल एक DRM क्लाइंट है, और अंतिम दो घटक DRM कोर हैं।




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



हम एक उदाहरण के रूप में नेटफ्लिक्स का उपयोग करेंगे। मैंने डिबगिंग ऐप लिखा है।

मैंने कहां से शुरू किया, मुझे लगता है कि, आप में से प्रत्येक शुरू होगा: मैंने उन अनुरोधों को देखा, जो मैं वीडियो शुरू करते समय नेटफ्लिक्स करता है, और मैंने बड़ी संख्या में रिकॉर्डिंग देखी।



हालांकि, यदि आप केवल उन लोगों को छोड़ते हैं जो वास्तव में वीडियो चलाने के लिए आवश्यक हैं, तो यह पता चलता है कि उनमें से केवल तीन हैं: प्रकट, लाइसेंस और वीडियो का पहला टुकड़ा।



नेटफ्लिक्स प्लेयर जावास्क्रिप्ट में लिखा गया है और इसमें कोड की 76,000 से अधिक लाइनें हैं, और निश्चित रूप से, मैं इसे पूरी तरह से पार्स नहीं कर सकता। लेकिन मैं मुख्य भागों को दिखाना चाहूंगा जो संरक्षित वीडियो चलाने के लिए आवश्यक हैं।

हम टेम्पलेट के साथ शुरू करेंगे:



ईएमई


लेकिन इससे पहले कि हम कार्यों में तल्लीन हों, हमें एक और तकनीक - EME (एन्क्रिप्टेड मीडिया एक्सटेंशन, एन्क्रिप्टेड मीडिया एक्सटेंशन) से परिचित होने की आवश्यकता है। यह तकनीक डिक्रिप्शन और डिकोडिंग नहीं करती है, यह सिर्फ एक ब्राउज़र एपीआई है। ईएमई सीडीएम के लिए एक इंटरफेस के रूप में कार्य करता है, कुंजीसिस्टम के लिए, एक लाइसेंस वाले सर्वर के लिए, और एक सर्वर के लिए जहां सामग्री संग्रहीत है।

तो चलिए getKeySystemConfig से शुरुआत करते हैं।



यह ध्यान में रखना चाहिए कि यह प्रदाता पर निर्भर करता है, इसलिए जो कॉन्फ़िगरेशन मैं यहां प्रस्तुत करता हूं वह नेटफ्लिक्स के लिए काम करता है, लेकिन अमेज़ॅन के लिए काम नहीं करता है, कहते हैं।

इस कॉन्फिगरेशन में, हमें बैकेंड सिस्टम को बताना होगा कि हम कितने विश्वसनीय रनटाइम दे सकते हैं। यह सुरक्षित हार्डवेयर डिकोडिंग या सुरक्षित सॉफ्टवेयर डिकोडिंग हो सकता है। यानी हम सिस्टम को बता रहे हैं कि प्लेबैक के लिए कौन सा हार्डवेयर और सॉफ्टवेयर इस्तेमाल किया जाएगा। और वह सामग्री की गुणवत्ता निर्धारित करेगा।



कॉन्फ़िगरेशन कॉन्फ़िगर होने के बाद, एक प्रारंभिक MediaKeySystem बनाना देखें।



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



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



जब यह किया जाता है, तो हमें वीडियो के मूल तत्व की ओर मुड़ना चाहिए और कहें: “ठीक है, यह एक महत्वपूर्ण प्रणाली है जिसका हम उपयोग करना चाहते हैं, और यह हैलो वीडियो टैग है। हमें आप एकजुट करें। ”



और यहां अंतिम फ़ंक्शन है जिसे आपको वीडियो सिस्टम को कॉन्फ़िगर करने की आवश्यकता है।



यह एक DRM सत्र, या MediaKeySession है। यह सिर्फ डेटा है जो प्रदाता से डिक्रिप्शन मॉड्यूल तक जाता है जो उनके साथ अनुरोधों पर हस्ताक्षर करता है। यह डेटा भी सादा पाठ है, जो नेटफ्लिक्स प्लेयर फ़ाइल में कई फ़ंक्शन के पीछे छिपा हुआ है, जहाँ से मैंने इसे कॉपी किया था।



जब हम क्रिएट कहते हैं। MediaKeys ऑब्जेक्ट पर सेशन, हमें यह बताने की आवश्यकता है कि हम किस वीडियो का समर्थन करते हैं। इस मामले में, यह mp4 है। यह हमें हमारे सीडीएम सिस्टम के साथ संदेश के संदर्भ में वापस लाता है। हमें प्रत्येक फॉर्म में आधार 64 सर्टिफिकेट को लागू करने के लिए नेटफ्लिक्स की भी आवश्यकता है, लेकिन क्रिएट सेशन में यह सभी कॉन्फिगरेशन फिर से डीआरएम सिस्टम पर निर्भर करता है।



नीचे अंतिम कार्य - keySession.generateRequest पृष्ठभूमि में एक लाइसेंस अनुरोध बनाता है। या सीडीएम पृष्ठभूमि में एक लाइसेंस अनुरोध का निर्माण कर रहा है। दूसरे शब्दों में, यह कच्चा बाइनरी डेटा है जिसे हमें बदले में एक वैध लाइसेंस प्राप्त करने के लिए लाइसेंस प्राप्त सर्वर को भेजना होगा।



यहाँ cenc ब्याज की है। यह एक आईएसओ एन्क्रिप्शन मानक है जो mp4 वीडियो के लिए सुरक्षा योजना को परिभाषित करता है। WebM में, इसे अलग तरह से कहा जाता है, लेकिन फ़ंक्शन समान कार्य करता है।

handleMessage EventListener इंटरफ़ेस है जिसे हमने कॉन्फ़िगर किया है। जब यह ईवेंट keySession में संदेश ईवेंट द्वारा उठाया जाता है, तो हम जानते हैं कि हम सर्वर से लाइसेंस प्राप्त करने के लिए तैयार हैं।



और इस कॉलबैक में हमें केवल एक लाइसेंस वाले सर्वर का अनुरोध मिलता है जो कुछ बाइनरी डेटा देता है (वे प्रदाता के आधार पर भिन्न भी हो सकते हैं)। हम इस डेटा का उपयोग लाइसेंस को जोड़कर वर्तमान सत्र को अपडेट करने के लिए करते हैं। यही है, जैसे ही हमें सर्वर से वैध लाइसेंस मिला, हमारे सीडीएम को पता है कि हम वीडियो को डीकोड और डिक्रिप्ट कर सकते हैं।



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



लेकिन ध्यान दें कि हमने अभी तक वीडियो का एक सेकंड भी नहीं खोया है, और भविष्य में कुछ वीडियो चलाने में सक्षम होने के लिए हम सभी को ऐसा करने की आवश्यकता है।

एमएसई


और एक और तकनीक जिस पर हमें शोध करने की आवश्यकता है, वह है MSE (मीडिया स्रोत एक्सटेंशन)। उन्हें ईएमई (एनक्रिप्टेड मीडिया एक्सटेंशन्स) की आधी बहन कहा जा सकता है। यह भी एक ब्राउज़र एपीआई है, और इसका DRM से कोई लेना-देना नहीं है। मैं इसे एक प्रोग्रामिंग इंटरफ़ेस के रूप में < Video/ > Src में देखता हूं। इसका उपयोग करके, आप जावास्क्रिप्ट में बाइनरी स्ट्रीम बना सकते हैं और वीडियो टुकड़े को < Video/ > तत्व पर लागू कर सकते हैं। इस प्रकार, इसके लिए धन्यवाद, < Video/ > टैग का स्रोत गतिशील हो जाता है।

इसलिए, हम मल्टीमीडिया स्रोतों के लिए एक्सटेंशन का उपयोग कर सकते हैं, वीडियो को त्वरित और एक्सेस कर सकते हैं, और फिर भागों में वीडियो टुकड़े डाउनलोड कर सकते हैं और उन्हें < Video/ > टैग पर लागू कर सकते हैं।



मुद्दा यह है कि जब आप दो घंटे का वीडियो देखते हैं, तो आप तब तक इंतजार नहीं करना चाहते जब तक कि यह पूरी तरह से लोड न हो जाए। इसके बजाय, आप इसे लगभग 30 सेकंड से 2 मिनट के आकार में छोटे टुकड़ों में काटते हैं और उन्हें एक बार में < Video/ > तत्व पर लागू करते हैं।

एक बार जब हमारा MediaSource बफर तैयार हो जाता है और < Video/ > तत्व से जुड़ा होता है, तो हम एक SourceBuffer जोड़ सकते हैं। हमें उसे फिर से बताना होगा कि हम किस वीडियो प्रारूप और कौन से कोडेक्स का उपयोग करते हैं, और फिर इसे बनाया जाएगा।



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



तो यह लगभग अंतिम चरण है जो हमें करना चाहिए। आपके पास एक वितरण नेटवर्क है, आपके पास टुकड़े हैं, और फिर ब्राउज़र एन्क्रिप्टेड और संकुचित टुकड़ों को सीडीएम में भेजता है, जहां डिक्रिप्शन और संभवतः, डिकोडिंग किया जाता है। फिर डिक्रिप्ट और असम्पीडित टुकड़े को ब्राउज़र में वापस भेज दिया जाता है, जहां उन्हें कल्पना और प्रदर्शित किया जाता है।



प्रकट


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



एमपीईजी डैश


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

यह गैलेक्सी के रखवालों के लिए घोषणापत्र जैसा दिखता है। इसमें हम देख सकते हैं कि अलग-अलग डाउनलोड गति से लोग अलग-अलग गुणवत्ता वाले वीडियो प्राप्त करेंगे, साथ ही इस तथ्य के साथ कि श्रवण दोष वाले लोगों के लिए ऑडियो ट्रैक हैं। यह सबटाइटल्स को भी मंत्र देता है।



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



फिर से मजबूती भी है, जो कहती है: यह टुकड़ा केवल तभी खो सकता है जब आपका सिस्टम आवश्यकताओं को पूरा करता है। इस मामले में, यह हार्डवेयर डिकोडिंग है - हार्डवेयर सिक्योर कोडेक।



वीडियो के एक ही हिस्से के लिए, आप विभिन्न प्रस्तावों के साथ किसी भी टुकड़े का निर्धारण कर सकते हैं।



और फिर आपको टुकड़ा लोड करने के लिए URL मिलता है, और रेंज पैरामीटर मिलीसेकंड में मानों की श्रेणी दिखाता है।



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



सामान्य तौर पर, यह सब है। ऊपर कहा गया था कि अमेज़ॅन, स्काई और अन्य प्लेटफार्मों से वीडियो देखने और लगभग किसी भी प्रदाता से वीडियो देखने के लिए एक ओपन सोर्स प्लेयर विकसित करने के लिए पर्याप्त है।

एम एस एल


नेटफ्लिक्स ने ब्राउज़र और सर्वर के बीच अतिरिक्त संदेश एन्क्रिप्शन को जोड़ने के लायक माना। उन्होंने इसे "संदेश सुरक्षा परत," संदेश सुरक्षा परत या MSL कहा। यह सीधे वीडियो के साथ कुछ भी नहीं करता है, यह एन्क्रिप्शन की सिर्फ एक अतिरिक्त परत है। MSL को लागू करने का एक कारण यह है कि HTTPS पर्याप्त सुरक्षित नहीं है। दूसरी ओर MSL , ओपन सोर्स है, इसलिए आप हमेशा देख सकते हैं कि यह कैसे काम करता है। यहां मैं इस विषय में नहीं जा रहा हूं, और यदि आप रुचि रखते हैं, तो आप हमेशा इस बारे में जानकारी पा सकते हैं कि नेटफ्लिक्स अपने ब्लॉग में एमएसएल क्यों करता है। GitHub के जावा में इसके कार्यान्वयन और कामकाजी कार्यान्वयन पर विस्तृत प्रलेखन है।

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

और फिर से "ब्लैक बॉक्स"


तो, आपने देखा कि हमें यह सब लागू करने के लिए क्या चाहिए, और मैंने कितनी बार सीडीएम का उल्लेख किया - Google से डाउनलोड किया गया "ब्लैक बॉक्स"। इस प्रकार, हमने फिर से वीडियो को "ब्लैक बॉक्स" पर लौटा दिया। सुंदर <वीडियो /> तत्व फिर से हमसे छिपा हुआ है। हमने तृतीय-पक्ष सॉफ़्टवेयर जोड़ा है जो हमारी सहायता करता है, लेकिन जो उसी समय बंद है और जिसे हम प्रबंधित नहीं कर सकते हैं। यह बहुत सी असंगत बातें कर सकता है: ट्रैकिंग, एनालिटिक्स, डेटा भेजना ...



इस बारे में टिम बर्नर्स ली ने यहां कहा है: "तो, सामान्य तौर पर, EME को अपेक्षाकृत सुरक्षित ऑनलाइन वातावरण के रूप में बनाए रखना महत्वपूर्ण है, जहां आप फिल्में देख सकते हैं, साथ ही सबसे सुविधाजनक और एक है जो इसे मानवता के परस्पर विचार विमर्श का हिस्सा बनाता है।"

लेकिन इस बारे में अन्य राय हैं। विशेष रूप से, इलेक्ट्रॉनिक फ्रंटियर्स फाउंडेशन से, जो DRM के आगमन से पहले W3C का सदस्य था। यहाँ वे कहते हैं: “2013 में, EFF यह जानकर निराश था कि W3C ने EME - एन्क्रिप्टेड मीडिया एक्सटेंशन के मानकीकरण प्रोजेक्ट को संभाला है। वास्तव में, हम एक एपीआई के बारे में बात कर रहे हैं जिसका एकमात्र कार्य ब्राउजर इकोसिस्टम में अग्रणी भूमिका के साथ DRM प्रदान करना था। हम यह सुनिश्चित करने के लिए लड़ते रहेंगे कि इंटरनेट मुक्त और खुला हो। "हम डीआरएम को विषाक्त बनाने वाले कानूनों को निरस्त करने के लिए अमेरिकी सरकार पर मुकदमा करना जारी रखेंगे, और हम वैश्विक कानून के स्तर पर लड़ते रहेंगे।"

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

, 24-25 , HolyJS 2018 Moscow , «The Universal Serial Web» : WebUSB, USB- . -, .

PS 1- . , — 50% .

Source: https://habr.com/ru/post/hi426727/


All Articles