अक्सर पूछे जाने वाले प्रश्न

WebP क्या है? मुझे इसका इस्तेमाल क्यों करना चाहिए?

WebP, लॉसी और लॉसलेस कंप्रेशन का एक तरीका है. इसका इस्तेमाल, वेब पर मौजूद फ़ोटोग्राफ़िक, पारदर्शी, और ग्राफ़िकल इमेज की कई तरह की फ़ाइलों के लिए किया जा सकता है. लॉसी कंप्रेशन को अडजस्ट किया जा सकता है, ताकि उपयोगकर्ता फ़ाइल के साइज़ और इमेज क्वालिटी के बीच समझौता कर सके. WebP, आम तौर पर JPEG और JPEG 2000 की तुलना में 30% ज़्यादा कंप्रेस करता है. हालांकि, इससे इमेज की क्वालिटी में कोई कमी नहीं आती (तुलनात्मक अध्ययन देखें).

WebP फ़ॉर्मैट का मुख्य मकसद, छोटी और बेहतर दिखने वाली इमेज बनाना है. इससे वेब की स्पीड तेज़ होती है.

कौनसे वेब ब्राउज़र, WebP फ़ॉर्मैट के साथ काम करते हैं?

वेबसाइट की परफ़ॉर्मेंस को बेहतर बनाने में दिलचस्पी रखने वाले वेबमास्टर, अपनी मौजूदा इमेज के लिए ऑप्टिमाइज़ किए गए WebP विकल्प आसानी से बना सकते हैं. साथ ही, उन्हें उन ब्राउज़र पर टारगेट के आधार पर दिखा सकते हैं जो WebP फ़ॉर्मैट के साथ काम करते हैं.

  • WebP लॉसलेस फ़ॉर्मैट के साथ काम करता है
    • Google Chrome (डेस्कटॉप) 17+
    • Android के लिए Google Chrome का वर्शन 25 या इसके बाद का वर्शन
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 11.10+
    • नेटिव वेब ब्राउज़र, Android 4.0 (ICS) या इसके बाद के वर्शन
    • Safari 14+ (iOS 14+, macOS Big Sur+)
  • WebP लॉसलेस, लॉसलेस, और ऐल्फ़ा सपोर्ट
    • Google Chrome (डेस्कटॉप) 23 या इसके बाद का वर्शन
    • Android के लिए Google Chrome का वर्शन 25 या इसके बाद का वर्शन
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 12.10+
    • नेटिव वेब ब्राउज़र, Android 4.2+ (JB-MR1)
    • Pale Moon 26+
    • Safari 14+ (iOS 14+, macOS Big Sur+)
  • WebP ऐनिमेशन के लिए सहायता
    • Google Chrome (डेस्कटॉप और Android) 32+
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 19+
    • Safari 14+ (iOS 14+, macOS Big Sur+)

यह भी देखें:

मैं यह कैसे पता लगाऊं कि ब्राउज़र में WebP फ़ॉर्मैट काम करता है या नहीं?

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

Accept हेडर के ज़रिए सर्वर साइड कॉन्टेंट नेगोशिएशन

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

Modernizr

Modernizr, एक JavaScript लाइब्रेरी है. इसका इस्तेमाल वेब ब्राउज़र में HTML5 और CSS3 की सुविधाओं का पता लगाने के लिए किया जाता है. Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha, और Modernizr.webp.animation प्रॉपर्टी ढूंढें.

HTML5 <picture> एलिमेंट

HTML5 में <picture> एलिमेंट काम करता है. इसकी मदद से, प्राथमिकता के क्रम में एक से ज़्यादा इमेज टारगेट लिस्ट किए जा सकते हैं. इससे क्लाइंट, पहली इमेज का अनुरोध करेगा, जिसे वह सही तरीके से दिखा सकता है. HTML5 Rocks पर इस चर्चा को देखें. <picture> एलिमेंट, ज़्यादातर ब्राउज़र पर काम करता है.

अपनी JavaScript में

पहचान करने का एक और तरीका यह है कि किसी खास सुविधा का इस्तेमाल करने वाली बहुत छोटी WebP इमेज को डिकोड करने की कोशिश की जाए और यह देखा जाए कि वह डिकोड हो रही है या नहीं. उदाहरण:

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

