คำถามที่พบบ่อย

WebP คืออะไร ทำไมฉันจึงควรใช้

WebP เป็นวิธีการบีบอัดแบบสูญเสียรายละเอียดบางส่วนและแบบไม่สูญเสียรายละเอียดที่ใช้ได้กับรูปภาพถ่าย รูปภาพโปร่งแสง และรูปภาพกราฟิกหลากหลายประเภทที่พบได้บนเว็บ คุณปรับระดับการบีบอัดแบบมีการสูญเสียได้เพื่อให้ผู้ใช้เลือก การแลกเปลี่ยนระหว่างขนาดไฟล์กับคุณภาพของรูปภาพได้ โดยทั่วไป WebP จะบีบอัดได้มากกว่า JPEG และ JPEG 2000 โดยเฉลี่ย 30% โดยไม่สูญเสียคุณภาพของรูปภาพ (ดูการศึกษา WebP แบบสูญเสียรายละเอียดบางส่วนและการศึกษา WebP แบบไม่สูญเสียรายละเอียดและแบบอัลฟ่า)

โดยพื้นฐานแล้ว รูปแบบ WebP มีจุดมุ่งหมายเพื่อสร้างรูปภาพที่มีขนาดเล็กลงและดูดีขึ้น ซึ่งจะช่วยให้เว็บเร็วขึ้น

เว็บเบราว์เซอร์ใดบ้างที่รองรับ WebP โดยค่าเริ่มต้น

ผู้ดูแลเว็บที่สนใจปรับปรุงประสิทธิภาพของเว็บไซต์สามารถสร้าง รูปภาพทางเลือก WebP ที่เพิ่มประสิทธิภาพแล้วสำหรับรูปภาพปัจจุบัน และแสดงรูปภาพเหล่านั้น ตามกลุ่มเป้าหมายในเบราว์เซอร์ที่รองรับ WebP ได้อย่างง่ายดาย

การรองรับ WebP แบบสูญเสีย
- Google Chrome (เดสก์ท็อป) 17 ขึ้นไป
- Google Chrome สำหรับ Android เวอร์ชัน 25 ขึ้นไป
- Microsoft Edge 18 ขึ้นไป
- Firefox 65 ขึ้นไป
- Opera 11.10 ขึ้นไป
- เว็บเบราว์เซอร์ดั้งเดิม, Android 4.0 ขึ้นไป (ICS)
- Safari 14 ขึ้นไป (iOS 14 ขึ้นไป, macOS Big Sur ขึ้นไป)
รองรับ WebP แบบสูญเสียข้อมูล แบบไม่สูญเสียข้อมูล และแบบมีช่องอัลฟ่า
- Google Chrome (เดสก์ท็อป) 23 ขึ้นไป
- Google Chrome สำหรับ Android เวอร์ชัน 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 ทั้งในฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ ผู้ให้บริการ CDN บางรายมีการตรวจหาการรองรับ 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 รองรับพื้นที่สีใดบ้าง

WebP แบบสูญเสียจะทำงานร่วมกับรูปแบบรูปภาพ Y'CbCr 4:2:0 แบบ 8 บิต (มักเรียกว่า YUV420) เท่านั้น ซึ่งสอดคล้องกับสตรีมบิต VP8 โปรดดูรายละเอียดเพิ่มเติมในส่วนที่ 2 "ภาพรวมรูปแบบ" ของ RFC 6386 รูปแบบข้อมูล VP8 และคำแนะนำในการถอดรหัส

WebP แบบไม่สูญเสียข้อมูลใช้ได้กับรูปแบบ RGBA เท่านั้น ดูข้อกำหนดของสตรีมบิตแบบไม่สูญเสียของ WebP

เหตุใดไฟล์ WebP แบบไม่สูญเสียข้อมูลของฉันจึงแตกต่างจากไฟล์ต้นฉบับ

