Video.js v10 - โปรแกรมเล่นวิดีโอโอเพนซอร์สที่เล็กลง 88%

 (videojs.org)
13 คะแนน โดย GN⁺ 2026-03-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Video.js v10 ที่ถูกเขียนใหม่ทั้งหมดเป็นครั้งแรกในรอบ 16 ปี ได้ถือกำเนิดใหม่ด้วยการลดขนาดบันเดิลลง 88% และโครงสร้างที่เหมาะกับสภาพแวดล้อมการพัฒนาสมัยใหม่
  • รองรับ React·TypeScript·Tailwind แบบ first-class พร้อม UI เริ่มต้นที่สวยงาม และ โครงสร้างเอกสารที่เป็นมิตรกับ AI
  • ด้วย Streaming Processor Framework(SPF) ใหม่ จึงสร้าง เอนจินสตรีมมิงแบบโมดูลาร์ ที่ประกอบเฉพาะฟังก์ชันที่ต้องใช้ได้ และทำให้มีขนาดเบากว่า HLS.js เหลือเพียง 12%
  • ด้วย สถาปัตยกรรมแบบ composition-based และ ระบบสกิน React/Web Components จึงสามารถเปลี่ยนหรือตัด UI และฟังก์ชันออกได้อย่างอิสระ
  • ตั้งเป้าเปิดตัวอย่างเป็นทางการในปี 2026 และกำลังพัฒนาไปสู่แพลตฟอร์มมีเดียโอเพนซอร์สยุคถัดไปผ่าน การพัฒนาร่วมกับ AI และ ระบบนิเวศพรีเซ็ตที่ขยายได้

ภาพรวม Video.js v10 เบต้า

  • Video.js v10.0.0 เบต้าเป็น การเขียนใหม่ทั้งหมดครั้งแรกในรอบ 16 ปี และเป็นผลลัพธ์จากความร่วมมือของหลายโครงการโอเพนซอร์ส ไม่ใช่แค่ Video.js แต่รวมถึง Plyr, Vidstack, Media Chrome ด้วย
  • ระบบนิเวศที่มีรวม 75,000 GitHub stars และยอดเล่นระดับหลายพันล้านครั้งต่อเดือนเข้ามามีส่วนร่วม และถูกออกแบบใหม่โดยคำนึงถึงแนวทางการพัฒนาสมัยใหม่และ สภาพแวดล้อมการพัฒนาแบบมี AI ช่วย
  • เป้าหมายหลักคือ ลดขนาดบันเดิล 88%, รองรับ React·TypeScript·Tailwind แบบ first-class, มี UI เริ่มต้นที่สวยงาม และมี โครงสร้างเอกสารที่เป็นมิตรกับ AI

การลดขนาดบันเดิลและการปรับปรุงประสิทธิภาพ

  • ตัวเล่น Video.js v10 พื้นฐานมี ขนาดบันเดิลพื้นฐานลดลง 88% เมื่อเทียบกับ v8 และแม้ตัดฟังก์ชัน ABR(Adaptive Bitrate) ออกก็ยัง ลดลง 66%
    • ตัวอย่าง: v8 พื้นฐาน 260.5kB(minified) → v10 HTML video player 97.4kB(minified), เวอร์ชัน React อยู่ที่ 62.0kB
  • ด้วยการนำ Streaming Processor Framework(SPF) ใหม่มาใช้ จึงสามารถสร้าง เอนจินสตรีมมิงแบบโมดูลาร์ ที่ประกอบเฉพาะฟังก์ชันที่ต้องใช้ได้
    • หากใช้ HLS แบบเรียบง่าย v10+SPF จะมี ขนาดไฟล์เพียง 19% ของ v8+VHS
    • ตัวเอนจิน SPF เองมีขนาดเพียง 12% ของ HLS.js-light (38.5kB minified) และเหมาะกับการจัดการ ABR แบบเรียบง่าย
  • SPF เข้ากันได้ทั้งหมด กับเอนจินเดิมอย่าง HLS.js, Shaka, dash.js และในกรณีที่ไม่ต้องใช้ฟังก์ชัน DRM หรือโฆษณาที่ซับซ้อน ก็สามารถทำให้ เบาได้อย่างมาก