ध्यान दें कि इमेज लोड करने की प्रोसेस, नॉन-ब्लॉकिंग और एसिंक्रोनस होती है. इसका मतलब है कि WebP के साथ काम करने वाले किसी भी कोड को कॉलबैक फ़ंक्शन में रखना चाहिए.

Google ने WebP को ओपन सोर्स के तौर पर क्यों रिलीज़ किया?

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

मैं अपनी निजी इमेज फ़ाइलों को WebP में कैसे बदलूं?

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

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

Windows:

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / macOS:

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

मैं WebP इमेज की क्वालिटी का आकलन कैसे करूं?

फ़िलहाल, WebP फ़ाइलों को ऐसे सामान्य फ़ॉर्मैट में बदलकर देखा जा सकता है जो बिना किसी नुकसान के कंप्रेस करता है. जैसे, PNG. इसके बाद, PNG फ़ाइलों को किसी भी ब्राउज़र या इमेज व्यूअर में देखा जा सकता है. WebP की क्वालिटी के बारे में तुरंत जानने के लिए, इस साइट पर गैलरी देखें. इसमें फ़ोटो की तुलना करने के लिए, उन्हें अगल-बगल दिखाया गया है.

मुझे सोर्स कोड कैसे मिलेगा?

कनवर्टर कोड, WebP ओपन-सोर्स प्रोजेक्ट पेज के डाउनलोड सेक्शन में उपलब्ध है. लाइटवेट डिकोडर और VP8 स्पेसिफ़िकेशन का कोड, WebM साइट पर उपलब्ध है. कंटेनर के स्पेसिफ़िकेशन के लिए, RIFF कंटेनर पेज देखें.

WebP इमेज का ज़्यादा से ज़्यादा साइज़ कितना हो सकता है?

WebP, VP8 के साथ बिटस्ट्रीम के तौर पर काम करता है. साथ ही, चौड़ाई और ऊंचाई के लिए 14 बिट का इस्तेमाल करता है. WebP इमेज के पिक्सल डाइमेंशन, ज़्यादा से ज़्यादा 16383 x 16383 होने चाहिए.

WebP फ़ॉर्मैट, किन कलर स्पेस के साथ काम करता है?

VP8 बिटस्ट्रीम के साथ काम करने वाला लॉसी WebP, सिर्फ़ 8-बिट Y'CbCr 4:2:0 (इसे अक्सर YUV420 कहा जाता है) इमेज फ़ॉर्मैट के साथ काम करता है. ज़्यादा जानकारी के लिए, कृपया RFC 6386 के सेक्शन 2, "फ़ॉर्मैट की खास जानकारी" में VP8 डेटा फ़ॉर्मैट और डिकोडिंग गाइड देखें.

लॉसलैस WebP सिर्फ़ RGBA फ़ॉर्मैट के साथ काम करता है. WebP लॉसलेस बिटस्ट्रीम स्पेसिफ़िकेशन देखें.

मेरी बिना क्वालिटी घटाए बनाई गई WebP फ़ाइल, ओरिजनल फ़ाइल से अलग क्यों है?

Simple Encoding API फ़ंक्शन (WebPEncodeLosslessRGB(), WebPEncodeLosslessBGR(), WebPEncodeLosslessRGBA(), WebPEncodeLosslessBGRA()), लाइब्रेरी की डिफ़ॉल्ट सेटिंग का इस्तेमाल करते हैं. बिना डेटा के नुकसान वाली क्वालिटी के लिए, इसका मतलब है कि 'बिलकुल सही' सेटिंग बंद है. पूरी तरह से पारदर्शी जगहों (यानी कि 0 के बराबर ऐल्फ़ा वैल्यू वाली जगहों) में आरजीबी वैल्यू में बदलाव किया जाएगा, ताकि कंप्रेशन को बेहतर बनाया जा सके. इससे बचने के लिए, WebPEncode() का इस्तेमाल करें और WebPConfig::exact को 1 पर सेट करें. Advanced Encoding API से जुड़ा दस्तावेज़ देखें.

