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

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

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

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

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

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

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

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

HDR

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

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

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

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

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

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

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

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

चेतावनी: एचएलएस डेटा डालने के यूआरएल पाने का यह तरीका, बीटा वर्शन में उपलब्ध है. आने वाले समय में, इसमें बदलाव हो सकता है.

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

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

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

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

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

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

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

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

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

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

एचएलएस की खास जानकारी में, दो तरह की प्लेलिस्ट के बारे में बताया गया है: मीडिया प्लेलिस्ट और मास्टर प्लेलिस्ट. 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 का इस्तेमाल किया जा सकता है. साथ ही, सिर्फ़ सिंगल-ट्रैक ऑडियो इस्तेमाल किया जा सकता है.
  • हमारा सुझाव है कि मीडिया सेगमेंट की अवधि एक से चार सेकंड के बीच होनी चाहिए. इस बारे में, अगले सेक्शन में बताया गया है. मीडिया सेगमेंट की अवधि पांच सेकंड से ज़्यादा नहीं होनी चाहिए.
  • मीडिया सेगमेंट को सिर्फ़ टीएलएस/एसएसएल लेयर में, एचटीटीपीएस के साथ एन्क्रिप्ट किया जाना चाहिए. एन्क्रिप्शन के अन्य तरीके इस्तेमाल नहीं किए जा सकते.

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

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

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

बिटरेट

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

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

अन्य शर्तें

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

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

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

सबटाइटल

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

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

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

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

200 (OK)

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

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

202 (स्वीकृत)

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

400 (अमान्य अनुरोध)

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

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

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

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

405 (इस तरीके का इस्तेमाल नहीं किया जा सकता)

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

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

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