สถาปัตยกรรมแบบ composition-based

  • v10 เป็นโครงสร้างคอมโพเนนต์ที่แยก State, UI, Media ออกจากกัน ทำให้แต่ละส่วนสามารถเปลี่ยนหรือลบออกได้อย่างอิสระ
    • ฟังก์ชัน createPlayer() รับอาร์เรย์ features เพื่อรวมเฉพาะความสามารถที่ต้องการ
    • ตัวอย่าง: หากไม่ต้องการฟังก์ชันเสียง โค้ด volume, mute จะไม่ถูกใส่ไว้ในบันเดิล
  • หากต้องการเอา UI ออก ก็เพียงแค่ไม่โหลดสกิน — ทำให้ ตัดโค้ดที่ไม่จำเป็นออกได้ทั้งหมด
  • ตัวอย่าง React แบบมินิมอลทำงานได้ด้วยขนาด ต่ำกว่า 5kB(gzipped) และมีเพียงปุ่มเล่น/หยุดชั่วคราวแบบเรียบง่าย

การปรับแต่ง UI และระบบสกิน

  • v10 มี ระบบสกินบนพื้นฐาน React และ Web Components และใช้โครงสร้าง unstyled UI primitives ที่ได้รับแรงบันดาลใจจาก Base UI, Radix
    • คอมโพเนนต์ UI แต่ละตัวเรนเดอร์เป็น HTML element เดียว จึงสามารถ ควบคุมได้โดยตรง
  • ใน v8 ที่ผ่านมา ตัวจับไทม์ไลน์ถูกควบคุมด้วย CSS pseudo-elements แต่ใน v10 เปลี่ยนเป็น DOM element จริง ทำให้จัดสไตล์ได้ง่ายขึ้น
  • ในเบต้ามีสกินมาให้ 2 แบบ
    • สกินเริ่มต้น: สไตล์โปร่งฝ้า(frosted) พร้อมแอนิเมชันที่นุ่มนวล
    • สกินมินิมอล: โครงพื้นฐานที่เรียบง่ายสำหรับการคัสตอม
  • ดีไซน์ของ หน้าต่างโต้ตอบข้อผิดพลาด ในสกินก็ถูกทำให้เป็นหนึ่งเดียวกัน ช่วยเพิ่มความสมบูรณ์ทางภาพ

ระบบพรีเซ็ต

  • v10 นำแนวคิด พรีเซ็ต(preset) ตามวัตถุประสงค์การใช้งาน มาใช้ เพื่อมอบ เทมเพลตตัวเล่นที่พร้อมใช้งานทันที ซึ่งรวมสกิน ฟังก์ชัน และการตั้งค่าสื่อเข้าด้วยกัน
    • Video preset: สำหรับวิดีโอบนเว็บทั่วไป
    • Audio preset: สำหรับเสียงอย่างพอดแคสต์
    • Background video preset: สำหรับวิดีโอพื้นหลัง โดยตัดคอนโทรลและเสียงออก
  • พรีเซ็ตช่วยให้เริ่มต้นได้รวดเร็ว ขณะเดียวกันก็ยัง เปลี่ยนทุกองค์ประกอบได้ และคงความยืดหยุ่นเต็มที่
  • ในอนาคตมีแผนเพิ่มพรีเซ็ตสำหรับ การศึกษา, ชอร์ตฟอร์ม, แพลตฟอร์มครีเอเตอร์

