สร้าง Chrome Extension แปลเสียงประชุม: บทเรียนจาก MV3
นักพัฒนาแชร์เบื้องหลังการสร้าง Chrome Extension แปลซับไตเติลดลสดสำหรับ Meet, Zoom และ Teams เผยปัญหาการจัดการเสียงใน MV3 และค่าใช้จ่ายที่ลดลง 17 เท่า
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- พัฒนา Chrome Extension แปลเสียงประชุมสดผ่าน Meet, Zoom และ Teams โดยไม่ต้องใช้บอทเข้าห้อง
- แก้ไขปัญหาข้อจำกัดของ MV3 ด้วยการใช้ offscreen document และ AudioWorklet เพื่อประมวลผลสตรีมเสียง
- เปลี่ยนมาใช้ผู้ให้บริการแบบสตรีมเดียว ช่วยลดต้นทุนจาก 2.55 ดอลลาร์เหลือ 0.154 ดอลลาร์ต่อชั่วโมง
- ทดสอบความแม่นยำและความหน่วงด้วยการจำลองผู้เข้าร่วม 4 โปรไฟล์ในลินุกซ์บ็อกซ์
นักพัฒนาซอฟต์แวร์รายหนึ่งได้แชร์ประสบการณ์การสร้าง Chrome Extension ขึ้นมาด้วยตนเอง ซึ่งมีความสามารถในการแสดงซับไตเติลแปลภาษาแบบเรียลไทม์บนหน้าต่างเบราว์เซอร์ที่กำลังใช้งาน Google Meet, Zoom หรือ Microsoft Teams จุดเด่นคือไม่มีบอทแปลกปลอมเข้าร่วมการประชุม แต่ดึงเสียงตรงมาจากแท็บเบราว์เซอร์นั้นๆ โดยตรง โดยอ้างอิงข้อมูลสถิติ ณ วันที่ 17 กันยายน 2026
ความท้าทายแรกเกิดขึ้นในสถาปัตยกรรม Manifest V3 (MV3) ซึ่งเบื้องหลังของส่วนขยายทำงานเป็น service worker ที่ไม่มีทั้ง Web Audio และ getUserMedia ทำให้ service worker ต้องรับเพียง stream id แล้วสร้าง offscreen document ขึ้นมา ซึ่งเป็นหน้าเว็บที่มองไม่เห็นและมี API เหล่านั้นอยู่ พร้อมใช้งาน AudioContext และ AudioWorklet ในการผสมช่องสัญญาณเสียงให้เป็นโมโน และปล่อยข้อมูลออกมาเป็น Int16 PCM ในบล็อกขนาด 4,096 ตัวอย่าง หรือประมาณ 85 มิลลิวินาที ที่ความถี่ 48 kHz
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
อุปสรรคสำคัญอีกประการคือข้อผิดพลาด "Cannot capture a tab with an active stream" ซึ่งมักปรากฏขึ้นเมื่อการจับภาพหน้าจอก่อนหน้านี้ยังไม่ถูกปล่อยอย่างสมบูรณ์ และการรีโหลดหน้าเว็บหรือใช้คำสั่ง chrome.runtime.reload() ก็ไม่สามารถล้างค่านี้ได้ เนื่องจากสตรีมยังคงทำงานอยู่ใน offscreen document จึงจำเป็นต้องปิดเอกสารนั้น แต่นั่นก็ยังไม่เพียงพอเพราะ Chrome ปล่อยสตรีมแบบ asynchronous ทำให้ต้องใช้วิธีการวนลูปตรวจสอบสถานะ (polling) แทนการคาดเดาด้วยเวลา timeout
การพัฒนาส่วนขยายสำหรับเบราว์เซอร์ในยุค Manifest V3 (MV3) มักพบข้อจำกัดด้านสถาปัตยกรรมความปลอดภัยที่แยกการทำงานเบื้องหลังออกจากหน้าเว็บโดยตรง นักพัฒนารุ่นใหม่จึงต้องประยุกต์ใช้เทคนิคอย่าง Offscreen Documents และ AudioWorklet ซึ่งเดิมทีไม่ได้ออกแบบมาเพื่อการดึงเสียงสตรีมโดยตรง แต่นับเป็นทางออกสำคัญในการจัดการระบบประมวลผลเสียงภายในเบราว์เซอร์ปัจจุบัน
ในเวอร์ชันแรก ระบบเลือกใช้บริการถอดเสียงจาก Deepgram และแปลภาษาด้วย DeepL แต่เพื่อให้คำแปลค่อยๆ ปรากฏขึ้นระหว่างประโยค ระบบจึงจำเป็นต้องส่งผลลัพธ์คั่นกลาง (interim results) ไปแปลด้วย ส่งผลให้มีค่าใช้จ่ายสูง เนื่องจาก DeepL คิดเงินตามความยาวของข้อความต้นทาง และข้อความที่ยังพิมพ์ไม่จบจะถูกส่งซ้ำเรื่อยๆ เมื่อมีความคืบหน้า
จากการทดสอบแทร็กเสียงจริงผ่านซ็อกเก็ตของ Deepgram เมื่อวันที่ 29 สิงหาคม พบว่ามีตัวอักษรถูกส่งไปแปลมากกว่าการแปลเฉพาะประโยคที่สมบูรณ์ถึง 2.53 เท่า ทำให้การประชุมนานหนึ่งชั่วโมงมีต้นทุนสูงถึงประมาณ 2.55 ดอลลาร์สหรัฐ ทางออกของปัญหานี้คือการเปลี่ยนไปใช้ผู้ให้บริการที่รองรับการถอดเสียงและแปลภาษาในสตรีมเดียวอย่าง Soniox ผ่านโมเดล stt-rt-v5 ซึ่งช่วยลดต้นทุนลงได้อย่างมหาศาล
"stt-rt-v5, $31.23 for 202.6 hours of audio, which is $0.154 per hour. Against $2.55 with two services, that is 17 times less."
นักพัฒนาผู้สร้างส่วนขยาย Chrome Extension
ข้อมูลจากหน้า /v1/usage/summary ระหว่างวันที่ 30 สิงหาคมถึง 17 กันยายน ระบุว่าการใช้งานโมเดล stt-rt-v5 มีค่าใช้จ่ายเพียง 31.23 ดอลลาร์ สำหรับเสียงความยาว 202.6 ชั่วโมง ซึ่งคิดเป็น 0.154 ดอลลาร์ต่อชั่วโมงเท่านั้น เมื่อเทียบกับต้นทุน 2.55 ดอลลาร์จากการใช้สองบริการเดิม จึงประหยัดกว่าถึง 17 เท่า อย่างไรก็ตาม ต้นทุนที่ต้องแลกมาคือเรื่องของความหน่วง (latency) ที่เพิ่มขึ้นจากเดิม
เพื่อให้แน่ใจว่าระบบทำงานได้เสถียร นักพัฒนาได้สร้างชุดทดสอบบนเครื่อง Linux โดยรันโปรไฟล์ Chrome 3 โพรไฟล์เข้าร่วมการประชุมเดียวกันและจำลองเสียงพูดจากสคริปต์สัมภาษณ์ความยาว 118บรรทัด ส่วนโปรไฟล์ที่ 4 จะทำหน้าที่รันส่วนขยายเพื่อเขียนซับไตเติล จากนั้นสคริปต์จะเปรียบเทียบผลลัพธ์เพื่อวัดความแม่นยำและระยะเวลาเป็นมิลลิวินาทีก่อนที่ประโยคสุดท้ายจะปรากฏขึ้น
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น