स्ट्रीमिंग एचएलएस। एचएलएस प्रोटोकॉल का उपयोग कब करें

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

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

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

एचएलएस कार्य सिद्धांत

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

आईपीटीवी सेट टॉप बॉक्स

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

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

सामान्य तौर पर, कई अज्ञात के साथ एक समीकरण प्राप्त होता है। प्रक्रिया की गतिशीलता यहां महत्वपूर्ण है - उद्योग सामान्य रूप से कहां जा रहा है? क्या होगा अगर मैं समर्थन प्रौद्योगिकी में निवेश करता हूं, और यह एक साल में मर जाएगा, क्योंकि यह पहले ही हो चुका है। या मैं एक आधुनिक तकनीक पर दांव लगाऊंगा, लेकिन कोई इसका समर्थन नहीं करता है?

हमने यह मूल्यांकन करने का निर्णय लिया कि समय के साथ विभिन्न प्रोटोकॉल का हिस्सा कैसे बदल गया - पूरी प्रक्रिया को गतिकी में देखने के लिए। डेटा पिछले साल से लिया गया था।

प्रारंभिक आंकड़े

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

हमने एक छोटी सी रिपोर्ट बनाई है जहां आप एक तिथि सीमा का चयन कर सकते हैं और विभिन्न प्रोटोकॉल के माध्यम से वीडियो दृश्यों की संख्या पर एक ग्राफ के साथ डेटा प्राप्त कर सकते हैं।

रिपोर्ट सर्वर पर डेटा प्रदान करती है:

Wowza स्ट्रीमिंग इंजन 2.2 से नवीनतम 4.x तक सभी संस्करणों में; सबसे - 3.x।
फुर्तीला स्ट्रीमर जो एचएलएस, स्मूथ, एचडीएस और प्रगतिशील डाउनलोड के साथ काम करता है, हमारा विकास है।
विंडोज मीडिया सर्विसेज - वस्तुतः उनमें से कुछ दर्जन हैं, लेकिन वे मौजूद हैं, और हमें उन्हें ध्यान में रखना चाहिए

इस लेखन के समय, सेवा 60 देशों के लगभग 1000 सर्वरों को सेवा प्रदान करती है।

रिपोर्ट समय-समय पर हमारे ब्लॉग पर भी अपडेट की जाती है, यह संबंधित टैग के तहत उपलब्ध है।

जाओ

जून/जुलाई 2014 की रिपोर्ट कुछ इस प्रकार है। से 1.4 बिलियन व्यूजआधे से ज्यादा एचएलएस हैं। दूसरे स्थान पर एक चौथाई व्यूज के साथ RTMP है। RTSP लगभग छठा है। शेष सांख्यिकीय त्रुटि के क्षेत्र में हैं।

एक साल पहले इसी अवधि के लिए क्या हुआ था? स्थिति लगभग एक दर्पण छवि है। RTMP - लगभग दो तिहाई, RTSP और HLS दूसरे और तीसरे स्थान पर हैं। सच है, माप के लिए आधार लगभग 3 गुना कम था - "केवल" 500 मिलियन व्यूज. हमारी सेवा में निश्चित रूप से कम सर्वर भी थे।

आइए इन दो बिंदुओं के बीच चलते हैं।

तो, जून - अगस्त 2014, गर्मी के 3 महीने। 800 मिलियन व्यूज, लेकिन शेयर वही हैं, अगस्त कोई बदलाव नहीं लाया।

सितंबर - नवंबर 2013। एक नया सीजन शुरू हो गया है, एचएलएस ने आरटीएमपी के हिस्से को खत्म करना शुरू कर दिया है। कुल 1.1 बिलियन व्यूज, RTMP के पास कुल का लगभग आधा है, HLS के पास एक चौथाई है।

