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

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

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

โดยพื้นฐานแล้ว รูปแบบ 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 เป็นส่วนหนึ่งของบริการของตน

การต่อรองเนื้อหาฝั่งเซิร์ฟเวอร์ผ่านส่วนหัว "ยอมรับ"

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

โมเดิร์นไรเซอร์

Modernizr เป็นไลบรารี JavaScript สำหรับตรวจหาการรองรับฟีเจอร์ HTML5 และ CSS3 ในเว็บเบราว์เซอร์ได้อย่างสะดวก มองหาพร็อพเพอร์ตี้ Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha และ Modernizr.webp.animation

องค์ประกอบ <picture> ของ HTML5

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

หากคุณมีรูปภาพจำนวนมากที่จะแปลง คุณสามารถใช้ Shell ของแพลตฟอร์มเพื่อทำให้การดำเนินการง่ายขึ้น เช่น หากต้องการแปลงไฟล์ 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 รองรับพื้นที่สีใดบ้าง

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

Lossless WebP ใช้งานได้กับรูปแบบ RGBA เท่านั้น ดูข้อกำหนดเฉพาะของ WebP Lossless Bitstream

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

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

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

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

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

WebP รองรับจอแสดงผลแบบโปรเกรสซีฟหรือแบบอินเตอร์เลซไหม

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

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

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

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

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

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

  1. ตรวจสอบว่าคุณติดตั้งปลั๊กอิน ADT พร้อมกับเครื่องมือ NDK และเส้นทาง NDK อย่างถูกต้อง (ค่ากำหนด > Android > NDK)
  2. สร้างโปรเจ็กต์ใหม่: ไฟล์ > ใหม่ > โปรเจ็กต์ > โปรเจ็กต์แอปพลิเคชัน Android
  3. โคลนหรือคลายแพ็ก libwebp ไปยังโฟลเดอร์ชื่อ jni ในโปรเจ็กต์ใหม่
  4. เพิ่ม swig/libwebp_java_wrap.c ลงในรายการLOCAL_SRC_FILES
  5. คลิกขวาที่โปรเจ็กต์ใหม่ แล้วเลือกเครื่องมือ Android > เพิ่มการสนับสนุนเนทีฟ ... เพื่อรวมไลบรารีในบิลด์

  6. เปิดพร็อพเพอร์ตี้ของโปรเจ็กต์ แล้วไปที่ C/C++ Build > ลักษณะการทำงาน เพิ่ม ENABLE_SHARED=1 ในส่วน Build (Incremental build) เพื่อสร้าง libwebp เป็นไลบรารีที่ใช้ร่วมกัน

    หมายเหตุ โดยทั่วไป การตั้งค่า 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 คุณสามารถนำบางขั้นตอนที่อธิบายข้างต้นมาใช้ซ้ำได้ในกรณีนั้น

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

