एचएलएस के ज़रिए YouTube पर लाइव कॉन्टेंट अपलोड करना

इस दस्तावेज़ में एचटीटीपी लाइव स्ट्रीमिंग (एचएलएस) प्रोटोकॉल का इस्तेमाल करने का तरीका बताया गया है एन्कोडर से YouTube पर लाइव डेटा स्ट्रीम करना. इस दस्तावेज़ का मकसद ऐसे एन्कोडर वेंडर जो अपने प्रॉडक्ट में एचएलएस से डेटा डालने की सुविधा जोड़ना चाहते हैं. HLS ऐसे प्रीमियम कॉन्टेंट के लिए डेटा डालना एक अच्छा विकल्प है जिसे हालांकि, क्वालिटी और हाई रिज़ॉल्यूशन में इन सुविधाओं का इस्तेमाल किया जा सकता है. कम शब्दों में डेटा डालने के अलग-अलग प्रोटोकॉल की तुलना YouTube लाइव से करना स्ट्रीमिंग में मदद करने के लिए, YouTube लाइव स्ट्रीमिंग का डेटा डालने के प्रोटोकॉल की तुलना देखें.

एचएलएस का इस्तेमाल करके लाइव डेटा स्ट्रीम करने के लिए, एन्कोडर को मीडिया की एक सीरीज़ भेजनी चाहिए HTTP PUT का इस्तेमाल करके, YouTube के HLS एंडपॉइंट पर प्लेलिस्ट और मीडिया सेगमेंट जोड़ना या POST अनुरोध. एन्कोडर के हिसाब से, YouTube एचएलएस एंडपॉइंट निष्क्रिय HTTP सर्वर प्रतीत होता है.

हर मीडिया सेगमेंट, असल मल्टीमीडिया कॉन्टेंट को दिखाता है जो एक से चार सेकंड तक चलती है. हर मीडिया प्लेलिस्ट में बताया गया है कि मीडिया सेगमेंट को स्ट्रीम के सही क्रम में फिर से कैसे जोड़ा जाए.

मीडिया फ़ॉर्मैट की ज़रूरी शर्तें

YouTube एचएलएस से डेटा डालने के लिए, वीडियो और ऑडियो की ये ज़रूरी शर्तें पूरी करनी होती हैं सामग्री:

• वीडियो और ऑडियो M2TS फ़ॉर्मैट में ही म्यूट होने चाहिए.
• H.264 और HEVC वीडियो कोडेक पर भी इसका इस्तेमाल किया जा सकता है.
• 60 एफ़पीएस (फ़्रेम प्रति सेकंड) तक के फ़्रेम रेट काम करते हैं.
• सिर्फ़ क्लोज़्ड जीओपी का इस्तेमाल किया जा सकता है.
• काम करने वाला ऑडियो कोडेक AAC है और सिर्फ़ सिंगल-ट्रैक ऑडियो काम करता है.

मीडिया सेगमेंट सेक्शन में ज़्यादा जानकारी वाली ज़रूरतें देखें.

एचडीआर

हाई डाइनैमिक रेंज (एचडीआर) वीडियो को HEVC कोडेक से इस्तेमाल किया जा सकता है. साथ ही, वीडियो में ये अन्य ज़रूरी शर्तें पूरी करनी होंगी:

• 10-बिट PQ और HLG कलर स्टैंडर्ड पर काम करते हैं. साथ ही, चमक कम या ज़्यादा होती है. ज़्यादा खास जानकारी:
  • क्रोमा का फ़ॉर्मैट YUV 4:2:0 10-बिट होना चाहिए.
  • ट्रांसफ़र फ़ंक्शन, PQ (जिसे SMPTE ST 2084 भी कहा जाता है) या HLG होना चाहिए (इसे ARIB STD-B67 के नाम से भी जाना जाता है).
  • बुनियादी रंग Rec. होना चाहिए. 2020 तक सेव किया गया था.
  • मैट्रिक्स गुणांक होना चाहिए. 2020 बदलती रहने वाली चमक.
• सीमित-रेंज (या MPEG-रेंज) और फ़ुल-रेंज (या JPEG-रेंज), दोनों सैंपल वैल्यू इस्तेमाल की जा सकती हैं. यह ज़रूरी है कि रेंज इस सैंपल वैल्यू की वह रेंज देखें जिसका इस्तेमाल कॉन्टेंट ने किया है. सीमित रेंज वाले सैंपल वैल्यू सुझाया गया.

एचएलएस का डेटा डालने का यूआरएल पाना

YouTube API से एचएलएस का डेटा डालने का यूआरएल पाना