ฟังก์ชัน Simple Encoding API (WebPEncodeLosslessRGB(), WebPEncodeLosslessBGR(), WebPEncodeLosslessRGBA(), WebPEncodeLosslessBGRA()) ใช้การตั้งค่าเริ่มต้นของไลบรารี สำหรับแบบไม่สูญเสียข้อมูล หมายความว่าปิดใช้ "ตรงกัน" ค่า RGB ใน พื้นที่โปร่งใสทั้งหมด (นั่นคือ พื้นที่ที่มีค่าอัลฟ่าเท่ากับ 0) จะ ได้รับการแก้ไขเพื่อปรับปรุงการบีบอัด หากต้องการหลีกเลี่ยงปัญหานี้ ให้ใช้ WebPEncode() และตั้งค่า WebPConfig::exact เป็น 1 ดูเอกสารประกอบเกี่ยวกับ Advanced Encoding API

รูปภาพ WebP มีขนาดใหญ่กว่ารูปภาพต้นฉบับได้ไหม

ได้ โดยปกติเมื่อแปลงจากรูปแบบแบบสูญเสียรายละเอียดเป็น WebP แบบไม่สูญเสียรายละเอียดหรือในทางกลับกัน สาเหตุหลักมาจากความแตกต่างของพื้นที่สี (YUV420 กับ ARGB) และการแปลงระหว่างพื้นที่สีเหล่านี้

โดยทั่วไปจะมี 3 สถานการณ์ดังนี้

หากรูปภาพต้นฉบับอยู่ในรูปแบบ ARGB แบบไม่สูญเสียข้อมูล การดาวน์แซมปลิงเชิงพื้นที่ เป็น YUV420 จะทำให้เกิดสีใหม่ที่บีบอัดได้ยากกว่า สีเดิม โดยปกติแล้ว สถานการณ์นี้จะเกิดขึ้นเมื่อแหล่งที่มาอยู่ในรูปแบบ PNG ที่มีสีน้อย การแปลงเป็น WebP แบบสูญเสียข้อมูล (หรือในทำนองเดียวกันเป็น JPEG แบบสูญเสียข้อมูล) อาจทำให้ไฟล์มีขนาดใหญ่ขึ้น
หากแหล่งที่มาอยู่ในรูปแบบที่มีการสูญเสีย การใช้การบีบอัด WebP แบบไม่สูญเสีย เพื่อบันทึกลักษณะที่มีการสูญเสียของแหล่งที่มามักจะส่งผลให้ ไฟล์มีขนาดใหญ่ขึ้น ปัญหานี้ไม่ได้เกิดขึ้นกับ WebP เท่านั้น แต่อาจเกิดขึ้นเมื่อ แปลงแหล่งที่มาของ JPEG เป็นรูปแบบ WebP หรือ PNG แบบไม่สูญเสียรายละเอียด เป็นต้น
หากแหล่งที่มาอยู่ในรูปแบบ Lossy และคุณพยายามบีบอัดเป็น WebP แบบ Lossy ที่มีการตั้งค่าคุณภาพสูงกว่า เช่น การพยายาม แปลงไฟล์ JPEG ที่บันทึกไว้ที่คุณภาพ 80 เป็นไฟล์ WebP ที่มีคุณภาพ 95 มักจะทำให้ได้ไฟล์ที่มีขนาดใหญ่ขึ้น แม้ว่าทั้ง 2 รูปแบบจะเป็นแบบสูญเสียข้อมูลก็ตาม การประเมินคุณภาพของแหล่งที่มามักเป็นไปไม่ได้ ดังนั้นเราขอแนะนำให้ ลดคุณภาพ WebP เป้าหมายหากขนาดไฟล์ใหญ่กว่าปกติอย่างต่อเนื่อง อีกทางเลือกหนึ่งคือหลีกเลี่ยงการใช้การตั้งค่าคุณภาพ แล้วกำหนดเป้าหมายขนาดไฟล์ที่ต้องการแทนโดยใช้ตัวเลือก -size ในเครื่องมือ cwebp หรือ API ที่เทียบเท่า เช่น การกำหนดเป้าหมายขนาด 80% ของไฟล์ต้นฉบับ อาจพิสูจน์ได้ว่ามีความเสถียรมากกว่า

