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 회선에서도 여러 압축률로 사용 사례가 있음
특허풀은 안전망이 아님을 밝힘. 이는 마치 특허 브리지를 건너려면 돈을 내야 하지만, 그 이후에 또 다른 특허 문제가 생기면 추가로 지불해야 하는 구조임을 설명함
이 분야 경력을 바탕으로, 하드웨어 인코더와 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 명령 예시와 세부 인코딩 파라미터까지 공유해줌
Hacker News 의견
BBC에서 개발한 인트라 전용 웨이블릿 기반 초저지연 코덱인 VC-2에 대해 이야기함. 이 코덱은 로열티 없이 사용할 수 있고, 현재로서는 ffmpeg와 공식 BBC 저장소에 CPU 기반 구현만 존재함. 자신의 석사 논문으로 CUDA 가속 버전을 만들 예정임. 작년 GSoC에서 진행된 Vulkan 구현들은 아직 만족스럽지 않음. 사람들이 이 코덱을 꼭 살펴보기를 추천함
이 글은 신호 특성에 맞는 왜곡 허용과 트레이드오프를 잘 매칭해서 설명한 훌륭한 예시임. 코덱을 설계하지 않고 선택하는 입장이라도 이 과정을 따라가면 좋은 결과를 얻을 수 있음. 극저지연이 중요한 분야에 관심 있다면, VSF가 여러 대안 코덱들의 특징을 정리한 리포트(링크)를 참고하면 유용함
나는 비디오 인코딩에 거의 아는 게 없지만, 인코더가 게임 엔진과 조금이라도 협력하면 비디오게임 스트리밍에서 놓치고 있는 많은 실용적 접근이 있을 거라 생각함. 예를 들어, 대부분의 렌더링 엔진에는 자체 용도의 모션 예측 버퍼가 이미 있는데, 이걸 인코딩용으로도 무료로 쓸 수 있음. 하지만 발명을 막는 특허가 있을 것 같아 실제로는 어렵지 않을지 아쉬움을 전함
LLM(대형 언어 모델)로 게임 내 상황을 매 프레임마다 몇 문장으로 요약해서 네트워크로 전송하고, 수신 측 LLM이 그 텍스트로 프레임을 재구성하는 접근을 제안함. 실시간은 어렵고 손실도 크지만, 압축률은 엄청나고 최신 트렌드에 부합함을 언급함
이 코덱 방식이 내가 연구 프로젝트에 활용하려던 것과 거의 일치함. 참고로, 상용 프로젝트에는 특허풀 이슈 때문에 유료 표준인 JPEG-XS(링크1, 링크2)도 초저지연을 주장하기에 더 안전한 선택일 수 있음을 안내함
VLC 창립자가 초저지연 스트리밍 프로토콜을 개발 중이라며, 인터뷰(링크)와 데모 영상(링크)을 공유함
이 CODEC이 HTJ2K(High-Throughput JPEG 2000)와 같은 알고리즘 기반임을 인지하고, 혹시 작성자가 본다면 HTJ2K와의 차이점에 대해 설명해주면 흥미로울 것 같음을 밝힘
로컬 네트워크 스트리밍만 집중한다면 최신 코덱의 많은 기능은 필요 없음을 설명함. 대역폭만 100Mbps 정도 확보된다면 처리 속도가 빠르고 지연도 적게 만들 수 있음. 예시로 Microsoft DXT 코덱은 최신 코덱 기능은 거의 없지만(엔트로피 인코딩, 모션 보상, 디블로킹 없음), 4~8배 압축률에 하드웨어 디코딩이 가능해 전체 지연 시간 단축에 유리함을 밝힘. 단, 최적화한다 해도 디스플레이 자체에서 30~100ms의 추가 지연이 생기는 점을 지적함
개발 결과가 정말 놀랍고, 언젠가 Moonlight나 비슷한 프로젝트에 적용되는 날을 기대함을 전함
이 코덱이 아직 생소하고 전문적인 분야라 경쟁 코덱과 비교 자료를 찾기 어렵다는 의견을 인용하면서, H.264/AVC(제로-지연 ffmpeg 옵션)와 JPEG XS와의 벤치마크가 궁금함을 밝힘. ffmpeg 명령 예시와 세부 인코딩 파라미터까지 공유해줌