프레임은 집에 돌아가지 않아도 된다: KwaFlux가 디코딩부터 인코딩까지 영상을 GPU에 두는 방식

핵심 요약

전 과정 GPU 영상 처리란 디코딩, 이미지 처리, AI 추론, 인코딩까지 픽셀을 최대한 GPU 메모리에 둔 채 처리하고, 시스템 메모리와 그래픽카드 사이를 오가지 않게 하는 것입니다. 복사가 적을수록 내보내기가 빨라지고 미리보기가 부드러워지며 CPU도 여유가 생깁니다.

이 글에서는 KwaFlux의 미디어 엔진이 이를 어떻게 해내는지 알아봅니다. 아홉 가지 프레임 형식이 같은 언어를 쓰게 하는 프레임 어댑터, 세 GPU 제조사의 하드웨어 디코더와 인코더를 채점해 고르는 방식, D3D11과 OpenGL 사이의 5단계 상호 운용 사다리, Mac의 VideoToolbox와 Metal, 플레이어가 HDR을 화면에 보내는 방식입니다. 마지막으로 한 번의 내보내기에서 픽셀이 지나는 경로와 KwaFlux에서 바꿀 수 있는 설정을 소개합니다.

• 4K, 10비트, 4:2:0 프레임 하나는 약 24.9MB입니다. 60fps에서는 시스템 메모리와 GPU 메모리 사이를 한 번 오갈 때마다 초당 약 1.5GB가 움직입니다. 오가는 횟수가 많을수록 내보내기는 느려지고 미리보기는 끊깁니다.
• KwaFlux의 미디어 엔진은 프레임마다 "신분증"을 발급합니다. CUDA 포인터든 D3D11 텍스처든 Metal 텍스처든 시스템 메모리든 상위 계층에는 "프레임 하나"로만 보이고, 다른 API가 필요하면 엔진이 부담이 가장 적은 다리를 고릅니다.
• Windows에서는 NVIDIA, Intel, AMD와 시스템 D3D11·D3D12의 하드웨어 디코딩·인코딩이 플러그인으로 함께 설치됩니다. GPU, 메모리, 해상도로 점수를 매기고, 하나가 실패하면 다음 후보로 넘어가며, 마지막에는 소프트웨어 디코딩이 받아 줍니다.
• D3D11 텍스처를 OpenGL로 넘기는 방법은 다섯 단계입니다. NVIDIA 제로 카피, AMD·Intel 준제로 카피, CUDA를 거치는 2단계 전달, 비동기 전송, CPU 폴백입니다. 빠른 컴퓨터는 위 단계를, 오래된 컴퓨터는 아래 단계를 쓰며, 어느 쪽이든 화면은 끊기지 않습니다.
• 모든 경로가 제로 카피인 것은 아닙니다. 아래 두 단계는 시스템 메모리를 거칩니다. 전 과정 GPU란 가능한 한 GPU에 머물고, 안 되면 한 단계씩 내려가는 것이지 실패하고 멈추는 것이 아닙니다.

픽셀을 "집에 보내는" 일이 비싼 이유

픽셀이 집에 간다는 것은 프레임을 GPU 메모리에서 시스템 메모리로 복사해 처리한 뒤 다시 GPU로 올리는 것을 말합니다. 하드웨어 디코더는 GPU 메모리에 화면을 풀어 놓고, AI 모델과 화질 필터도 GPU에서 돌며, 하드웨어 인코더도 GPU 메모리에서 읽습니다. 중간에 시스템 메모리의 픽셀만 받는 단계가 하나라도 있으면, 그 프레임은 PCIe를 왕복해야 합니다.

먼저 프레임 하나의 크기를 계산해 봅니다(4:2:0에서는 색차가 휘도의 절반 크기만큼 더해집니다).

