ลองออกแบบ PyroWave วิดีโอโค้ดेकสำหรับเกมสตรีมมิงความเร็วสูงสุดขีดด้วยตัวเอง

 (themaister.net)
4 คะแนน โดย GN⁺ 2025-07-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เกมสตรีมมิง จำเป็นต้องมี ค่าหน่วงต่ำ อย่างยิ่ง
  • PyroWave ทำความเร็วได้สุดขีดด้วยการตัด motion prediction และ entropy coding ออก
  • ใช้แนวทางบนพื้นฐานของ Discrete Wavelet Transform (DWT) ซึ่งแตกต่างจากโค้ดेकแบบ DCT เดิม
  • ด้วยการประมวลผลแบบขนานเป็นบล็อกขนาด 32×32 และ rate control ที่รวดเร็วมาก ทำให้เข้ารหัส/ถอดรหัสบน GPU ได้เร็วมาก
  • การประเมินคุณภาพเมื่อเทียบกับ H.264/HEVC/AV1 ก็ยังให้ผลที่เพียงพอในบางสถานการณ์

ความต้องการค่าหน่วงต่ำมากของเกมสตรีมมิงและข้อจำกัดของวิธีเดิม

  • เมื่อความต้องการ สตรีมเกมเพลย์ เพิ่มขึ้น การส่งภาพแบบเรียลไทม์ผ่านเครือข่ายจากอุปกรณ์หนึ่งไปสู่อีกอุปกรณ์หนึ่งจึงกลายเป็นเรื่องสำคัญ
  • ตั้งแต่ DMA, การเรนเดอร์, การเข้ารหัส, การส่งข้อมูล, การถอดรหัส ไปจนถึงการแสดงผลบนหน้าจอ ค่าหน่วงเวลา ที่สะสมในแต่ละขั้นตอนส่งผลอย่างมากต่อประสบการณ์โดยรวม
  • ทางแก้แบบดั้งเดิมคือใช้ วิดีโอโค้ดेकที่เร่งด้วย GPU เช่น H.264, HEVC, AV1
  • แต่ในการสตรีมไม่สามารถใช้ เทคนิคบีบอัดสูงอย่าง B-frame ได้ ทำให้มีข้อจำกัดด้าน latency และ bitrate อย่างมาก

ปรัชญาการออกแบบ: ตัด motion prediction และ entropy coding ออก

ตัด motion prediction ออก – แนวทาง Intra-Only

  • ตัด motion prediction ของวิดีโอโค้ดेकแบบเดิมออก เพื่อให้ทุกเฟรมถูกจัดการแบบแยกอิสระ
  • ผลคือ bitrate สูงขึ้น แต่ได้ข้อดีด้าน ความทนทานต่อความผิดพลาด, ความเรียบง่าย และความสม่ำเสมอของคุณภาพ
  • มีประสบการณ์ใช้งานแนวทาง Intra-only ในงานอย่าง digital cinema อยู่แล้ว
  • จึงอาจไม่เหมาะกับการสตรีมผ่านอินเทอร์เน็ต แต่ให้ผลลัพธ์ที่ดีได้ใน สภาพแวดล้อมแบนด์วิดท์สูงอย่าง LAN

ตัด entropy coding ออก

  • entropy coding ไม่เหมาะกับ การประมวลผลแบบขนาน บน GPU จึงถูกตัดออกทั้งหมด
  • ทำให้สิ่งที่เคยมีอยู่เฉพาะใน ASIC หรืออุปกรณ์เฉพาะทาง สามารถเกิดขึ้นได้ด้วย แนวทางซอฟต์แวร์
  • เปิดทางให้กับหมวด โค้ดेकค่าหน่วงต่ำมากที่ไม่มีใน FFmpeg

แนวทางใหม่ด้วยการใช้ Wavelet Transform (DWT)

  • แทนที่จะใช้ DCT แบบโค้ดेकเดิม เลือกใช้ Discrete Wavelet Transform (DWT)
  • wavelet transform มีลักษณะคล้าย โครงสร้าง mip-map ที่โปรแกรมเมอร์สายกราฟิกคุ้นเคย
  • แยกภาพออกเป็นหลายย่านความถี่ แล้วใช้ quantization กับแต่ละย่าน
  • ย่านความถี่สูงจะถูก quantize หนักกว่า เพื่อใช้ คุณลักษณะด้านการมองเห็น ให้คุ้มที่สุด
  • กระบวนการนี้ยังเชื่อมโยงกับการควบคุมอัตราบิต (rate control) ด้วย