क्या WebP इमेज का साइज़, सोर्स इमेज से बड़ा हो सकता है?

हां, आम तौर पर ऐसा तब होता है, जब लॉसलेस फ़ॉर्मैट से WebP लॉसलेस फ़ॉर्मैट में या इसके उलट फ़ॉर्मैट में बदला जाता है. ऐसा मुख्य रूप से, कलरस्पेस (YUV420 बनाम ARGB) में अंतर और इनके बीच कन्वर्ज़न की वजह से होता है.

आम तौर पर, ये तीन स्थितियां होती हैं:

  1. अगर सोर्स इमेज, बिना किसी नुकसान वाले ARGB फ़ॉर्मैट में है, तो YUV420 में स्पैटियल डाउनसैंपलिंग करने पर, नए रंग जुड़ जाएंगे. इन्हें कंप्रेस करना, ओरिजनल रंगों की तुलना में ज़्यादा मुश्किल होगा. ऐसा आम तौर पर तब होता है, जब सोर्स इमेज कुछ रंगों वाली PNG फ़ाइल में होती है. इसे लॉसलेस WebP (या इसी तरह के लॉसलेस JPEG) में बदलने पर, फ़ाइल का साइज़ बढ़ सकता है.
  2. अगर सोर्स फ़ाइल लॉसलेस फ़ॉर्मैट में है, तो सोर्स फ़ाइल के लॉसलेस फ़ॉर्मैट को कैप्चर करने के लिए, लॉसलेस WebP कंप्रेशन का इस्तेमाल करने पर आम तौर पर फ़ाइल का साइज़ बढ़ जाता है. यह समस्या सिर्फ़ WebP फ़ॉर्मैट में नहीं होती. ऐसा तब भी हो सकता है, जब JPEG सोर्स को बिना क्वालिटी में बदलाव किए WebP या PNG फ़ॉर्मैट में बदला जा रहा हो.
  3. अगर सोर्स फ़ाइल लॉसलेस फ़ॉर्मैट में है और आपको उसे लॉसलेस WebP फ़ॉर्मैट में कंप्रेस करना है, लेकिन क्वालिटी की सेटिंग ज़्यादा है. उदाहरण के लिए, क्वालिटी 80 पर सेव की गई JPEG फ़ाइल को क्वालिटी 95 वाली WebP फ़ाइल में बदलने पर, आम तौर पर फ़ाइल का साइज़ बढ़ जाता है. भले ही, दोनों फ़ॉर्मैट में डेटा का कुछ हिस्सा मिट जाता है. सोर्स की क्वालिटी का आकलन करना अक्सर मुमकिन नहीं होता. इसलिए, अगर फ़ाइल का साइज़ लगातार बड़ा है, तो टारगेट WebP क्वालिटी को कम करने का सुझाव दिया जाता है. इसके अलावा, क्वालिटी सेटिंग का इस्तेमाल न करके, cwebp टूल में मौजूद -size विकल्प या इसके बराबर के एपीआई का इस्तेमाल करके, फ़ाइल के साइज़ को टारगेट किया जा सकता है. उदाहरण के लिए, ओरिजनल फ़ाइल के 80% साइज़ को टारगेट करने से, बेहतर नतीजे मिल सकते हैं.

ध्यान दें कि JPEG सोर्स को लॉसलेस WebP में या PNG सोर्स को लॉसलेस WebP में बदलने पर, फ़ाइल के साइज़ में इस तरह के बदलाव नहीं होते.

क्या WebP, प्रोग्रेसिव या इंटरलेस्ड डिसप्ले के साथ काम करता है?

WebP, JPEG या PNG की तरह प्रोग्रेसिव या इंटरलेस्ड डिकोडिंग रीफ़्रेश की सुविधा नहीं देता. इससे डिकोडिंग क्लाइंट के सीपीयू और मेमोरी पर बहुत ज़्यादा दबाव पड़ सकता है, क्योंकि हर रीफ़्रेश इवेंट में डीकंप्रेशन सिस्टम से पूरा डेटा पास होता है.

औसतन, प्रोग्रेसिव JPEG इमेज को डिकोड करने में उतना ही समय लगता है जितना बेसलाइन इमेज को डिकोड करने में तीन बार लगता है.

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