การออกแบบที่เป็นมิตรกับ AI

  • v10 ตั้งเป้าเป็นโครงสร้างที่ AI agent สามารถร่วมพัฒนาได้
    • ใช้ คอมโพเนนต์ที่ไม่ถูกทำให้นามธรรมเกินไป และ unstyled UI primitives เพื่อเพิ่มความเข้าใจโค้ด
    • มีไฟล์ llms.txt เพื่อช่วยให้สำรวจเอกสารได้มีประสิทธิภาพ รวมถึงเวอร์ชันแยกตามเฟรมเวิร์ก
    • เอกสารทั้งหมดถูกจัดทำในรูปแบบ Markdown เพื่อให้ AI เข้าถึงได้โดยตรงโดยไม่มีบริบท HTML ที่ไม่จำเป็น
    • มี ชุดทักษะ AI ภายในรีโพซิทอรี เพื่อรองรับการช่วยพัฒนาของผู้ใช้ในอนาคต

คำแนะนำการใช้งานเบต้า

  • API ยังไม่เสถียร, จึงอาจมีการเปลี่ยนแปลงอินเทอร์เฟซบางส่วนก่อนเปิดตัวอย่างเป็นทางการ
  • ขณะนี้ยัง เน้นฟังก์ชันการเล่นบนเว็บไซต์พื้นฐาน, รองรับการเข้าถึง คำบรรยาย และฟอร์แมตหลากหลายได้ แต่ เมนูตั้งค่าและส่วนอื่น ๆ ยังไม่ถูกพัฒนา
  • กำลังรวบรวม ฟีดแบ็กผ่าน GitHub Issues และ Discord อย่างต่อเนื่อง
  • ผู้ใช้เวอร์ชันเดิมควร ย้ายหลังจากมีการเผยแพร่ migration guide