อาร์ติแฟกต์และข้อจำกัดหลักของโค้ดেকแบบ wavelet

  • แทนที่จะเกิด blocking artifact แบบ JPEG, โค้ดेक wavelet มักทำให้เกิด ภาพเบลอ หรือ ringing
  • และเพราะมันทับซ้อนกับ เอฟเฟกต์เบลอจาก TAA ในเกมสมัยใหม่ ปัญหาจริงอาจไม่ใหญ่เท่าไร

การแพ็กบิตสตรีมความเร็วสูงและการทำงานแบบขนาน

  • ประมวลผลบล็อกค่าสัมประสิทธิ์ 32×32 อย่างอิสระ เพื่อจำกัดผลกระทบเมื่อ packet loss เกิดขึ้นให้เหลือเพียง ความเบลอเฉพาะจุด
  • ใช้โครงสร้างบล็อกย่อย 8×8, 4×2 เพื่อปรับให้เหมาะกับการประมวลผลแบบขนานระดับ GPU workgroup
  • ใช้ bitplane encoding แต่บันทึกเป็นข้อมูลบิตดิบโดยไม่มี entropy coding ที่ซับซ้อน
  • ใช้วิธีที่เป็นมิตรกับ GPU เช่น การจัดเก็บ SSBO แบบ 8-bit เพื่อดันทั้งประสิทธิภาพหน่วยความจำและความเร็วการประมวลผลให้สูงสุด

rate control ที่แม่นยำและรวดเร็ว

  • ต่างจากวิธี entropy coding แบบเดิม ระบบนี้จะวัดและเก็บจำนวนบิตที่ละทิ้งได้ของแต่ละบล็อกซ้ำ ๆ แล้วปรับสัดส่วนให้เหมาะสม
  • คำนวณช่วง rate-distortion ที่เหมาะสมที่สุดในระดับรวม เพื่อรักษา CBR ได้อย่างเคร่งครัด
  • ทำให้ความสามารถเด่นของโค้ดेकตระกูล wavelet อย่าง การหยุดเร็วในระดับ bitplane เกิดขึ้นได้ด้วยซอฟต์แวร์เช่นกัน

ประสิทธิภาพและความคุ้มค่าจริง

  • ที่ 1080p 4:2:0 สามารถเข้ารหัส/ถอดรหัสเสร็จใน 0.13ms บน GPU RX 9070 XT
  • ใช้การปรับแต่ง FP16 ในแต่ละขั้นตอน เช่น DWT และ quantization ทำให้สัมผัสได้ถึง trade-off ระหว่างคุณภาพกับความเร็ว
  • ยังยืนยันจากการทดลองได้ว่าแม้เป็นวิดีโอ 4K ก็ บีบอัดบน GPU ก่อนส่ง ได้เร็วกว่าอัตราการส่งผ่าน PCI-e
  • ทำความเร็วได้ เร็วกว่าโค้ดेकฮาร์ดแวร์เฉพาะทางสูงสุดมากกว่า 10 เท่า

การประเมินคุณภาพและการเปรียบเทียบกับโค้ดेकอื่น

  • กลุ่มที่ใช้เปรียบเทียบคือ GPU encoder ของ FFmpeg (H.264/HEVC/AV1) ในโหมด Intra-only, CBR และ latency ต่ำสุด
  • ภายใต้เงื่อนไข 200Mbps, 60fps, PyroWave มีอาร์ติแฟกต์จากการบีบอัดที่แทบแยกออกด้วยตาเปล่าไม่ได้
  • สำหรับฉากเกมที่หลากหลาย ก็ให้ผลเพียงพอใน ตัวชี้วัดคุณภาพเชิงวัตถุวิสัย อย่าง VMAF, SSIM, PSNR
  • ตัวชี้วัดบางตัว (เช่น VMAF) ประเมิน PyroWave ค่อนข้างใจดี ขณะที่ PSNR เป็นต้นเผยให้เห็นผลของความละเอียดภายในระบบ
  • แม้ภาพจะมีความเบลอหรืออาร์ติแฟกต์คุณภาพต่ำอยู่บ้าง แต่เมื่อมองจากภาพลักษณ์ของเกมยุคใหม่และวัตถุประสงค์การใช้งานจริง ก็ไม่ใช่ปัญหาใหญ่