โปรดทราบว่าการแปลงแหล่งที่มา JPEG เป็น WebP แบบสูญเสียรายละเอียด หรือแหล่งที่มา PNG เป็น WebP แบบไม่สูญเสียรายละเอียด จะไม่ทำให้เกิดปัญหาเรื่องขนาดไฟล์ดังกล่าว

WebP รองรับการแสดงผลแบบ Progressive หรือ Interlaced ไหม

WebP ไม่มีการรีเฟรชการถอดรหัสแบบก้าวหน้าหรือแบบสลับในลักษณะของ JPEG หรือ PNG ซึ่งอาจทำให้ CPU และหน่วยความจำของไคลเอ็นต์การถอดรหัสทำงานหนักเกินไป เนื่องจากเหตุการณ์การรีเฟรชแต่ละครั้งต้องผ่านระบบการคลายการบีบอัดทั้งหมด

โดยเฉลี่ยแล้ว การถอดรหัสรูปภาพ JPEG แบบ Progressive จะเทียบเท่ากับการถอดรหัสรูปภาพแบบพื้นฐาน 3 ครั้ง

อีกทางเลือกหนึ่งคือ WebP มีการถอดรหัสแบบเพิ่มทีละส่วน ซึ่งจะใช้ไบต์ขาเข้าทั้งหมดของบิตสตรีมที่พร้อมใช้งานเพื่อพยายามสร้างแถวตัวอย่างที่แสดงได้โดยเร็วที่สุด ซึ่งจะช่วยประหยัดหน่วยความจำ, CPU และลดความพยายามในการวาดใหม่ในไคลเอ็นต์ พร้อมทั้งให้คิวภาพเกี่ยวกับสถานะการดาวน์โหลด ฟีเจอร์การถอดรหัสแบบเพิ่มจะพร้อมใช้งานผ่าน Advanced Decoding API

ฉันจะใช้การเชื่อมโยง Java ของ libwebp ในโปรเจ็กต์ Android ได้อย่างไร

WebP รองรับการเชื่อมโยง JNI กับอินเทอร์เฟซตัวเข้ารหัสและตัวถอดรหัสอย่างง่ายในไดเรกทอรี swig/

การสร้างไลบรารีใน Eclipse

ตรวจสอบว่าคุณได้ติดตั้ง ปลั๊กอิน ADT พร้อมกับเครื่องมือ NDK และตั้งค่าเส้นทาง NDK อย่างถูกต้อง (ค่ากำหนด > Android > NDK)
สร้างโปรเจ็กต์ใหม่: File > New > Project > Android Application Project
โคลนหรือ แตกไฟล์ libwebp ไปยังโฟลเดอร์ชื่อ jni ในโปรเจ็กต์ใหม่
เพิ่ม swig/libwebp_java_wrap.c ลงในรายการ LOCAL_SRC_FILES
คลิกขวาที่โปรเจ็กต์ใหม่ แล้วเลือก Android Tools > Add Native Support ... เพื่อรวมไลบรารีไว้ในการสร้าง
เปิดพร็อพเพอร์ตี้ของโปรเจ็กต์ แล้วไปที่การสร้าง C/C++ > ลักษณะการทำงาน เพิ่ม ENABLE_SHARED=1 ลงในส่วน Build (Incremental build) เพื่อสร้าง libwebp เป็นไลบรารีที่ใช้ร่วมกัน

หมายเหตุ การตั้งค่า NDK_TOOLCHAIN_VERSION=4.8 โดยทั่วไปจะช่วยปรับปรุง ประสิทธิภาพการสร้าง 32 บิต
เพิ่ม swig/libwebp.jar ลงในโฟลเดอร์โปรเจ็กต์ libs/
สร้างโปรเจ็กต์ การดำเนินการนี้จะสร้าง libs/<target-arch>/libwebp.so
ใช้ System.loadLibrary("webp") เพื่อโหลดไลบรารีที่รันไทม์

โปรดทราบว่าคุณสร้างไลบรารีได้ด้วยตนเองโดยใช้ ndk-build และ Android.mk ที่รวมอยู่ คุณสามารถนำขั้นตอนบางอย่างที่อธิบายไว้ข้างต้นมาใช้ซ้ำในกรณีดังกล่าวได้

