क्या प्रगतिशील HTTP लाइव वीडियो प्रदान करने के लिए HLS / DASH / RTMP का एक व्यवहार्य विकल्प है?


16

मैं एक ऐसी वेबसाइट पर काम कर रहा हूं, जिसमें उपयोगकर्ताओं के लिए लाइव वीडियो स्ट्रीम करने की आवश्यकता है, और जैसे कि मुझे अपने सिर को वर्तमान ब्राउज़र-आधारित वीडियो-स्ट्रीमिंग तकनीक की क्षमा अवस्था के आसपास प्राप्त करना है। वर्तमान में लाइव स्ट्रीमिंग के लिए सबसे लोकप्रिय समाधान में संगतता मुद्दे हैं; RTMP के लिए Flash की आवश्यकता होती है, HLS केवल Android के लिए Safari और Chrome पर मूल रूप से समर्थित है, DASH को कहीं भी मूल रूप से समर्थित नहीं है, और डैश का उपयोग करने के लिए Media Source एक्सटेंशन की आवश्यकता होती है , जो अभी तक व्यापक रूप से समर्थित नहीं हैं।

यह एक प्रश्न है जो मुझे स्पष्ट लगता है: क्या HLS, RTMP और DASH जैसे प्रोटोकॉल के विकल्प के रूप में सरल प्रगतिशील डाउनलोड का उपयोग करना संभव है जो या तो ब्राउज़र समर्थन या प्लगइन्स की आवश्यकता है?

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

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

क्यों? क्या कोई मौलिक सीमा है जो मैं नहीं देख रहा हूँ जिससे यह असंभव हो सकता है कि एक वीडियो फ़ाइल को MP4 की तरह प्रगतिशील डाउनलोड के माध्यम से स्ट्रीम किया जाए क्योंकि यह उत्पन्न हो रहा है, और <video>इसे डाउनलोड करने के साथ ही एक तत्व में चलाएं ?


क्या आप अपने पृष्ठ के लिए क्रॉस ब्राउज़र HLS समर्थन जोड़ने के लिए HLS जावास्क्रिप्ट लाइब्रेरी (जैसे, hls.js यहाँ: github.com/video-dev/hls.js/tree/master ) का उपयोग नहीं कर सकते थे ? मुझे लगता है कि यह तब मौजूद नहीं था जब आपने मूल रूप से यह प्रश्न पूछा था ... लेकिन, यह अब होता है। :)
stuckj

जवाबों:


3

आपका प्रश्न मान्य है और सैद्धांतिक रूप से मुझे लगता है कि आप लाइव वीडियो स्ट्रीमिंग के लिए प्रगतिशील डाउनलोड का उपयोग कर सकते हैं । वास्तव में YouTube आदि जैसे बहुत सारे ऑनलाइन स्ट्रीमिंग वीडियो पहले से ही HTTP का उपयोग करते हैं। मैं मान रहा हूं कि आप LIVE स्ट्रीमिंग के बारे में सख्ती से बात कर रहे हैं, न कि सिर्फ स्ट्रीमिंग के बारे में।

आपको लाइव स्ट्रीमिंग उपयोग के मामलों को लागू करना होगा, हालांकि, स्वयं! जो अन्यथा स्ट्रीमिंग प्रोटोकॉल (RTMP आदि) स्वयं करते हैं। इन प्रोटोकॉल और वास्तुकला को पसंद करने के कुछ कारण यहां दिए गए हैं:

1. परिवर्तनीय बिट दर

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

विकिपीडिया के अनुसार

यह वास्तविक समय में उपयोगकर्ता की बैंडविड्थ और सीपीयू क्षमता का पता लगाने और तदनुसार वीडियो स्ट्रीम की गुणवत्ता को समायोजित करके काम करता है

2. लाइव सामग्री

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

3. मांगने में अक्षम

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

4. लगातार डिस्कनेक्ट / अविश्वसनीय नेटवर्क

मैं इस बिंदु के बारे में थोड़ा स्पष्ट नहीं हूं, लेकिन मुझे पता है कि एक बार आने वाली HTTP डाउनलोड को डिस्कनेक्ट कर दिया जाता है, तो दूसरे हैंडशेक (यहां तक ​​कि keep-alive) को स्थापित करने में कुछ समय लग सकता है । लाइव प्रोटोकॉल अगले बिंदु के कारण कनेक्ट और डिस्कनेक्ट करने के लिए बहुत तेज़ हैं ->

5. विलंबता

HTTP टीसीपी पर स्वाभाविक रूप से चलता है जो पैकेट की गारंटीकृत डिलीवरी देता है। इसकी तुलना बहुत सारे प्रोटोकॉल (विशेष रूप से लाइव मल्टीप्लेयर गेमिंग) में उपयोग किए जाने वाले यूडीपी से करें जहां गारंटी पर गति को प्राथमिकता दी जाती है।

अधिक जानकारी के लिए यहां देखें -> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6. सामग्री की नकल

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

अब, HTTP को उपर्युक्त अधिकांश प्रदान करने के लिए मॉडल किया जा सकता है।

आपके द्वारा उल्लिखित Apple का HTTP लाइव स्ट्रीमिंग (HLS) , आप जो हासिल करने की कोशिश कर रहे हैं, उसके करीब आता है।

और इस क्षेत्र में सक्रिय अनुसंधान चल रहा है जैसा कि यहां दिया गया है -> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

मैं और अधिक जानकारी की तलाश में हूं और इस उत्तर को अपडेट करूंगा।


विलंबता को HTTP प्रगतिशील डाउनलोड का उपयोग करने के नुकसान के रूप में उल्लेख करना गलत लगता है क्योंकि प्राथमिक प्रतियोगियों में डैश और एचएलएस शामिल हैं जो कई अनुक्रमिक HTTP अनुरोधों के माध्यम से वीडियो के सेगमेंट वितरित करते हैं। मुझे प्रोटोकॉल के प्रत्येक विवरण के बारे में नहीं पता है, लेकिन मुझे लगता है कि बाद वाले दृष्टिकोण के लिए कम से कम खंड लंबाई का न्यूनतम विलंबता की आवश्यकता होती है, जबकि प्रगतिशील डाउनलोड दृष्टिकोण के साथ कोई सैद्धांतिक न्यूनतम विलंबता नहीं है - कम विलंबता होनी चाहिए एक विज्ञापन प्रगतिशील डाउनलोड दृष्टिकोण की सहूलियत, है ना?
मार्क अमेरी

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

@MarkAmery यदि आप DASH और HLS से तुलना करते हैं, तो हाँ मुझे इसका तुलनीय लगता है। लेकिन, अगर आप इसकी तुलना यूडीपी के कुछ पुराने प्रोटोकॉल से करते हैं तो HTTP हाथ नीचे कर लेता है! यहां तक ​​कि अगर आप बहुत सारे रियलटाइम सिस्टम देखते हैं, तो आज वेबसैट और एचटीएचडब्ल्यू HTTP का उपयोग करके बनाया गया है, क्योंकि इसके विलंबता के मुद्दे हैं।
गौरव रामानन

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

@MarkAmery जब रियलटाइम और लाइव स्ट्रीमिंग की बात आती है, तो हमें प्रदर्शन पर विचार करना चाहिए, न कि केवल संभावना पर। मैं डीएएसएच में देखूंगा लेकिन मुझे आश्चर्य है कि अगर बेंचमार्क हैं जो स्ट्रीमिंग प्रोटोकॉल और HTTP के बीच प्रदर्शन की तुलना को डिस्कनेक्ट से ठीक कर रहे हैं।
गौरव रामानन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.