इस पेज का अनुवाद Cloud Translation API से किया गया है.

फिर से अपलोड करने की सुविधा

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

फिर से शुरू किए जा सकने वाले अपलोड का इस्तेमाल, खास तौर पर इनमें से किसी भी मामले में फ़ायदेमंद होता है:

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

इस गाइड में, एचटीटीपी अनुरोधों के क्रम के बारे में बताया गया है. कोई ऐप्लिकेशन, वीडियो अपलोड करने के लिए, फिर से शुरू की जा सकने वाली अपलोडिंग प्रोसेस का इस्तेमाल करता है. यह गाइड मुख्य रूप से उन डेवलपर के लिए है जो Google API क्लाइंट लाइब्रेरी का इस्तेमाल नहीं कर सकते. इनमें से कुछ लाइब्रेरी, फिर से शुरू किए जा सकने वाले अपलोड के लिए नेटिव सपोर्ट देती हैं. असल में, YouTube Data API - वीडियो अपलोड करना गाइड में, वीडियो अपलोड करने के लिए, Python के लिए Google API क्लाइंट लाइब्रेरी का इस्तेमाल करने का तरीका बताया गया है. इस लाइब्रेरी की मदद से, वीडियो को फिर से शुरू करके अपलोड किया जा सकता है.

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

httplib2.debuglevel = 4

पहला चरण - फिर से शुरू किया जा सकने वाला सेशन शुरू करना

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

https://www.googleapis.com/upload/youtube/v3/videos?uploadType=resumable&part=PARTS

अनुरोध के मुख्य हिस्से को video संसाधन पर सेट करें. ये एचटीटीपी अनुरोध हेडर भी सेट करें:

Authorization – अनुरोध के लिए अनुमति टोकन.
Content-Length – अनुरोध के मुख्य हिस्से में दिए गए बाइट की संख्या. ध्यान दें कि अगर चंक किए गए ट्रांसफ़र को कोड में बदलने की सुविधा का इस्तेमाल किया जा रहा है, तो आपको यह हेडर देने की ज़रूरत नहीं है.
Content-Type – वैल्यू को application/json; charset=UTF-8 पर सेट करें.
X-Upload-Content-Length – अगले अनुरोधों में अपलोड किए जाने वाले बाइट की संख्या. इस वैल्यू को अपलोड की जा रही फ़ाइल के साइज़ पर सेट करें.
x-upload-content-type – अपलोड की जा रही फ़ाइल का MIME टाइप. किसी भी वीडियो MIME टाइप (video/*) या application/octet-stream MIME टाइप वाली फ़ाइलें अपलोड की जा सकती हैं.

इस उदाहरण में, वीडियो अपलोड करने के लिए, फिर से शुरू किया जा सकने वाला सेशन शुरू करने का तरीका बताया गया है. अनुरोध, video संसाधन के snippet और status हिस्सों में प्रॉपर्टी सेट करता है और उन्हें फिर से हासिल करेगा. साथ ही, यह संसाधन के contentdetails हिस्से में भी प्रॉपर्टी हासिल करेगा.

post /upload/youtube/v3/videos?uploadType=resumable&part=parts http/1.1
host: www.googleapis.com
authorization: bearer auth_token
content-length: content_length
content-type: application/json; charset=utf-8
x-upload-content-length: x_upload_content_length
X-Upload-Content-Type: X_UPLOAD_CONTENT_TYPE

video resource

नीचे दिए गए उदाहरण में एक पोस्ट अनुरोध दिखाया गया है, जिसमें पुष्टि करने वाले टोकन को छोड़कर, ये सभी वैल्यू अपने-आप भरी गई हैं. उदाहरण में दी गई categoryId वैल्यू, वीडियो की कैटगरी से जुड़ी है. काम करने वाली कैटगरी की सूची, एपीआई के videoCategories.list तरीके का इस्तेमाल करके देखी जा सकती है.

POST /upload/youtube/v3/videos?uploadType=resumable&part=snippet,status,contentDetails HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer AUTH_TOKEN
Content-Length: 278
Content-Type: application/json; charset=UTF-8
X-Upload-Content-Length: 3000000
X-Upload-Content-Type: video/*

{
  "snippet": {
    "title": "My video title",
    "description": "This is a description of my video",
    "tags": ["cool", "video", "more keywords"],
    "categoryId": 22
  },
  "status": {
    "privacyStatus": "public",
    "embeddable": True,
    "license": "youtube"
  }
}

दूसरा चरण - फिर से शुरू किए जा सकने वाले सेशन का यूआरआई सेव करना

अगर आपका अनुरोध पूरा हो जाता है, तो एपीआई सर्वर 200 (OK) एचटीटीपी स्टेटस कोड के साथ जवाब देगा. साथ ही, जवाब में Location एचटीटीपी हेडर शामिल होगा, जो फिर से शुरू किए जा सकने वाले सेशन के यूआरआई की जानकारी देता है. इस यूआरआई का इस्तेमाल, वीडियो फ़ाइल अपलोड करने के लिए किया जाएगा.

नीचे दिए गए उदाहरण में, पहले चरण में किए गए अनुरोध के लिए एपीआई का जवाब दिखाया गया है:

HTTP/1.1 200 OK
Location: https://www.googleapis.com/upload/youtube/v3/videos?uploadType=resumable&upload_id=xa298sd_f&part=snippet,status,contentDetails
Content-Length: 0

तीसरा चरण - वीडियो फ़ाइल अपलोड करना

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

PUT UPLOAD_URL HTTP/1.1
Authorization: Bearer AUTH_TOKEN
Content-Length: CONTENT_LENGTH
Content-Type: CONTENT_TYPE

BINARY_FILE_DATA

अनुरोध, एचटीटीपी अनुरोध के ये हेडर सेट करता है:

Authorization – अनुरोध के लिए अनुमति टोकन.
Content-Length – अपलोड की जा रही फ़ाइल का साइज़. यह वैल्यू, पहले चरण में X-Upload-Content-Length एचटीटीपी अनुरोध हेडर की वैल्यू जैसी होनी चाहिए.
Content-Type – अपलोड की जा रही फ़ाइल का MIME टाइप. यह वैल्यू, पहले चरण में X-Upload-Content-Type एचटीटीपी अनुरोध हेडर की वैल्यू जैसी होनी चाहिए.

चौथा चरण - अपलोड की प्रोसेस पूरी करना

आपके अनुरोध के बाद, इनमें से कोई एक स्थिति हो सकती है:

आपका वीडियो अपलोड हो गया है.

एपीआई सर्वर, एचटीटीपी 201 (Created) रिस्पॉन्स कोड के साथ जवाब देता है. रिस्पॉन्स का मुख्य हिस्सा, आपका बनाया गया video रिसॉर्स होता है.
आपका वीडियो अपलोड नहीं हो सका, लेकिन उसे फिर से अपलोड किया जा सकता है.

इनमें से किसी भी मामले में, अपलोड फिर से शुरू किया जा सकता है:
- आपके अनुरोध में रुकावट आई है, क्योंकि आपके ऐप्लिकेशन और एपीआई सर्वर के बीच का कनेक्शन टूट गया है. ऐसे में, आपको एपीआई से कोई जवाब नहीं मिलेगा.
- एपीआई के रिस्पॉन्स में, इनमें से कोई एक 5xx रिस्पॉन्स कोड शामिल होता है. इनमें से कोई भी कोड मिलने के बाद, अपलोड फिर से शुरू करते समय आपके कोड को एक्सपोनेंशियल बैकऑफ़ की रणनीति का इस्तेमाल करना चाहिए.
  - 500 – Internal Server Error
  - 502 – Bad Gateway
  - 503 – Service Unavailable
  - 504 – Gateway Timeout
अपलोड की प्रोसेस फिर से शुरू करने के लिए, अपलोड की स्थिति देखने और अपलोड की प्रोसेस फिर से शुरू करने के लिए, यहां दिए गए निर्देशों का पालन करें. ध्यान रखें कि फिर से शुरू किए जा सकने वाले हर सेशन के यूआरआई की समयसीमा तय होती है और वह समयसीमा खत्म होने पर यूआरआई काम नहीं करता. इसलिए, हमारा सुझाव है कि सेशन यूआरआई मिलने के बाद, फिर से शुरू किया जा सकने वाला अपलोड शुरू करें. साथ ही, रुकावट आने के कुछ समय बाद, रुके हुए अपलोड को फिर से शुरू करें.
आपका अपलोड हमेशा के लिए पूरा नहीं हो सका.

अपलोड न हो पाने की स्थिति में, जवाब में गड़बड़ी का जवाब शामिल होता है. इससे, अपलोड न हो पाने की वजह के बारे में पता चलता है. अगर अपलोड हमेशा के लिए पूरा नहीं होता है, तो एपीआई के रिस्पॉन्स में ऊपर दिए गए कोड के अलावा, 4xx या 5xx रिस्पॉन्स कोड दिखेगा.

अगर सेशन के खत्म हो चुके यूआरआई के साथ अनुरोध भेजा जाता है, तो सर्वर 404 एचटीटीपी रिस्पॉन्स कोड (Not Found) दिखाता है. इस मामले में, आपको फिर से शुरू किया जा सकने वाला नया अपलोड शुरू करना होगा, नया सेशन यूआरआई पाना होगा, और नए यूआरआई का इस्तेमाल करके अपलोड को शुरू से शुरू करना होगा.

चौथा चरण: अपलोड की स्थिति देखना

बीच में रुके हुए अपलोड की स्थिति देखने के लिए, अपलोड के उस यूआरएल पर खाली PUT अनुरोध भेजें जिसे आपने दूसरे चरण में पाया था और तीसरे चरण में इस्तेमाल किया था. अपने अनुरोध में, Content-Range हेडर की वैल्यू को bytes */CONTENT_LENGTH पर सेट करें. यहां CONTENT_LENGTH, अपलोड की जा रही फ़ाइल का साइज़ है.

PUT UPLOAD_URL HTTP/1.1
Authorization: Bearer AUTH_TOKEN
Content-Length: 0
Content-Range: bytes */CONTENT_LENGTH

चौथा चरण: एपीआई से मिले रिस्पॉन्स को प्रोसेस करना

अगर अपलोड पहले ही पूरा हो चुका है, तो एपीआई वही रिस्पॉन्स दिखाएगा जो अपलोड पूरा होने पर दिखाया गया था. भले ही, अपलोड पूरा हो गया हो या नहीं.

हालांकि, अगर अपलोड में रुकावट आई है या वह अब भी जारी है, तो एपीआई के रिस्पॉन्स में एचटीटीपी 308 (Resume Incomplete) रिस्पॉन्स कोड होगा. जवाब में, Range हेडर से पता चलता है कि फ़ाइल के कितने बाइट पहले ही अपलोड हो चुके हैं.

हेडर वैल्यू को 0 से इंडेक्स किया जाता है. इसलिए, 0-999999 की हेडर वैल्यू से पता चलता है कि फ़ाइल के पहले 1,000,000 बाइट अपलोड हो चुके हैं.
अगर अभी तक कुछ भी अपलोड नहीं किया गया है, तो एपीआई के रिस्पॉन्स में Range हेडर शामिल नहीं होगा.

यहां दिए गए सैंपल रिस्पॉन्स में, फिर से शुरू किए जा सकने वाले अपलोड के लिए एपीआई रिस्पॉन्स का फ़ॉर्मैट दिखाया गया है:

308 Resume Incomplete
Content-Length: 0
Range: bytes=0-999999

अगर एपीआई रिस्पॉन्स में Retry-After हेडर भी शामिल है, तो अपलोड को फिर से शुरू करने का समय तय करने के लिए, उस हेडर की वैल्यू का इस्तेमाल करें.

चौथा चरण: अपलोड फिर से शुरू करना

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

PUT UPLOAD_URL HTTP/1.1
Authorization: Bearer AUTH_TOKEN
Content-Length: REMAINING_CONTENT_LENGTH
Content-Range: bytes FIRST_BYTE-LAST_BYTE/TOTAL_CONTENT_LENGTH

PARTIAL_BINARY_FILE_DATA

आपको ये एचटीटीपी अनुरोध हेडर सेट करने होंगे:

Authorization – अनुरोध के लिए अनुमति टोकन.
Content-Length – उस कॉन्टेंट का साइज़, बाइट में जो अब तक अपलोड नहीं किया गया है. अगर किसी फ़ाइल का बाकी हिस्सा अपलोड किया जा रहा है, तो इस वैल्यू का हिसाब लगाने के लिए, TOTAL_CONTENT_LENGTH वैल्यू से FIRST_BYTE वैल्यू को घटाएं. दोनों वैल्यू का इस्तेमाल Content-Range हेडर में किया जाता है.
Content-Range – फ़ाइल का वह हिस्सा जिसे अपलोड किया जा रहा है. हेडर वैल्यू में तीन वैल्यू होती हैं:
- FIRST_BYTE – उस बाइट नंबर का 0 पर आधारित अंकों वाला इंडेक्स जिससे अपलोड फिर से शुरू किया जा रहा है. यह वैल्यू, पिछले चरण में रीट्रिव किए गए Range हेडर में मौजूद दूसरी वैल्यू से एक नंबर ज़्यादा है. पिछले उदाहरण में, Range हेडर की वैल्यू 0-999999 थी. इसलिए, फिर से शुरू किए गए अपलोड में पहला बाइट 1000000 होगा.
- LAST_BYTE – अपलोड की जा रही बाइनरी फ़ाइल के आखिरी बाइट का 0 पर आधारित अंकों वाला इंडेक्स. आम तौर पर, यह फ़ाइल का आखिरी बाइट होता है. उदाहरण के लिए, अगर फ़ाइल का साइज़ 3000000 बाइट है, तो फ़ाइल का आखिरी बाइट 2999999 नंबर होगा.
- TOTAL_CONTENT_LENGTH – वीडियो फ़ाइल का कुल साइज़, बाइट में. यह वैल्यू, ओरिजनल अपलोड रिक्वेस्ट में बताए गए Content-Length हेडर से मेल खाती है.
ध्यान दें: बाइनरी फ़ाइल का ऐसा ब्लॉक अपलोड नहीं किया जा सकता जो लगातार न हो. अगर कोई ऐसा ब्लॉक अपलोड किया जाता है जो लगातार नहीं है, तो बाकी बचे बाइनरी कॉन्टेंट को अपलोड नहीं किया जाएगा.

इसलिए, फिर से शुरू किए गए अपलोड में अपलोड किया गया पहला बाइट, YouTube पर पहले से अपलोड किए गए आखिरी बाइट के बाद का होना चाहिए. (चौथे चरण के दूसरे हिस्से में, Range हेडर के बारे में चर्चा देखें.

इसलिए, अगर Range हेडर का आखिरी बाइट 999999 है, तो अपलोड को फिर से शुरू करने के अनुरोध का पहला बाइट 1000000 होना चाहिए. (दोनों नंबर, 0 पर आधारित इंडेक्स का इस्तेमाल करते हैं.) अगर अपलोड को 999999 या उससे पहले के बाइट (ओवरलैप होने वाले बाइट) या 1000001 या उससे बाद के बाइट (बाइट को स्किप करना) से फिर से शुरू करने की कोशिश की जाती है, तो कोई भी बाइनरी कॉन्टेंट अपलोड नहीं किया जाएगा.

फ़ाइल को अलग-अलग हिस्सों में अपलोड करना

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

किसी फ़ाइल को अलग-अलग हिस्सों में अपलोड करने के निर्देश, इस गाइड में पहले बताई गई चार चरणों वाली प्रोसेस से मिलते-जुलते हैं. हालांकि, फ़ाइल को एक बार में अपलोड करने के अनुरोध (ऊपर दिया गया तीसरा चरण) और अपलोड को फिर से शुरू करने के अनुरोध (ऊपर दिया गया 4.3 चरण), दोनों में Content-Length और Content-Range हेडर वैल्यू अलग-अलग सेट की जाती हैं. ऐसा तब होता है, जब फ़ाइल को कई हिस्सों में अपलोड किया जा रहा हो.

Content-Length हेडर की वैल्यू से, उस चंक का साइज़ पता चलता है जिसे अनुरोध भेज रहा है. चंक के साइज़ से जुड़ी इन सीमाओं का ध्यान रखें:
- चंक का साइज़, 256 केबी का मल्टीपल होना चाहिए. (यह पाबंदी आखिरी चंक पर लागू नहीं होती, क्योंकि हो सकता है कि पूरी फ़ाइल का साइज़ 256 केबी का मल्टीपल न हो.) याद रखें कि बड़े डेटा चंक ज़्यादा असरदार होते हैं.
- अपलोड के क्रम में हर अनुरोध के लिए, चंक का साइज़ एक जैसा होना चाहिए. हालांकि, आखिरी अनुरोध के लिए ऐसा नहीं है. आखिरी अनुरोध में, फ़ाइनल चंक का साइज़ तय किया जाता है.
Content-Range हेडर से पता चलता है कि अनुरोध में जिस फ़ाइल को अपलोड किया जा रहा है उसमें कितने बाइट हैं. इस वैल्यू को सेट करते समय, चौथे चरण में Content-Range हेडर सेट करने के निर्देश लागू होते हैं.

उदाहरण के लिए, bytes 0-524287/2000000 की वैल्यू से पता चलता है कि अनुरोध, 2,000,000 बाइट की फ़ाइल में पहले 5,24,288 बाइट (256 x 2048) भेज रहा है.

यहां दिए गए उदाहरण में, अनुरोधों की सीरीज़ के पहले अनुरोध का फ़ॉर्मैट दिखाया गया है. इस अनुरोध से, 2,000,000 बाइट की फ़ाइल को कई हिस्सों में अपलोड किया जाएगा:

PUT UPLOAD_URL HTTP/1.1
Authorization: Bearer AUTH_TOKEN
Content-Length: 524888
Content-Type: video/*
Content-Range: bytes 0-524287/2000000

{bytes 0-524287}

अगर आखिरी अनुरोध के अलावा कोई अन्य अनुरोध पूरा हो जाता है, तो एपीआई सर्वर 308 (Resume Incomplete) रिस्पॉन्स के साथ जवाब देता है. जवाब का फ़ॉर्मैट वही होगा जो ऊपर चौथा चरण: एपीआई के जवाब को प्रोसेस करना में बताया गया है.

अगले चंक को कहां से शुरू करना है, यह तय करने के लिए एपीआई रिस्पॉन्स के Range हेडर में दी गई ऊपरी वैल्यू का इस्तेमाल करें. चौथा चरण: अपलोड फिर से शुरू करना में बताए गए तरीके से, PUT अनुरोध भेजते रहें. इससे, फ़ाइल के अगले हिस्से अपलोड किए जा सकेंगे. ऐसा तब तक करें, जब तक पूरी फ़ाइल अपलोड न हो जाए.

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

अगर किसी अनुरोध में रुकावट आती है या आपके ऐप्लिकेशन को कोई 5xx रिस्पॉन्स कोड मिलता है, तो अपलोड पूरा करने के लिए चौथे चरण में बताई गई प्रोसेस अपनाएं. हालांकि, फ़ाइल के बाकी हिस्से को अपलोड करने के बजाय, उस हिस्से को अपलोड करना जारी रखें जहां से अपलोड को फिर से शुरू किया जा रहा है. फ़ाइल अपलोड करने की प्रोसेस को फिर से शुरू करने के लिए, अपलोड के स्टेटस की जांच करना न भूलें. यह न मानें कि सर्वर को पिछले अनुरोध में भेजे गए सभी (या कोई भी) बाइट नहीं मिले.

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