ฉันจะใช้ libwebp กับ C# ได้อย่างไร

WebP สามารถสร้างเป็น DLL ที่ส่งออก libwebp API ได้ จากนั้นจะนำเข้าฟังก์ชันเหล่านี้ใน C# ได้

สร้าง libwebp.dll ซึ่งจะตั้งค่า WEBP_EXTERN อย่างถูกต้องเพื่อส่งออกฟังก์ชัน API
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

เพิ่ม libwebp.dll ลงในโปรเจ็กต์และนำเข้าฟังก์ชันที่ต้องการ โปรดทราบว่าหากใช้ Simple API คุณควรเรียกใช้ 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 แบบเคลื่อนไหว

ข้อดีของ WebP แบบเคลื่อนไหวเมื่อเทียบกับ GIF แบบเคลื่อนไหว

WebP รองรับสี RGB 24 บิตที่มีช่องอัลฟ่า 8 บิต ซึ่งแตกต่างจากสี 8 บิตและอัลฟ่า 1 บิตของ GIF
WebP รองรับการบีบอัดทั้งแบบสูญเสียบางส่วนและไม่สูญเสียข้อมูล โดยที่ภาพเคลื่อนไหวเดียวสามารถรวมเฟรมแบบสูญเสียบางส่วนและไม่สูญเสียข้อมูลได้ GIF รองรับเฉพาะ การบีบอัดแบบไม่สูญเสีย เทคนิคการบีบอัดแบบสูญเสียบางส่วนของ WebP เหมาะสำหรับ รูปภาพเคลื่อนไหวที่สร้างจากวิดีโอในโลกแห่งความเป็นจริง ซึ่งเป็นแหล่งที่มาของรูปภาพเคลื่อนไหวที่ได้รับความนิยมมากขึ้นเรื่อยๆ
WebP ใช้ไบต์น้อยกว่า GIF¹ GIF แบบเคลื่อนไหวที่แปลงเป็น WebP แบบสูญเสียรายละเอียดบางส่วนมีขนาดเล็กลง 64% ขณะที่ WebP แบบไม่สูญเสียรายละเอียดมีขนาดเล็กลง 19% ซึ่งมีความสำคัญอย่างยิ่งบนเครือข่ายมือถือ
WebP ใช้เวลาในการถอดรหัสน้อยกว่าเมื่อมีการกรอ ใน Blink การเลื่อนหรือการเปลี่ยนแท็บอาจซ่อนและแสดงรูปภาพ ซึ่งส่งผลให้ระบบหยุดภาพเคลื่อนไหวชั่วคราวแล้วข้ามไปยังจุดอื่น การใช้งาน CPU มากเกินไปซึ่งส่งผลให้ภาพเคลื่อนไหว หลุดเฟรมอาจทำให้ตัวถอดรหัสต้องค้นหาไปข้างหน้าใน ภาพเคลื่อนไหวด้วย ในสถานการณ์เหล่านี้ WebP แบบเคลื่อนไหวใช้เวลาในการถอดรหัสทั้งหมดน้อยกว่า GIF 0.57 เท่า² ซึ่งส่งผลให้เกิดอาการกระตุกน้อยลง ขณะเลื่อนและกู้คืนจากการใช้ CPU สูงได้เร็วขึ้น ซึ่งเป็นผลมาจากข้อได้เปรียบ 2 ประการของ WebP เหนือ GIF ดังนี้
- รูปภาพ WebP จะจัดเก็บข้อมูลเมตาเกี่ยวกับว่าแต่ละเฟรมมีอัลฟ่าหรือไม่ จึงไม่จำเป็นต้องถอดรหัสเฟรมเพื่อพิจารณาสิ่งนี้ ซึ่งจะช่วยให้การอนุมานเฟรมก่อนหน้าซึ่งเฟรมที่กำหนดขึ้นอยู่กับนั้นแม่นยำยิ่งขึ้น จึงลดการถอดรหัสเฟรมก่อนหน้าที่ไม่จำเป็น
- ตัวเข้ารหัส WebP จะเพิ่ม คีย์เฟรมเป็นระยะๆ (ซึ่งตัวเข้ารหัส GIF ส่วนใหญ่ไม่ได้ทำ) คล้ายกับตัวเข้ารหัสวิดีโอสมัยใหม่ ซึ่งจะช่วยปรับปรุงการกรอวิดีโอในภาพเคลื่อนไหวขนาดยาวได้อย่างมาก WebP เพิ่มแฟล็ก "วิธีการผสม" สำหรับแต่ละเฟรม นอกเหนือจากวิธีการทิ้งเฟรมที่ GIF ใช้ เพื่ออำนวยความสะดวกในการ แทรกเฟรมดังกล่าวโดยไม่เพิ่มขนาดรูปภาพมากนัก ซึ่งจะช่วยให้คีย์เฟรมวาดได้ราวกับว่าได้ล้างรูปภาพทั้งรูป เป็นสีพื้นหลังโดยไม่ต้องบังคับให้เฟรมก่อนหน้าเป็น ขนาดเต็ม