दिसंबर 2013 - फरवरी 2014। 1.4 बिलियन व्यूज, जिनमें से एचएलएस का हिस्सा 40% से अधिक है। आरटीएमपी और आरटीएमपी तिमाही शेयर के साथ दूसरे और तीसरे स्थान पर हैं। सोची में ओलंपिक ने विचारों की संख्या में वृद्धि की और साथ ही प्रदाताओं को अपने सभी विदेशी या पुराने उपकरणों के साथ सभी ग्राहकों को याद रखने के लिए मजबूर किया जो केवल आरटीएसपी को समझते हैं - इसलिए इस प्रोटोकॉल में उछाल।

जैसा कि अभ्यास ने दिखाया है, आरटीएमपी की तुलना में वीडियो के लिए सबसे अच्छा परिवहन एचएलएस है। इसके कारण:

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

संपूर्ण सर्वर अवसंरचना का सरलीकरण। विचार के आधार पर, वीडियो को पोर्ट 80 के माध्यम से http के माध्यम से टुकड़ों में दिया गया है। स्टैटिक्स को वापस करने के लिए Nginx ही जिम्मेदार हो सकता है। रिटर्निंग स्टैटिक्स (50kB के वीडियो टुकड़े) nginx के लिए एक बहुत ही आसान काम है।

चूंकि टुकड़ों की संख्या स्थिर है, पुराने हटा दिए जाते हैं, नए जोड़े जाते हैं, हार्ड ड्राइव कभी भी ओवरफ्लो नहीं होगी।

प्रसार RTMP की तुलना में अधिक है। H.264 वीडियो एन्कोडिंग के साथ HLS iOS द्वारा समर्थित है और निर्बाध रूप से काम करता है। 1 जुलाई 2014 तक, HLS परिवहन के साथ स्ट्रीमिंग वीडियो कनेक्शन 55%, RTMP - 26%, RTSP - 15% और MPEG-DASH 1% से कम हैं।

अधिकांश मोबाइल उपकरणों, डेस्कटॉप, टैबलेट के लिए सीधे ब्राउज़र से समर्थन।

सिद्धांत रूप में RTSP में प्रसारण की तुलना में बहुत आसान है। चूंकि पुश (स्ट्रीम प्रकाशित करना) या पुल (स्ट्रीम प्राप्त करना) जैसी कोई प्रक्रिया नहीं है।

बहुत अधिक http अनुकूल प्रारूप।

नुकसान निम्नलिखित हैं:

वही, सभी डिवाइस इस प्रारूप का समर्थन नहीं करते हैं। 4.2 से कम के Android संस्करण आधिकारिक तौर पर H.264 कोडेक और परिवहन का समर्थन नहीं करते हैं, लेकिन Android पर, ब्राउज़र के बजाय, आप देखने के लिए किसी तृतीय-पक्ष एप्लिकेशन का उपयोग कर सकते हैं - उदाहरण के लिए, MX प्लेयर

यह सब कैमरे पर निर्भर करता है। यदि कैमरा छोटी गाड़ी है, उदाहरण के लिए Dlink DCS-3010, तो पूरा सिस्टम बहुत बुरी तरह से काम करेगा (ffmpeg लगातार गिर जाता है)। उदाहरण के लिए, कैमरे AXIS M1011-W, HIKVISION DS-2CD2412F-IW ऐसे बंडल में अच्छी तरह से काम करते हैं (बिना किसी शिकायत के एक महीने तक (मैंने अभी इसका परीक्षण नहीं किया है))। केबल रूटिंग भी महत्वपूर्ण है। इस अर्थ में, हम आदर्श विकल्प पर विचार करेंगे।

एचएलएस परिवहन क्या है

