วิธีแปลงข้อมูลสดให้เป็นวิดีโอที่แชร์ได้โดยอัตโนมัติ

• สร้างเวิร์กโฟลว์บนเว็บเพื่อทำ ข้อมูลสด ที่อัปเดตทุก ๆ หลายวันให้กลายเป็นวิดีโอสำหรับโซเชียล โดยไม่ต้องให้คนมาตัดต่อใหม่ทุกครั้ง
• ต้นฉบับของวิดีโอไม่ใช่ไฟล์ตัดต่อ แต่เป็น หน้าเว็บที่ซ่อนไว้ โดย Playwright จะขยับเบราว์เซอร์ทีละเฟรม และ ffmpeg จะนำมารวมเป็น MP4 และ GIF
• ไฟล์ storyboard.ts สั้น ๆ และ playhead เดียว ใช้จัดองค์ประกอบตัวเลขของวันนี้, เฟด, จุดเริ่มต้นในเดือนธันวาคม 2024 และช่วงการเติบโต 18 เดือน ให้เป็นคลิปราว 14 วินาที
• GitHub Action ที่ตั้งเวลาไว้จะตรวจจับการเปลี่ยนแปลงของข้อมูล แล้วรีบิลด์และรีดีพลอยเว็บไซต์ พร้อมสร้าง 4 เวอร์ชัน ตามสัดส่วนภาพและชุดภาษา ก่อนเผยแพร่บน CloudFront CDN
• YouTube อัปโหลดเป็นฉบับร่างแบบไม่เผยแพร่ได้ แต่ Instagram รองรับเฉพาะการโพสต์สาธารณะทันที จึงยังคงมี ขั้นตอนอนุมัติโดยมนุษย์ สำหรับการตรวจทานขั้นสุดท้ายและแก้ไขแคปชัน

---

โครงสร้างที่ใช้หน้าเว็บเป็นต้นฉบับวิดีโอ

• วิดีโอไม่ได้เริ่มจากโปรเจ็กต์ตัดต่อแยกต่างหาก แต่เริ่มจาก หน้าเฉพาะที่ซ่อนไว้ ภายในเว็บไซต์
• หน้านี้ออกแบบมาให้พอดีกับหน้าจอแนวตั้งแบบ 9:16 ที่ใช้ใน Reels, Shorts และ TikTok
• บนหน้าจอมีการนำองค์ประกอบเดิมจากเว็บไซต์ไลฟ์กลับมาใช้
  • พาดหัว
  • ตัวเลขสถาบันขนาดใหญ่
  • กราฟแบบแอนิเมชัน
  • แผนที่ทั้งประเทศ
  • บรรทัดเครดิตขนาดเล็ก
• ใช้แอนิเมชันบนไทม์ไลน์ของเว็บเบราว์เซอร์และเอฟเฟกต์การเคลื่อนไหว โดยคอมพิวเตอร์จะควบคุม เบราว์เซอร์แบบ headless ที่ผู้ใช้มองไม่เห็น
• สามารถเปิดดูในเบราว์เซอร์ได้โดยตรงเหมือนหน้าเว็บทั่วไป เพื่อพรีวิวและดีบักด้วยการเลื่อนไปหน้า-หลัง
• สืบทอดเฟรมเวิร์กหลายภาษาของเว็บไซต์มาโดยตรง ทำให้จับภาพวิดีโอแยกตามภาษาที่รองรับได้
• asset bakery, data pipeline และฟรอนต์เอนด์ของโปรเจ็กต์นี้เปิดเป็น open source

storyboard.ts และ playhead

• ไฟล์เดียวอย่าง storyboard.ts กำหนดจังหวะเวลาและการเปลี่ยนผ่านของวิดีโอ เหมือน shot list ของผู้กำกับ
• โครงสร้างประกอบด้วย beat ที่ตั้งชื่อไว้หลายช่วงและระยะเวลาของแต่ละช่วง
  • คงตัวเลขรวมของวันนี้ไว้ 1.5 วินาที
  • เฟด 0.7 วินาที
  • คงจุดเริ่มข้อมูลในเดือนธันวาคม 2024 ไว้ 1.5 วินาที
  • จากนั้นเล่นช่วงการเติบโต 18 เดือนต่อไปข้างหน้า
  • แล้วกลับมาหยุดที่หน้าจอของวันนี้อีกครั้ง