ข้อเสียของ WebP แบบเคลื่อนไหวเมื่อเทียบกับ GIF แบบเคลื่อนไหว

หากไม่มีการค้นหา การถอดรหัส WebP แบบเส้นตรงจะใช้ CPU มากกว่า GIF WebP แบบสูญเสียรายละเอียดใช้เวลาในการถอดรหัสมากกว่า GIF 2.2 เท่า ส่วน WebP แบบไม่สูญเสียรายละเอียดใช้เวลามากกว่า 1.5 เท่า
การรองรับ WebP ไม่ได้แพร่หลายเท่าการรองรับ GIF ซึ่ง เป็นรูปแบบที่ใช้กันอย่างแพร่หลาย
การเพิ่มการรองรับ WebP ในเบราว์เซอร์จะเพิ่มร่องรอยของโค้ดและพื้นผิวการโจมตี ใน Blink จะมีโค้ดเพิ่มเติมประมาณ 1,500 บรรทัด (รวมถึงไลบรารีการแยกมัลติเพล็กซ์ WebP และตัวถอดรหัสรูปภาพ WebP ฝั่ง Blink) โปรดทราบว่าปัญหานี้อาจลดลงได้ในอนาคตหาก WebP และ WebM ใช้โค้ดการถอดรหัสร่วมกันมากขึ้น หรือหากความสามารถของ WebP รวมอยู่ใน WebM

ทำไมเราจึงไม่รองรับ WebM ใน <img>

การรองรับรูปแบบวิดีโอภายในแท็ก <img> อาจเป็นเรื่องสมเหตุสมผลในระยะยาว อย่างไรก็ตาม การทำเช่นนี้ในตอนนี้โดยมีเจตนาให้ WebM ใน <img> สามารถทำหน้าที่ตามที่เสนอไว้สำหรับ WebP แบบเคลื่อนไหวเป็นเรื่องที่น่ากังวล