บทสรุป

  • PyroWave เสนอทางเลือกที่น่าสนใจอย่างมากสำหรับงาน สตรีมเกมภายในเครือข่ายแบบโลคัล ที่ต้องการค่าหน่วงต่ำมากและการประมวลผลความเร็วสูง
  • มันถูกออกแบบมาให้เหมาะกับ การประมวลผลแบบขนานและการควบคุม CBR บนสถาปัตยกรรม GPU ยุคใหม่
  • แม้จะเป็นโปรเจกต์ส่วนตัว แต่ก็ให้ความพึงพอใจสูงในฐานะ โซลูชันสตรีมมิงความเร็วสูงแบบ DIY

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

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

 
GN⁺ 2025-07-30
ความคิดเห็นจาก Hacker News

  • มีการพูดถึง VC-2 โคเด็กความหน่วงต่ำมากแบบเวฟเล็ตที่เข้ารหัสแบบ intra-only ซึ่งพัฒนาโดย BBC โคเด็กนี้ใช้งานได้แบบปลอดค่าลิขสิทธิ์ และในตอนนี้มีเพียงอิมพลีเมนเทชันแบบใช้ CPU ใน ffmpeg และรีโพซิทอรีทางการของ BBC เท่านั้น ผู้แสดงความคิดเห็นวางแผนจะทำเวอร์ชันเร่งด้วย CUDA เป็นวิทยานิพนธ์ปริญญาโทของตน ส่วนงานอิมพลีเมนต์ด้วย Vulkan ที่ทำใน GSoC ปีที่แล้วนั้นยังไม่น่าพอใจ และแนะนำให้ผู้คนลองศึกษาโคเด็กนี้กัน

    • มีคนถามว่าสามารถอธิบายเพิ่มเติมได้หรือไม่ว่าทำไมอิมพลีเมนเทชัน Vulkan ถึงยังไม่ดีพอ โดยย้ำว่าไม่ได้ตั้งใจวิจารณ์ แต่อยากรู้จริง ๆ
    • มีคนถามถึงประสบการณ์เรื่องความต่างด้านคุณภาพภาพระหว่าง VC-2 กับ JPEG XS โดยบอกว่าปกติได้ยินมาว่า JPEG XS ให้คุณภาพด้านการมองเห็นที่ดีกว่า แต่อยากรู้ความรู้สึกจากการใช้งานจริง

  • โพสต์นี้เป็นตัวอย่างที่ยอดเยี่ยมของการอธิบายการจับคู่ระหว่างความยอมรับต่อความเพี้ยนและ trade-off ให้เหมาะกับลักษณะของสัญญาณ แม้จะไม่ได้ออกแบบโคเด็กเองแต่เป็นฝ่ายเลือกใช้ การเดินตามกระบวนการนี้ก็ช่วยให้ได้ผลลัพธ์ที่ดี หากสนใจงานที่ความหน่วงต่ำมากเป็นพิเศษ รายงานของ VSF ที่สรุปลักษณะของโคเด็กทางเลือกหลายแบบก็น่าอ่านมาก(ลิงก์)

  • ฉันแทบไม่รู้อะไรเกี่ยวกับการเข้ารหัสวิดีโอเลย แต่คิดว่าถ้า encoder ทำงานร่วมกับเกมเอนจินได้แม้เพียงเล็กน้อย น่าจะมีแนวทางเชิงปฏิบัติอีกมากสำหรับการสตรีมวิดีโอเกมที่ยังไม่ได้ถูกนำมาใช้ ตัวอย่างเช่น เอนจินเรนเดอร์ส่วนใหญ่มักมี motion prediction buffer ของตัวเองอยู่แล้วเพื่อใช้ภายใน ซึ่งอาจนำมาใช้กับการเข้ารหัสได้ฟรี ๆ แต่ก็น่าเสียดายที่อาจติดปัญหาสิทธิบัตรจนทำจริงได้ยาก

    • มีการย้ำว่า “motion vector” ของ H.264 เป็นเพียงเทคนิคบีบอัดภาพในระดับบิต ไม่เหมือนกับ motion vector ที่ใช้ในเกม 3D จริง ๆ motion vector ของเกม 3D คือปริมาณการเปลี่ยนตำแหน่งของวัตถุในปริภูมิ 3D แต่ใน H.264 จะเป็นการคัดลอกบล็อกพิกเซลจากเฟรมก่อนหน้าแบบใดก็ได้ แล้วเข้ารหัสส่วนต่างด้วยวิธีคล้าย JPEG และเพราะการคัดลอกเป็นบล็อกนี่เอง เมื่อแบนด์วิดท์ไม่พอ ภาพ H.264 จึงมักพังเป็นชิ้นสี่เหลี่ยม
    • มีการยกตัวอย่างเกม FPS ที่มี network latency 2 เฟรม ว่าหากเกมเอนจินส่ง UI กับมุมมองโลก 3D มาเป็นเฟรมบัฟเฟอร์แยกกัน ฝั่งไคลเอนต์ก็สามารถขยับเฉพาะมุมมองโลกของเฟรมก่อนหน้าที่ได้จากเซิร์ฟเวอร์ล่วงหน้าได้ทันทีที่รับอินพุตเมาส์ เกม VR เองก็ใช้วิธีลักษณะนี้เพื่อชดเชย input latency อยู่แล้ว แม้ไม่สมบูรณ์แบบแต่ช่วยได้มาก และเรื่อง parallax ก็พอจำลองได้บางส่วนถ้าใช้ depth map
    • เช่นเดียวกับการเข้ารหัสวิดีโอที่อาศัยเซ็นเซอร์ อาจใช้ข้อมูลจาก accelerometer หรือเข็มทิศดิจิทัลของโทรศัพท์มาเป็น hint สำหรับการเข้ารหัสได้(ลิงก์) สำหรับเกม 2D นั้นสามารถส่ง motion vector ของฉากหลังและวัตถุ foreground ขนาดใหญ่ได้อย่างแม่นยำ ส่วนองค์ประกอบ 2D อย่าง overlay, HUD, กระดานคะแนน, คำบรรยาย สามารถส่งด้วยวิธีบีบอัดแยกต่างหากเพื่อให้ความคมชัดของพิกเซลดีกว่า ผู้แสดงความคิดเห็นบอกว่าประหลาดใจที่ใน HN มีคนจำนวนมากไม่ค่อยเชื่อในแนวคิดแบบนี้
    • ฉันก็สงสัยเรื่องนี้มาตลอดเหมือนกัน คิดว่าไคลเอนต์น่าจะจัดการ compositing บางส่วนเองได้ เช่น เรนเดอร์ฉากหลังกับฉากหน้าในรอบเวลาต่างกัน หรือให้ HUD ใช้โคเด็กที่ชัดเจนตามลำดับความสำคัญ สิ่งที่น่าแปลกใจเสมอคือ Stadia มีทั้งเกมที่ทำเอง แต่ก็ยังใช้วิธีสตรีมวิดีโอแบบตรงไปตรงมา บางทีพวกเขาอาจลองหลายแนวทางแล้วแต่ไม่ได้ประโยชน์มากพอเมื่อเทียบกับโคเด็กวิดีโอแบบเดิม
    • ถ้าเป็นเกมสไปรต์ 2D ก็สามารถให้ motion vector ที่แม่นยำมากกับ encoder ได้ง่าย แต่สำหรับเกมเรนเดอร์ 3D ยังไม่แน่ใจว่าการแปลง motion vector ของวัตถุ 3D ให้เข้ากับการเข้ารหัสแบบ 2D จะช่วยได้จริงแค่ไหนในทางปฏิบัติ

  • มีการเสนอแนวทางใช้ LLM (large language model) สรุปสถานการณ์ในเกมทุกเฟรมออกมาเป็นไม่กี่ประโยค แล้วส่งผ่านเครือข่าย จากนั้นให้ LLM ฝั่งรับสร้างเฟรมกลับขึ้นมาจากข้อความนั้น แม้จะยากต่อการทำแบบเรียลไทม์และมีการสูญเสียสูง แต่ก็บอกว่าอัตราการบีบอัดจะมหาศาลและเข้ากับกระแสยุคนี้

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

  • วิธีการของโคเด็กนี้แทบจะตรงกับสิ่งที่ฉันเคยอยากใช้ในโปรเจกต์วิจัยพอดี ทั้งนี้ สำหรับโปรเจกต์เชิงพาณิชย์ก็มีคำแนะนำว่าเพราะประเด็น patent pool มาตรฐานแบบเสียเงินอย่าง JPEG-XS(ลิงก์1, ลิงก์2) ที่ชูจุดเด่นเรื่องความหน่วงต่ำมาก อาจเป็นตัวเลือกที่ปลอดภัยกว่า

    • JPEG-XS เด่นเรื่องความหน่วงต่ำมาก แต่ใช้แบนด์วิดท์มากกว่า เราใช้อยู่กับการสตรีมภาพแบบเรียลไทม์สำหรับงาน post-production ภาพยนตร์/โทรทัศน์(ลิงก์กรณีศึกษา) โดยใช้ IntoPIX CUDA encoder/decoder และการส่งข้อมูลแบบหน่วงต่ำผ่าน SRT บนเครือข่ายที่ดี การทำให้ความหน่วงรวมต่ำกว่า 16ms เป็นเรื่องที่ทำได้สบาย และก็มีการใช้งานด้วยอัตราการบีบอัดหลายแบบทั้งระหว่างดาต้าเซ็นเตอร์กับห้อง post-production ในเมือง หรือแม้แต่ระหว่างประเทศผ่านลิงก์ 1GbE
    • มีการชี้ว่า patent pool ไม่ใช่ตาข่ายนิรภัย แต่มันเหมือนสะพานสิทธิบัตรที่คุณต้องจ่ายเงินเพื่อข้ามไป และหลังจากนั้นหากมีปัญหาสิทธิบัตรอื่นอีกก็ยังต้องจ่ายเพิ่มอยู่ดี

  • มีการแชร์ว่าผู้ก่อตั้ง VLC กำลังพัฒนาโปรโตคอลสตรีมมิงแบบหน่วงต่ำมาก พร้อมแนบทั้งบทสัมภาษณ์(ลิงก์) และวิดีโอเดโม(ลิงก์)

    • ผู้ที่มีประสบการณ์ในสายนี้ย้ำว่า hardware encoder และ H.264 มีความหน่วงต่ำมากอยู่แล้ว NVENC สามารถเข้ารหัสได้แทบจะทันทีหากปิดฟีเจอร์เสริมต่าง ๆ เช่น multi-frame prediction, B-frame เป็นต้น ตราบใดที่หลีกเลี่ยงอัลกอริทึมประมวลผลขั้นสูงหรือวิธีที่ต้องรอหลายเฟรม ก็สามารถเข้ารหัสได้ภายใน <10ms หลัง GPU เรนเดอร์เสร็จ
    • มีการบอกว่าวิดีโอในลิงก์ตอนนี้ดูไม่ได้แล้ว

  • มีคนสังเกตว่า CODEC นี้ใช้แนวอัลกอริทึมคล้ายกับ HTJ2K(High-Throughput JPEG 2000) และบอกว่าถ้าผู้เขียนผ่านมาเห็น ก็น่าสนใจหากจะอธิบายความต่างเมื่อเทียบกับ HTJ2K

  • มีการอธิบายว่าหากเน้นเฉพาะการสตรีมบนเครือข่ายภายใน โคเด็กสมัยใหม่หลายฟีเจอร์ก็ไม่จำเป็นเลย ถ้ามีแบนด์วิดท์สักราว 100Mbps ก็สามารถเลือกแนวทางที่ประมวลผลเร็วและมีความหน่วงต่ำได้ ตัวอย่างเช่น Microsoft DXT codec แทบไม่มีฟีเจอร์ของโคเด็กสมัยใหม่เลย (ไม่มี entropy encoding, motion compensation, deblocking) แต่ยังบีบอัดได้ราว 4~8 เท่า และรองรับ hardware decoding จึงเป็นประโยชน์ต่อการลดความหน่วงรวม อย่างไรก็ตาม ยังชี้ว่าต่อให้ปรับแต่งดีแค่ไหน ตัวจอแสดงผลเองก็มักเพิ่มความหน่วงอีก 30~100ms อยู่ดี

  • มีคนบอกว่าผลงานพัฒนานี้น่าทึ่งจริง ๆ และหวังว่าสักวันจะถูกนำไปใช้กับ Moonlight หรือโปรเจกต์คล้ายกัน

    • อีกคนบอกว่าคิดเหมือนกัน และถ้ามีทั้งเวลาและทักษะก็อยากลองเพิ่มการรองรับโคเด็กนี้ให้ Moonlight ด้วยตัวเอง เพราะเวลาสตรีมเกมอย่าง Clair Obscure ผ่าน Sunshine/Moonlight บน LAN นั้น ความหน่วงต่ำที่ดีพอเป็นเรื่องสำคัญมาก

  • มีการอ้างความเห็นว่าเพราะโคเด็กนี้ยังค่อนข้างเฉพาะทางและไม่ค่อยเป็นที่รู้จัก จึงหาเอกสารเปรียบเทียบกับโคเด็กคู่แข่งได้ยาก พร้อมบอกว่าอยากเห็น benchmark เทียบกับ H.264/AVC (ตัวเลือก zero-latency ของ ffmpeg) และ JPEG XS โดยมีการแชร์ตัวอย่างคำสั่ง ffmpeg และพารามิเตอร์การเข้ารหัสอย่างละเอียดด้วย