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

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

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

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

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

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

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

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

एचडीआर

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

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

एचएलएस इनजेशन यूआरएल पाना

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

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

"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= पैरामीटर की वैल्यू पर ये नियम लागू होते हैं:

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

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

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

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

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

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

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

बिटरेट

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

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

अन्य शर्तें

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

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

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

सबटाइटल

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

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

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

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

200 (ठीक है)

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

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

202 (स्वीकृत)

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

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

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

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

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

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

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

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

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

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