Tôi đã tự thiết kế PyroWave, codec video phát trực tuyến game siêu nhanh

• Phát trực tuyến game đòi hỏi độ trễ cực thấp là điều kiện bắt buộc
• PyroWave đạt tốc độ cực hạn bằng cách loại bỏ dự đoán chuyển động và mã hóa entropy
• Cách tiếp cận dựa trên biến đổi wavelet rời rạc (DWT) tạo khác biệt so với các codec DCT truyền thống
• Nhờ xử lý song song theo khối 32×32 và triển khai rate control nhanh, việc mã hóa/giải mã trên GPU diễn ra rất nhanh
• Đánh giá chất lượng cho thấy so với H.264/HEVC/AV1, trong một số tình huống nó vẫn cho kết quả đủ tốt

---

Yêu cầu siêu độ trễ thấp của phát trực tuyến game và giới hạn của các cách làm hiện có

• Khi nhu cầu phát trực tuyến gameplay gần đây tăng lên, việc truyền thời gian thực từ thiết bị này sang thiết bị khác qua mạng trở nên quan trọng
• Từ DMA, render, mã hóa, truyền, giải mã cho đến xuất hình ra màn hình, độ trễ tích lũy ở từng giai đoạn ảnh hưởng lớn đến toàn bộ trải nghiệm
• Giải pháp truyền thống là dùng các codec video tăng tốc bằng GPU như H.264, HEVC, AV1
• Tuy nhiên trong streaming, không thể dùng các kỹ thuật nén cao như B-frame, nên các ràng buộc về độ trễ và bitrate trở nên rất khắt khe

Triết lý thiết kế: loại bỏ dự đoán chuyển động và mã hóa entropy

Loại bỏ dự đoán chuyển động – cách làm Intra-Only

• Loại bỏ dự đoán chuyển động của các codec video truyền thống để mọi khung hình được xử lý độc lập
• Kết quả là bitrate tăng lên, nhưng đổi lại có ưu điểm về khả năng phục hồi lỗi, tính đơn giản và độ nhất quán chất lượng
• Điện ảnh kỹ thuật số cũng đã có kinh nghiệm sử dụng cách làm Intra-only
• Vì vậy nó không phù hợp cho streaming qua Internet, nhưng có thể cho kết quả tốt trong môi trường băng thông cao như LAN

Loại bỏ mã hóa entropy

• Mã hóa entropy bất lợi cho xử lý song song trên GPU nên bị loại bỏ hoàn toàn
• Hiện thực bằng phần mềm một lĩnh vực vốn chỉ tồn tại cho ASIC chuyên dụng hoặc thiết bị đặc thù
• Mở ra mảng codec siêu độ trễ thấp chưa có trong FFmpeg

Cách tiếp cận mới tận dụng biến đổi wavelet (DWT)

• Thay vì DCT của các codec hiện có, tác giả chọn biến đổi wavelet rời rạc (DWT)
• Biến đổi wavelet tương tự với cấu trúc mip-map vốn quen thuộc với các lập trình viên đồ họa
• Ảnh được tách thành nhiều dải, rồi áp dụng lượng tử hóa cho từng dải
• Các dải tần cao được lượng tử hóa mạnh hơn để tận dụng tối đa đặc tính thị giác
• Quá trình này cũng liên kết với điều khiển tốc độ (rate control)

Artifact tiêu biểu và giới hạn của codec dựa trên wavelet

• Thay vì artifact blocking như JPEG, wavelet chủ yếu gây ra mờ hoặc hiện tượng ringing
• Điều này có thể không phải vấn đề lớn trong thực tế, vì nó chồng lấp với hiệu ứng blur do TAA trong các game hiện đại

Đóng gói bitstream tốc độ cao và song song hóa

• Các khối hệ số 32×32 được xử lý độc lập, nên khi mất gói ảnh hưởng chỉ bị giới hạn ở mức mờ cục bộ
• Cấu trúc tiểu khối 8×8 và 4×2 giúp tối ưu xử lý song song theo đơn vị GPU workgroup
• Dùng mã hóa bitplane, nhưng lưu dữ liệu bit thô mà không có mã hóa entropy phức tạp
• Các cách làm thân thiện với GPU như lưu trữ SSBO 8-bit giúp tối đa hóa hiệu quả bộ nhớ và tốc độ xử lý

