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

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

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

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

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

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

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

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

एचडीआर

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

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

एचएलएस से लाइव स्ट्रीमिंग करने के लिए, वीडियो का यूआरएल पाना

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

पूरा इनजेशन यूआरएल पाने के लिए, एन्कोडर YouTube Live Streaming API का इस्तेमाल करके, liveStream संसाधन को इन प्रॉपर्टी के साथ insert कर सकते हैं:

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

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

YouTube Creator Studio से एचएलएस इनजेस्ट करने का यूआरएल पाना

YouTube Creator Studio के वेब इंटरफ़ेस में, क्रिएटर के "स्ट्रीम बनाएं" पर क्लिक करने के बाद, 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=

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

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

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

एचएलएस स्ट्रीम करने के लिए, डेटा डालने वाले यूआरएल को पूरा करना

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

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

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

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

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

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

एन्कोडर को ये काम करने होंगे:

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

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

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

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

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

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

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

• EXT-X-MEDIA-SEQUENCE टैग से, प्लेलिस्ट में शामिल पहले मीडिया सेगमेंट के क्रम संख्या की पहचान होनी चाहिए.

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

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

  ध्यान दें कि सर्वर, मीडिया सेगमेंट मिलने की पुष्टि करता है. इसके लिए, वह सेगमेंट अपलोड होने पर 200 (OK) या 202 (Accepted) रिस्पॉन्स दिखाता है. A 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 सेगमेंट में PAT और PMT होना चाहिए. साथ ही, सेगमेंट में पहले दो ट्रांसपोर्ट स्ट्रीम पैकेट, PAT और PMT होने चाहिए.
• कॉन्टेंट
  • वीडियो और ऑडियो को मल्टीप्लेक्स किया जाना चाहिए.
  • H.264 और HEVC वीडियो कोडेक इस्तेमाल किए जा सकते हैं.
  • HEVC फ़ॉर्मैट में एचडीआर क्वालिटी के वीडियो देखे जा सकते हैं. एचडीआर क्वालिटी के वीडियो से जुड़ी ज़रूरी शर्तें देखें.
  • 60fps तक की फ़्रेम दर वाले वीडियो इस्तेमाल किए जा सकते हैं.
  • सिर्फ़ क्लोज़्ड जीओपी का इस्तेमाल किया जा सकता है.
  • इसके साथ काम करने वाला ऑडियो कोडेक AAC है. साथ ही, सिर्फ़ सिंगल-ट्रैक ऑडियो काम करता है.
  • मीडिया सेगमेंट की अवधि एक से चार सेकंड के बीच होनी चाहिए. इस बारे में यहां बताया गया है. मीडिया सेगमेंट की अवधि पांच सेकंड से ज़्यादा नहीं होनी चाहिए.
  • मीडिया सेगमेंट को सिर्फ़ एचटीटीपीएस के साथ टीएलएस/एसएसएल लेयर में एन्क्रिप्ट (सुरक्षित) किया जाना चाहिए. अन्य एन्क्रिप्शन मेकेनिज़्म काम नहीं करते.

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

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

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

बिटरेट

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

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

अन्य शर्तें

• एनकोडर को एचटीटीपी अनुरोध में User-Agent हेडर सेट करना चाहिए. इसके लिए, यहाँ दिया गया सिंटैक्स इस्तेमाल करें. इसमें डिवाइस बनाने वाली कंपनी का नाम, मॉडल का नाम, और वर्शन शामिल होता है:

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

सबटाइटल

HLS इनजेस्शन में, सबटाइटल भेजने के लिए दो विकल्प उपलब्ध हैं:

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

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

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

200 (OK)

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

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

202 (स्वीकृत)

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

400 (गलत अनुरोध)

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

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

401 (अनुमति नहीं है)

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

405 (इस एचटीटीपी मेथड से ऐक्सेस करने की अनुमति नहीं है)

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

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

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