• ผลลัพธ์ทั้งหมดเป็นคลิปราว 14 วินาที
• การวาดกราฟ, การแสดงจุดบนแผนที่ และการเพิ่มค่าตัวนับ จะเคลื่อนที่ไปพร้อมกันโดยผูกกับ playhead เดียว
• playhead ทำให้ทุกคอมโพเนนต์เรนเดอร์สถานะเดียวกันใน timestamp ที่กำหนด เพื่อไม่ให้องค์ประกอบบนหน้าจอคลาดกัน

วิธี “อบ” ทีละเฟรม

• ไฟล์วิดีโอจริงถูกสร้างโดยเปิดหน้าเว็บในเบราว์เซอร์แบบ headless และควบคุม Chromium ด้วย Playwright
• ตอนแรกมองว่าน่าจะกดปุ่มเล่นเสมือนแล้วจับภาพด้วยการบันทึกหน้าจอได้ แต่การบันทึกแบบเรียลไทม์อาจมีเฟรมตกหรือสะดุด
• วิดีโอเดียวกันอาจเล่นลื่นบนเครื่องโลคัล แต่ทำงานต่างออกไปบนฮาร์ดแวร์คลาวด์ และในการทดลองช่วงแรกบางครั้งยังเล่นเร็วผิดปกติด้วย
• เพื่อให้ผลลัพธ์เสถียรกว่าเดิม จึงไม่บันทึกแบบเรียลไทม์ แต่สร้างทีละเฟรมเหมือน flipbook
  • สั่งหน้าเว็บให้ “แสดงภาพ ณ เวลา 0.04 วินาที”
  • ถ่ายสกรีนช็อต
  • ขยับไปที่ 0.08 วินาทีแล้วถ่ายสกรีนช็อตอีกครั้ง
  • ทำซ้ำแบบนี้หลายร้อยครั้ง
• เพราะเป็นการค่อย ๆ พลิกหน้าเหมือนเลื่อนดูหน้าที่หยุดนิ่งด้วยมือ แต่ละภาพจึงถูกจับในสถานะที่เรนเดอร์เสร็จสมบูรณ์
• ผลลัพธ์จึง กำหนดได้แน่นอนและทดสอบได้ และหากรันสองครั้งก็ควรได้เฟรมชุดเดิมที่ตรวจสอบซ้ำได้
• ถ้าเพิ่มจำนวนเฟรมเป็นสองเท่า เวลาคำนวณในการเรนเดอร์และพื้นที่จัดเก็บที่ต้องใช้ก็จะเพิ่มขึ้นราวสองเท่าเช่นกัน

รายละเอียดที่ช่วยให้การเรนเดอร์บนเซิร์ฟเวอร์เสถียร

• แผนที่ทั้งประเทศใช้ MapLibre GL JS และเรนเดอร์ด้วยโค้ด WebGL ซึ่งโดยทั่วไปคาดหวัง GPU
• แต่เซิร์ฟเวอร์ไม่มี GPU จึงตั้งค่าให้ Chromium ใช้ ซอฟต์แวร์เรนเดอร์ริง
  • ช้ากว่าฮาร์ดแวร์กราฟิกจริง
  • แต่รันได้ด้วยคุณภาพใกล้เคียงกันบนแทบทุกแพลตฟอร์ม
• แต่ละเฟรมถูกบันทึกเป็น JPEG ไม่ใช่ PNG
  • ส่วนที่ช้าในการจับภาพหน้าจอคือการเข้ารหัส PNG
  • วิดีโอที่ได้ดูเหมือนเดิม จึงได้ประโยชน์ด้านความเร็วตลอดหลายร้อยเฟรม
• ต้องใช้แฟล็กบางอย่างเพื่อให้เบราว์เซอร์แบบ headless รันได้เสถียรบน bare server ภายในคอนเทนเนอร์ และรายละเอียดทั้งหมดอยู่ในรีโพสาธารณะ
• จากนั้นจึงนำภาพหลายร้อยใบที่สร้างได้มาต่อรวมเป็น MP4 และ GIF แบบวนซ้ำด้วย ffmpeg

ระบบอัตโนมัติบน GitHub Action

