▲

초고속 게임 스트리밍 비디오 코덱 PyroWave를 직접 설계해보았음

 (themaister.net)
3P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 게임 스트리밍은 매우 낮은 지연 시간이 필수 조건임
  • PyroWave는 모션 예측과 엔트로피 코딩을 제거하여 극한의 속도를 달성함
  • 이산 웨이블릿 변환(DWT) 기반 방식으로 기존 DCT 코덱과 차별화됨
  • 32×32 블록 단위 병렬 처리 및 빠른 레이트 컨트롤 구현으로 GPU에서 인코딩/디코딩이 매우 빠름
  • 품질 평가는 H.264/HEVC/AV1 등과 비교해도 특정 상황에서 충분한 결과를 보여줌

게임 스트리밍의 초저지연 요구와 기존 방식의 한계

  • 최근 게임플레이 스트리밍 수요가 증가함에 따라 네트워크를 통한 한 기기에서 다른 기기로의 실시간 전송이 중요해짐
  • DMA, 렌더링, 인코딩, 전송, 디코딩, 화면 출력까지 각 단계마다 누적되는 지연 시간이 전체 경험에 큰 영향을 미침
  • 전통적인 해결책은 H.264, HEVC, AV1 등 GPU 가속 비디오 코덱을 사용하는 것임
  • 하지만 스트리밍에서는 B-프레임 등 고압축 기술을 사용하지 못해 레이턴시 및 비트레이트 제약이 심해짐

설계 철학: 모션 예측 및 엔트로피 코딩 제거

모션 예측 제거 – Intra-Only 방식

  • 기존 비디오 코덱의 모션 예측을 제거해 모든 프레임을 개별적으로 취급함
  • 그 결과 비트레이트는 상승하지만, 오류 복원력, 단순성, 품질 일관성 등에서 장점이 있음
  • 디지털 시네마 등에서도 Intra-only 방식 사용 경험이 있음
  • 이로써 인터넷 스트리밍에는 부적합하지만, LAN 등 고대역폭 환경에서 좋은 결과 가능

엔트로피 코딩 제거

  • 엔트로피 코딩은 GPU 병렬 처리에 불리하여 전면 제외함
  • ASIC 전용이나 특수 장비용으로만 존재하던 영역을 소프트웨어 방식으로 실현
  • FFmpeg에 없는 극저지연 코덱분야를 개척

웨이블릿 변환(DWT)을 활용한 새로운 접근 방식

  • 기존 코덱의 DCT 대신, 이산 웨이블릿 변환(DWT) 을 채택
  • 웨이블릿 변환은 그래픽 프로그래머에게 익숙한 mip-map 구조와 유사
  • 이미지를 여러 대역으로 분리하고, 각 대역별로 양자화를 적용
  • 고주파 대역은 더 강하게 양자화하여 시각적 특성을 최대한 활용함
  • 이 과정은 비율 제어(rate control)와도 연계됨

웨이블릿 기반 코덱의 대표적 아티팩트와 한계

  • JPEG의 블로킹 아티팩트 대신, 웨이블릿은 주로 블러 또는 링잉 현상 발생
  • 최근 게임의 TAA로 인한 블러 효과와 겹쳐 실제로 큰 문제는 아닐 수 있음

고속 비트스트림 패킹 및 병렬화

  • 32×32 계수 블록을 독립적으로 처리하여 패킷 손실 시 국소적 블러로만 영향 제한
  • 8×8, 4×2 하위 블록 구성을 통해 GPU 워크그룹 단위 병렬처리 최적화
  • 비트플레인 인코딩을 사용하되, 복잡한 엔트로피 코딩 없이 원시 비트 데이터 저장
  • SSBO 8-비트 저장 등 GPU 친화 방식으로 메모리 효율 및 처리 속도 극대화

정확하고 빠른 레이트 컨트롤

  • 기존 엔트로피 코딩 방식과 달리, 각 블록별로 생략 비트수를 반복 측정/저장 알맞게 비율 조정
  • 전역적으로 최적의 레이트-디스토션 구간 산출로 CBR을 엄격히 준수
  • 웨이블릿 류 코덱의 강점인 비트플레인별 조기 중단을 소프트웨어로도 달성

실질적인 성능 및 효율

  • 1080p 4:2:0 기준, RX 9070 XT GPU에서 0.13ms에 인코딩/디코딩 완료
  • DWT, 양자화 등 각 처리 과정별 FP16 최적화 활용으로 품질과 속도 트레이드오프 체감
  • 4K 영상도 PCI-e 전송 속도보다 GPU 압축 후 전송이 더 빠르다는 실험 결과 확인
  • 전용 하드웨어 코덱보다도 최대 10배 이상 빠른 속도 실현