PCIe 4.0 x16의 이론 대역폭은 한 방향에 약 31.5GB/s입니다. 넉넉해 보이지만 이는 최대치일 뿐이고, 복사할 때마다 GPU가 하던 일을 끝내길 기다리고 드라이버 동기화를 기다리며 CPU도 이를 조율해야 합니다. 아래 그림의 위쪽이 흔한 방식입니다. 디코딩, 효과, AI, 인코딩이 저마다 자기 메모리를 원하니 한 번의 내보내기에서 같은 프레임이 PCIe를 다섯 번 건넙니다. 4K 10비트 60fps라면 복사에만 초당 약 7.5GB가 듭니다.

프레임 어댑터: 아홉 가지 프레임 형식, 하나의 프레임

프레임 어댑터는 KwaFlux 미디어 엔진의 한 계층으로, 프레임이 실제로 어느 메모리에 있든 플레이어, 효과, 인코더에는 똑같은 "프레임 하나"로 보이게 합니다. 미디어 소프트웨어는 사투리투성이입니다. FFmpeg은 AVFrame, NVIDIA는 CUDA 장치 포인터, Intel과 AMD의 하드웨어 디코더는 D3D11 텍스처, Vulkan은 VkImage, Apple은 CVPixelBuffer를 씁니다. 각각 수명, 정렬, 색 배치가 다릅니다.

상위 계층은 하나의 프레임 인터페이스만 받고, 다른 형태가 필요하면 "이 형태로 바꿔 줘"라고 요청할 뿐입니다. 그 컴퓨터에서 부담이 가장 적은 다리는 엔진이 고릅니다. GPU 제조사가 셋으로 늘어도 무너지지 않도록 몇 가지 설계 장치가 있습니다.

• 타입은 컴파일할 때 정해집니다. 인터페이스를 넘나드는 조회는 정적 변환 한 번으로 끝나고 런타임 타입 정보에 기대지 않으므로, DLL 경계에서 충돌하지 않습니다.
• GPU 작업은 GPU 리소스를 실제로 가진 프레임에만 붙습니다. 복제, 변환, 행렬로 내보내기 같은 작업은 개별 프레임 타입에 있고 공통 인터페이스에는 쌓아 두지 않습니다.
• 소유권이 분명합니다. 할당한 쪽이 해제하고, 공유 핸들을 두 번 해제하지 않습니다. GPU 장치를 다시 만들 때는 거기에 의존하는 상호 운용 리소스도 함께 무효화하고 다시 만들기 때문에, 이전 GPU의 텍스처가 다음 GPU에 남지 않습니다.

Windows: 세 제조사 GPU의 하드웨어 디코딩과 인코딩

Windows용 KwaFlux에는 영상 디코더 플러그인 8개와 영상 인코더 플러그인 6개가 함께 설치되며, 각각 독립된 DLL입니다. 디먹싱 후 선택기는 설정을 따르고, 자동일 때는 모든 후보를 채점해 점수가 높은 것부터 시도하며, 초기화에 실패하면 다음으로 넘어갑니다. 남은 경우는 소프트웨어 디코딩이 받아 줍니다.

표는 플러그인 자체가 지원하는 범위입니다. 쓰시는 GPU가 어떤 코덱을 하드웨어로 디코딩할 수 있는지는 GPU 세대에 달려 있습니다. 예를 들어 NVIDIA 지원표를 보면 소비자용 카드의 AV1 하드웨어 디코딩은 RTX 30 시리즈부터입니다.

채점에서 보는 것. 제조사가 다르면 바로 탈락합니다. NVIDIA가 아닌 GPU에서 NVDEC는 0점입니다. GPU 메모리가 빠듯하면 하드웨어 디코딩 점수가 깎이고, CPU가 충분히 강하면 소프트웨어 디코딩이 앞설 수도 있어 하드웨어 디코딩을 고집하느라 컴퓨터를 무겁게 만들지 않습니다. 4K에서는 하드웨어에 가산점을 줍니다. 고정 기능 유닛이 나설 때가 바로 그때입니다. D3D11로 화면을 표시한다면 D3D11VA에 가산점을 주고, 디코딩과 표시가 다른 GPU에서 이뤄지면 GPU 간 복사가 생기므로 감점합니다.

