आपके यूज़र्स पहले से जानते हैं कि छोटा क्लिप क्या होता है। उनके पास जो नहीं है, वह है आपके ऐप के भीतर ही क्लिप बनाने का तरीका, बिना दूसरे टैब पर कूदे और फ़ाइल लेकर लौटे। Picasso IA API के साथ आपका ऐप हर जनरेशन के लिए एक अनुरोध भेजता है, जिसमें एक वीडियो मॉडल और उसके इनपुट बताए जाते हैं, और तैयार क्लिप एक फ़ाइल के रूप में लौटता है जिसे आप दिखा सकते हैं, सहेज सकते हैं और जाँच सकते हैं। अनुरोध आसान हिस्सा है। असली काम उसके आसपास का प्रोडक्ट है: इंतज़ार, क्रेडिट, मॉडरेशन, स्टोरेज और अधिकार।
वीडियो फ़ीचर आपके प्रोडक्ट का मकसद बदल देता है। कार्ड बनाने वाला ऐप जो कार्ड को चला सके, यात्रा डायरी जो तस्वीर को चलती पोस्टकार्ड बना दे, गेम टूल जो किसी किरदार का छोटा इंट्रो बनाए, स्टोर डैशबोर्ड जो प्रोडक्ट क्लिप का ड्राफ़्ट तैयार करे: हर मामले में यूज़र वहीं रहता है जहाँ उसका काम पहले से है, एक्सपोर्ट, कन्वर्ट और इम्पोर्ट करने के बजाय।
दूसरा कारण है विकल्प। Picasso IA कैटलॉग में 502 मॉडल हैं, जिनमें 121 टेक्स्ट से वीडियो श्रेणी में हैं और 28 वीडियो एडिटिंग में। बनाने वाले के लिए यह मायने रखता है, क्योंकि कोई एक वीडियो मॉडल हर चीज़ में सबसे अच्छा नहीं होता। कोई इंसान को अच्छे से संभालता है, कोई कैमरा निर्देश को बारीकी से मानता है, कोई ड्राफ़्ट के लिए सस्ता विकल्प है। API को उसी कैटलॉग और उसी क्रेडिट सिस्टम तक पहुँचने के लिए सोचा गया है जो टूलकिट में है, इसलिए आप अपना फ़ीचर किसी एक इंजन की आदतों से नहीं बाँधते।
ईमानदार नज़रिया: यह जनरेशन देने का तरीका है, नतीजों की गारंटी देने का नहीं। आपके यूज़र्स का बनाया हर क्लिप एक मॉडल की प्रॉम्प्ट की व्याख्या है, और आपके प्रोडक्ट को इसी तथ्य के इर्द-गिर्द डिज़ाइन होना चाहिए, इसके बावजूद नहीं।
किसी भी आर्किटेक्चर से पहले वे तीन या चार काम लिख लीजिए जो कोई व्यक्ति आपके फ़ीचर में करता है। ज़्यादातर वीडियो फ़ीचर क्रियाओं के उसी छोटे समूह में सिमट जाते हैं, और उन्हें जल्दी नाम देने से इंटरफ़ेस ईमानदार रहता है।
पहला है टेक्स्ट से वीडियो: यूज़र एक या दो वाक्यों में दृश्य और गति बताता है और क्लिप पाता है। दूसरा है इमेज से वीडियो: यूज़र अपनी कोई तस्वीर जोड़ता है, जैसे प्रोडक्ट फ़ोटो, ड्रॉइंग या अपना पोर्ट्रेट, और उसे चलाने को कहता है। तीसरा है दोबारा कोशिश: पहला क्लिप क़रीब है पर ग़लत, तो वह एक शब्द बदलकर फिर जनरेट करता है। चौथा, अगर आपके प्रोडक्ट को चाहिए, बाद का छोटा एडिट है, जैसे ट्रिम करना, अपस्केल करना या आवाज़ जोड़ना, जिसे कैटलॉग के दूसरे मॉडल कवर करते हैं। दूसरी क्रिया कैसे काम करती है यह देखने के लिए तस्वीरों को वीडियो में बदलें टूलकिट में पूरा रास्ता दिखाता है।
इस सूची में कुछ भी ऐसा नहीं है जिसके लिए यूज़र को जानना पड़े कि कौन सा मॉडल चला। आप चुनने का विकल्प दे सकते हैं या उसके लिए ख़ुद चुन सकते हैं।
पाँच चिंताएँ तय करती हैं कि वीडियो फ़ीचर भरोसेमंद लगेगा या झुंझलाहट भरा। इनमें से कोई भी प्रोग्रामिंग की समस्या नहीं है, और हर एक का एक रूप है जो यूज़र को दिखता है। यह तालिका योजना की शीट है: यूज़र क्या अनुभव करता है, और कौन सा फ़ैसला आपका है।
| चिंता | आपका यूज़र क्या अनुभव करता है | आपका फ़ैसला |
|---|
| इंतज़ार का समय | क्लिप तुरंत नहीं बनता, इसलिए स्क्रीन को उसकी एक स्थिति चाहिए | प्रगति दिखाना, जाकर लौटने देना, या सूचना भेजना |
| क्रेडिट | हर जनरेशन में क्रेडिट लगते हैं जो मॉडल और सेटिंग पर निर्भर हैं | लागत यूज़र पर डालना, ख़ुद उठाना, या क्लिप की संख्या सीमित करना |
| मॉडरेशन | कुछ प्रॉम्प्ट या तस्वीरें कभी क्लिप नहीं बननी चाहिए | इनपुट छानना, आउटपुट जाँचना, और रिपोर्ट पर क्या हो यह तय करना |
| स्टोरेज | लौटी फ़ाइल वहाँ रहनी चाहिए जहाँ वे उसे दोबारा पा सकें | कहाँ रखी जाए, कितने समय और कौन हटा सकता है |
| अधिकार | क्लिप में किसी का चेहरा, आवाज़ या डिज़ाइन दिख सकता है | शर्त रखना कि लोग केवल अपनी सामग्री या काल्पनिक पात्र अपलोड करें |
इंतज़ार के समय पर सबसे ज़्यादा डिज़ाइन ध्यान चाहिए, क्योंकि यही यूज़र महसूस करता है। जनरेशन में सचमुच समय लगता है और यह मॉडल और सेटिंग के साथ बदलता है, इसलिए एक संख्या के बजाय एक दायरे के लिए बनाइए। जो यूज़र क्लिप बनते समय आपका ऐप इस्तेमाल करता रह सकता है, वह लंबा इंतज़ार माफ़ कर देता है।
क्रेडिट दूसरा शांत मुद्दा है। लागत चुने गए मॉडल और सेटिंग से आती है, और प्लान प्राइसिंग पेज पर हैं। जल्दी तय कीजिए कि आपके यूज़र्स क्रेडिट देखेंगे या नहीं, क्योंकि इससे आपका इंटरफ़ेस बदलता है: जो ऐप आपके क्रेडिट उनकी ओर से खर्च करता है उसे सीमाएँ चाहिए, और जो उन्हें आगे बढ़ाता है उसे क्लिक से पहले साफ़ क़ीमत चाहिए।
डिज़ाइन नियम: क्लिप को ऐसे नतीजे की तरह लीजिए जो बाद में आता है, ऐसे जवाब की तरह नहीं जिसका आप इंतज़ार करते हैं। अगर आपकी स्क्रीन तभी चलती है जब जवाब तेज़ हो, तो पहली बार किसी मॉडल के धीमे होते ही वह फ़ेल हो जाएगी।
आप इस चक्र का ज़्यादातर हिस्सा आज बिना कुछ लिखे चला सकते हैं, क्योंकि टूलकिट वही कैटलॉग चलाता है जिसे API सामने रखने के लिए सोची गई है। इसका इस्तेमाल यह तय करने में कीजिए कि आपके फ़ीचर को यूज़र्स से क्या माँगना चाहिए, फिर वही ढाँचा अपने ऐप में बनाइए।
- टूलकिट में प्रॉम्प्ट आज़माएँ। टूलकिट खोलिए, veo-3.1 या kling-v3-video जैसा वीडियो मॉडल चुनिए और ठीक वैसा प्रॉम्प्ट लिखिए जैसा आपके यूज़र्स लिखेंगे, ख़राब वाले भी।
- अपने अकाउंट में एक की बनाएँ। API उस की से चलती है जो आप अपने अकाउंट में बनाते हैं। इसे पासवर्ड की तरह रखिए: अपने सर्वर पर रखिए, कभी ऐसे ऐप या पेज में नहीं जिसे लोग डाउनलोड या जाँच सकें।
- हर क्लिप के लिए एक अनुरोध भेजें। आपका सर्वर मॉडल और इनपुट बताता है, एक प्रॉम्प्ट और, तस्वीर को चलाने वाले मॉडलों के लिए, एक तस्वीर। आपका ऐप यूज़र को तुरंत बताता है कि उसका क्लिप बन रहा है।
- इंतज़ार करें, फिर फ़ाइल लें। नतीजा एक फ़ाइल के रूप में लौटता है जिसे आप डाउनलोड कर सकते हैं। उस पर अपनी जाँच का चरण चलाइए, फिर उसे वहाँ रखिए जहाँ यूज़र उसे दोबारा पा सके।
- क्लिप दिखाएँ और क्रेडिट गिनें। क्लिप को यूज़र की लाइब्रेरी में रखिए, जनरेशन की लागत दर्ज कीजिए और कुल को अपने अकाउंट के प्लान से मिलाइए।
तीसरे कदम से पहले पहला कदम दर्जन भर असली प्रॉम्प्ट के साथ चलाइए। किसी अजनबी के लिखे प्रॉम्प्ट ही आपके मॉडरेशन फ़ैसलों की जड़ हैं।
पूरे फ़ीचर के लिए एक ही मॉडल पर टिकना ज़रूरी नहीं। भूमिकाओं में सोचिए, टूलकिट में कुछ आज़माइए और हर इस्तेमाल के हिसाब से चुनिए। ये ऐसे मॉडल हैं जो आज कैटलॉग में मौजूद हैं, सब टेक्स्ट से वीडियो श्रेणी में, जिसमें इमेज से वीडियो वाले रूप भी आते हैं।
किसी ख़ास पल पर बढ़िया नतीजे के लिए google का veo-3.1 या kwaivgi का kling-v3-video से शुरू कीजिए। छोटे, चंचल क्लिप के लिए bytedance का seedance-2.0 और minimax का hailuo-2.3 चलाने लायक हैं। alibaba का wan-3 और openai का sora-2 पहली तुलना पूरी करते हैं, और lightricks का ltx-2.3-fast वह नाम है जिसे तब आज़माइए जब देखना हो कि हल्का मॉडल ड्राफ़्ट में कैसा व्यवहार करता है।
इसे रैंकिंग की तरह मत पढ़िए। हर एक में वही तीन प्रॉम्प्ट चलाइए, चेहरे, हाथ, गति और प्रॉम्प्ट कितना माना गया यह देखिए, और लिख लीजिए कि कौन सा मॉडल किस काम में जीतता है। अगर आपका प्रोडक्ट स्थिर तस्वीरों को क्लिप बनाता है, तो AI प्रोडक्ट डेमो वीडियो पेज दिखाता है कि प्रोडक्ट शॉट को एनिमेशन झेलने के लिए क्या चाहिए। अपनी छोटी सूची पक्की करने से पहले कैटलॉग में पूरी सूची देखिए।
जनरेशन API आपको क्लिप देती है। वह आपको वीडियो प्रोडक्ट नहीं देती। ये वे सीमाएँ हैं जिनके हिसाब से योजना बनानी चाहिए, ताकि लॉन्च के बाद कोई भी चौंकाए नहीं।
- समय: हर क्लिप को बनने में कुछ समय लगता है और समय मॉडल और सेटिंग पर निर्भर है। आपके इंटरफ़ेस को इंतज़ार की स्थिति, बाद में लौटने का तरीका और फ़ेल होने वाले अनुरोध की योजना चाहिए।
- लागत: हर जनरेशन क्रेडिट खर्च करती है और भारी मॉडल ज़्यादा खर्च करते हैं। बिना सीमा का फ़ीचर क्रेडिट उम्मीद से तेज़ जला सकता है, इसलिए पहले यूज़र से पहले सीमाएँ तय कीजिए।
- अंतर: मॉडल अलग होते हैं, और वही प्रॉम्प्ट अलग इंजनों पर, यहाँ तक कि अलग कोशिशों पर भी, अलग नतीजे देता है। आप यूज़र से किसी ख़ास क्लिप का वादा नहीं कर सकते, सिर्फ़ एक कोशिश का।
- जाँच: आउटपुट में अजीब हाथ, पिघला टेक्स्ट या भटकता चेहरा हो सकता है। किसी इंसान या किसी नियम को क्लिप देखने होंगे इससे पहले कि वे वहाँ दिखें जहाँ दूसरे लोग देखते हैं।
- अधिकार: जो फ़ाइल आपको मिलती है वह तय नहीं करती कि वह जो दिखाती है उसका मालिक कौन है। आपकी शर्तों में लिखा होना चाहिए कि यूज़र केवल अपनी सामग्री या काल्पनिक पात्र अपलोड करें, किसी असली व्यक्ति की छवि उसकी सहमति के बिना कभी नहीं।
इनमें से कुछ भी फ़ीचर के ख़िलाफ़ तर्क नहीं है। यह उसका दायरा तय करने के पक्ष में तर्क है: छोटे क्लिप, साफ़ इंतज़ार की स्थिति, दिखते क्रेडिट और जाँच का चरण। अनुमान के मुताबिक़ चलने वाला छोटा फ़ीचर लोगों को चौंकाने वाले बड़े फ़ीचर से बेहतर है।
क्या मेरे यूज़र्स मेरा ऐप छोड़े बिना वीडियो बना सकते हैं?
Picasso IA API का मकसद यही है। आपका सर्वर हर क्लिप के लिए एक अनुरोध भेजता है, जिसमें मॉडल और उसके इनपुट बताए जाते हैं, और नतीजा एक फ़ाइल के रूप में लौटता है जिसे आप डाउनलोड करके अपनी ही स्क्रीन पर दिखा सकते हैं। आपके यूज़र्स कोई दूसरी साइट नहीं देखते। जो वे नोटिस करेंगे वह इंतज़ार है, क्योंकि क्लिप को बनने में समय लगता है, इसलिए अनुभव आपके बनाए किसी भी और हिस्से से ज़्यादा एक अच्छी प्रगति स्थिति पर टिका है।
क्या मुझे API की चाहिए और उसे कैसे संभालूँ?
हाँ। एक्सेस उस की से चलता है जो आप अपने अकाउंट में बनाते हैं, और उसे पासवर्ड की तरह संभालना चाहिए। उसे अपने सर्वर पर रखिए, सीक्रेट स्टोर या एनवायरनमेंट सेटिंग से लोड कीजिए, और उसे कभी मोबाइल ऐप, ब्राउज़र बंडल या पब्लिक रिपॉज़िटरी में मत डालिए। अगर लगे कि वह लीक हो गई, तो अपने अकाउंट से उसे बदलिए और सर्वर अपडेट कीजिए। आपके यूज़र्स को उसे कभी देखने की ज़रूरत नहीं।
वीडियो फ़ीचर में मैं कौन से मॉडल दे सकता हूँ?
कैटलॉग में कुल 502 में से 121 टेक्स्ट से वीडियो और 28 वीडियो एडिटिंग मॉडल हैं, और टूलकिट आज इन सबको चलाता है। पहले आज़माने लायक नामों में veo-3.1, kling-v3-video, seedance-2.0, hailuo-2.3, wan-3 और sora-2 हैं। हर मॉडल का पेज देखिए कि वह क्या स्वीकार करता है, क्योंकि कुछ सिर्फ़ प्रॉम्प्ट लेते हैं और कुछ तस्वीर से शुरू हो सकते हैं। चुनने से पहले अपने प्रॉम्प्ट टूलकिट में चलाइए।
मेरे यूज़र्स को क्लिप के लिए कितना इंतज़ार करना होगा?
यह मॉडल, लंबाई और सेटिंग पर निर्भर है, इसलिए यह पेज कोई संख्या नहीं बताता। एक दायरे की योजना बनाइए: कुछ क्लिप जल्दी लौटेंगे और कुछ साफ़ तौर पर ज़्यादा समय लेंगे। सुरक्षित डिज़ाइन यह है कि अनुरोध तुरंत पक्का करें, दिखाएँ कि काम चल रहा है, व्यक्ति को आपका ऐप इस्तेमाल करते रहने दें और फ़ाइल तैयार होने पर सूचना दें। असली इंतज़ार महसूस करने के लिए अपने चुने मॉडल टूलकिट में आज़माइए।
जब मेरे यूज़र्स क्लिप बनाते हैं तो क्रेडिट कैसे काम करते हैं?
जनरेट करने में क्रेडिट लगते हैं और मात्रा चुने गए मॉडल और सेटिंग पर निर्भर है। API को टूलकिट वाला ही क्रेडिट सिस्टम इस्तेमाल करने के लिए सोचा गया है, इसलिए वहाँ जो दिखता है वही उम्मीद रखिए। प्लान और उनकी सीमाएँ प्राइसिंग पेज पर हैं, और नए अकाउंट को टेस्ट के लिए मुफ़्त क्रेडिट मिलते हैं। आप तय करते हैं कि लागत ख़ुद उठाएँ, यूज़र्स पर डालें या हर व्यक्ति के क्लिप की संख्या सीमित करें।
वीडियो फ़ीचर में मुझे क्या मॉडरेट करना चाहिए?
दो जगह: जो अंदर आता है और जो बाहर जाता है। इनपुट में तय कीजिए कि कौन से प्रॉम्प्ट और अपलोड की गई तस्वीरें आप ठुकराते हैं, जैसे ऐसे असली लोगों की तस्वीरें जो दिखने के लिए सहमत नहीं हुए। आउटपुट में क्लिप सार्वजनिक रूप से साझा करने से पहले जाँचिए, क्योंकि मॉडल अजीब या अवांछित नतीजे दे सकते हैं। यूज़र्स को क्लिप रिपोर्ट करने का तरीका दीजिए और तय कीजिए कि उसके बाद क्या होगा। आपकी अपनी उपयोग की शर्तों में यह सब साफ़ लिखा होना चाहिए।
बनाए गए क्लिप मुझे कहाँ रखने चाहिए?
नतीजा एक फ़ाइल के रूप में लौटता है जिसे आप डाउनलोड कर सकते हैं, इसलिए उसे सँभालना आपके ऊपर है। उसे ऐसे स्टोरेज में सहेजिए जिसे आप नियंत्रित करते हैं, उस यूज़र से जोड़कर जिसने उसे माँगा, और तय कीजिए कि वह कितने समय रहे और कौन उसे हटा सकता है। इस पर भरोसा मत कीजिए कि लौटाई गई फ़ाइल हमेशा उपलब्ध रहेगी। अगर क्लिप साझा हो सकते हैं, तो एक्सेस के नियम शुरू से सोचिए।
मेरे यूज़र्स जो क्लिप बनाते हैं उनका मालिक कौन है?
दो चीज़ें जाँचिए। पहला, इनपुट के अधिकार: जो यूज़र अपने प्रोडक्ट की तस्वीर अपलोड करता है वह उससे अलग स्थिति में है जो किसी और का आर्टवर्क अपलोड करता है, और जनरेटर यह नहीं बदलता कि तस्वीर जो दिखाती है उसका मालिक कौन है। दूसरा, आउटपुट के लिए आपके प्लान की शर्तें। अपने नियम यूज़र्स के सामने रखिए, और अगर क्लिप बेचे या व्यावसायिक रूप से प्रकाशित किए जाएँगे तो किसी योग्य व्यक्ति से उनकी समीक्षा करवाइए।
क्या यूज़र्स अपनी या दूसरों की तस्वीरें चला सकते हैं?
सिर्फ़ अपनी, किसी ऐसे व्यक्ति की जिसने साफ़ सहमति दी हो, या किसी काल्पनिक पात्र की। किसी पहचाने जा सकने वाले असली व्यक्ति की सहमति के बिना कभी नहीं, और किसी नाबालिग की तस्वीर कभी नहीं जो किसी और ने अपलोड की हो। इसे अपनी अपलोड स्क्रीन पर एक छोटी साफ़ पंक्ति में, और अपनी शर्तों में शामिल कीजिए। साफ़ नियम चतुर फ़िल्टर से बेहतर है।
अगर क्लिप ग़लत निकले या अनुरोध फ़ेल हो जाए तो?
दोनों के लिए योजना बनाइए। ग़लत क्लिप सामान्य हैं: यूज़र्स को प्रॉम्प्ट बदलकर दोबारा कोशिश करने दीजिए, और बटन दबाने से पहले दोबारा कोशिश की क्रेडिट लागत दिखाइए। फ़ेल अनुरोधों को साफ़ संदेश और दोबारा कोशिश का तरीका चाहिए। अगर आपकी तरफ़ कुछ टूटा लगे या अकाउंट के बारे में सवाल हो, तो सपोर्ट किसी इंसान तक सीधा रास्ता है।
शुरुआत का अच्छा तरीका है वे क्लिप आज़माना जो आपके यूज़र्स माँगेंगे। टूलकिट खोलिए, कुछ असली प्रॉम्प्ट दो या तीन वीडियो मॉडलों में चलाइए और लिखिए कि आपके फ़ीचर को क्या वादा करना है।