Adobe और OpenSource से HTTP डायनामिक स्ट्रीमिंग के आधार पर वीडियो वितरण प्रणाली का निर्माण

परियोजना के हिस्से के रूप में, हमारे ग्राहकों में से एक ने एक बार फिर इंटरनेट पर वीडियो को परिवर्तित / संग्रहीत / वितरित करने के लिए एक प्रणाली बनाने के कार्य का सामना किया। एक ऐसा विशिष्ट कार्य केवल पेशेवर और यूजीसी सामग्री के साथ अपना खुद का छोटा (या इतना छोटा नहीं) "ट्यूब" बनाना है।



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



हमारी राय में सबसे दिलचस्प हालिया रुझान हैं:

• विभिन्न उपकरणों से एक वीडियो साइट देखने की क्षमता,
• अनुकूली http स्ट्रीमिंग तकनीक

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



यह सब तथाकथित में फिट बैठता है। "तीन स्क्रीन" की अवधारणा जिससे लोग निकट भविष्य में वीडियो (और आमतौर पर इंटरनेट सामग्री) का उपभोग करेंगे - सड़क पर एक मोबाइल फोन (टैबलेट), कार्यालय में एक पीसी, घर के रहने वाले कमरे में एक टीवी।



मैं अनुकूली HTTP स्ट्रीमिंग तकनीक के बारे में अधिक विस्तार से बात करना चाहूंगा, जो इस लेख का विषय है।



इंटरनेट वीडियो वितरण के लिए विशेष रूप से वास्तविक समय में स्वाभाविक रूप से खराब है। एक तरफ, हम एक चिकनी निरंतर वीडियो स्ट्रीम देखना चाहते हैं, दूसरी तरफ, समय के साथ फ्लोटिंग विशेषताओं के साथ हमारे पास एक अस्थिर संबंध है और इससे निपटने के दो तरीके हैं - विलंब (बफर) या स्ट्रीम बिट दर अनुकूलन में वृद्धि।



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



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



व्यवहार में, इसका अर्थ है कि हम न केवल एक अस्थिर / कमजोर चैनल वाले उपयोगकर्ताओं की सेवा में, क्षेत्रों में कहीं गहरे में, बल्कि वाईफाई नेटवर्क के उपयोगकर्ताओं के उपयोगकर्ताओं के लिए भी, जो घर में कई उपयोगकर्ताओं के लिए एक कनेक्शन सामान्य है, आदि के साथ सेवा की धारणा में सुधार कर सकते हैं। .D। एक समर्पित उच्च-गुणवत्ता वाले चैनल वाले उपयोगकर्ताओं के लिए, यह तकनीक बस अपने चैनल की गति को स्वचालित रूप से निर्धारित करेगी और एक उपयुक्त बिटरेट में वीडियो देगी - अर्थात अंत उपयोगकर्ता को अब यह जानने की जरूरत नहीं है कि 360p, 240p या SD, HD, आदि क्या है। - सब कुछ अपने आप होता है।



इन सभी लाभों के लिए भुगतान करने के लिए 3 चीजें हैं -

• स्ट्रीमिंग प्रक्रिया को जटिल बनाना,
• अतिरिक्त कोडिंग लागत,
• अतिरिक्त भंडारण लागत।

इस समय पहले कारण को ध्यान में नहीं रखा जाना चाहिए, क्योंकि इस तरह के सिस्टम के निर्माण के लिए पहले से तैयार ओपन-सोर्स ईंटें हैं, जिनकी मैं बाद में चर्चा करूंगा।



दूसरे और तीसरे कारण, निश्चित रूप से, महत्वपूर्ण हैं, लेकिन यहां साइट डेवलपर्स को खुद तय करना होगा कि क्या उनके उपयोगकर्ता इन अतिरिक्त लागतों के लायक हैं।



फिलहाल, अनुकूली मल्टी-बिटरेट स्ट्रीमिंग तकनीक के कम से कम तीन कार्यान्वयन हैं जो मुझे पता है:

• IPhone / iPad के लिए Apple HTTP अनुकूली स्ट्रीमिंग,
• सिल्वरलाइट के लिए Microsoft चिकनी स्ट्रीमिंग,
• एडोब डायनामिक स्ट्रीमिंग फ्लैश के लिए।

वीडियो साइटों को विकसित करने के अभ्यास के लिए, सबसे महत्वपूर्ण, निश्चित रूप से, Adobe से कार्यान्वयन है, क्योंकि Apple HTTP एडेप्टिव स्ट्रीमिंग केवल MacOS X के लिए iOS उपकरणों और Safari के लिए काम करती है (हालाँकि मुझे हाल ही में एक STB दिखाया गया था जिसमें यह प्रोटोकॉल लागू है), और Silverlight, चलो बस कहना है, जब तक मुझे फ्लैश जैसी लोकप्रियता नहीं मिली।