สามารถสร้าง WebP เป็น DLL ซึ่งส่งออก libwebp API จากนั้นคุณก็สามารถนำเข้า ฟังก์ชันเหล่านี้ใน C#

  1. สร้าง libwebp.dll วิธีนี้จะตั้งค่า WEBP_EXTERN อย่างเหมาะสมเพื่อส่งออกฟังก์ชัน API

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

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

  1. WebP รองรับสี RGB 24 บิตที่มีช่องอัลฟ่า 8 บิต เมื่อเทียบกับสี 8 บิตและอัลฟ่า 1 บิตของ GIF

  2. WebP รองรับทั้งการบีบอัดแบบสูญเสียและไม่สูญเสียข้อมูล อันที่จริงแล้ว ภาพเคลื่อนไหวเดียวอาจรวมเฟรมแบบสูญเสียและไม่สูญเสียข้อมูลได้ GIF รองรับเฉพาะการบีบอัด แบบไม่สูญเสียข้อมูล เทคนิคการบีบอัดแบบสูญเสียบางส่วนของ WebP เหมาะอย่างยิ่งกับภาพเคลื่อนไหวที่สร้างขึ้นจากวิดีโอจริง ซึ่งเป็นแหล่งที่มาของภาพเคลื่อนไหวที่ได้รับความนิยมเพิ่มขึ้นเรื่อยๆ

  3. WebP มีจำนวนไบต์น้อยกว่า GIF1 GIF แบบเคลื่อนไหวที่แปลงเป็น WebP แบบสูญเสียบางส่วนจะมีขนาดเล็กกว่า 64% ขณะที่ WebP แบบไม่สูญเสียข้อมูลจะมีขนาดเล็กกว่า 19% ซึ่งสำคัญมากโดยเฉพาะเมื่อใช้เครือข่ายมือถือ

  4. WebP ใช้เวลาน้อยลงในการถอดรหัสเมื่อทำการค้นหา ฟีเจอร์กะพริบ การเลื่อนหรือเปลี่ยนแท็บจะซ่อนและแสดงรูปภาพได้ ซึ่งส่งผลให้ภาพเคลื่อนไหวหยุดชั่วคราว แล้วข้ามไปยังจุดอื่น การใช้ CPU มากเกินไปซึ่งส่งผลให้เฟรมของภาพเคลื่อนไหวลดเฟรมลงอาจทำให้ตัวถอดรหัสค้นหาไปข้างหน้าในภาพเคลื่อนไหวด้วย ในสถานการณ์เหล่านี้ WebP แบบเคลื่อนไหวจะใช้เวลาถอดรหัสรวมมากกว่า 2 ถึง 0.57 เท่า ซึ่งทําให้เกิดความยุ่งยากระหว่างการเลื่อนน้อยลงและการกู้คืนเร็วขึ้นจากการใช้งาน CPU ที่เพิ่มขึ้นอย่างรวดเร็ว เนื่องจากมีข้อได้เปรียบ 2 ข้อของ WebP ที่เหนือกว่า GIF ดังนี้

    • รูปภาพ WebP จัดเก็บข้อมูลเมตาว่าแต่ละเฟรมมีอัลฟ่าหรือไม่ คุณจึงไม่ต้องถอดรหัสเฟรมเพื่อทำการตัดสินนี้ ซึ่งจะนำไปสู่การอนุมานที่แม่นยำมากขึ้นว่าเฟรมหนึ่งๆ ต้องใช้เฟรมใดก่อนหน้านี้ จึงช่วยลดการถอดรหัสเฟรมก่อนหน้าโดยไม่จำเป็น

    • โปรแกรมเปลี่ยนไฟล์ WebP แบบดั้งเดิมจะเพิ่มคีย์เฟรมในช่วงเวลาที่สม่ำเสมอ ซึ่งคล้ายกับโปรแกรมเปลี่ยนไฟล์วิดีโอสมัยใหม่ (ซึ่งโปรแกรมเปลี่ยนไฟล์ GIF ส่วนใหญ่ไม่ทำ) วิธีนี้ช่วยปรับปรุงการกรอวิดีโอไปยังภาพเคลื่อนไหวขนาดยาวได้อย่างมาก WebP เพิ่มแฟล็ก "วิธีการผสมผสาน" สำหรับแต่ละเฟรมนอกเหนือจากวิธีการทิ้งเฟรมที่ GIF ใช้ เพื่อความสะดวกในการใส่เฟรมดังกล่าวโดยไม่ต้องเพิ่มขนาดรูปภาพให้ใหญ่ขึ้น ซึ่งจะช่วยให้คีย์เฟรมวาดได้ราวกับว่ารูปภาพทั้งหมดได้รับการล้างเป็นสีพื้นหลังโดยไม่ต้องบังคับให้เฟรมก่อนหน้าเป็นขนาดเต็ม

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

  1. ในกรณีที่ไม่มีการกรอวิดีโอ การถอดรหัส WebP แบบเส้นตรงจะใช้ CPU มากกว่า GIF Lossy WebP ใช้เวลาถอดรหัสมากกว่า GIF 2.2 เท่า ในขณะที่ WebP แบบไม่สูญเสียรายละเอียดจะใช้เวลามากกว่า 1.5 เท่า

  2. การรองรับ WebP ยังไม่แพร่หลายเท่ากับการรองรับ GIF ซึ่งเป็นการรองรับสากลที่มีประสิทธิภาพ

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

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

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

  1. เมื่อถอดรหัสเฟรมที่ใช้เฟรมก่อนหน้า WebM ต้องใช้หน่วยความจำมากกว่า WebP แบบเคลื่อนไหว 50% เพื่อรองรับจำนวนเฟรมก่อนหน้าขั้นต่ำ3

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

  3. สแต็กวิดีโอ Chromium ได้รับการเพิ่มประสิทธิภาพเพื่อการเล่นที่ลื่นไหล และสมมติว่ามีการเล่นวิดีโอครั้งละ 1 หรือ 2 รายการ ด้วยเหตุนี้ การติดตั้งใช้งานจึงเข้มงวดในการใช้ทรัพยากรระบบ (ชุดข้อความ หน่วยความจำ ฯลฯ) เพื่อเพิ่มคุณภาพการเล่นสูงสุด การติดตั้งใช้งานดังกล่าวไม่สามารถปรับขนาดให้เหมาะกับวิดีโอหลายรายการพร้อมกันและต้องออกแบบใหม่ให้เหมาะสําหรับการใช้งานกับหน้าเว็บที่มีรูปภาพจำนวนมาก

  4. ขณะนี้ WebM ยังไม่ได้รวมเทคนิคการบีบอัดทั้งหมดจาก WebP ดังนั้นอิมเมจนี้จะบีบอัดด้วย WebP ได้ดีกว่ารูปภาพอื่นอย่างมาก

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

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

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

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