Rate control chính xác và nhanh

• Khác với cách mã hóa entropy truyền thống, hệ thống lặp lại việc đo/số bit bị lược bỏ theo từng khối rồi điều chỉnh tỷ lệ cho phù hợp
• Tính toán toàn cục vùng rate-distortion tối ưu để tuân thủ CBR một cách nghiêm ngặt
• Ngay cả bằng phần mềm vẫn đạt được lợi thế của codec họ wavelet là dừng sớm theo từng bitplane

Hiệu năng và hiệu quả thực tế

• Ở chuẩn 1080p 4:2:0, việc mã hóa/giải mã hoàn tất trong 0,13ms trên GPU RX 9070 XT
• Tận dụng tối ưu FP16 cho từng bước xử lý như DWT, lượng tử hóa... để cân bằng trade-off giữa chất lượng và tốc độ
• Thử nghiệm cho thấy với video 4K, nén trên GPU rồi truyền đi còn nhanh hơn tốc độ truyền qua PCI-e
• Đạt tốc độ nhanh hơn tới hơn 10 lần so với codec phần cứng chuyên dụng

Đánh giá chất lượng và so sánh với các codec khác

• Nhóm đối chứng: bộ mã hóa GPU của FFmpeg (H.264/HEVC/AV1) ở chế độ Intra-only, CBR, độ trễ tối thiểu
• Với điều kiện 200Mbps, 60fps, PyroWave cho artifact nén gần như khó phân biệt bằng mắt thường
• Trên nhiều cảnh game khác nhau, nó cũng cho kết quả đủ tốt theo các chỉ số chất lượng khách quan như VMAF, SSIM, PSNR
• Một số chỉ số nhất định (như VMAF) đánh giá PyroWave hơi ưu ái, trong khi PSNR lại bộc lộ ảnh hưởng của độ chính xác nội bộ
• Dù hình ảnh có mờ hoặc xuất hiện artifact chất lượng thấp, điều đó không phải vấn đề lớn trong thực tế sử dụng với đồ họa game hiện đại và mục đích sử dụng này

Kết luận

• PyroWave đưa ra một phương án thay thế đột phá cho lĩnh vực phát trực tuyến game cục bộ cần xử lý cực nhanh và siêu độ trễ thấp
• Nó được tối ưu cho xử lý song song và điều khiển CBR khi kết hợp với kiến trúc GPU hiện đại
• Dù là một dự án cá nhân, đây vẫn là một giải pháp streaming siêu nhanh tự làm rất đáng hài lòng

[GN⁺]

Ý kiến trên Hacker News

• Bàn về VC-2, một codec siêu độ trễ thấp dựa trên wavelet chỉ dùng intra do BBC phát triển. Codec này có thể dùng miễn phí bản quyền, và hiện tại mới chỉ có các bản triển khai chạy trên CPU trong ffmpeg và kho chính thức của BBC. Người viết dự định làm một phiên bản tăng tốc CUDA cho luận văn thạc sĩ của mình. Các bản triển khai Vulkan thực hiện trong GSoC năm ngoái vẫn chưa thật sự thỏa đáng. Họ khuyến nghị mọi người nên xem kỹ codec này

  • Hỏi liệu có thể giải thích chi tiết hơn vì sao bản triển khai Vulkan còn thiếu sót hay không. Nói rõ rằng không phải để chỉ trích mà thật sự tò mò
  • Hỏi về trải nghiệm khác biệt chất lượng hình ảnh giữa VC-2 và JPEG XS. Thường nghe nói JPEG XS cho chất lượng thị giác cao hơn, nhưng muốn biết cảm nhận khi dùng thực tế ra sao

• Đây là một ví dụ rất hay về việc giải thích cách ghép đúng mức độ chấp nhận méo dạng và các đánh đổi cho phù hợp với đặc tính tín hiệu. Ngay cả khi chỉ ở vị trí chọn codec chứ không tự thiết kế, làm theo quy trình này cũng có thể cho kết quả tốt. Nếu quan tâm đến các lĩnh vực mà siêu độ trễ thấp là quan trọng, báo cáo của VSF tóm tắt đặc điểm của nhiều codec thay thế khác nhau sẽ rất hữu ích (liên kết)