Adobe ने कुछ समय के लिए rtmp प्रोटोकॉल के तहत डायनामिक स्ट्रीमिंग को लागू किया और केवल अपेक्षाकृत हाल ही में (फ्लैश 10.1 के आगमन के साथ) HTTP स्ट्रीमिंग का उपयोग करना संभव हो गया। यह एक बहुत ही महत्वपूर्ण कदम है, क्योंकि पहले, गतिशील स्ट्रीमिंग का उपयोग करने के लिए, आपको एक विशेष स्ट्रीमिंग सर्वर की आवश्यकता थी, अब अधिकांश कार्य क्लाइंट को स्थानांतरित कर दिया गया है, और सर्वर समर्थन सामान्य HTTP स्टेटिक्स तक सही किया जाता है।



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







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



एक प्रोग्रामिंग दृष्टिकोण से, Adobe के लोगों ने HTTP डायनेमिक स्ट्रीमिंग का समर्थन करने के लिए एक सरल कार्य किया - NetStream ऑब्जेक्ट पर appendBytes विधि दिखाई दी। इनपुट सरणी का प्रारूप FLV प्रारूप में बाइट स्ट्रीम है। वास्तव में, यह बाइट स्ट्रीम खेलना संभव बनाता है, और इसके वितरण के मुद्दे एक अलग कार्य है। उदाहरण के लिए, आप इन बाइट्स को HTTP स्लाइस के माध्यम से वितरित कर सकते हैं और आपको HTTP स्ट्रीमिंग मिल सकती है।



Apple और Microsoft सिस्टम अपने "ब्लैक बॉक्स" के अंदर एक डिलीवरी और प्लेबैक सिस्टम लागू करते हैं, और Adobe सिस्टम को अपने दम पर प्रोग्राम करना संभव बनाता है। उन्होंने अपने ओपन सोर्स मीडिया फ्रेमवर्क के हिस्से के रूप में इस तरह की प्रणाली का एक खुला कार्यान्वयन भी किया। OSMF बेस कक्षाओं का एक सेट है जो ActionScript3 में वीडियो खिलाड़ियों को लिखने को सरल बनाता है, जिसमें अन्य बातों के अलावा, गतिशील स्ट्रीमिंग के लिए HTTP समर्थन का कार्यान्वयन शामिल है। इसके अलावा, इस प्रोटोकॉल और कार्यान्वयन विवरण के विनिर्देशों का खुलासा करने की कोशिश कर रहा है। आप इसे यहाँ और यहाँ देख सकते हैं। क्या आप इससे पहले कल्पना कर सकते हैं कि जब फ्लैश का कोई प्रतियोगी नहीं था और उनका भविष्य पूरी तरह से बादल रहित था?



इसलिए, समस्या के बयान पर वापस - हम वीडियो होस्टिंग करना चाहते हैं, डेस्कटॉप संस्करण फ्लैश और HTTP अनुकूली स्ट्रीमिंग तकनीक का उपयोग करेगा।



वीडियो को परिवर्तित करने और वितरित करने के लिए ऐसी प्रणाली को कैसे इकट्ठा किया जाए?



हम mp4, कोडेक्स - x264 और faac, टूल्स - ffmpeg, mencoder में एनकोड करेंगे। अगर हम मुफ्त विकल्प हैं तो हम वास्तव में वाणिज्यिक सॉफ्टवेयर पसंद नहीं करते हैं।



फिलहाल, मैं इस तकनीक के निम्नलिखित कार्यान्वयन से अवगत हूं:

• वाणिज्यिक सॉफ्टवेयर। Adobe और Wowza के वाणिज्यिक सर्वरों में इस तकनीक का कार्यान्वयन है, OSMF का उपयोग खिलाड़ी के लिए आधार के रूप में किया जा सकता है। विकल्प शायद अच्छा है, लेकिन महंगा है।
• एडोब से ही एक स्वतंत्र लेकिन बंद कार्यान्वयन है। यह एक निश्चित f4f प्रारूप में स्रोत फ़ाइलों का पुनर्खरीदकर्ता है और अपाचे के लिए एक मॉड्यूल है जो इस तरह की मरम्मत की गई फ़ाइलों के साथ काम करता है। विपक्ष - मैं ffmpeg द्वारा बनाई गई mp4 फाइलों के साथ काम नहीं कर सकता, क्योंकि स्रोत बंद हैं, यह समझने के लिए कि समस्या क्यों है।
• कोडशॉप से ​​यूएसपी। पेशेवरों - सर्वर भाग का एक अद्भुत खुला कार्यान्वयन, विपक्ष - ग्राहक बंद है और वास्तव में, सॉफ्टवेयर वाणिज्यिक है, यद्यपि ओपनसोर्स। यदि तकनीक का उपयोग करने वाली साइट वाणिज्यिक है, तो वह विज्ञापन प्रदर्शित करती है या देखने का शुल्क लेती है, आपको लाइसेंस खरीदने की आवश्यकता होती है।

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



परिणाम OpenHttpStreamer परियोजना है, जिसे हमने LGPL के तहत OpenSource में डालने का फैसला किया है।

आधिकारिक परियोजना पृष्ठ - http://inventos.ru/OpenHttpStreamer

GitHub पर स्रोत उपलब्ध हैं - https://github.com/inventos/OpenHttpStreamer