인코딩: 디코더가 내놓은 것을 그대로 받습니다.

프레임 어댑터의 가치가 가장 잘 드러나는 곳이 NVENC입니다. 모든 프레임을 먼저 CUDA로 바꿀 필요가 없습니다. CUDA 프레임은 장치 안에서 2D 복사, D3D11 프레임은 상호 운용, D3D12는 D3D11을 거쳐 CUDA로, Vulkan은 외부 메모리, OpenGL은 픽셀 버퍼 다리를 씁니다. 처음부터 시스템 메모리에 있던 프레임만 한 번 업로드됩니다. HEVC와 AV1에서는 HDR 마스터링 정보와 콘텐츠 밝기 정보를 인코더 설정에 쓰고, 기본 항목이 없는 H.264에서는 SEI에 직접 기록합니다.

참고: NVIDIA 지원표에 따르면 인코더가 있는 GeForce 카드는 동시 인코딩 세션이 최대 12개입니다. 세션이 바닥나면 KwaFlux의 NVENC 플러그인이 스스로 물러나 다음 인코더에 일을 넘기므로, 인코딩 도중에 실패하는 상황을 피합니다.

플러그인에는 버전 확인이 있어 맞지 않으면 불러오지 않고, 기능 확인은 플러그인을 불러오지 않고도 채점할 수 있습니다. 새 세대 GPU가 나오면 플러그인만 추가하면 되고, 위의 플레이어와 변환기는 바뀌지 않습니다.

5단계 사다리: D3D11 텍스처를 OpenGL로 넘기기

디코더와 표시용 API가 맞지 않는 경우가 많습니다. NVIDIA는 CUDA나 D3D11로 디코딩하는데 화면은 OpenGL로 가야 하고, Intel은 D3D11로 디코딩하는데 필터는 OpenGL 텍스처에서 돕니다. KwaFlux의 그래픽 코어가 다리를 놓으며, D3D11과 OpenGL 사이에서는 컴퓨터가 허락하는 한 높은 단계를 쓰는 5단계 사다리입니다.

1. NVIDIA 제로 카피. WGL_NV_DX_interop2 확장으로 D3D11 텍스처를 OpenGL 객체로 등록하고, 잠그면 OpenGL이 바로 읽고 씁니다. 픽셀은 시스템 메모리를 거치지 않습니다.
2. AMD·Intel 준제로 카피. DXGI 공유 핸들과 GL_EXT_memory_object_win32 확장으로 두 API가 같은 GPU 메모리를 봅니다.
3. CUDA를 거치는 2단계 전달. 먼저 CUDA로, 다음에 OpenGL로 옮기며 두 번의 복사 모두 GPU에서 이뤄집니다.
4. 픽셀 버퍼 객체(PBO) 비동기 전송. 제조사를 가리지 않고, 전송과 명령 제출을 겹쳐 진행합니다. CPU는 중계만 합니다.
5. CPU 폴백. 상호 운용 확장이 하나도 없는 컴퓨터에서도 느리긴 하지만 화면은 나옵니다.

사다리 옆에는 전용 다리도 있습니다. CUDA와 D3D11은 서로를 등록하고, D3D12와 D3D11은 DXGI 공유 핸들과 펜스로 동기화하므로 D3D12가 모든 API로 가는 직통로를 따로 둘 필요가 없습니다. Vulkan과 D3D11은 외부 메모리를 씁니다. CUDA 쪽 색 변환 커널은 라이브러리에 컴파일되어 있어 NV12와 P016을 BGRA로 바꾸는 작업이 GPU에서 이뤄지고, 10비트 화면은 16비트 RGBA로 유지되어 입구에서 8비트로 잘리지 않습니다.

Mac: VideoToolbox로 디코딩, Metal로 표시