โรดแมปในอนาคต

  • ตั้งเป้า เปิดตัวอย่างเป็นทางการ (GA) ช่วงกลางปี 2026
  • มีแผนทำให้ฟังก์ชันเทียบเท่ากับ Plyr, Vidstack, Media Chrome
  • วางแผนรองรับ ฟังก์ชันโฆษณา ในช่วงครึ่งหลังของปี 2026
  • มีแผนเผยแพร่ migration guide และพรีเซ็ตเพิ่มเติม

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-25
ความคิดเห็นจาก Hacker News

  • เผื่อใครสงสัย ขอบอกไว้ก่อนว่า ธีมสี syntax highlighting ของเว็บไซต์นี้คือ “gruvbox”
    ส่วนตัวชอบมาก แต่ใช้เวลานานพอสมควรกว่าจะหาว่าเป็นธีมนี้
    ลิงก์ GitHub ของ gruvbox

    • มีใครรู้ไหมว่าเว็บไซต์นี้สร้างด้วยเทคโนโลยีอะไร? ชอบดีไซน์กับ UI มาก
    • เผื่อไว้ก่อน ธีมนี้ใช้ใน VSCode ได้ด้วย

  • ฉันไม่เคยใช้ video.js มาก่อน แต่รู้สึกว่าเว็บหรือโฆษณานี้เหมือนทำมาสำหรับคนที่คุ้นเคยกับมันอยู่แล้ว
    ระหว่างอ่านก็มีอย่างหนึ่งที่สงสัยว่า มันต่างจาก แท็ก HTML video ตรงไหน? หรือแค่คอนโทรลเลอร์ต่างกัน?

    • เป็นประเด็นที่ดี ควรอธิบายส่วนนั้นในเว็บไซต์ให้ชัดกว่านี้
      ทุกวันนี้แท็ก video ดีขึ้นมากแล้ว แต่ Video.js ยังแตกต่างตรง การทำสไตล์ให้สม่ำเสมอข้ามเบราว์เซอร์, ฟีเจอร์ขั้นสูง (analytics, DRM, วิดีโอ 360 องศา ฯลฯ), และ รองรับฟอร์แมตสตรีมมิงหลายแบบ (HLS, DASH ฯลฯ)
      สุดท้ายแล้วจะทำด้วยแท็ก video อย่างเดียวก็ได้ แต่พอทำไปทำมาก็จะลงเอยด้วยการสร้างอะไรสักอย่างที่คล้าย Video.js เอง
    • แท็ก video ไม่ได้ทำงานได้สมบูรณ์ในทุกสภาพแวดล้อม มี edge case ตามแต่ละเบราว์เซอร์เยอะมาก
      ถ้าต้องการเพลเยอร์หรือฟังก์ชันสตรีมมิงที่เสถียร ก็ใช้ Video.js จะดีกว่า
      อ้างอิงจากประสบการณ์ ฉันเคยทำ TV broadcast player สำหรับประเทศจอร์เจีย ที่รองรับตั้งแต่ LG Smart TV ปี 2009 ไปจนถึงเบราว์เซอร์รุ่นใหม่
    • เบราว์เซอร์ส่วนใหญ่ ไม่รองรับ HLS หรือ DASH
      นี่สำคัญเพราะเกี่ยวกับ การปรับบิตเรตแบบไดนามิก และยังช่วยให้แคชมีประสิทธิภาพขึ้นด้วย

  • สงสัยว่าสถานการณ์ของ WebVTT เดี๋ยวนี้เปลี่ยนไปหรือยัง
    เมื่อก่อนเคยพยายามปรับแต่งการเรนเดอร์ซับไตเติล แต่ยากมาก

  • สงสัยว่าทำไมถึงไม่แจกจ่ายสิ่งนี้เป็น Web Component
    สำหรับฉันมันดูเป็น use case ที่สมบูรณ์แบบเลย — เพราะเป็นคอนโทรลที่ฝังอยู่ในออบเจ็กต์ที่มีความหมายอยู่แล้ว

    • คำถามดี ก่อนหน้านี้เคยพยายามทำ media-chrome กับ Mux Player เป็น Web Component แล้วเจอปัญหาเรื่อง การรวมกับ React อย่างหนัก
      สุดท้ายเลยแก้ด้วยการทำ React shim แต่ก็ทำให้เกิดปัญหาอีกชุดหนึ่ง
      ใน VJS 10 เลยหาจุดลงตัวด้วยสถาปัตยกรรม headless core + rendering layer
      ผลคือรองรับทั้ง React component และ Web Component
      ลิงก์ GitHub ของ media-chrome
    • Web Component ดูเท่มาก แต่ในทางปฏิบัติมักเสียเวลาไปกับปัญหา styling กับ SSR เยอะ
      ทั้งบั๊กของ Shadow DOM และความเข้ากันได้ระหว่างเฟรมเวิร์ก ทำให้สุดท้ายใช้เวลาไปกับการตั้งค่าสภาพแวดล้อมมากกว่าทำตัวเพลเยอร์
      ผู้ใช้ส่วนใหญ่ไม่ได้สนใจเรื่องพวกนี้ ฉันคิดว่าแค่ JS library + API ที่สะอาด ดีกว่ามาก
    • จริง ๆ แล้วโค้ด React ถูกคอมไพล์เป็น HTML Custom Elements ได้ ดังนั้นในความหมายกว้าง ๆ มันก็เป็น Web Component อยู่แล้ว
      แต่เหตุผลที่ใช้ React คือ tree-shaking ทำให้รวมเฉพาะโค้ดที่จำเป็นได้
      ใน HTML ทั่วไปยังทำ optimization แบบนี้ได้ยาก ดังนั้น build pipeline จึงทำหน้าที่คล้าย ตัวสร้าง Web Component ไปในตัว

  • ฉันเคยลองเปลี่ยน audio player ของตัวเองจาก Plyr มาเป็น Video.js แต่พบว่าค่าเริ่มต้นยังมี ช่องว่างด้านฟีเจอร์ อยู่บ้าง
    ไม่มีความเร็วเล่นต่ำกว่า 1x, ปรับเสียงบนมือถือไม่ได้, ไม่มีปุ่ม seek, ปรับแต่งสีได้ยาก, เดโมน้อย ฯลฯ

    • เป็นฟีดแบ็กที่ดี จะเอาเรื่องพวกนี้ไป เปิดเป็น issue
      ตอนนี้ตั้งเป้าไว้ที่ feature parity กับ Plyr และตัวอื่น ๆ โดยเล็ง GA ไว้ช่วงกลางปีนี้

  • ฉันไม่ได้รู้เรื่อง video hosting มากนัก แต่เคยใช้ HTML5 video player
    เลยสงสัยว่าฝั่งเซิร์ฟเวอร์ต้องทำ endpoint ที่คอยเสิร์ฟวิดีโอเป็นชังก์ เองหรือเปล่า
    ถ้าแบ่งด้วย ffmpeg ทีละ 2MB ควรเอาไปไว้ที่ไหน? CDN? เซิร์ฟเวอร์ตัวเอง?
    ถ้าอยากให้ Video.js ทำงานลื่นที่สุด โครงสร้างแบบไหนดีที่สุด?

    • แค่ แปลงเป็น HLS ก็พอ มันจะถูกแบ่งเป็นชังก์อัตโนมัติทีละ 1–2 วินาที และเสิร์ฟเป็นไฟล์สแตติกผ่าน nginx ได้
      ทำงานเข้ากับ Video.js ได้ดี และบน LG TV ก็ยัง เล่นแบบอิงแท็ก ได้ด้วย
    • ถ้าไม่ต้องการสลับเวอร์ชันตอนรันไทม์ (ABR) ก็ไม่ต้องแบ่งชังก์เองด้วยซ้ำ
      แค่ให้เซิร์ฟเวอร์รองรับ Range request เบราว์เซอร์ก็จัดการที่เหลือเอง
      ฉันใช้ชุด object storage + CDN อย่าง DO Spaces อยู่ และมันก็ทำงานได้ดี
    • แต่ชังก์ต้องเริ่มด้วย IDR keyframe เลยไม่ใช่เรื่องง่าย
      ต้องจัดการทั้ง encoding และ segment splitting ไปพร้อมกัน (เช่น ใช้ dash formatter ของ ffmpeg)
      ถ้าจะให้ความยาวของ audio กับ video segment ตรงกัน เครื่องคำนวณ GOP ก็มีประโยชน์
      โดยทั่วไปคือเข้ารหัสจากไฟล์ต้นฉบับคุณภาพสูงออกมาเป็นหลายความละเอียด แล้วอัปขึ้นที่ไหนสักแห่งอย่าง S3 พร้อม manifest ของ HLS/DASH
      จากนั้นเพลเยอร์ก็ใช้แค่ manifest URL เดียวเพื่อค้นหาทรัพยากรทั้งหมดที่ต้องใช้
    • MPE-DASH ก็น่าพิจารณาเหมือนกัน

  • โพสต์ในบล็อกเขียนมาดีมาก
    ประทับใจวิธีอธิบายที่ ให้เกียรติผู้อ่านในฐานะผู้เชี่ยวชาญ อยากเห็นการเปิดตัวผลิตภัณฑ์แบบนี้มากขึ้น

  • Steve ยินดีด้วย!
    ตอนก่อนหน้านี้ที่ฉันทำงานที่ JW Player ฉันประทับใจกับความเรียบง่ายและ ระบบธีม ของ Video.js มาก
    หวังว่าเวอร์ชันนี้จะประสบความสำเร็จอย่างมาก

    • ไม่ได้คุยกันนานเลย Zach! ดีใจที่ได้เจอ
      สนุกมากที่ได้คุยกับทีม JW ตาม FOMS และงานคอนเฟอเรนซ์ต่าง ๆ
      สายเทคโนโลยีวิดีโอยังเป็น พื้นที่ที่ร้อนแรง อยู่เสมอ ถ้าอยากกลับมาก็ยินดีต้อนรับทุกเมื่อ

  • ตัวเลข 88% นี่น่าทึ่งมาก
    อยากรู้ว่าจุดปรับปรุงที่ใหญ่ที่สุดคืออะไร — เดาว่าน่าจะเป็น ระบบปลั๊กอิน
    แล้วก็อยากรู้ว่าระหว่างรีไรต์ มี integration สำคัญ ๆ พังไปบ้างไหม

  • อยากรู้ว่ามี การเปลี่ยนแปลงด้านสถาปัตยกรรม อะไรบ้างระหว่างการรีไรต์ และมี trade-off อะไรเมื่อเทียบกับดีไซน์ Video.js แบบเดิม