हमने उबंटू 10.10, फेडोरा 12, डेबियन (निचोड़) के तहत निर्माण करने की कोशिश की। सुविधाओं में से - आपको स्कैन्स की आवश्यकता है, जी ++ संस्करण 4.3.0 और उच्चतर और बढ़ावा> = 1.39।



कैसे उपयोग करें:

$ git clone https://github.com/inventos/OpenHttpStreamer.git

$ cd OpenHttpStreamer/mp4frag

$ scons configure && scons

$ sudo scons install







यदि सब कुछ / usr / स्थानीय / बिन / mp4frag में अच्छी तरह से चला गया तो स्थैतिक टुकड़े बनाने के लिए एक संकलित उपयोगिता होगी



$ mp4frag

Allowed options:

--help produce help message

--src arg source mp4 file name

--video_id arg (=some_video) video id for manifest file

--manifest arg (=manifest.f4m) manifest file name

--fragmentduration arg (=3000) single fragment duration, ms

--template make template files instead of full fragments

--nofragments make manifest only







किसी भी वीडियो को दो गुणों में एन्कोड करें ffmpeg - 400 और 700 kbit / s (लगभग)



$ ffmpeg -y -i test.mpg -acodec libfaac -ac 2 -ab 96k -ar 44100 -vcodec libx264 -vpre medium -g 100 -keyint_min 50 -b 300k -bt 300k -threads 2 test-q1.mp4

$ ffmpeg -y -i test.mpg -acodec libfaac -ac 2 -ab 96k -ar 44100 -vcodec libx264 -vpre medium -g 100 -keyint_min 50 -b 600k -bt 600k -threads 2 test-q2.mp4







हमें दो mp4 फाइलें मिलीं- test-q1.mp4 और test-q2.mp4, जिनसे हम स्थैतिक अंश उत्पन्न करते हैं:



$ mp4frag --src test-q1.mp4 --src test-q2.mp4 --manifest=test.f4m







कार्य का परिणाम एक फ़ाइल विवरणक ("प्रकट") है - test.f4m और फ़ोल्डर्स 0/1 और 1/1 में स्थिर स्निपेट फ़ाइलें



हम किसी भी वेब सर्वर के DocRoot के तहत test.f4m 0/1 / को फैलाते हैं जो स्थैतिक दे सकता है, और हमें बस इंजन के रूप में OSMF का उपयोग करके फ्लैश पर एक साधारण खिलाड़ी लिखना होगा या तैयार खिलाड़ी लेना होगा।



एक त्वरित परीक्षण के लिए, आप OSMF प्लेयर की हमारी असेंबली का उपयोग कर सकते हैं।

इसके लिए

1. हमारे सर्वर के DocRoot (test.f4m के समान स्थान पर) के तहत हम ऐसे crossdomain.xml डालते हैं:

<?xml version="1.0"?>

<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>

<allow-access-from domain="inventos.ru" />

</cross-domain-policy>







2. लिंक http://inventos.ru/OpenHttpStreamer?url=http://your_http_host/test.f4m पर ब्राउज़र पर जाएं





हमेशा की तरह, अगर कुछ काम नहीं करता है, तो हम अपने सर्वर के लॉग को देखते हैं - क्या खिलाड़ी के पास से किसी भी तरह के कॉल के लिए crossdomain.xml, test.f4m, सेगमेंट की फाइलें हैं। यह जांचने के लिए सुविधाजनक है कि क्या सब कुछ सही है - आवश्यक पते खुद को "खींचने" के लिए -

wget -O - -S «http://your_http_host/test.f4m»

wget -O - -S «http://your_http_host/1/Seg1Frag1»







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



हमें अपने मूल (mp4 को ffmpeg में परिवर्तित करने के बाद) फ़ॉर्म को संग्रहीत करने के लिए गतिशील पीढ़ी मॉड्यूल की आवश्यकता है, क्योंकि यह अन्य उद्देश्यों (अन्य प्लेटफार्मों पर स्ट्रीमिंग) के लिए उपयुक्त काफी सार्वभौमिक प्रारूप है। एक दिलचस्प विकल्प है - खंडित mp4 का उपयोग करना, लेकिन यह कम सार्वभौमिक है।



हम एक आसान तरीका लेकर आए हैं - आवश्यक अंशों के त्वरित उपयोग के लिए सूचकांक mp4 और सामग्री के बगल में एक अलग फ़ाइल में सूचकांक डाल दिया। अनुक्रमणिका का आकार केवल स्रोत फ़ाइलों का लगभग 1% होगा। इस तथ्य के कारण कि स्रोत mp4 में वांछित mdat टुकड़ा तक त्वरित पहुंच प्राप्त करने के बाद भी, हमें अभी भी flv हेडर (OSMF कार्यान्वयन की एक विशेषता) जोड़कर डेटा को रिमिक्स करने की आवश्यकता है, हम स्टैटिक्स की तुलना में प्रदर्शन में खो देते हैं। हालांकि, तेज वेब-कैश और कैशिंग प्रतिक्रियाओं के माध्यम से इस मॉड्यूल के लिए अनुरोधों को प्राप्त करके, हम उच्च प्रदर्शन और महान बहुमुखी प्रतिभा दोनों प्राप्त करते हैं।