डेटा डालने का पूरा यूआरएल पाने के लिए, एन्कोडर YouTube लाइव स्ट्रीमिंग का इस्तेमाल कर सकते हैं लाइव स्ट्रीम शामिल करने के लिए, एपीआई संसाधन होगा. इसके साथ ही, ये संसाधन भी दिए गए हैं: प्रॉपर्टी:

"cdn": {
  "ingestionType": "hls",
  "frameRate": "variable",
  "resolution": "variable"
}

एपीआई से मिले रिस्पॉन्स में, cdn.ingestionInfo.ingestionAddress फ़ील्ड से पता चलता है कि डेटा डालने का मुख्य यूआरएल और cdn.ingestionInfo.backupIngestionAddress फ़ील्ड बैकअप डेटा डालने का यूआरएल तय करता है. ज़्यादा जानकारी के लिए, यह दस्तावेज़ देखें: liveStreams संसाधन.

YouTube Studio से एचएलएस का डेटा डालने का यूआरएल पाना

चेतावनी: एचएलएस से डेटा डालने वाले यूआरएल पाने का यह तरीका बीटा वर्शन है और में ज़्यादा बदलाव नहीं होगा.

YouTube Creator Studio के वेब इंटरफ़ेस में, जब क्रिएटर "बनाएं" पर क्लिक करेगा Stream", YouTube पर "स्ट्रीम कुंजी" दिख रही है जिसमें अक्षर और अंक शामिल हैं वर्ण और हाइफ़न शामिल करें. इस सीक्रेट कुंजी से, क्रिएटर और क्रिएटर, YouTube पर स्ट्रीम करने की सुविधा मिलती है.

इस स्ट्रीम कुंजी से एचएलएस यूआरएल बनाने के लिए, यह तरीका अपनाएं:

https://a.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=0&file=

... जहां $STREAM_KEY, वेब इंटरफ़ेस में दिखाई जाने वाली स्ट्रीम कुंजी है. जैसे: https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file=

ज़्यादा विश्वसनीयता के लिए, डेटा डालने की दूसरी कॉपी को भेजा जा सकता है इस बैकअप URL को कॉपी कर सकते हैं:

https://b.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=1&file=

ध्यान दें कि बैकअप के मुख्य यूआरएल और बैकअप यूआरएल में दो अंतर हैं: दोनों होस्टनेम और copy= पैरामीटर बदल गया है. डेटा का बैकअप लेने की सुविधा, ज़रूरी है मुख्य डेटा डालने से बचने के लिए, copy= पैरामीटर की वैल्यू अलग-अलग हो स्ट्रीम को खराब कर रही हूँ.

एचएलएस का डेटा डालने का यूआरएल पूरा करना

दोनों में से किसी भी तरीके से मिले यूआरएल, अधूरे टेंप्लेट हैं; दोनों खत्म हो जाते हैं बिना खाली file= क्वेरी पैरामीटर के साथ. फ़ाइनल यूआरएल बनाने के लिए, एन्कोडर को यह ज़रूरी है URL के अंत में किसी मीडिया प्लेलिस्ट या मीडिया सेगमेंट का फ़ाइल नाम जोड़ें, इस तरह, file= पैरामीटर को पूरा किया जा रहा है.

file= पैरामीटर की वैल्यू पर ये नियम लागू होते हैं:

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

एचएलएस प्रोटोकॉल की ज़रूरी शर्तें

एन्कोडर से भेजे गए मीडिया प्लेलिस्ट और मीडिया सेगमेंट इन शर्तों के मुताबिक होने चाहिए: HTTP लाइव स्ट्रीमिंग का दूसरा वर्शन खास जानकारी.

एचएलएस की खास बातें दो तरह की प्लेलिस्ट के बारे में बताती हैं: मीडिया प्लेलिस्ट और मास्टर प्लेलिस्ट. YouTube, कॉन्टेंट को अलग-अलग रिज़ॉल्यूशन में ट्रांसकोड करता है और बिटरेट, एन्कोडर को अलग-अलग बिटरेट वाले कॉन्टेंट को YouTube. इसलिए, एचएलएस से लाइव स्ट्रीमिंग करने के लिए, YouTube पर सिर्फ़ मीडिया प्लेलिस्ट की सुविधा काम करती है. और मास्टर प्लेलिस्ट को अनदेखा कर दिया जाता है. (मास्टर प्लेलिस्ट में वैरिएंट का एक सेट शामिल होता है स्ट्रीम, जिनमें से हर एक ही कॉन्टेंट के अलग-अलग वर्शन के बारे में बताती है.)

एन्कोडर को ये ज़रूरी शर्तें पूरी करनी होंगी:

• अपनी पसंद के हिसाब से सबसे ज़्यादा रिज़ॉल्यूशन वाली, एन्कोड की गई ठीक एक स्ट्रीम भेजें उपयोगकर्ताओं को दिखाया जाएगा (एक रिज़ॉल्यूशन और कोडेक).
• मक्स ऑडियो और वीडियो.
• सभी अनुरोधों के लिए, एचटीटीपीएस और स्थायी कनेक्शन का इस्तेमाल करना चाहिए.

नीचे दिए गए सेक्शन में, मीडिया प्लेलिस्ट के लिए कुछ खास ज़रूरी शर्तें दी गई हैं और मीडिया सेगमेंट शामिल हैं.

मीडिया प्लेलिस्ट

मीडिया प्लेलिस्ट में मीडिया सेगमेंट की एक सूची होती है, जिसे जोड़ा जा सकता है जो लगातार और डिकोड की जा सकने वाली मल्टीमीडिया स्ट्रीम दिखाती हैं. मीडिया प्लेलिस्ट से पता चलता है कि सर्वर से कि मीडिया सेगमेंट से किसकी उम्मीद की जानी चाहिए और कैसे वे स्ट्रीम को दोबारा इकट्ठा और इस्तेमाल करने में मदद कर सकता है.

ज़रूरी शर्तें

• मीडिया प्लेलिस्ट फ़ाइल के नाम के आखिर में .m3u8 या .m3u होना चाहिए.

• किसी स्ट्रीम के लिए भेजी गई पहली मीडिया प्लेलिस्ट, क्रम संख्या से शुरू होनी चाहिए 0 और क्रम संख्या, एक विराम चिह्न के रूप में बढ़नी चाहिए.

• EXT-X-MEDIA-SEQUENCE टैग को प्लेलिस्ट में मौजूद पहला मीडिया सेगमेंट.

• किसी मीडिया प्लेलिस्ट में पांच से ज़्यादा सेगमेंट नहीं होने चाहिए. ऐप्लिकेशन अगर सर्वर को सेगमेंट नहीं मिला है या वह स्वीकार नहीं किया गया है, तो सेगमेंट बाकी है उसकी रसीद मिल गई है.

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

  ध्यान दें कि सर्वर उस सेगमेंट को अपलोड करने पर 200 (OK) या 202 (Accepted) जवाब. ऐप्लिकेशन 202 रिस्पॉन्स से पता चलता है कि सर्वर को उस सेगमेंट की पहचान करने वाली प्लेलिस्ट.

• हर मीडिया सेगमेंट के लिए अपडेट की गई मीडिया प्लेलिस्ट भेजें, ताकि मीडिया प्लेलिस्ट खो जाने पर, सर्वर तुरंत रिकवर हो सकता है.

• जैसे ही सर्वर मीडिया सेगमेंट की रसीद स्वीकार कर लेता है, आप मीडिया प्लेलिस्ट को बनने से रोकने के लिए, EXT-X-MEDIA-SEQUENCE टैग की वैल्यू बहुत लंबा है. उदाहरण के लिए, यदि सर्वर ने पहले ही पहले नौ मीडिया सेगमेंट, अगली मीडिया प्लेलिस्ट में आठवें, नौवां और दसवां मीडिया सेगमेंट.

• EXT-X-KEY और EXT-X-SESSION-KEY टैग काम नहीं करते.

उदाहरण

यहां दी गई सूची में उन फ़ाइलों के उदाहरण दिए गए हैं जिनकी उम्मीद, एन्कोडर से ली जा सकती है भेजें:

Media Playlist file with seqnum #0
Media Segment file #0
Media Playlist file with seqnum #0-#1
Media Segment file #1
Media Playlist file with seqnum #0-#2
Media Segment file #2
Media Playlist file with seqnum #1-#3
Media Segment file #3
...

यहां दिए गए उदाहरण में, किसी लाइव वीडियो के बीच में भेजी गई मीडिया प्लेलिस्ट को दिखाया गया है स्ट्रीम. यह उदाहरण किसी स्ट्रीम के बीच का है, इसलिए EXT-X-MEDIA-SEQUENCE टैग की वैल्यू शून्य नहीं है.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:3.975,
fileSequence2680.ts
#EXTINF:3.941,
fileSequence2681.ts
#EXTINF:3.975,
fileSequence2682.ts

मीडिया सेगमेंट

यह सूची मीडिया सेगमेंट की शर्तों के बारे में बताती है:

• फ़ाइल नाम
  • यूआरएल में मीडिया सेगमेंट की फ़ाइल के नामों में .ts फ़ाइल नाम होना चाहिए एक्सटेंशन और प्लेलिस्ट के फ़ाइल नामों से मेल खाना चाहिए.
  • एन्कोडर को फिर से चालू करने पर, मीडिया सेगमेंट की फ़ाइल के नाम अलग-अलग होने चाहिए स्ट्रीम फिर से शुरू हो जाती है.
• फ़ॉर्मैट
  • मीडिया सेगमेंट, M2TS फ़ॉर्मैट में होने चाहिए और ये अपने-आप शुरू होने चाहिए.
  • हर M2TS सेगमेंट में एक MPEG-2 प्रोग्राम होना चाहिए.
  • M2TS सेगमेंट में एक पीएटी और पीएमटी होना ज़रूरी है. साथ ही, पहले दो सेगमेंट होने चाहिए एक सेगमेंट में ट्रांसपोर्ट स्ट्रीम पैकेट, पीएटी और पीएमटी होने चाहिए.
• कॉन्टेंट
  • वीडियो और ऑडियो मिक्स होने चाहिए.
  • H.264 और HEVC वीडियो कोडेक पर भी इसका इस्तेमाल किया जा सकता है.
  • एचईवीसी वाला एचडीआर काम करता है (एचडीआर से जुड़ी ज़रूरी शर्तें देखें).
  • 60 एफ़पीएस (फ़्रेम प्रति सेकंड) तक के फ़्रेम रेट काम करते हैं.
  • सिर्फ़ क्लोज़्ड जीओपी का इस्तेमाल किया जा सकता है.
  • काम करने वाला ऑडियो कोडेक AAC है और सिर्फ़ सिंगल-ट्रैक ऑडियो समर्थित हैं.
  • मीडिया सेगमेंट की अवधि एक और चार के बीच रखने का सुझाव दिया जाता है सेकंड, जैसा कि नीचे दिए गए सेक्शन में बताया गया है. मीडिया सेगमेंट को यह नहीं करना चाहिए की अवधि 5 सेकंड से ज़्यादा हो.
  • मीडिया सेगमेंट, सिर्फ़ एचटीटीपीएस के साथ TLS/एसएसएल लेयर में एन्क्रिप्ट (सुरक्षित) होने चाहिए. एन्क्रिप्ट (सुरक्षित) करने के अन्य तरीके काम नहीं करते.

मीडिया सेगमेंट की अवधि

हमें उम्मीद है कि एचएलएस से लाइव स्ट्रीमिंग करने के लिए, एचएलएस का इस्तेमाल ऐसे प्रीमियम कॉन्टेंट के लिए किया जाना चाहिए जिसके लिए की क्वालिटी और हाई रिज़ॉल्यूशन. आम तौर पर, आरटीएमपी की तुलना में एचएलएस से डेटा डालने में इंतज़ार का समय ज़्यादा होता है- और WebRTC-आधारित डेटा डालने की प्रक्रिया, क्योंकि एचएलएस से डेटा डालने का तरीका सेगमेंट पर आधारित है.

हम एक से चार सेकंड की मीडिया सेगमेंट अवधि रखने की सलाह देते हैं, क्योंकि छोटे मीडिया सेगमेंट का इस्तेमाल करने पर, इंतज़ार का समय कम हो सकता है. हालांकि, इसकी लागत बढ़ सकती है बफ़र रेट और कोड में बदलने की कम क्षमता. जैसा कि पिछले सेक्शन में बताया गया है, मीडिया सेगमेंट 5 सेकंड से ज़्यादा लंबे नहीं होने चाहिए.

बिटरेट

YouTube सहायता सेंटर बिटरेट की सेटिंग के लिए दिशा-निर्देश देती है.

ध्यान दें कि एचईवीसी से आम तौर पर, एक ही समय में 25% से 50% ज़्यादा डेटा कंप्रेशन मिलता है H.264 की तुलना में वीडियो की क्वालिटी. इसलिए, वीडियो के निचले हिस्से में बिटरेट सुझाई गई रेंज का इस्तेमाल एचईवीसी के साथ किया जा सकता है, ताकि बैंडविथ सेव किया जा सके. खास तौर पर, 4K कॉन्टेंट के लिए मददगार.

अन्य शर्तें

• एन्कोडर को एचटीटीपी अनुरोध में User-Agent हेडर को सेट करने के लिए, जिसमें निर्माता का नाम, मॉडल का नाम, और वर्शन:

  User-Agent: <manufacturer> / <model> / <version>
  

  ध्यान दें: इस जानकारी का इस्तेमाल सिर्फ़ डीबग करने के लिए किया जाएगा. ऐसा नहीं होगा इसका इस्तेमाल, स्ट्रीम मैनेज करने से जुड़े फ़ैसले लेने में किया जाता है.