• Tôi gần như không biết gì về mã hóa video, nhưng nghĩ rằng nếu encoder có thể phối hợp dù chỉ một chút với game engine thì sẽ có rất nhiều cách tiếp cận thực dụng còn bị bỏ lỡ trong streaming videogame. Ví dụ, đa số engine dựng hình đã có sẵn buffer dự đoán chuyển động cho mục đích riêng, và có thể dùng miễn phí cho việc mã hóa. Tuy vậy, thật tiếc vì có lẽ bằng sáng chế ngăn cản kiểu phát minh này nên thực tế có thể khó làm

  • Nhấn mạnh rằng “motion vector” của H.264 chỉ là một kỹ thuật nén ảnh theo bit, không giống motion vector dùng trong game 3D thực tế. Motion vector của game 3D là lượng thay đổi vị trí của vật thể trong không gian 3D, còn trong H.264 thì đó là cách sao chép các khối pixel từ một khung hình trước đó bất kỳ rồi mã hóa phần khác biệt theo kiểu JPEG. Chính việc sao chép khối này khiến video H.264 trông như bị vỡ thành các mảng vuông khi thiếu băng thông
  • Lấy ví dụ một game FPS có độ trễ mạng 2 frame: nếu game engine cung cấp UI và góc nhìn thế giới 3D thành các framebuffer riêng biệt, phía client có thể ngay khi nhận input chuột thì dịch chuyển trước phần góc nhìn thế giới trên khung hình cũ nhận từ server. Các game VR đã dùng kiểu này để bù độ trễ đầu vào. Nó không hoàn hảo nhưng tạo khác biệt lớn, và cả parallax cũng có thể giả lập phần nào nếu dùng depth map
  • Có thể tận dụng thông tin từ gia tốc kế hay la bàn số của điện thoại để cung cấp gợi ý cho việc mã hóa, tương tự mã hóa video dựa trên cảm biến (liên kết). Với game 2D, có thể cung cấp chính xác motion vector của nền và các vật thể tiền cảnh lớn. Các thành phần 2D như overlay, HUD, bảng điểm, phụ đề có thể truyền bằng cơ chế nén riêng để giữ độ nét pixel tốt hơn. Trên HN có nhiều người hoài nghi về các ý tưởng này, điều đó khá bất ngờ
  • Tôi cũng luôn thắc mắc về điểm này. Tôi nghĩ client có thể tự xử lý một ít compositing. Ví dụ, render nền và tiền cảnh theo nhịp khác nhau, hoặc dùng một codec rõ nét hơn cho HUD theo mức ưu tiên. Stadia có cả game tự phát triển mà vẫn chỉ dùng cách stream video đơn thuần luôn khiến tôi ngạc nhiên. Có lẽ họ đã thử nhiều hướng nhưng không thu được lợi ích đủ lớn so với codec video truyền thống
  • Nếu là game sprite 2D thì có thể rất dễ cung cấp motion vector cực kỳ chính xác cho encoder. Với game dựng hình 3D, tôi không chắc việc chuyển motion vector của vật thể 3D sang dạng phù hợp cho mã hóa 2D có thực tế hữu ích hay không

• Đề xuất một cách tiếp cận là dùng LLM (mô hình ngôn ngữ lớn) để tóm tắt tình huống trong game thành vài câu ở mỗi frame rồi gửi qua mạng, phía nhận dùng LLM khác tái tạo khung hình từ văn bản đó. Cách này khó đạt thời gian thực và mất mát lớn, nhưng tỷ lệ nén thì khổng lồ và rất hợp xu hướng hiện nay

  • Ví dụ cho frame 1, có thể mô tả: “Bạn đang đứng trên cánh đồng phía tây, cánh cửa trước của ngôi nhà màu trắng bị đóng ván kín. Có một hộp thư nhỏ ở đây”
  • Bổ sung rằng nếu dùng blockchain để truyền các mô tả này thì còn có thể tạo bản ghi bất biến
  • Hy vọng rằng một ngày nào đó game có thể được chạy trực tiếp trên máy tính của từng người dùng
  • Nói rằng ý tưởng trên khá thú vị