h.264 में एन्कोडेड वीडियो स्ट्रीम (वैसे: प्रोफ़ाइल बेसलाइन को एंड्रॉइड डिवाइस द्वारा समझा जाता है), *.ts एक्सटेंशन के साथ टुकड़ों में विभाजित है, उदाहरण के लिए, प्रत्येक 5 सेकंड में, एक प्लेलिस्ट live.m3u8 में बनाई जाती है, जिसमें एक इन टुकड़ों का क्रमिक विवरण। प्लेलिस्ट की लंबाई पूर्व निर्धारित है, उदाहरण के लिए, 10 टुकड़े। जब वीडियो का 11वां भाग दिखाई देता है, तो वीडियो का पहला भाग हटा दिया जाता है, प्लेलिस्ट को फिर से बनाया जाता है। अधिक विवरण डेवलपर की वेबसाइट पर पाया जा सकता है।

सिस्टम के काम करने के लिए, हम कैमरे से छवि को उसी तरह सेट करेंगे जैसे हम इसे साइट पर देखना चाहते हैं, छवि प्रारूप और छवि गुणवत्ता। हम सर्वर पर रिकोड नहीं करेंगे। कैमरा आपको आवश्यक छवि देने के लिए डिज़ाइन किया गया है। कैमरों में आमतौर पर कई प्रोफाइल होते हैं। आप एक प्रोफ़ाइल को H.264 के लिए, HLS के लिए, और दूसरी को MPEG4 के साथ MPEG-DASH के लिए कॉन्फ़िगर कर सकते हैं। आप एक विस्तृत और संकीर्ण इंटरनेट चैनल के लिए भिन्न गुणवत्ता भी सेट कर सकते हैं। अपने लिए सोचो - अपने लिए फैसला करो।

महत्वपूर्ण!कैमरे में एक आउटपुट छवि होनी चाहिए जिसे फिर से एन्कोड करने की आवश्यकता नहीं है।

उच्च भार के लिए संरचनात्मक आरेख

कैमरा (आरटीएसपी) ----->

-----> एक कनेक्शन FFmpeg (rtsp-> hls) -> Nginx (nginx-rtmp-मॉड्यूल) ----->

-----> एक बड़े कैश के साथ एक मध्यवर्ती nginx प्रॉक्सी के लिए एक कनेक्शन =====>

=====> कई JWPlayer(hls) क्लाइंट

हमारा सर्वर ffmpeg के साथ कैमरे से जुड़ता है और nginx hls एप्लिकेशन के साथ रजिस्टर होता है। nginx एक विशिष्ट निर्देशिका में टुकड़े और प्लेलिस्ट बनाता है। फिर यह इन टुकड़ों को प्रॉक्सी सर्वर को भेजता है। क्लाइंट JWPlayer का उपयोग करके प्रॉक्सी सर्वर से जुड़ते हैं।

Nginx एप्लिकेशन सेट करना

आइए nginx-rtmp-module के साथ nginx का निर्माण करें। इस प्रक्रिया को लेख में विस्तार से वर्णित किया गया है।

मान लीजिए कि हमारे पास कई कैमरे हैं, हम उन्हें सीरियल नंबर से विभाजित करेंगे। मैं 2 कैमरों के लिए nginx कॉन्फ़िगरेशन का वर्णन करूंगा। हम स्थानीय कैश में 5 मिनट के लिए स्थिर छवियों को कैश करते हैं, अगर छवि 5 सेकंड के भीतर लोड नहीं होती है, तो हम एक स्थिर स्प्लैश स्क्रीन देते हैं।

# नैनो /etc/nginx/nginx.conf

Nginx कॉन्फ़िगरेशन संपादित करें