मैं अपने Android प्रोजेक्ट में libwebp Java बाइंडिंग का इस्तेमाल कैसे करूं?

WebP में, swig/ डायरेक्ट्री में मौजूद सामान्य एन्कोडर और डिकोडर इंटरफ़ेस के लिए, JNI बाइंडिंग की सुविधा शामिल है.

Eclipse में लाइब्रेरी बनाना:

  1. पक्का करें कि आपने NDK टूल के साथ-साथ ADT प्लगिन इंस्टॉल किया हो. साथ ही, NDK का पाथ सही तरीके से सेट किया हो (Preferences > Android > NDK).
  2. नया प्रोजेक्ट बनाएं: File > New > Project > Android Application Project.
  3. नए प्रोजेक्ट में, jni नाम के फ़ोल्डर में libwebp को क्लोन करें या अनपैक करें.
  4. swig/libwebp_java_wrap.c को LOCAL_SRC_FILES सूची में जोड़ें.
  5. नए प्रोजेक्ट पर राइट क्लिक करें और Android टूल > नेटिव सपोर्ट जोड़ें ... को चुनें, ताकि लाइब्रेरी को अपने बिल्ड में शामिल किया जा सके.

  6. प्रोजेक्ट की प्रॉपर्टी खोलें और C/C++ Build > Behaviour पर जाएं. libwebp को शेयर की गई लाइब्रेरी के तौर पर बनाने के लिए, Build (Incremental build) सेक्शन में ENABLE_SHARED=1 जोड़ें.

    ध्यान दें NDK_TOOLCHAIN_VERSION=4.8 को सेट करने से, आम तौर पर 32-बिट बिल्ड की परफ़ॉर्मेंस बेहतर होगी.

  7. libs/ प्रोजेक्ट फ़ोल्डर में swig/libwebp.jar जोड़ें.

  8. अपना प्रोजेक्ट बनाएं. इससे libs/<target-arch>/libwebp.so बन जाएगा.

  9. लाइब्रेरी को रनटाइम पर लोड करने के लिए, System.loadLibrary("webp") का इस्तेमाल करें.

ध्यान दें कि लाइब्रेरी को मैन्युअल तरीके से ndk-build और इसमें शामिल Android.mk की मदद से बनाया जा सकता है. ऐसे में, ऊपर बताए गए कुछ चरणों को फिर से इस्तेमाल किया जा सकता है.

मैं C# के साथ libwebp का इस्तेमाल कैसे करूं?