सबटाइटल

एचएलएस से डेटा डालने के लिए, सबटाइटल भेजने के दो विकल्प इस्तेमाल किए जा सकते हैं:

• अलग-अलग एचटीटीपी पोस्ट अनुरोधों का इस्तेमाल करके सबटाइटल भेजें. यह सभी के लिए काम करता है एचएलएस से डेटा डालना.
• एम्बेड किए गए 608/708 सबटाइटल, H264 का इस्तेमाल करने वाले एचएलएस से जोड़े जा सकते हैं वीडियो कोडेक का इस्तेमाल करें, लेकिन HEVC वीडियो कोडेक से डेटा डालने के बजाय. ज़्यादा के लिए ज़्यादा जानकारी के लिए, लाइव कैप्शन से जुड़ी ज़रूरी शर्तें देखें के बारे में ज़्यादा जानें.

एचटीटीपी रिस्पॉन्स कोड

इन सेक्शन में, उन रिस्पॉन्स कोड के बारे में बताया गया है जिन्हें YouTube दिखाता है HLS का इस्तेमाल करके डिलीवर किए गए मीडिया सेगमेंट और मीडिया प्लेलिस्ट को मिले रिस्पॉन्स.

200 (ठीक)

PUT या POST अनुरोध के जवाब में, एक HTTP 200 (OK) प्रतिक्रिया यह बताती है YouTube सर्वर को उम्मीद के मुताबिक कार्रवाई मिली और उसने उसे मैनेज किया का इस्तेमाल किया जा सकता है.

DELETE अनुरोध के जवाब में, HTTP 200 (OK) जवाब यह बताता है कि YouTube सर्वर को अनुरोध मिला और उसने उसे अनदेखा कर दिया. YouTube का सर्वर यह काम करता है इसके लिए, क्लाइंट को स्ट्रीम में किसी संसाधन को मिटाने की ज़रूरत नहीं होती और इसे अनदेखा कर देता है अनुरोध मिटाएं पर क्लिक करें. परफ़ॉर्मेंस की वजह से, YouTube, ग्राहकों के लिए सुझाव डिलीट न भेजें.

202 (स्वीकृत)

एचटीटीपी 202 (स्वीकार किया गया) रिस्पॉन्स यह बताता है कि YouTube सर्वर को उस मीडिया सेगमेंट वाली मीडिया प्लेलिस्ट पाने से पहले मीडिया सेगमेंट. यह क्लाइंट को यह बताता है कि उसे वह मीडिया प्लेलिस्ट भेजनी चाहिए जिसमें उस मीडिया सेगमेंट को जितना जल्दी हो सके, ताकि प्रोसेस करने में होने वाली देरी को रोका जा सके सेगमेंट. ध्यान दें कि अगर एन्कोडर अपडेट किया गया कोई अपडेट भेजता है, तो इसमें कोई समस्या नहीं होगी हर मीडिया सेगमेंट के लिए मीडिया प्लेलिस्ट.

400 (खराब अनुरोध)

एचटीटीपी 400 (खराब अनुरोध) रिस्पॉन्स, इनमें से कोई एक समस्या दिखाता है हुआ:

• यह यूआरएल कुनिर्मित है
• प्लेलिस्ट को पार्स नहीं किया जा सकता या उसमें ऐसे टैग हैं जो काम नहीं करते

401 (बिना अनुमति के)

एचटीटीपी 401 (बिना अनुमति के) रिस्पॉन्स से पता चलता है कि YouTube एचएलएस एंडपॉइंट के बेस यूआरएल में कोई गड़बड़ी है या इसकी समयसीमा खत्म हो चुकी है. क्लाइंट आगे बढ़ने के लिए, को cid पैरामीटर को अपडेट करना चाहिए.

405 (तरीका की अनुमति नहीं है)

एचटीटीपी 405 (मेथड की अनुमति नहीं है) रिस्पॉन्स से पता चलता है कि अनुरोध यह पोस्ट, PUT या DELETE अनुरोध नहीं है.

500 (सर्वर में गड़बड़ी)

एचटीटीपी 500 (इंटरनल सर्वर गड़बड़ी) रिस्पॉन्स बताता है कि सर्वर अनुरोध को प्रोसेस नहीं कर सका. इस गड़बड़ी को ठीक करने के लिए, हमारी सलाह है कि आप फिर से कोशिश करें एक्सपोनेन्शियल के साथ अनुरोध बैकऑफ़.