เมื่อถอดรหัสเฟรมที่อิงตามเฟรมก่อนหน้า WebM ต้องใช้หน่วยความจำมากกว่า WebP แบบเคลื่อนไหว 50% เพื่อเก็บจำนวนเฟรมก่อนหน้าขั้นต่ำ³
การรองรับตัวแปลงรหัสและคอนเทนเนอร์วิดีโอจะแตกต่างกันอย่างมากในเบราว์เซอร์และ อุปกรณ์ต่างๆ หากต้องการอำนวยความสะดวกในการแปลงรหัสเนื้อหาโดยอัตโนมัติ (เช่น สำหรับพร็อกซีที่ประหยัดแบนด์วิดท์) เบราว์เซอร์จะต้องเพิ่มส่วนหัว Accept ที่ระบุรูปแบบที่แท็กรูปภาพรองรับ แม้ว่าข้อมูลนี้อาจไม่เพียงพอ เนื่องจากประเภท MIME เช่น "video/webm" หรือ "video/mpeg" ก็ยังไม่ได้ระบุการรองรับตัวแปลงรหัส (เช่น VP8 กับ VP9) ในทางกลับกัน รูปแบบ WebP จะหยุดการพัฒนาอย่างมีประสิทธิภาพ และหากผู้ให้บริการที่จัดส่ง รูปแบบนี้ตกลงที่จะจัดส่ง WebP แบบเคลื่อนไหว ลักษณะการทำงานของ WebP ใน UA ทั้งหมด ควรสอดคล้องกัน และเนื่องจากระบบใช้ส่วนหัว "image/webp" Accept เพื่อระบุการรองรับ WebP อยู่แล้ว จึงไม่จำเป็นต้องเปลี่ยนแปลงส่วนหัว Accept ใหม่
สแต็กวิดีโอ Chromium ได้รับการเพิ่มประสิทธิภาพเพื่อ การเล่นที่ราบรื่น และถือว่ามีวิดีโอเพียง 1 หรือ 2 รายการที่เล่นพร้อมกัน ในแต่ละครั้ง ด้วยเหตุนี้ การใช้งานจึงใช้ทรัพยากรของระบบ (เธรด หน่วยความจำ ฯลฯ) อย่างมากเพื่อเพิ่มคุณภาพการเล่นให้สูงสุด การติดตั้งใช้งานดังกล่าวไม่สามารถปรับขนาดให้รองรับวิดีโอหลายรายการที่เล่นพร้อมกันได้ และจะต้องออกแบบใหม่เพื่อให้เหมาะกับการใช้กับหน้าเว็บที่มีรูปภาพจำนวนมาก
ปัจจุบัน WebM ยังไม่ได้รวมเทคนิคการบีบอัดทั้งหมด จาก WebP ด้วยเหตุนี้ รูปภาพนี้จึงบีบอัดได้ดีกว่าทางเลือกอื่นอย่างมากเมื่อใช้ WebP

¹ สำหรับการเปรียบเทียบทั้งหมดระหว่าง GIF แบบเคลื่อนไหวกับ WebP แบบเคลื่อนไหว เรา ใช้คลังรูปภาพ GIF แบบเคลื่อนไหวประมาณ 7, 000 รูปภาพที่สุ่มมาจากเว็บ รูปภาพเหล่านี้ได้รับการแปลงเป็น WebP แบบเคลื่อนไหวโดยใช้เครื่องมือ "gif2webp" โดยใช้ การตั้งค่าเริ่มต้น (สร้างจากแผนผังแหล่งที่มาของ libwebp ล่าสุด ณ วันที่ 08/10/2013) ตัวเลขเปรียบเทียบคือค่าเฉลี่ยของรูปภาพเหล่านี้

² เวลาในการถอดรหัสคำนวณโดยใช้ libwebp เวอร์ชันล่าสุด + ToT Blink ณ วันที่ 08/10/2013 โดยใช้เครื่องมือเปรียบเทียบ "เวลาในการถอดรหัส เมื่อมีการกรอ" จะคำนวณเป็น "ถอดรหัส 5 เฟรมแรก ล้างแคชบัฟเฟอร์เฟรม ถอดรหัส 5 เฟรมถัดไป และอื่นๆ"

³ WebM จะเก็บเฟรมอ้างอิง YUV 4 เฟรมไว้ในหน่วยความจำ โดยแต่ละเฟรมจะ จัดเก็บพิกเซล (ความกว้าง+96)*(ความสูง+96) สำหรับ YUV 4:2:0 เราต้องใช้ 4 ไบต์ต่อ 6 พิกเซล (หรือ 3/2 ไบต์ต่อพิกเซล) ดังนั้น เฟรมอ้างอิงเหล่านี้จึงใช้หน่วยความจำ 4*3/2*(width+96)*(height+96) ไบต์ ในทางกลับกัน WebP จะต้องการเพียงเฟรมก่อนหน้า (ใน RGBA) ซึ่งมีขนาด 4*width*height ไบต์

⁴ การแสดงผล WebP แบบเคลื่อนไหวต้องใช้ Google Chrome เวอร์ชัน 32 ขึ้นไป