เจาะเบื้องหลังระบบสร้างวิดีโออัตโนมัติ: บทเรียนราคาแพงจากบั๊กแคชและเศษทศนิยม
นักพัฒนาแชร์ประสบการณ์ปรับปรุงระบบสร้างวิดีโอประวัติศาสตร์แบบอัตโนมัติ เผชิญหน้ากับปัญหาแรมล้น แคชรูปภาพซ้ำซ้อน และความแม่นยำของเฟรมวิดีโอที่ต้องเป๊ะระดับมิลลิวินาที

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ระบบสร้างวิดีโออัตโนมัติเปลี่ยนจากภาพเดียวซูมยาว เป็นภาพใหม่ทุกประโยค รวม 17 ภาพตามสคริปต์
- เจอปัญหาใหญ่สองจุดคือ การแคชรูปภาพซ้ำซ้อนเมื่อสั่งเรซูม และปัญหาเศษทศนิยมสะสมทำให้วิดีโอกับเสียงไม่ตรงกัน
- การจำกัดการใช้แรมด้วยระบบเช็คเมมโมรี่ก่อนรันช่วยป้องกันระบบล่มบนเครื่อง Mac 16GB ได้
- แก้ปัญหาความยาววิดีโอด้วยเทคนิคการปัดเศษแบบสะสม (cumulative rounding) แทนการปัดเศษแยกทีละชิ้น
การสร้างวิดีโออธิบายประวัติศาสตร์แบบอัตโนมัติทั้งกระบวนการตั้งแต่สคริปต์ เสียงบรรยาย รูปภาพ ไปจนถึงวิดีโอจบในตัวคนเดียว เคยใช้แนวทางเรียบง่ายคือใช้ภาพนิ่งภาพเดียวแล้วค่อยๆ ซูมความยาวสองนาทีครึ่ง ซึ่งทำให้คนดูเบื่อหน่ายอย่างรวดเร็ว
ทางออกคือการปรับใหม่ให้เปลี่ยนภาพทุกๆ ประโยค สคริปต์ความยาว 17 ประโยคจึงต้องใช้ภาพ 17 ภาพ โดยภาพทั้งหมดสร้างจากโมเดลโอเพนซอร์สท้องถิ่นอย่าง FLUX ขนาด 1024x576 พิกเซล ทำงาน 4 ขั้นตอน และควอนไทต์แบบ 3-bit รันบนเครื่อง Mac แรม 16GB ที่ภาพหนึ่งภาพกินแรมมหาศาล ทำให้ไม่สามารถรันขนานกันได้ ต้องทำทีละภาพและรอให้กระบวนการก่อนหน้าปิดสนิทจริงๆ เท่านั้น

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การรันโมเดลปัญญาประดิษฐ์สร้างภาพอย่าง FLUX ในเครื่องที่มีทรัพยากรจำกัด เช่น แรม 16GB ถือเป็นความท้าทายสำคัญ การทำ Pre-flight check หรือระบบตรวจสอบแรมว่างก่อนเริ่มทำงาน (กำหนดไว้ที่ต้องมีแรมว่างมากกว่า 50%) ช่วยป้องกันไม่ให้เครื่องเกิดอาการค้างหรือระบบปฏิบัติการบังคับปิดแอปพลิเคชันกลางคัน ซึ่งเป็นแนวทางปฏิบัติที่ดีในการจัดการระบบอัตโนมัติภายในบ้านหรือเซิร์ฟเวอร์ขนาดเล็ก
ระบบตรวจความพร้อมตั้งเงื่อนไขว่าหากแรมว่างต่ำกว่า 50% จะปฏิเสธการทำงาน ในความพยายามครั้งแรก เมมโมรี่เหลือเพียง 35% จนต้องปิดเบราว์เซอร์หนักๆ เพื่อดันแรมกลับมาที่ 64% ระบบจึงยอมปล่อยให้สร้างภาพ 17 ภาพติดต่อกัน ภาพละประมาณหนึ่งนาที ใช้เวลารวมทั้งหมด 15 ถึง 20 นาที
หลังจากสร้างไปได้ 14 ภาพแล้วหยุดไว้เพื่อจะมาทำต่ออีก 3 ภาพที่เหลือ นั่นคือจุดเริ่มต้นของปัญหาแรก เมื่อสั่งเรซูมการสร้างภาพ บันทึกความคืบหน้ากลับเงียบสนิทจนต้องหันไปปรึกษา Claude Code และถามย้ำถึงสามครั้งว่าระบบกำลังทำงานอยู่จริงหรือไม่ จนพบว่ามันไม่ได้ทำงานต่ออย่างที่คิด
"Nothing's starting at all — is it running?"
Jun Ueno
สาเหตุมาจากตัวห่อหุ้ม FLUX ตั้งชื่อไฟล์ผลลัพธ์ตามหมายเลขซีดและแคชไว้ เมื่อสั่งสร้างต่อด้วยแฟล็ก --force มันจึงวาดภาพใหม่ตั้งแต่ภาพแรกทับ 14 ภาพเดิมที่มีอยู่แล้วโดยสร้างไฟล์ใหม่ลงท้ายด้วย _1 แทนที่จะข้ามไปทำภาพที่ 15 การแก้ปัญหาทำได้โดยเขียนโค้ดตรวจสอบเงื่อนไขไม่ให้เริ่มใหม่ทั้งหมด แต่ให้สร้างเฉพาะสิ่งที่ขาดหายไป พร้อมเพิ่มระบบเช็คไฟล์ว่าง work/.stop เพื่อให้หยุดการทำงานได้อย่างนุ่มนวลที่รอยต่อฉากเมื่อต้องการ

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
เมื่อได้ภาพครบ 17 ภาพ ขั้นตอนต่อไปคือการนำมาตัดต่อรวมเป็นวิดีโอ พร้อมใส่เอฟเฟกต์ซูมช้าๆ ตัดเป็นคลิปสั้น 17 คลิป ต่อเข้าด้วยกัน และวางซ้อนซับไตเติลกับเสียงบรรยาย ซึ่งความยาววิดีโอต้องตรงกับเสียงบรรยายแบบเป๊ะๆ หากเกิดความเหลื่อมล้ำ ภาพจะค้างตอนท้ายหรือซับไตเติลจะคลาดเคลื่อนทันที
เทคนิคที่ช่วยแก้ปัญหาเรื่องเศษทศนิยมสะสมจากการปัดเศษเฟรมแต่ละคลิปแยกกัน คือการเปลี่ยนมาใช้ "การปัดเศษแบบสะสม" (Round Cumulatively) โดยคำนวณตำแหน่งเริ่มต้นของแต่ละฉากจากวินาทีสะสมคูณด้วยเฟรมเรตก่อน แล้วค่อยหาผลต่างกับฉากถัดไปเป็นจำนวนเฟรม ผลลัพธ์ที่ได้ทำให้ผลรวมของทุกคลิปตรงกับจำนวนเฟรมทั้งหมดของเสียงเป๊ะๆ ที่ 121.40 วินาทีพอดี
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น