macOS에서는 플러그인 목록의 길이로 겨루지 않습니다. Apple은 칩의 미디어 엔진에 인코딩과 디코딩을 넣어 두었고, KwaFlux는 그 엔진을 같은 프레임 언어에 연결합니다.

• 디코딩은 VideoToolbox가 맡고, 넘겨받은 CVPixelBuffer를 CVPixel 프레임으로 감쌉니다. H.264, HEVC, VP9, ProRes를 지원합니다.
• 인코딩은 h264_videotoolbox, hevc_videotoolbox, prores_videotoolbox를 쓰며, ProRes 내보내기도 VideoToolbox가 처리합니다.
• 표시는 Metal이 맡습니다. CAMetalLayer가 디스플레이의 확장 다이내믹 레인지(EDR) 지원 여부를 확인해, 지원하면 HDR을 EDR로 표시하고, 지원하지 않으면 Windows와 같은 계산의 톤 매핑으로 PQ나 HLG를 SDR로 바꿉니다.

플레이어, 효과, 변환 처리에서 보면 Windows의 D3D11 텍스처도 Mac의 CVPixelBuffer도 똑같은 "프레임 하나"이므로, 기능을 운영체제별로 두 벌 만들 필요가 없습니다.

플레이어: 오디오가 시계를 맡고 HDR은 프레임마다 전환

오디오가 마스터 클록입니다. 귀는 눈보다 흔들림에 훨씬 민감하므로, 화면이 소리를 따라가고 소리가 화면을 따라가지는 않습니다. 시계는 오디오 콜백 사이를 시스템 시간으로 선형 보간하고 지수 이동 평균으로 흔들림을 고르며, 판단 기준은 고정된 밀리초가 아니라 프레임 간격에 비례합니다. 프레임마다 내리는 결정은 기다리기, 그리기, 버리기 세 가지뿐입니다. 버리는 것은 늦은 프레임이지 재생 위치가 아닙니다.

탐색은 하나의 트랜잭션입니다. 디코딩을 멈추고, 지난 프레임 대기열을 비우고, 세대 번호로 옛 프레임을 막고, 시계를 초기화합니다. 새 위치의 화면이 실제로 그려진 뒤에야 오디오 시계가 다시 움직입니다. 보이는 것은 이동한 위치이지, 대기열에 남아 있던 직전 1초가 아닙니다.

HDR을 파일 전체에 한꺼번에 켜지 않습니다. 프레임마다 자기 전달 특성을 보고, PQ와 HLG일 때만 HDR 스왑 체인을 요청합니다. 다음 구간이 SDR이면 스왑 체인을 되돌리므로, 일반 영상이 PQ 신호로 처리되어 회색으로 뜨는 일이 없습니다. HLG는 셰이더에서 PQ로 바꾼 뒤 디스플레이에 넘깁니다.

일반 디스플레이에서의 HDR. 네 백엔드는 같은 톤 매퍼를 씁니다. PQ나 HLG를 먼저 니트 단위의 실제 휘도로 바꾸고, IPT 색 공간으로 옮겨 톤 테이블과 색역 테이블을 참조한 뒤 BT.709와 sRGB로 출력합니다. 톤 테이블은 화면의 피크를 따라가며, 피크는 아주 작은 오프스크린 이미지로 측정하고 GPU를 멈추지 않고 읽어 오며, 장면이 바뀔 때는 부드럽게 넘어갑니다. 마스터링 휘도가 없는 파일은 보기 좋은 상수를 대충 넣지 않고 1,000니트에서 시작합니다. sRGB 자막을 HDR 스왑 체인에 넣을 때는 PQ 기준 화이트까지 올리므로, 밝은 장면에서 흰 글자가 회색으로 죽지 않습니다.

비교 재생에서는 원본과 처리 결과를 두 갈래로 나누고, 분할선 양쪽이 각자 밝기 기록을 가집니다. 왼쪽이 야경이어도 오른쪽 낮 장면이 어둡게 매핑되지 않습니다. 재생하는 동안 백그라운드 작업은 GPU를 양보하고, 멈추면 천천히 되찾습니다. 실시간 재생이 먼저이고 내보내기는 줄을 섭니다.