• Cách làm của codec này gần như trùng khớp với thứ tôi từng định dùng cho một dự án nghiên cứu. Nhân tiện, với dự án thương mại thì do vấn đề patent pool, một tiêu chuẩn trả phí như JPEG-XS (liên kết1, liên kết2) cũng tuyên bố có độ trễ cực thấp nên có thể là lựa chọn an toàn hơn

  • JPEG-XS có thế mạnh về siêu độ trễ thấp nhưng dùng nhiều băng thông hơn. Chúng tôi đang dùng nó cho streaming hình ảnh thời gian thực trong hậu kỳ phim/TV (liên kết ví dụ). Dùng encoder/decoder CUDA của IntoPIX cùng cơ chế truyền tải độ trễ thấp SRT. Trên mạng đủ tốt, hoàn toàn có thể đạt tổng độ trễ dưới 16ms. Có cả các trường hợp sử dụng với nhiều tỷ lệ nén khác nhau giữa datacenter và phòng hậu kỳ trong đô thị, hoặc trên đường truyền 1GbE xuyên quốc gia
  • Nói rõ rằng patent pool không phải là tấm khiên an toàn. Nó giống như phải trả tiền để đi qua một cây cầu bằng sáng chế, nhưng sau đó nếu phát sinh thêm vấn đề bằng sáng chế khác thì vẫn phải trả tiếp

• Chia sẻ rằng người sáng lập VLC đang phát triển một giao thức streaming siêu độ trễ thấp, kèm bài phỏng vấn (liên kết) và video demo (liên kết)

  • Dựa trên kinh nghiệm làm việc trong lĩnh vực này, nhấn mạnh rằng hardware encoder và H.264 có độ trễ rất thấp. NVENC gần như có thể mã hóa ngay lập tức nếu tắt các tính năng phụ như dự đoán nhiều frame, B-frame, v.v. Chỉ cần tránh các thuật toán xử lý cao cấp hoặc những cách đòi hỏi phải chờ nhiều frame, thì có thể mã hóa trong vòng <10ms sau khi GPU render xong
  • Nói rằng video ở liên kết hiện không xem được

• Nhận ra rằng CODEC này dựa trên thuật toán tương tự HTJ2K (High-Throughput JPEG 2000), và nếu tác giả có đọc được thì sẽ rất thú vị nếu giải thích sự khác biệt so với HTJ2K

• Giải thích rằng nếu chỉ tập trung vào streaming trong mạng nội bộ thì không cần nhiều tính năng của các codec hiện đại. Chỉ cần đảm bảo băng thông khoảng 100Mbps là có thể làm cho xử lý nhanh và độ trễ thấp hơn. Ví dụ, codec Microsoft DXT hầu như không có các tính năng codec hiện đại (không entropy encoding, không motion compensation, không deblocking), nhưng vẫn đạt tỷ lệ nén 4–8 lần và có thể giải mã bằng phần cứng nên có lợi cho việc giảm tổng độ trễ. Tuy nhiên, ngay cả khi tối ưu thì bản thân màn hình hiển thị vẫn có thể thêm 30–100ms độ trễ nữa

• Kết quả phát triển thật sự ấn tượng, và mong một ngày nào đó nó được áp dụng vào Moonlight hoặc dự án tương tự

  • Tôi cũng nghĩ vậy, và nếu có thời gian cùng đủ kỹ năng thì đã muốn tự thêm hỗ trợ codec này vào Moonlight. Khi stream các game như Clair Obscure qua Sunshine/Moonlight trên LAN, nhu cầu độ trễ đủ thấp là rất rõ ràng

• Trích ý kiến rằng codec này vẫn còn khá xa lạ và chuyên biệt nên khó tìm tài liệu so sánh với các codec cạnh tranh, rồi bày tỏ muốn xem benchmark với H.264/AVC (tùy chọn ffmpeg zero-latency) và JPEG XS. Họ còn chia sẻ cả ví dụ lệnh ffmpeg cùng các tham số mã hóa chi tiết