WebP को एक DLL के तौर पर बनाया जा सकता है, जो libwebp API को एक्सपोर्ट करता है. इसके बाद, इन फ़ंक्शन को C# में इंपोर्ट किया जा सकता है.

  1. libwebp.dll बनाएं. इससे WEBP_EXTERN को सही तरीके से सेट किया जाएगा, ताकि एपीआई फ़ंक्शन एक्सपोर्ट किए जा सकें.

    libwebp> nmake /f Makefile.vc CFG=release-dynamic

  2. अपने प्रोजेक्ट में libwebp.dll जोड़ें और ज़रूरी फ़ंक्शन इंपोर्ट करें. ध्यान दें कि अगर सिंपल एपीआई का इस्तेमाल किया जाता है, तो आपको WebPFree() को कॉल करना होगा, ताकि लौटाए गए सभी बफ़र खाली किए जा सकें.

    [DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

मुझे ऐनिमेशन वाले WebP का इस्तेमाल क्यों करना चाहिए?

ऐनिमेट किए गए GIF की तुलना में, ऐनिमेट किए गए WebP के फ़ायदे

  1. WebP, 24-बिट आरजीबी कलर और 8-बिट ऐल्फ़ा चैनल के साथ काम करता है. वहीं, GIF में 8-बिट कलर और 1-बिट ऐल्फ़ा होता है.

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

  3. WebP को GIF1 के मुकाबले कम बाइट की ज़रूरत होती है. क्वालिटी कम करके WebP में बदली गई ऐनिमेटेड GIF इमेज का साइज़ 64% कम हो जाता है. वहीं, क्वालिटी कम किए बिना WebP में बदली गई इमेज का साइज़ 19% कम हो जाता है. यह खास तौर पर मोबाइल नेटवर्क पर ज़रूरी है.

  4. सीकिंग की सुविधा चालू होने पर, WebP को डिकोड होने में कम समय लगता है. Blink में, स्क्रोल करने या टैब बदलने पर इमेज दिख सकती हैं और छिप सकती हैं. इससे ऐनिमेशन रुक जाते हैं और फिर उन्हें किसी दूसरे पॉइंट पर स्किप कर दिया जाता है. सीपीयू का ज़रूरत से ज़्यादा इस्तेमाल होने की वजह से, ऐनिमेशन के फ़्रेम कम हो सकते हैं. ऐसे में, डिकोडर को ऐनिमेशन में आगे बढ़ने की ज़रूरत पड़ सकती है. इन मामलों में, ऐनिमेटेड WebP को GIF की तुलना में 0.57 गुना कम समय लगता है. इससे स्क्रोलिंग के दौरान कम जंक होता है और सीपीयू के इस्तेमाल में अचानक होने वाली बढ़ोतरी से तेज़ी से रिकवर किया जा सकता है. ऐसा इसलिए है, क्योंकि GIF की तुलना में WebP के दो फ़ायदे हैं:

    • WebP इमेज, इस बारे में मेटाडेटा सेव करती हैं कि हर फ़्रेम में ऐल्फ़ा है या नहीं. इससे यह तय करने के लिए फ़्रेम को डिकोड करने की ज़रूरत नहीं पड़ती. इससे यह बेहतर तरीके से पता चलता है कि कोई फ़्रेम, पिछले किन फ़्रेम पर निर्भर करता है. इससे पिछले फ़्रेम को गैर-ज़रूरी तरीके से डिकोड करने की ज़रूरत नहीं पड़ती.

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

ऐनिमेटेड GIF की तुलना में, ऐनिमेटेड WebP के नुकसान

  1. सीकिंग की सुविधा के बिना, WebP को डिकोड करने में GIF की तुलना में ज़्यादा सीपीयू लगता है. लॉसी WebP को डिकोड करने में, GIF की तुलना में 2.2 गुना ज़्यादा समय लगता है. वहीं, लॉसलेस WebP को डिकोड करने में, GIF की तुलना में 1.5 गुना ज़्यादा समय लगता है.

  2. WebP फ़ॉर्मैट का इस्तेमाल, GIF फ़ॉर्मैट की तुलना में कम किया जाता है. GIF फ़ॉर्मैट का इस्तेमाल लगभग हर जगह किया जाता है.

  3. ब्राउज़र में WebP फ़ॉर्मैट के लिए सहायता जोड़ने से, कोड फ़ुटप्रिंट और अटैक सर्फ़ेस बढ़ जाता है. Blink में, यह करीब 1,500 लाइनें होती हैं. इनमें WebP demux लाइब्रेरी और Blink-साइड WebP इमेज डिकोडर शामिल हैं. ध्यान दें कि अगर WebP और WebM, डिकोडिंग के लिए एक ही कोड का इस्तेमाल करते हैं या WebP की सुविधाओं को WebM में शामिल कर लिया जाता है, तो आने वाले समय में इस समस्या को कम किया जा सकता है.

<img> में WebM फ़ॉर्मैट का इस्तेमाल क्यों नहीं किया जा सकता?

<img> टैग में वीडियो फ़ॉर्मैट इस्तेमाल करने की सुविधा लंबे समय तक काम आ सकती है. हालांकि, अब ऐसा करने से समस्या हो सकती है. ऐसा इसलिए, क्योंकि <img> में WebM का इस्तेमाल, ऐनिमेटेड WebP की भूमिका को पूरा करने के लिए किया जा सकता है:

  1. पिछले फ़्रेम पर निर्भर रहने वाले फ़्रेम को डिकोड करने के लिए, WebM को ऐनिमेशन वाले WebP की तुलना में 50% ज़्यादा मेमोरी की ज़रूरत होती है. ऐसा इसलिए, ताकि पिछले फ़्रेम की कम से कम संख्या 3 को सेव किया जा सके.

  2. ब्राउज़र और डिवाइसों के हिसाब से, वीडियो कोडेक और कंटेनर के साथ काम करने की सुविधा अलग-अलग होती है. कॉन्टेंट को अपने-आप ट्रांसकोड करने की सुविधा (जैसे कि बैंडविथ बचाने वाली प्रॉक्सी के लिए) को बेहतर बनाने के लिए, ब्राउज़र को Accept हेडर जोड़ने होंगे. इससे यह पता चलेगा कि उनके इमेज टैग किन फ़ॉर्मैट के साथ काम करते हैं. यह जानकारी भी काफ़ी नहीं हो सकती, क्योंकि "video/webm" या "video/mpeg" जैसे एमआईएमई टाइप से अब भी कोडेक के साथ काम करने की जानकारी नहीं मिलती. उदाहरण के लिए, VP8 बनाम VP9. दूसरी ओर, WebP फ़ॉर्मैट को फ़्रीज़ कर दिया गया है. अगर इसे शिप करने वाले वेंडर, ऐनिमेशन वाले WebP को शिप करने के लिए सहमत होते हैं, तो सभी यूए में WebP का व्यवहार एक जैसा होना चाहिए. साथ ही, "image/webp" accept हेडर का इस्तेमाल पहले से ही WebP के साथ काम करने की सुविधा के बारे में बताने के लिए किया जाता है. इसलिए, accept हेडर में कोई नया बदलाव करने की ज़रूरत नहीं है.

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

  4. फ़िलहाल, WebM में WebP की सभी कंप्रेशन तकनीकों को शामिल नहीं किया गया है. इस वजह से, WebP फ़ॉर्मैट में यह इमेज अन्य फ़ॉर्मैट के मुकाबले ज़्यादा बेहतर तरीके से कंप्रेस होती है:

1 ऐनिमेटेड GIF और ऐनिमेटेड WebP के बीच सभी तुलनाओं के लिए, हमने वेब से रैंडम तरीके से ली गई करीब 7,000 ऐनिमेटेड GIF इमेज का कॉर्पस इस्तेमाल किया. इन इमेज को ऐनिमेशन वाले WebP में बदलने के लिए, 'gif2webp' टूल का इस्तेमाल किया गया है. इसके लिए, डिफ़ॉल्ट सेटिंग का इस्तेमाल किया गया है. ये सेटिंग, 08/10/2013 तक के libwebp सोर्स ट्री के सबसे नए वर्शन के हिसाब से बनाई गई हैं. तुलना करने के लिए दिए गए नंबर, इन इमेज की औसत वैल्यू हैं.

2 डिकोड करने में लगने वाले समय का हिसाब, 08/10/2013 तक के libwebp + ToT Blink के सबसे नए वर्शन का इस्तेमाल करके लगाया गया था. इसके लिए, बेंचमार्क टूल का इस्तेमाल किया गया था. "सीकिंग के साथ डिकोड करने में लगने वाला समय" का हिसाब इस तरह लगाया जाता है: "पहले पांच फ़्रेम डिकोड करें, फ़्रेम बफ़र कैश मेमोरी मिटाएं, अगले पांच फ़्रेम डिकोड करें, और इसी तरह आगे भी".

3 WebM, मेमोरी में चार YUV रेफ़रंस फ़्रेम रखता है. हर फ़्रेम में (चौड़ाई+96)*(ऊंचाई+96) पिक्सल सेव होते हैं. YUV 4:2:0 के लिए, हमें हर 6 पिक्सल के लिए 4 बाइट (या हर पिक्सल के लिए 3/2 बाइट) की ज़रूरत होती है. इसलिए, ये रेफ़रंस फ़्रेम 4*3/2*(width+96)*(height+96) बाइट मेमोरी का इस्तेमाल करते हैं. वहीं दूसरी ओर, WebP को सिर्फ़ पिछले फ़्रेम (RGBA में) की ज़रूरत होगी. यह 4*width*height बाइट मेमोरी का इस्तेमाल करता है.

4 ऐनिमेटेड WebP रेंडर करने के लिए, Google Chrome का वर्शन 32 या इसके बाद का वर्शन होना ज़रूरी है