libplacebo: 스케일링, 톤 매핑, 디밴딩

libplacebo는 mpv 플레이어에서 떼어 낸 GPU 화질 라이브러리입니다. KwaFlux는 이를 효과 노드로 넣고, 들어오는 프레임에 따라 백엔드를 고릅니다. OpenGL 프레임, 소프트웨어 디코딩 프레임, CUDA 프레임, CVPixel 프레임은 OpenGL로 가고, D3D11 NV12는 D3D11 백엔드로 바로 들어가 색 왕복을 한 번 줄이며, Vulkan 프레임은 Vulkan에 남습니다.

• 확대는 EWA Lanczos, 축소는 Lanczos를 쓰고, 속도가 중요하면 바이리니어로 바꿉니다.
• HDR을 SDR로 바꿀 때 BT.2390, Reinhard, Spline, Hable 커브를 고를 수 있고, 피크는 화면에서 측정할 수 있습니다.
• 디밴딩, 디더링, 링잉 억제로 그러데이션 하늘이 줄무늬가 되지 않게 합니다.
• 디인터레이스는 프레임마다 따로 추측하지 않고 이전·현재·다음 프레임으로 된 시간 창을 씁니다.
• 프리셋은 빠름과 고품질 두 가지입니다. 미리보기와 인코딩 전 스케일링은 빠름, 최종 렌더링은 고품질입니다.

자동 보정(회전, 픽셀 종횡비, 인터레이스, 색차 위치)과 인코딩 전 스케일링은 먼저 libplacebo에 맡깁니다. 업스케일로 해상도가 바뀌어도 스케일링 노드는 인코더 앞에 있으므로 인코더가 받는 것은 목표 크기입니다. libplacebo를 시작할 수 없으면 FFmpeg의 scale, zscale, yadif 필터가 이어받으므로, 모듈 하나가 빠져도 작업이 멈추지 않습니다.

한 번의 내보내기에서 픽셀이 지나는 이상적인 경로

지금까지를 이으면 Windows에서 한 번의 내보내기는 다음과 같습니다.

1. 파일을 패킷으로 디먹싱하고, 선택기가 그 컴퓨터에 맞는 하드웨어 디코더를 고릅니다.
2. 프레임은 시스템 메모리에 할당한 블록이 아니라 CUDA 포인터나 D3D11 텍스처로 태어납니다.
3. 회전, 종횡비 보정, 디인터레이스, SDR 납품용 톤 매핑은 libplacebo가 GPU에서 처리합니다.
4. AI 모델(업스케일, 화질 복구, SDR→HDR 변환 등)이 GPU에서 프레임마다 처리합니다. 도중에 프레임 형태가 바뀌어도 작업 쪽은 어떤 다리를 건넜는지 알 필요가 없습니다.
5. 해상도를 목표에 맞춰야 하면 빠른 스케일링을 한 번 더 합니다.
6. 각 인코더가 자기 방식으로 프레임을 받습니다. NVENC는 CUDA, oneVPL과 AMF는 D3D11입니다.
7. 패킷이 먹서로 들어가고, 타임스탬프가 정리되고, 파일이 기록됩니다.

한 문장으로 말하면, 하드웨어 디코딩이 텍스처를 남기고, 상호 운용이 다른 API에 그것을 보여 주며, 화질 처리는 GPU에 머물고, 하드웨어 인코더가 같은 GPU 메모리에서 프레임을 읽어 비트스트림을 만듭니다. 시스템 메모리가 등장하는 것은 그 컴퓨터에 더 높은 다리가 없거나, 어떤 단계가 정말로 CPU의 픽셀을 읽어야 할 때뿐입니다. 어디까지나 폴백일 뿐, 설계의 중심이 아닙니다.

