WebM को WebP में बदलें

किसी वेब पन्ने के लिए बनी तस्वीर अलग कसौटी पर परखी जाती है। कोई इसे इमेज-व्यूअर में नहीं खोलेगा; यह उन बीस चीज़ों में से एक होगी जो ब्राउज़र किसी के रुकने का फ़ैसला करते समय डाउनलोड करता है। इसका किलोबाइट में आकार हर विज़िटर चुकाई गई असली क़ीमत है।

यही JPG के बजाय WebP की पूरी दलील है। एक जैसा दिखने वाला नतीजा, लगभग तीस प्रतिशत कम बाइट, और मौजूदा ब्राउज़रों में सार्वभौमिक समर्थन। दर्जन भर ट्यूटोरियल थंबनेल के ग्रिड पर यह तस्वीर के वज़न का एक तिहाई हटाता है, बिना कोई नज़र आने वाला बदलाव।

WebP और WebM एक ही मेहनत से आते हैं। Google ने दोनों 2010 के आस-पास पेटेंट-बंधी फ़ॉर्मेट के रॉयल्टी-मुक्त जवाब के रूप में जारी किए, और WebP का स्थिर-तस्वीर संपीड़न VP8 की intra-frame कोडिंग से निकला — वही वीडियो-कोडेक जिस पर WebM बना।

इससे कन्वर्ज़न बिना नुक़सान वाला नहीं बनता, और यह साफ़ कहना ज़रूरी है ताकि कोई ऐसी उम्मीद न रखे। फ़्रेम पिक्सेल में डिकोड होकर शुरू से दोबारा एन्कोड होता है, तयशुदा गुणवत्ता 82 पर।

इस कन्वर्ज़न से सबसे काम की चीज़ भी सबसे साफ़ है: WebM से फ़्रेम लेकर उसे उसी वीडियो के poster के रूप में इस्तेमाल कीजिए। ब्राउज़र चलना शुरू होने तक पोस्टर दिखाता है, इसलिए लोग सबसे पहले वीडियो का ही एक असली फ़्रेम देखते हैं, काला चौकोर या बेमेल कोई स्टॉक तस्वीर नहीं।

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

फ़्रेम वीडियो के अपने पिक्सेल-नाप पर आता है, कुछ भी घटाया नहीं। 1080p की स्क्रीन-रिकॉर्डिंग 1920 गुणा 1080 की WebP देती है; 4K कैप्चर 3840 गुणा 2160। यह जान-बूझकर है — फ़्रेम का असली रिज़ॉल्यूशन होता है और इस कन्वर्ज़न का काम है वह अनुमानित नाप की बजाय जस का तस थमाना।

नाप बदलना आगे की चेन में होता है। जो भी आपका responsive srcset बनाता है, या आपका CMS का इमेज-पाइपलाइन, वे पहले से जानते हैं कि लेआउट को किन चौड़ाइयों की ज़रूरत है, और वे पूरे-रिज़ॉल्यूशन स्रोत से बेहतर काम करेंगे।

WebM के भीतर की तस्वीर हरकत के लिए एन्कोड हुई थी। वीडियो कोडेक अपने बिट वहाँ ख़र्च करता है जहाँ चीज़ें हिलती हैं और वहाँ बचाता है जहाँ नहीं, इस मान्यता पर कि कोई एक फ़्रेम को घूर कर नहीं देखेगा। किसी को रोकना ठीक वही करना है जो किसी के न करने की उम्मीद थी।

थंबनेल के लिए व्यावहारिक असर छोटा है, क्योंकि थंबनेल अपने असली नाप के एक हिस्से पर दिखता है और छोटा करना नरमी को अच्छे से छिपा देता है। यह तब मायने रखता है जब स्थिर तस्वीर बड़ी इस्तेमाल हो — हीरो इमेज, पूरी चौड़ाई का चित्रण — जहाँ पैन या स्क्रोल के बीच लिया फ़्रेम बाक़ी पन्ने के मुक़ाबले धुँधला दिखेगा।

ब्राउज़र अब समस्या नहीं; बाक़ी दुनिया कहीं और है। कुछ ईमेल क्लाइंट WebP नहीं दिखाते, इसलिए न्यूज़लेटर थंबनेल JPG होनी चाहिए। कुछ पुराने डेस्कटॉप ऐप्लिकेशन, प्रिंट-वर्कफ़्लो और कुछ अपलोड फ़ॉर्म अब भी फ़ॉर्मेट नकारते हैं।

ब्राउज़र के भीतर WebP को सार्वभौमिक मानना सुरक्षित है, यही इसे AVIF से ज़्यादा व्यावहारिक तयशुदा बनाता है। मंज़िल वेब पन्ने के अलावा कुछ भी हो — ईमेल, दस्तावेज़, प्रिंटर, फ़ॉर्म — तो JPG लीजिए और इस पर सोचना बंद कर दीजिए।

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

समय जान-बूझकर चुनना बेहतर है, सबको शून्य पर छोड़ने से। सारे थंबनेल में ख़ाली एडिटर या लोडिंग स्पिनर दिखने से विज़िटर को कुछ पता नहीं चलता कि कौन-सी वीडियो कौन-सी है।

जिन रिकॉर्डिंग को पोस्टर फ़्रेम चाहिए वे आमतौर पर वही होती हैं जो अभी लॉन्च नहीं हुईं — कोई प्रोडक्ट डेमो, फ़ीचर वॉकथ्रू, कोर्स मॉड्यूल। सिर्फ़ 60 KB का थंबनेल पाने के लिए पूरी वीडियो किसी कन्वर्टर पर अपलोड करना बहुत ज़्यादा उजागर करना है।

डिकोड और एन्कोड दोनों टैब में होते हैं, ब्राउज़र के पहले से मौजूद WebM-चलाने वाले कोडेक इस्तेमाल करते हुए। वीडियो ले जाने वाला कुछ भी भेजा नहीं जाता, कोई खाता नहीं और कोई दैनिक सीमा नहीं।