품질 평가 및 타 코덱과 비교

  • 비교군: FFmpeg의 GPU 인코더(H.264/HEVC/AV1)에서 Intra-only, CBR, 최소 지연 모드
  • PyroWave는 200Mbps, 60fps 조건에서 육안상 압축 아티팩트가 거의 구별 어려움
  • 다양한 게임 장면에 대해 VMAF, SSIM, PSNR 등 객관적 품질 지표로도 충분한 결과 확보
  • 특정 지표(VMAF 등)는 PyroWave에 다소 후하게 평가됨, 반면 PSNR 등은 내부 정밀도의 영향 노출
  • 이미지에 블러나 저품질 아티팩트가 있지만 현대 게임 비주얼 및 사용 목적상 실사용에 큰 문제 없음

결론

  • PyroWave는 극저지연, 고속 처리가 필요한 로컬 게임 스트리밍 분야에서 혁신적인 대안을 제시함
  • 최신 GPU 아키텍처와 맞물려 병렬 처리 및 CBR 제어에 특화되어 있음
  • 개인적 프로젝트이지만, DIY 초고속 스트리밍 솔루션으로 만족도 높음
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • BBC에서 개발한 인트라 전용 웨이블릿 기반 초저지연 코덱인 VC-2에 대해 이야기함. 이 코덱은 로열티 없이 사용할 수 있고, 현재로서는 ffmpeg와 공식 BBC 저장소에 CPU 기반 구현만 존재함. 자신의 석사 논문으로 CUDA 가속 버전을 만들 예정임. 작년 GSoC에서 진행된 Vulkan 구현들은 아직 만족스럽지 않음. 사람들이 이 코덱을 꼭 살펴보기를 추천함

    • Vulkan 구현이 왜 부족한지 좀 더 자세히 설명해줄 수 있는지 물어봄. 비난하려는 의도는 아니고 진심으로 궁금함을 밝힘
    • VC-2와 JPEG XS의 화질 차이에 대한 경험을 물어봄. 일반적으로 JPEG XS가 더 높은 시각적 품질을 제공한다고 들었으나, 실제 사용 시의 느낌이 궁금함을 언급함

  • 이 글은 신호 특성에 맞는 왜곡 허용과 트레이드오프를 잘 매칭해서 설명한 훌륭한 예시임. 코덱을 설계하지 않고 선택하는 입장이라도 이 과정을 따라가면 좋은 결과를 얻을 수 있음. 극저지연이 중요한 분야에 관심 있다면, VSF가 여러 대안 코덱들의 특징을 정리한 리포트(링크)를 참고하면 유용함

  • 나는 비디오 인코딩에 거의 아는 게 없지만, 인코더가 게임 엔진과 조금이라도 협력하면 비디오게임 스트리밍에서 놓치고 있는 많은 실용적 접근이 있을 거라 생각함. 예를 들어, 대부분의 렌더링 엔진에는 자체 용도의 모션 예측 버퍼가 이미 있는데, 이걸 인코딩용으로도 무료로 쓸 수 있음. 하지만 발명을 막는 특허가 있을 것 같아 실제로는 어렵지 않을지 아쉬움을 전함

    • H.264의 ‘모션 벡터’는 비트 단위 이미지 압축 기법일 뿐, 실제 3D 게임에서 사용하는 모션 벡터와 다름을 강조함. 3D 게임의 모션 벡터는 3D 공간 내에서 오브젝트 위치 변화량이고, H.264에서는 임의의 이전 프레임에서 픽셀 블록을 복사해 차이를 JPEG 방식으로 인코딩하는 방식임. 이 블록 복사 때문에 대역폭이 부족하면 H.264 영상이 네모난 조각들로 망가져 보이게 됨을 설명함
    • 네트워크 지연이 2프레임 있는 FPS 게임을 예로 들어, 게임 엔진이 UI와 3D 월드 뷰를 별도 프레임버퍼로 제공하면, 클라이언트에서 마우스 입력을 받자마자 서버에서 받은 이전 프레임에 월드 뷰만 미리 이동시킬 수 있음. VR 게임들은 이미 이런 식으로 입력 지연을 보완하고 있음. 완벽하진 않지만 큰 차이를 만들어내며, 패럴럭스도 깊이 맵을 활용한다면 어느 정도 가상으로 구현 가능함
    • 센서 기반 비디오 인코딩처럼 폰의 가속도계나 디지털 나침반 정보를 활용해 인코딩 힌트를 줄 수 있음(링크). 2D 게임의 경우 배경과 대형 전경 오브젝트의 모션 벡터를 정확하게 제공할 수 있음. 오버레이, HUD, 점수판, 자막 등 2D 요소는 별도 압축 방식으로 전송해 픽셀 선명도를 높일 수 있음. HN에서는 이런 아이디어에 회의적인 사람이 많아 의외임을 밝힘
    • 나도 이 부분을 늘 궁금하게 생각함. 클라이언트가 약간의 컴포지팅은 직접 처리할 수 있다고 생각함. 예를 들어, 배경과 전경을 다른 주기로 렌더링하거나, HUD는 우선순위에 따라 명확한 코덱을 사용하는 방식임. Stadia는 자체 제작 게임이 있으면서도 단순 영상 스트리밍 방식이었다는 점이 늘 놀라웠음. 어쩌면 다양한 시도를 했지만 기존 비디오 코덱 대비 충분한 이득을 못 받았을 수 있다고 추측함
    • 2D 스프라이트 게임이라면 인코더에 매우 정확한 모션 벡터를 쉽게 제공할 수 있음. 3D 렌더링 게임은 3D 오브젝트에 대한 모션 벡터를 2D 인코딩에 맞게 변환하는 작업이 현실적으로 도움이 될지 확신이 없음

  • LLM(대형 언어 모델)로 게임 내 상황을 매 프레임마다 몇 문장으로 요약해서 네트워크로 전송하고, 수신 측 LLM이 그 텍스트로 프레임을 재구성하는 접근을 제안함. 실시간은 어렵고 손실도 크지만, 압축률은 엄청나고 최신 트렌드에 부합함을 언급함

    • 프레임1 예시로, “당신은 서쪽 들판에 서있으며, 흰색 집 앞문은 널빤지로 막혀있다. 여기에는 작은 우체통이 있다”와 같이 설명할 수 있음을 보여줌
    • 블록체인을 이용해 이런 설명을 전송하면 변경 불가한 기록도 만들 수 있음을 덧붙임
    • 언젠가 게임이 각 사용자 컴퓨터에서 직접 실행되는 시대가 올 수도 있음을 기대함
    • 위 아이디어가 흥미롭다고 밝힘

  • 이 코덱 방식이 내가 연구 프로젝트에 활용하려던 것과 거의 일치함. 참고로, 상용 프로젝트에는 특허풀 이슈 때문에 유료 표준인 JPEG-XS(링크1, 링크2)도 초저지연을 주장하기에 더 안전한 선택일 수 있음을 안내함

    • JPEG-XS는 초저지연에 강점이 있지만 대역폭을 더 많이 사용함. 우리는 영화/TV 후반 작업 실시간 이미지 스트리밍에 활용 중임(사례 링크). IntoPIX CUDA 인코더/디코더와 SRT 저지연 전송 방식을 씀. 쾌적한 네트워크상에서는 전체 지연 16ms 이내 달성이 충분히 가능함. 데이터센터와 도심의 후반 작업실, 또는 국가 간 1GbE 회선에서도 여러 압축률로 사용 사례가 있음
    • 특허풀은 안전망이 아님을 밝힘. 이는 마치 특허 브리지를 건너려면 돈을 내야 하지만, 그 이후에 또 다른 특허 문제가 생기면 추가로 지불해야 하는 구조임을 설명함

  • VLC 창립자가 초저지연 스트리밍 프로토콜을 개발 중이라며, 인터뷰(링크)와 데모 영상(링크)을 공유함

    • 이 분야 경력을 바탕으로, 하드웨어 인코더와 H.264의 지연이 매우 낮다고 강조함. NVENC는 부가 기능(다중 프레임 예측, B-프레임 등)을 꺼두면 거의 즉시 인코딩이 가능함. 고급 처리 알고리즘이나 여러 프레임 대기를 요구하는 방식만 피하면, GPU 렌더링 종료 직후 <10ms 내 인코딩이 가능함을 설명함
    • 링크 영상이 현재는 시청 불가임을 언급함

  • 이 CODEC이 HTJ2K(High-Throughput JPEG 2000)와 같은 알고리즘 기반임을 인지하고, 혹시 작성자가 본다면 HTJ2K와의 차이점에 대해 설명해주면 흥미로울 것 같음을 밝힘

  • 로컬 네트워크 스트리밍만 집중한다면 최신 코덱의 많은 기능은 필요 없음을 설명함. 대역폭만 100Mbps 정도 확보된다면 처리 속도가 빠르고 지연도 적게 만들 수 있음. 예시로 Microsoft DXT 코덱은 최신 코덱 기능은 거의 없지만(엔트로피 인코딩, 모션 보상, 디블로킹 없음), 4~8배 압축률에 하드웨어 디코딩이 가능해 전체 지연 시간 단축에 유리함을 밝힘. 단, 최적화한다 해도 디스플레이 자체에서 30~100ms의 추가 지연이 생기는 점을 지적함

  • 개발 결과가 정말 놀랍고, 언젠가 Moonlight나 비슷한 프로젝트에 적용되는 날을 기대함을 전함

    • 본인도 같은 생각임을 밝히며, 시간과 실력이 있었다면 직접 이 코덱 지원을 Moonlight에 추가해보고 싶었음. LAN에서 Sunshine/Moonlight로 Clair Obscure 같은 게임을 스트리밍할 때 충분한 저지연이 꼭 필요함을 언급함

  • 이 코덱이 아직 생소하고 전문적인 분야라 경쟁 코덱과 비교 자료를 찾기 어렵다는 의견을 인용하면서, H.264/AVC(제로-지연 ffmpeg 옵션)와 JPEG XS와의 벤치마크가 궁금함을 밝힘. ffmpeg 명령 예시와 세부 인코딩 파라미터까지 공유해줌

답변달기