• กระบวนการทั้งหมดถูกเชื่อมเข้ากับ data pipeline อัตโนมัติที่รันด้วย GitHub Action ตามเวลาที่ตั้งไว้
• ระบบจะตรวจดูว่าข้อมูลเปลี่ยนไปกี่ครั้งในแต่ละวัน
• เมื่อมีข้อมูลใหม่ งานจะทำสิ่งต่อไปนี้
  • รีบิลด์เว็บไซต์
  • รีดีพลอยเว็บไซต์
  • สร้าง 4 เวอร์ชัน ตามชุดสัดส่วนสี่เหลี่ยมจัตุรัส/แนวตั้ง และภาษาอังกฤษ/สเปน
  • เผยแพร่ไปยัง CloudFront CDN
• หน้าดาวน์โหลดสาธารณะจะแสดงเวอร์ชันล่าสุดสำหรับแต่ละภาษาที่รองรับ
• ขั้นตอนสุดท้ายรวมถึงการอัปโหลดฉบับร่างขึ้น YouTube และการแจ้งเตือนสำหรับการโพสต์ลง Instagram
  • สคริปต์สำหรับ YouTube คือ publish-social-youtube.mjs
  • การแจ้งเตือนเตรียมโพสต์ Instagram คือ notify-social-ready.mjs
  • มีแผนจะรวม TikTok ด้วยในอนาคต

ขอบเขตระหว่างระบบอัตโนมัติกับการควบคุมเชิงบรรณาธิการ

• โปรเจ็กต์นี้ไม่ได้ตัดความเป็นไปได้ของระบบอัตโนมัติเต็มรูปแบบทิ้งไป แต่ยังคงให้มี การตรวจทานโดยมนุษย์ ก่อนปล่อยวิดีโอทุกชิ้น
• การควบคุมเชิงบรรณาธิการต่อพาดหัวและแคปชัน, การรีวิวขั้นสุดท้าย และการตัดสินใจเรื่องวิธีโพสต์ ยังเป็นหน้าที่ของมนุษย์
• หลีกเลี่ยงการโพสต์อัตโนมัติแบบไม่ไตร่ตรอง เพราะข้อมูลตั้งต้นอาจมีปัญหา หรือระบบอาจสร้างผลลัพธ์ที่ผิดพลาดได้
• YouTube สามารถสร้าง วิดีโอฉบับร่าง แบบไม่เผยแพร่ผ่าน API ทางการได้
• ส่วน Instagram API รองรับเฉพาะการโพสต์แบบเผยแพร่ทันที ดังนั้นทุกครั้งที่มีข้อมูลใหม่ ระบบจะสร้างฉบับร่างบน YouTube และส่งอีเมลแจ้งให้สร้างโพสต์ Instagram แบบแมนนวล

การทำวิดีโอโซเชียลที่จบได้ด้วยงานออกแบบเว็บ

• ข้อดีของวิธีนี้คือดีไซน์วิดีโอกลายเป็น งานออกแบบเว็บ ไปโดยตรง
• ไม่ต้องพึ่ง After Effects, การเอ็กซ์พอร์ตซ้ำด้วยมือ, ตัวเลขที่ล้าสมัย หรือเว็บโปรดิวเซอร์ที่ยุ่งมาก
• การเปลี่ยนสีหรือป้ายกำกับจบได้ด้วยการแก้เพียงบรรทัดเดียว และสะท้อนในรอบเรนเดอร์ถัดไปทันที
• ทั้งระบบประกอบด้วย glue code เพียงไม่กี่ร้อยบรรทัดที่ล้อมรอบเครื่องมือเดิม
  • data pipeline
  • เบราว์เซอร์แบบ headless
  • แผนที่และกราฟที่เว็บไซต์ใช้อยู่แล้ว
  • ffmpeg
• ค่าใช้จ่ายในการรันอยู่ที่ระดับไม่กี่ดอลลาร์ต่อเดือน
• ตัวอย่างเปรียบเทียบอย่าง Missouri Vehicle Stops MCP ดูเหมือนจะมีค่าใช้จ่ายอยู่ที่ราว 50 ดอลลาร์ ต่อเดือนในปัจจุบัน
• asset bakery มีต้นทุนต่อผู้ใช้ต่ำกว่า MCP ส่วน MCP ใกล้เคียงกับเครื่องมือที่ให้การมีส่วนร่วมกับข้อมูลได้ลึกกว่า

กลยุทธ์และบทบาทของ “shortcut”

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