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

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

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

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

कौनसे वेब ब्राउज़र, WebP के साथ मूल रूप से काम करते हैं?

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

  • WebP की नुकसान पहुंचाने वाली सहायता
    • Google Chrome (डेस्कटॉप) 17+
    • Android के लिए Google Chrome वर्शन 25+
    • Microsoft Edge 18 और उसके बाद के वर्शन
    • Firefox 65+
    • ऑपरा 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+
    • ऑपरा 12.10 और उसके बाद के वर्शन
    • नेटिव वेब ब्राउज़र, Android 4.2+ (JB-MR1)
    • पेल मून 26+
    • Safari 14+ (iOS 14+, macOS Big Sur+)
  • WebP ऐनिमेशन की सुविधा
    • Google Chrome (डेस्कटॉप और Android) 32+
    • Microsoft Edge 18 और उसके बाद के वर्शन
    • Firefox 65+
    • ऑपरा 19+
    • Safari 14+ (iOS 14+, macOS Big Sur+)

यह भी देखें:

मैं WebP के लिए ब्राउज़र पर काम करने की सुविधा का पता कैसे लगाऊं?

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

स्वीकार किए जाने वाले हेडर के ज़रिए सर्वर-साइड की कॉन्टेंट पर बातचीत

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

मॉडर्नाइज़र

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 की क्वालिटी का अंदाज़ा लगाने के लिए, साथ-साथ फ़ोटो की तुलना करने के लिए इस साइट पर Gallery देखें.

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

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

WebP वाली इमेज का ज़्यादा से ज़्यादा साइज़ क्या हो सकता है?

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

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

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

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

क्या 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/ डायरेक्ट्री में मौजूद आसान एन्कोडर और डिकोडर इंटरफ़ेस पर जेएनआई बाइंडिंग की सुविधा काम करती है.

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

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

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

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

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

  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, 8-बिट वाले ऐल्फ़ा चैनल वाले 24-बिट आरजीबी कलर में काम करता है. वहीं, GIF के 8-बिट कलर और 1-बिट ऐल्फ़ा चैनल में यह सुविधा उपलब्ध है.

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

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

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

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

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

GIF की तुलना में ऐनिमेशन वाले WebP फ़ॉर्मैट के नुकसान

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

  2. WebP वाली सहायता, GIF से जुड़ी सहायता जितनी बड़ी संख्या में नहीं होती.

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

सिर्फ़ <img> में WebM के साथ काम क्यों नहीं किया जाता?

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

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

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

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

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

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

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

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

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