เครื่องมือจัดการไฟล์ที่ไฟล์ไม่เคยออกจากเครื่องคุณ

เมื่อไม่นานมานี้ ผมได้ใช้เวลาเขียนโปรแกรมอรรถประโยชน์เล็กๆ ตัวหนึ่ง: มันคือเครื่องมือแปลงไฟล์วิดีโอที่ทำงานบนเบราว์เซอร์ทั้งหมด โดยขับเคลื่อนด้วยแกนหลักของ FFmpeg เพื่อทดสอบความสามารถของมัน ผมจึงนำ MacBook Air M3 (RAM 16GB) ของผมมาเป็นหนูทดลอง โดยลองรันการแปลงไฟล์ AVI เก่าๆ เป็น MP4 โดยตรงบน Google Chrome

ผลลัพธ์ที่ได้นั้นทั้งน่าขบขันและน่าทึ่งในทางเทคนิค: นาฬิกาจับเวลาหยุดลงที่ 747.44 วินาที พอดี (มากกว่า 12.5 นาทีเพียงเล็กน้อย) และชิป M3 ที่ขึ้นชื่อเรื่องความเย็นก็ทำให้ตัวเครื่องอะลูมิเนียมอุ่นขึ้นจนสัมผัสได้อย่างชัดเจน

แล้วทำไมคอมพิวเตอร์ที่ติดตั้งหนึ่งในชิปที่ทรงพลังที่สุดในตลาดปัจจุบันถึงต้อง "เหนื่อยหอบ" นานกว่า 12 นาที เพียงเพื่อเปลี่ยนรูปแบบไฟล์วิดีโอ? ในบทความนี้ เราจะมาเจาะลึกถึงหลักการทำงานทางเทคนิคเบื้องหลังกระบวนการนี้ และตอบคำถามสำคัญที่ว่า: ถ้ามันช้าขนาดนั้น ทำไมเราถึงยังต้องการเครื่องมือประมวลผลบนเบราว์เซอร์อีกล่ะ?

1. คอขวดแรก: Remux เทียบกับ Transcode

เหตุผลหลักที่ทำให้การทดสอบของผมใช้เวลานานมากไม่ใช่เพราะตัวเครื่อง แต่เป็นเพราะไฟล์ต้นฉบับ ไฟล์ที่ผมเลือกคือรูปแบบ AVI รุ่นเก่าที่ใช้มาตรฐานการบีบอัดข้อมูล (Codecs) แบบดั้งเดิม เช่น DivX หรือ Xvid

ในโลกของการประมวลผลวิดีโอ คุณต้องแยกแยะระหว่างสองแนวคิดหลักนี้:

• Remux (คัดลอก - เร็วมาก): หากวิดีโอต้นฉบับของคุณใช้ Codec สมัยใหม่ (เช่น H.264) อยู่แล้ว FFmpeg เพียงแค่ดึง "แกนกลาง" ของวิดีโอและเสียงออกมา แล้วนำไปใส่ใน "กรอบ" MP4 อันใหม่ กระบวนการนี้เปรียบเสมือนการคัดลอกข้อมูลจากโฟลเดอร์หนึ่งไปยังอีกโฟลเดอร์หนึ่ง และใช้เวลาเพียงไม่กี่วินาที
• Transcode (ถอดรหัสและเข้ารหัส - ช้ามาก): เนื่องจากไฟล์ AVI ของผมใช้มาตรฐานที่ล้าสมัยซึ่งไม่เข้ากันกับ MP4 ทำให้ FFmpeg ต้อง "สร้างใหม่ตั้งแต่ต้น" มันต้อง Decode (ถอดรหัส) ทุกๆ เฟรมของวิดีโอเก่า จากนั้นจึง Encode (เข้ารหัส) กองเฟรมจำนวนมหาศาลเหล่านั้นให้เป็นมาตรฐาน H.264/H.265 ที่ทันสมัย การทำงานแบบพิกเซลต่อพิกเซลนี้กินทรัพยากร CPU อย่างมหาศาล

2. ความเป็นจริงของ WebAssembly (WASM) บนเบราว์เซอร์

ในการรันซอฟต์แวร์ที่ใช้งานหนักอย่าง FFmpeg (ซึ่งเดิมเขียนด้วย C/C++) โดยตรงบน Google Chrome ผมต้องใช้ประโยชน์จาก WebAssembly (WASM) นี่คือความก้าวหน้าอันน่ามหัศจรรย์สำหรับเว็บสมัยใหม่ แต่มันก็มีจุดอ่อนร้ายแรง: มันไม่สามารถใช้ประโยชน์จากการเร่งความเร็วด้วยฮาร์ดแวร์เฉพาะทาง (Hardware acceleration) ได้อย่างเต็มที่