Mac에서는 같은 말을 다른 사투리로 합니다. VideoToolbox가 미디어 엔진에서 디코딩하고, 프레임은 CVPixelBuffer로 처리 과정에 들어가며, Metal이 EDR로 HDR을 화면에 보내고, ProRes와 HEVC 내보내기는 다시 VideoToolbox로 돌아갑니다.

구간 병렬 내보내기는 타임라인을 여러 구간으로 나누지만, 각 구간이 지나는 것은 이 같은 처리 과정이며, 속도를 위해 색 처리를 건너뛰는 지름길을 따로 두지 않습니다.

KwaFlux에서 바꿀 수 있는 설정

대부분은 자동이지만, 다음 설정으로 동작을 바꿀 수 있습니다.

• 하드웨어 가속 디코딩(설정 › 성능): 자동(기본), 사용, 사용 안 함 중에서 고릅니다. 특정 파일에서 디코딩이 깨지거나 오류가 나면 사용 안 함으로 바꿔 소프트웨어 디코딩으로 원인을 가려 보세요. 변경 사항은 앱을 다시 시작한 뒤 적용됩니다.
• AI 프로세서(설정 › 성능): AI 처리에 GPU를 쓸지, 앱이 정하게 할지 고릅니다. 보통 GPU가 더 빠르며, 다음 내보내기, 미리보기, 마스크 생성부터 적용됩니다.
• AI 내보내기 리소스 사용량: 저부하(한 갈래만 처리하고 GPU가 여러 개면 하나만 사용), 균형(기본), 속도를 끝까지 끌어올리는 모드, 사용자 지정(사용할 GPU와 GPU당 동시 처리 수를 지정)이 있습니다. 낮추면 진행 중인 내보내기에 바로 적용되고, 끝난 구간은 사라지지 않습니다.

문제 해결

이 아키텍처가 할 수 없는 것

• 모든 경로의 제로 카피. 사다리의 4단계와 5단계는 시스템 메모리를 거치며, 오래된 GPU나 상호 운용 확장이 없는 드라이버는 여기로 갑니다.
• Dolby Vision 재현. HDR에서 확실히 말할 수 있는 것은 정적 HDR10과 HLG입니다.
• Mac에서 Windows만큼의 전면적인 상호 운용. Mac의 강점은 VideoToolbox, ProRes, CVPixel 프레임, Metal EDR이지, Windows만큼 많은 다리가 아닙니다.
• 속도 향상 배수의 약속. 복사가 줄어 얼마나 빨라지는지는 GPU, 드라이버, 해상도, 처리 단계에 따라 다릅니다. 직접 소재로 미리보기하고 측정해 보세요.

마치며

전 과정 GPU는 구호가 아니라 단계적으로 폴백하는 라우팅 표입니다. 빠른 컴퓨터에서는 픽셀이 끝까지 GPU에 머물고, 느린 컴퓨터도 한 단계씩 내려가며 일을 끝냅니다. 다음에 내보낼 때 GPU와 CPU 사용률을 한번 보세요. 픽셀이 어느 길로 갔는지 알 수 있습니다.

내 실제 영상으로 효과를 확인하세요

KwaFlux는 포맷 변환과 모든 AI 도구를 사용자 GPU에서 실행하며, 디코딩, 처리, 인코딩을 가능한 한 그래픽카드에서 처리합니다. AI 처리는 사용자 GPU에서 실행되며 미디어 파일이 처리를 위해 업로드되지 않습니다. Windows 10(64비트, 버전 1809 이상), Windows 11, Apple Silicon 탑재 macOS 12 이상에서 실행됩니다. 미리보기에는 계정이 필요 없습니다. 어떤 클립이든 1·3·5초 미리보기를 렌더링할 수 있습니다. 내보내기, 변환, 파일 복구, 링크에서 파일 다운로드에만 로그인과 유료 플랜이 필요합니다.

KwaFlux 받기 · 플랜 보기