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

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 सहायता का पता लगाने के लिए, कई तकनीकों का इस्तेमाल किया जाता है. सीडीएन की सेवा देने वाली कुछ कंपनियां, अपनी सेवा के तौर पर वेबपी सहायता उपलब्ध कराती हैं.

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

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

मॉडर्नाइज़र

मॉडर्नर एक 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 साइट पर दिया गया है. कंटेनर की खास जानकारी के लिए, आरआईएफ़एफ़ कंटेनर पेज देखें.

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

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

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

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

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

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

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

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

  1. अगर सोर्स इमेज में एआरजीबी फ़ॉर्मैट का कोई नुकसान नहीं है, तो YUV420 के लिए स्थानिक डाउनसैंपलिंग में नए रंग शामिल किए जाएंगे. यह स्थिति आम तौर पर तब हो सकती है, जब सोर्स PNG फ़ॉर्मैट में हो और उसके रंग कम हों: खराब वेबपी में बदलने (या नुकसान पहुंचाने वाले 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 पाथ सही तरीके से सेट किया गया हो (प्राथमिकताएं > Android > NDK).
  2. नया प्रोजेक्ट बनाएं: फ़ाइल > नया > प्रोजेक्ट > Android ऐप्लिकेशन प्रोजेक्ट.
  3. क्लोन करें या नए प्रोजेक्ट में jni नाम के फ़ोल्डर में libwebp को अनपैक करें.
  4. swig/libwebp_java_wrap.c को LOCAL_SRC_FILES सूची में जोड़ें.
  5. अपने बिल्ड में लाइब्रेरी शामिल करने के लिए, नए प्रोजेक्ट पर दायां क्लिक करें और Android टूल > नेटिव सहायता जोड़ें ... को चुनें.
  6. प्रोजेक्ट प्रॉपर्टी खोलें और C/C++ Build > व्यवहार पर जाएं. शेयर की गई लाइब्रेरी के तौर पर लाइब्रेरी बनाने के लिए, 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. GIF के 8-बिट रंग और 1-बिट ऐल्फ़ा की तुलना में, WebP 8-बिट अल्फ़ा चैनल के साथ 24-बिट आरजीबी रंग के साथ काम करता है.

  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 को नष्ट करने के लिए इस्तेमाल होने वाले फ़्रेम के अलावा दूसरा तरीका भी इस्तेमाल करता है. इससे किसी मुख्य-फ़्रेम को इस तरह से ड्रॉ किया जा सकता है, जैसे कि पूरी इमेज को बैकग्राउंड कलर में मिटाकर, पिछले फ़्रेम को फ़ुल-साइज़ में दिखाए बिना.

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

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

  2. WebP की सुविधा, GIF की सुविधा के मुकाबले उतनी ही बड़ी है जितनी आम तौर पर हर जगह होती है.

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

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

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

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

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

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

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


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

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

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

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