...

การประมวลผลมัลติมีเดียบนเว็บกำลังก้าวหน้าไปอย่างรวดเร็ว ด้วยการมาถึงของ WebCodecs API ที่ทำงานร่วมกับ WebAssembly (WASM) ทำให้เป้าหมายในการประมวลผลวิดีโอขั้นสูงฝั่งไคลเอนต์ (Client-side) ที่ดึงพลังจากฮาร์ดแวร์เฉพาะทางมาใช้ กลายเป็นความจริงได้ในที่สุด

แต่ทฤษฎีก็เรื่องหนึ่ง แล้วการใช้งานจริงล่ะเป็นอย่างไร? เพื่อหาคำตอบ ผมจึงได้ทำการทดสอบ stress test อย่างหนักหน่วง โดยใช้เครื่องมือบีบอัดวิดีโอที่พัฒนาขึ้นเอง ซึ่งทำงานบนเบราว์เซอร์ทั้งหมด เพื่อประมวลผลไฟล์วิดีโอความละเอียด 1080p ที่มีขนาดใหญ่กว่า 300MB ผลลัพธ์ที่ได้ให้บทเรียนทางเทคนิคที่น่าสนใจมากว่า เบราว์เซอร์ยุคใหม่ทำงานร่วมกับฮาร์ดแวร์ของอุปกรณ์อย่างไร

1. สภาพแวดล้อมการทดสอบในโลกแห่งความจริง

แทนที่จะสร้างสภาพแวดล้อมการทดสอบแบบอุดมคติ (เช่น ปิดแอปทั้งหมด, ล้าง RAM) ผมตัดสินใจรันการทดสอบในสภาพแวดล้อมเดียวกับที่เราทำงานกันจริงๆ ในแต่ละวัน:

• เบราว์เซอร์ที่ใช้ทดสอบ: Chrome Version 150.0.7871.187 (Official Build) (arm64)
• อุปกรณ์: MacBook Air M3, RAM 16GB (รุ่นไร้พัดลม)
• การใช้งานแบบมัลติทาสก์: เบราว์เซอร์มีแท็บงานที่เปิดใช้งานอยู่ 5-6 แท็บ ทำงานพร้อมกับ Firefox (ที่เปิด Slack) บนหน้าจอที่สอง
• ข้อมูลที่ใช้นำเข้า: วิดีโอเชิงวิชาการที่มีรายละเอียดสูงจากช่อง Computerphile ("How AI 'Understands' Images (CLIP)") ความยาว: 18 นาที รูปแบบไฟล์: MP4 1080p ขนาดต้นฉบับ: 327MB

เป้าหมายของการทดสอบนี้คือเพื่อดูว่า WebCodecs API สามารถใช้ Hardware Acceleration ได้อย่างมีประสิทธิภาพและเสถียรเพียงใด ในขณะที่หน่วยความจำ 16GB (Unified Memory) ถูกแชร์อย่างหนักกับการทำงานแบบมัลติทาสก์

2. ขั้นตอนการประมวลผล: พลังของการเร่งความเร็วด้วยฮาร์ดแวร์ (Hardware Acceleration)

ทันทีที่โหลดไฟล์เข้าสู่เครื่องมือและเริ่มทำงาน การประมวลผลก็เป็นไปอย่างราบรื่น ไม่พบอาการกระตุกหรือหน่วงในแท็บ Chrome อื่นๆ ที่เปิดอยู่เลย

นี่คือฟีเจอร์เด็ดของ WebCodecs สำหรับรูปแบบไฟล์สมัยใหม่ (เช่น MP4): แทนที่จะพึ่งพา CPU เพื่อคำนวณการเข้ารหัสวิดีโอผ่านซอฟต์แวร์ (ซึ่งอาจทำให้เบราว์เซอร์ค้างได้ง่ายๆ) WebCodecs API จะเรียกใช้งาน Media Engine ของคอมพิวเตอร์โดยตรงเพื่อจัดการงานเข้ารหัส/ถอดรหัส (encode/decode)

เนื่องจากเป็นดีไซน์แบบไร้พัดลม ฐานด้านล่างทั้งหมดของ Mac M3 จึง ค่อนข้างร้อน ตลอดกระบวนการ นี่เป็นหลักฐานทางกายภาพที่ชัดเจนว่าฮาร์ดแวร์ (โดยเฉพาะ Media Engine) ถูกผลักดันให้ทำงานถึงขีดสุดเพื่อรับส่งบัฟเฟอร์ข้อมูลระหว่างสภาพแวดล้อมของเบราว์เซอร์และตัวเร่งความเร็วฮาร์ดแวร์อย่างต่อเนื่อง

...