उपयोगकर्ता www-डेटा; कार्यकर्ता_प्रोसेस ऑटो; पिड/रन/nginx. पीआईडी; error_log / var / log / nginx / nginx_error। लॉग डीबग; एनवी पथ; ईवेंट (# मल्टी_स्वीकार ऑन;) http (एक्सेस_लॉग / var / लॉग / nginx / एक्सेस। लॉग; एरर_लॉग / var / लॉग / nginx / एरर। लॉग; माइम शामिल करें। प्रकार; डिफॉल्ट_टाइप एप्लिकेशन / ऑक्टेट-स्ट्रीम; सेंडफाइल ऑन; Keepalive_timeout 65 ; proxy_cache_path / var / www / कैश / स्थानीय स्तर = 1: 2 key_zone = nginx_local_cache: 1 मीटर निष्क्रिय = 30 मीटर max_size = 512 मीटर; प्रॉक्सी_टेम्प_पथ / var / www / कैश / स्थानीय / tmp; सर्वर (80 सुनें; # आरटीएमपी स्टेट स्थान / स्थिति ( rtmp_stat सभी ; rtmp_stat_stylesheet stat . xsl ; ) स्थान / स्थिति xsl (# आप stat . xsl को किसी भिन्न स्थान पर ले जा सकते हैं रूट / आदि / nginx ; ) स्थान / ( rtmp_control all ; ) error_page 500 502 503 504 / 50 x .html ;स्थान = / 50 x .html (रूट html;) में कैमरे_एचटीटीपी_लोकेशन .conf शामिल हैं;) सूचित करें_विधि प्राप्त करें; Camera_rtmp_applications शामिल करें। कॉन्फ़; ) )

कैश पथ बनाएं # mkdir /var/www/cache/local कैशे की अनुमति ठीक करें:

# chmod -R 755 /var/www/cache/local # chown -R www-data:www-data /var/www/cache/local`

आइए कैमरों के लिए http स्थान बनाएं:

# नैनो कैमरे_http_locations.conf

प्रकार (अनुप्रयोग / vnd। सेब। mpegurl m3u8; वीडियो / mp2t ts;) # कैमरे से छवि दें 1 - /1/img/ # सभी कैमरों के लिए अलग होते हैं, क्योंकि कैमरा आईपी पते अलग हैं "http://192.168.0.2/GetImage.cgi?CH=1"# कैमरे से छवि दें 2 - /2/img/स्थान / 1 / img / (proxy_cache nginx_local_cache; proxy_cache_key $ request_uri; 1 मीटर की समय सीमा समाप्त हो जाती है; # 1 मिनट के लिए कैश add_header कैश - नियंत्रण सार्वजनिक; # प्रॉक्सी पर कैश करने के लिए proxy_ignore_headers कैश - नियंत्रण; # कैमरा प्रॉक्सी_पास से हेडर हटाने के लिए "http://192.168.0.3/GetImage.cgi?CH=1"; प्रॉक्सी_सेट_हेडर प्राधिकरण "बेसिक"; error_page 502 504 404 @ Fallback_img; ) # प्लेलिस्ट दें - /1/hls/live.m3u8 या /3/hls/live.m3u8 # प्लेलिस्ट प्रॉक्सी पर 10 सेकंड के लिए कैश की जाती हैस्थान ~* / एचएलएस /। * \। m3u8 $ (फिर से लिखें "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 विराम s ; add_header कैश - सार्वजनिक नियंत्रण ; ) # कैमरों से वीडियो का एक टुकड़ा दें - /1/hls/live-12345678.ts या /2/hls/live-12345678.ts # स्थानीय मशीन पर कैशिंग की आवश्यकता नहीं है # टुकड़ा प्रॉक्सी पर 3 मिनट के लिए कैश किया जाता हैस्थान ~* / एचएलएस /। * \। ts $ (फिर से लिखें "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 ब्रेक; रूट / tmp /; 3 मीटर समाप्त हो जाता है; add_header कैश - सार्वजनिक नियंत्रण;) # नामित स्थान अगर कोई छवि नहीं हैस्थान @ Fallback_img (फिर से लिखना (। +) / फ़ॉलबैक। जेपीजी ब्रेक; रूट / आदि / nginx /;)

आइए हमारे कैमरों के लिए एप्लिकेशन के साथ rtmp सर्वर के लिए एक hls कॉन्फ़िगरेशन फ़ाइल बनाएं:

# नैनो कैमरे_rtmp_applications.conf

चंक_साइज 4000; एप्लिकेशन hls_1 (लाइव ऑन; सिंक 10 एमएस; exec_static ffmpeg - i rtsp: //व्यवस्थापक: [ईमेल संरक्षित]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log;एचएलएस चालू; एचएलएस_पथ / टीएमपी / एचएलएस - 1 /; # सर्वर hls_fragment_naming टाइमस्टैम्प पर टुकड़ों को संग्रहीत करने के लिए पथ; # विखंडू के नाम के लिए टाइमस्टैम्प का उपयोग करें) एप्लिकेशन hls_2 (लाइव ऑन; सिंक 10 एमएस; exec_static ffmpeg - i rtsp: //व्यवस्थापक: [ईमेल संरक्षित].0.3:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_2/live 2>>/var/log/nginx/ffmpeg_2.log;एचएलएस चालू; एचएलएस_पथ / टीएमपी / एचएलएस - 2 /; hls_fragment_naming टाइमस्टैम्प; )

/tmp/hls-1/ निर्देशिका की सामग्री

$ एलएस / टीएमपी / एचएलएस - 1 / लाइव - 10458360। टीएस लाइव - 13292010। टीएस लाइव - 16129440। टीएस लाइव - 18963270। टीएस लाइव - 10930050। टीएस लाइव - 13767390। टीएस लाइव - 16602660। टीएस लाइव - 19435050। टीएस लाइव - 11405250. टीएस लाइव - 14239260. टीएस लाइव - 17072820. टीएस लाइव। m3u8 लाइव - 11878560। टीएस लाइव - 14710860। टीएस लाइव - 17544960। टीएस लाइव - 12348630। टीएस लाइव - 15182550। टीएस लाइव - 18020160। टीएस लाइव - 12821760। टीएस लाइव - 15658740। टीएस लाइव - 184 टीएस 2750

उदाहरण live.m3u8 फ़ाइल

#EXTM3U #EXT-X-VERSION:3 #EXT-X-मीडिया-अनुक्रम:35 #EXT-X-TARGETDURATION:5 #EXTINF:5.224, लाइव - 16602660. ts #EXTINF:5.246, लाइव - 17072820. ts #EXTINF :5.280, लाइव - 17544960। टीएस #EXTINF:5.251, लाइव - 18020160। टीएस #EXTINF:5.228, लाइव - 18492750। टीएस #EXTINF:5.242, लाइव - 18963270। ts

कैमरे गिरने की समस्या का समाधान

सबसे सही निर्णय बग्गी कैमरा बदलना है। यह 90% समय में मदद करता है। यदि कोई रास्ता नहीं है और आपको किसी तरह जीने की जरूरत है, तो निम्नलिखित समाधान मदद करेगा।

इस समाधान में दो शामिल हैं - पूरक:

प्रत्येक कैमरे के लिए एक अलग nginx प्रक्रिया चलाएँ और स्टैटिक्स को वापस करने के लिए एक सामान्य प्रक्रिया चलाएँ। यही है, दो कैमरों के लिए, आरटीएमपी सर्वर के साथ अलग-अलग कॉन्फ़िगरेशन लिखें और http के साथ एक सामान्य। तब बग्गी कैमरा समग्र प्रक्रिया को प्रभावित नहीं करेगा।

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

प्रत्येक कैमरे के लिए, /etc/init.d/ में एक निष्पादन योग्य स्क्रिप्ट बनाई जाती है, nginx की एक प्रति, जिसका नाम कैमरा_1 और कैमरा_2 है

# सीपी /etc/init.d/nginx /etc/init.d/camera_1 # सीपी /etc/init.d/nginx /etc/init.d/camera_2 # चामोद +x /etc/init.d/camera_1 # चामोद +x /etc/init.d/camera_2

Nginx स्टार्टअप स्क्रिप्ट का संपादन।

नैनो / आदि / init. डी/nginx

DAEMON_OPTS चर बदलें। मुख्य nginx डेमॉन सभी स्थैतिक की सेवा करेगा। यह कैमरों के लिए जिम्मेदार डेमॉन को भी शुरू और बंद कर देगा। d /camera_1 बंद करो अगर [- f "/etc/init.d/camera_2"]; फिर /etc/init. d/camera_2 बंद करो फाई

do_reload फ़ंक्शन में जोड़ें:

# कैमरे फिर से लोड करें अगर [- f "/etc/init.d/camera_1"]; फिर /etc/init. d / कैमरा_1 फिर से लोड करें अगर [- f "/etc/init.d/camera_2"]; फिर /etc/init. d/camera_2 फिर से लोड करें

हम उदाहरण के अनुसार कैमरा 1 कैमरा_1 और कैमरा 2 कैमरा_2 के लिए nginx स्टार्टअप स्क्रिप्ट संपादित करते हैं।

# नैनो /etc/init.d/camera_1

DAEMON_OPTS और DESC चर बदलना

DESC = "CAMERA-1 के लिए कैमरा_1" DAEMON_OPTS = "-c /etc/nginx/nginx_1.conf"

हम उदाहरण के अनुसार कैमरा 2 कैमरा_2 के लिए nginx स्टार्टअप स्क्रिप्ट को संपादित करते हैं।

http स्थानों के साथ /etc/nginx/nginx_0.conf में मैं जादू की रेखाएँ लिखता हूँ:

# डीआईआर-प्रोसेस-नाम /tmp/hls-1/camera_1 # डीआईआर-प्रोसेस-नाम /tmp/hls-2/camera_2

वे खोज शब्द DIR-PROCESS-NAME, एक स्थान, निर्देशिका और पुनरारंभ की जाने वाली प्रक्रिया के नाम से अलग करते हैं।

इंतिहान:

# सर्विस nginx स्टार्ट # सर्विस कैमरा_1 रीस्टार्ट

स्क्रिप्ट जो कैमरों को पुनः लोड करती है। यह खंड फ़ोल्डरों के माध्यम से जाता है, जहां कोई * .m3u8 फ़ाइलें नहीं हैं। यदि फ़ोल्डर में कोई फाइल नहीं है, तो यह मुख्य डेमॉन के विन्यास के अनुसार संबंधित डेमॉन की खोज करता है, लाइन द्वारा DIR-PROCESS-NAME । इसे पुनः लोड करता है।

# नैनो /स्क्रिप्ट/cameras_reloader.sh

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#!/bin/bash PATH = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin mask = "*.m3u8" dir = "/tmp/ hls-*" function find_process()( process_str = $(cat /etc/nginx/nginx_0.conf | grep "# DIR-PROCESS-NAME" | grep $1 | cut -d" " -f4) hls_dir के लिए echo $process_str ) $ डीआईआर में; do find_result = $(find $hls_dir -name $mask -type f) if [-z $find_result ] ; फिर प्रक्रिया = $ (find_process $ hls_dir) सेवा $ प्रक्रिया पुनरारंभ करें फाई नींद 15s

HLS की तुलना MPEG-DASH . से

MPEG-DASH, MPEG-4 के परिवहन के रूप में Google द्वारा निर्मित HLS का एक एनालॉग है। यह परिवहन व्यापक नहीं है और व्यावहारिक रूप से समर्थित नहीं है। उनकी विचारधारा एक ही है, धारा को टुकड़ों में तोड़ दो, केवल और टुकड़े, वीडियो के लिए अलग टुकड़े, ऑडियो के लिए अलग टुकड़े। Nginx-rtmp-मॉड्यूल में, यह प्रारूप HLS के समान ही कॉन्फ़िगर किया गया है।

कोशिश करो, कॉपी करो, इसके लिए जाओ!

यदि लेख आपके लिए उपयोगी था, तो कृपया विज्ञापन पर क्लिक करें। आपको धन्यवाद!

Flussonic Media Server HLS प्रोटोकॉल के माध्यम से वीडियो वितरण का समर्थन करता है।

उपलब्ध सुविधाओं में से कई एचएलएस के लिए गैर-मानक हैं, लेकिन हम आपकी सुविधा के लिए उनका समर्थन करते हैं।

समर्थित कोडेक्स: H264, H265, MPEG2 वीडियो, AAC, MP3, MPEG2 ऑडियो, AC-3।

Flussonic मीडिया सर्वर आपको एचएलएस के माध्यम से लाइव टीवी, मांग पर वीडियो, संग्रह से वीडियो (कैचअप और टाइमशिफ्ट) प्राप्त करने की अनुमति देता है।

आसान एचएलएस प्लेबैक

यदि आपके पास एक साधारण लाइव स्ट्रीम या फ़ाइल (एक वीडियो, एक ध्वनि) है, तो HLS के माध्यम से चलाने के लिए URL बहुत सरल है:

http://flussonic-ip/STREAMNAME/index.m3u8

जहां Flussonic-ip आपके Flussonic Media Server के एड्रेस + पोर्ट का एक उदाहरण है।

Flussonic Media Server अन्य सर्वरों के साथ पश्चगामी संगतता के लिए URL के अंत में प्लेलिस्ट.m3u8 को भी स्वीकार करता है।

जब आप बहुभाषी या बहु-बिटरेट सामग्री के साथ काम करना शुरू करते हैं, तो चीजें और जटिल हो जाती हैं।

बहुभाषी एचएलएस

यदि आप iPhone पर अपनी बहुभाषी स्ट्रीम चलाना चाहते हैं, तो आपको उसी http://192.168.2.3:8080/STREAMNAME/index.m3u8 का उपयोग करना होगा।

लेकिन अगर आप वीएलसी या सेट-टॉप बॉक्स का उपयोग करके एक बहुभाषी स्ट्रीम देखना चाहते हैं, तो आपको video.m3u8 को शामिल करना होगा।

प्लेयर के लिए URL: http://flussonic-ip/STREAMNAME/video.m3u8

यह इस तथ्य के कारण है कि, Apple HLS की आवश्यकताओं के अनुसार, प्रत्येक व्यक्तिगत भाषा के लिए केवल ऑडियो विकल्प के साथ एक अलग प्लेलिस्ट निर्दिष्ट की जानी चाहिए। एमपीईजी-टीएस का एक अलग तंत्र है: सभी ऑडियो ट्रैक वीडियो के बगल में रखे जाते हैं, और खिलाड़ी खुद चुनता है कि क्या खेला जाएगा। किसी वीडियो को iPhone पर देखने के लिए, उसे Apple के दिशानिर्देशों को पूरा करना होगा। लेकिन वीएलसी और सेट-टॉप बॉक्स, एचएलएस मानक के उल्लंघन में, एमपीईजी-टीएस के पुराने संस्करण को एचएलएस में बदलने की उम्मीद करते हैं। इसलिए, आपको video.m3u8 शामिल करना होगा।

Apple के लिए "केवल ऑडियो" जोड़ना

Apple को आपके सभी स्ट्रीम के लिए नो वीडियो, ऑडियो ओनली विकल्प की आवश्यकता है।

उनका मानना है कि यदि उपयोगकर्ता 3 जी पर वीडियो देख रहा है और एक बार अनिश्चित स्वागत के क्षेत्र में है, तो उसके लिए बफरिंग की तुलना में केवल ध्वनि होना बेहतर होगा।

आप Flussonic Media Server में इस विकल्प को सक्षम कर सकते हैं:

स्ट्रीम ऑर्ट (यूआरएल यूडीपी: // 239.0.0.1: 1234; add_audio_only;)

ध्यान रखें कि यह आपके index.m3u8 पते को VLC या सेट-टॉप बॉक्स में चलाने योग्य नहीं बना सकता है। ऐसे में video.m3u8 का इस्तेमाल करें।

सेट-टॉप बॉक्स के लिए अलग बिटरेट

जब आपके पास बहु-बिटरेट बहुभाषी सामग्री है और आप इसे ऐसे सेट-टॉप बॉक्स पर चलाना चाहते हैं जो बहु-बिटरेट HLS प्लेलिस्ट का समर्थन नहीं करता है, तो आप Flussonic Media Server से एक वीडियो और सभी ऑडियो ट्रैक के साथ अलग-अलग प्लेलिस्ट का अनुरोध कर सकते हैं, ठीक उसी तरह जैसे मोनो विकल्प:

http://flussonic-ip/STREAMNAME/video1. एम3यू8

यह प्लेलिस्ट मल्टी-बिटरेट नहीं है, इसमें सेगमेंट का URL है, जिसमें पहला वीडियो ट्रैक और सभी उपलब्ध ऑडियो ट्रैक हैं।

यदि आप ऐसे सेट-टॉप बॉक्स में बहुभाषी, मल्टीबिटरेट स्ट्रीम डिलीवर करना चाहते हैं जो Apple के बहुभाषी मानक को नहीं समझते हैं, तो video.m3u8 का उपयोग करें:

http://flussonic-ip/STREAMNAME/video. एम3यू8

यह एक बहु-बिटरेट प्लेलिस्ट है जो विभिन्न गुणों वाली प्लेलिस्ट की सूची लौटाती है: video1.m3u8, video2.m3u8, आदि।

डीवीआर कैचअप प्लेबैक

जब आपकी स्ट्रीम पहले से ही हमारे डीवीआर द्वारा सर्वर पर रिकॉर्ड की जाती है, तो आप प्रसारण के प्रारंभ और समाप्ति समय (उदाहरण के लिए, ईपीजी से) का उपयोग करके एचएलएस के माध्यम से वीडियो चला सकते हैं।

http://flussonic-ip/STREAMNAME/archive-1508403742-3600। एम3यू8

यह प्लेलिस्ट तथाकथित होगी। यदि स्ट्रीम में एक से अधिक ऑडियो ट्रैक या एक से अधिक बिटरेट होंगे तो वैरिएंट। यह यूटीसी 1362504585 (2013 मार्च 5 17:29:45 जीएमटी) से शुरू होने वाले और एक घंटे आगे के खंडों को सूचीबद्ध करेगा।

मोनो यूआरएल एमपीईजी-टीएस में सभी ट्रैक वाले सेगमेंट की एक सूची देगा:

http://flussonic-ip/STREAMNAME/mono-1362504585-3600। एम3यू8

एक अधिक विशिष्ट वीडियोएन प्लेलिस्ट एन वीडियो ट्रैक और सभी ऑडियो ट्रैक वाले सेगमेंट की सूची देगी:

http://flussonic-ip/STREAMNAME/video1-1362504585-3600। एम3यू8

और वीडियोएन प्लेलिस्ट की सूची के साथ एक भिन्न वीडियो प्लेलिस्ट:

http://flussonic-ip/STREAMNAME/video-1362504585-3600। एम3यू8

प्लेलिस्ट रिवाइंड करें

एक विशेष प्लेलिस्ट है "रिवाइंड-N.m3u8"एक बड़ी "स्लाइडिंग" विंडो के साथ जो आपको HLS स्ट्रीम को लंबे समय तक रिवाइंड और पॉज़ करने की अनुमति देती है।

http://flussonic-ip/STREAMNAME/rewind-7200। एम3यू8

7200 - सेकंड में एचएलएस प्लेलिस्ट की लंबाई। इसका मतलब है कि आपके ग्राहक विशेष संग्रह लिंक तक पहुंच के बिना प्रसारण को 2 घंटे के लिए रोक सकते हैं या फ़ुटबॉल मैच की शुरुआत में रिवाइंड कर सकते हैं।