Current Issue

초고해상도 영상 재생에 있어 코덱의 선택은 시스템 성능과 재생 품질에 결정적인 영향을 끼친다. 2012년 Vidvox에서 개발한 HAP 코덱은 기존 범용 코덱과는 근본적으로 다른 접근 방식을 취한다^[11]. 일반적인 비디오 코덱이 압축 효율성 극대화에 중점을 두는 반면, HAP 코덱은 실시간 처리 성능과 GPU 친화적인 구조에 초점을 맞추고 있다. HAP 코덱은 이중 압축 구조를 통해 CPU와 GPU 간의 효율적인 작업 분담을 실현한다. 인코딩 과정은 두 단계로 이루어지는데, 그 중 첫 번째 단계는 원본 이미지를 GPU에서 직접 사용 가능한 DXT으로 압축한다. 이 방식은 4:1에서 6:1의 압축률을 제공하며^[13][14], 특히 GPU에서 네이티브하게 지원되는 장점을 가진다. 두 번째 단계는 DXT 압축된 데이터를 Google의 Snappy 알고리즘으로 추가 압축한다. Snappy는 압축 효율보다 인/디코딩 속도에 초점을 맞춘 알고리즘으로 파일 크기를 줄이면서 동시에 빠른 디코딩이 가능하다.

디코딩 과정에서는 이 두 단계를 역순으로 적용하여 영상을 디코딩한다. 먼저 CPU에서 Snappy의 디코딩 과정을 거치는데, 이는 멀티코어 시스템에서의 병렬화가 가능하다. 해제된 DXT 상태의 데이터를 GPU로 전송한다. 12K 해상도 기준 한 프레임의 DXT 형식 데이터 크기는 32~50MB로, RGB 데이터 형태인 200MB에 비해 4~6배 가량 데이터 크기가 작으며, CPU와 GPU 간 데이터 전송에 있어 PCIe 대역폭 사용을 크게 줄인다.

기존 H.264/H.265 코덱과 비교하여, HAP은 각 프레임을 독립적으로 압축하는 인트라(Intra) 코딩 방식을 취하기 때문에 무작위 접근성이 우수하고, 병렬 처리에 유리하다. 또한 H.264/H.265가 하드웨어 디코딩에서 8K의 해상도까지만 지원하는 반면, HAP은 GPU 텍스처 제한에 따라 최대 16K 해상도를 지원한다. HAP은 이에 반해 H.264/H.265에 비해 수 배에서 수십 배 수준으로 압축 효율이 낮으며, 이를 극복하기 위한 SSD와 같은 데이터 처리량이 빠른 고성능 저장 장치가 필수적이다. HAP 코덱은 전시, 공연, 대형 LED 스크린과 같이 압축 효율보다 재생 안정성 확보가 중요한 환경에 특히 적합하다. 그러나 이러한 이점을 최대화하기 위해서는 HAP 코덱의 특성을 고려한 최적화된 플레이어 구현이 필요하다. 특히 CPU에서의 Snappy 압축 해제, GPU로의 데이터 전송, 그리고 GPU에서의 렌더링 과정이 효율적인 파이프라인화가 요구된다.

Snappy는 Google에서 개발한 데이터 압축 알고리즘으로, 최대 압축 효율보다는 빠른 압축 및 해제 속도에 중점을 둔 설계 철학을 가진다. 이 알고리즘은 초당 수백 메가바이트의 데이터를 처리할 수 있는 뛰어난 처리 속도를 제공하며, 이는 zlib와 같은 기존 압축 알고리즘 대비 5~10배 빠른 수준에 해당한다. Snappy의 압축률은 일반적으로 1.5:1에서 2:1 정도로 다소 제한적이지만, HAP 코덱과 같이 실시간 처리가 중요한 환경에서는 높은 압축률보다 빠른 속도가 더 중요한 요소로 작용한다. 특히 Snappy는 복잡한 사전이나 예측 테이블을 사용하지 않는 단순한 구현 방식을 채택하여 메모리 사용량을 최소화하고, 독립적인 청크 단위로 데이터를 처리할 수 있어 멀티코어 CPU 환경에서 병렬 압축 해제가 가능하다는 장점을 가진다. HAP 코덱에서 Snappy 압축 해제는 CPU에서 수행되는 첫 번째 디코딩 단계로 작용하며, CPU의 여러 코어를 활용한 병렬화를 통해 전체 디코딩 과정의 속도를 크게 향상시키는 핵심 역할을 담당한다.

DXT 또는 S3TC(S3 Texture Compression)는 GPU에 최적화된 텍스처 압축 포맷으로, HAP 코덱의 핵심 기술 중 하나이다. 이 압축 기술의 가장 큰 특징은 모든 현대 GPU가 하드웨어 수준에서 DXT 압축 텍스처의 직접 렌더링을 지원한다는 점으로, 텍스처가 압축된 형태로 GPU 메모리에 저장된 상태에서 렌더링 시 실시간으로 압축 해제가 이루어진다. DXT는 고정된 압축률을 제공하는데, DXT1은 약 6:1, DXT5는 약 4:1의 압축률을 가지며, 이는 영상 콘텐츠의 특성에 관계없이 일정한 메모리 요구사항을 보장한다. 또한 4×4 픽셀 블록 단위로 이미지를 압축하는 블록 기반 압축 방식을 사용하여, 각 블록이 독립적으로 처리되므로 텍스처의 일부분만 필요한 경우에도 효율적인 처리가 가능하다. DXT는 손실 압축 방식이므로 원본 이미지와 약간의 화질 차이가 발생할 수 있지만, HAP Q 변형에서는 YCoCg 색상 공간을 사용하여 이러한 화질 손실을 최소화한다. HAP 코덱의 핵심 이점은 DXT 압축된 데이터를 CPU에서 GPU로 전송한 후 GPU 내에서 직접 텍스처로 사용할 수 있다는 점으로, 이는 기존 코덱 방식 대비 CPU-GPU 간 데이터 전송량을 약 1/4에서 1/6로 크게 줄이며, GPU의 하드웨어 기반 DXT 압축 해제 지원으로 디코딩 부하를 현저히 감소시켜 8K 이상의 초고해상도 영상 처리에서 CPU는 Snappy 압축 해제, GPU는 DXT 압축 해제와 렌더링을 담당하는 효율적인 작업 분담을 가능하게 한다.

본 연구는 초고해상도 영상의 안정적인 재생을 위한 HAP 코덱 기반 플레이어를 개발한다. 그림 2는 본 연구에서 개발한 HAP 코덱 기반 플레이어의 개요도를 보여준다. HAP 코덱을 기반으로 인코딩된 비트스트림을 입력으로 받아 패킷 버퍼에 저장한다. 디코딩 과정은 두 과정으로 이루어진다. 먼저 Snappy 압축의 해제를 위해 Packet을 Chunk 단위로 나누고 여러 개의 Snappy 디코더를 거친다. Snappy는 Chunk 단위의 dependency가 없으며, 독립적으로 멀티 코어 병렬 처리가 가능하다. 디코딩을 거쳐 만들어진 DXT 포맷의 데이터는 텍스처 버퍼에 저장된 후 렌더링 타임에 맞춰 PCIe를 통해 CPU에서 GPU로 데이터가 전달된다. GPU 상에서 DXT 디코딩이 이루어지고, 재구성된 프레임을 디스플레이함으로써 HAP 코덱 기반 플레이어가 동작하게 된다.

Fig. 2. 
Overview of Hap Player proposed in this paper

기존 오픈소스 플레이어는 패킷 버퍼만을 사용하여 Render Loop에서 패킷을 읽고 디코딩한 후 화면에 렌더링하는 단순한 구조를 채택한다. 반면 제안된 플레이어는 이중 버퍼링 시스템을 도입하여 I/O, 디코딩, 렌더링 과정 간의 시간적 변동성을 흡수한다. 패킷 버퍼는 파일에서 읽어들인 압축된 HAP 패킷을 저장하는 첫 번째 버퍼로, 사용자가 메모리 용량에 따라 크기를 조절할 수 있으며 기본값은 300MB로 설정되어 있다. Read Thread가 이 버퍼를 지속적으로 채워 디스크 I/O의 불규칙성을 완화하고 안정적인 데이터 공급을 보장한다. 텍스처 버퍼는 Snappy 압축이 해제된 DXT 형식의 텍스처 데이터를 저장하는 두 번째 버퍼로, 압축 해제된 RGB 프레임을 직접 저장하는 방식 대비 메모리 사용량을 절약할 수 있다. 이 버퍼 역시 사용자 설정이 가능하며 기본값은 10프레임으로 구성된다. Decode Thread는 텍스처 버퍼를 지속적으로 채워 CPU 디코딩 과정의 시간적 편차를 흡수하고, 렌더링 루프에 안정적인 텍스처 데이터를 공급한다. 두 버퍼의 크기는 사용자의 하드웨어 사양과 대상 영상의 해상도에 따라 조절할 수 있으며, 고해상도 환경에서는 더 큰 버퍼 용량이 재생 안정성 확보에 도움이 된다.

제안된 플레이어는 재생 안정성을 더욱 향상시키기 위해 프리로드(Pre-load) 메커니즘을 구현하였다. 이 기능은 동영상 재생이 시작되기 전에 패킷 버퍼와 텍스처 버퍼를 모두 설정된 용량까지 미리 채워놓는 방식으로 동작한다. 프리로드 과정에서는 Read Thread와 Decode Thread가 동시에 동작하여 두 버퍼가 각각의 최대 크기까지 채워질 때까지 대기한다. 이러한 사전 준비 과정을 통해 재생 초기에 버퍼가 비어있는 상태에서 발생할 수 있는 버퍼 언더런(Buffer Underrun) 현상을 방지하고, 초고해상도 영상의 첫 번째 프레임부터 안정적인 재생을 보장할 수 있다. 프리로드 메커니즘은 재생 시작 시점에서 충분한 데이터를 미리 확보함으로써 초기 프레임 드랍 발생 가능성을 줄여 전체적인 재생 품질을 안정화한다.

본 연구를 통해 개발한 HAP 코덱 플레이어의 성능 평가를 위해 두 가지 실험 환경에서 평가를 진행한다. 표 1은 실험 환경을 보여준다. 하나는 고성능 데스크톱 환경이며, 고성능의 CPU와 GPU를 포함하는 환경에 해당된다. 다른 하나는 상대적으로 성능이 낮은 노트북 환경이다. 이는 상대적으로 낮은 구동 환경에서의 동작 성능을 검증하기 위함이다. 테스트에 사용된 영상은 4K(3840×2160)에서16K(15360×8640)까지의 다양한 초고해상도 영상을 대상으로 하였다. 그림 3은 실제 테스트 화면을 캡처한 그림으로 테스트에 사용된 영상은 4k 해상도의 Big Buck Bunny의 10초 분량을 다양한 해상도로 HAP 코덱으로 인코딩하여 사용하였다. 4K(3840×2160)부터 16K(15360×8640)까지의 해상도를 테스트하여 초고해상도 영상에서의 성능을 중점적으로 평가하였다. 모든 영상은 60fps로 인코딩되었다.

Fig. 3. 
HAP Codec Player Test Screen (Big Buck Bunny 16K Video)

본 실험에서는 제안된 플레이어(Ours)와 오픈소스 HAP 플레이어(ofxHapPlayer)의 성능을 비교하였다. 본 연구에서는 주요 평가 지표로 프레임 드랍 발생 비율을 고려한다. 하나는 렌더링 루프 동작 시간이다. 이는 각 프레임 별 렌더링 루프에서 소요되는 시간을 측정한다. 60fps 기준 한 프레임 당 16.6ms의 임계치가 있으며, 이를 초과할 경우 프레임 드랍이 발생했음으로 판단하고, 해당 영상은 디스플레이하지 않는다. 다른 하나는 프레임 드랍률이다. 전체 프레임 중, 렌더링 루프 소요 시간을 기준으로 프레임 드랍이 발생한 프레임의 비율을 의미한다.

그림 4와 그림 5는 8K(7680×4320) 해상도에서 본 논문에서 개발한 플레이어와 기존 ofxHapPlayer의 성능을 프레임 드랍 측면에서 비교하며 각각 노트북 환경과 고성능 데스크톱 환경에서의 결과를 의미한다. 각 결과에서 프레임 드랍은 산점도의 형태로 시각화하였으며, 그래프의 가로 축은 프레임 번호를 세로 축은 각 프레임의 렌더링 소요시간을 의미한다. 16.6ms 임계선을 초과하여 프레임 드랍이 발생한 프레임은 빨간색으로 표시하였으며, 임계값 이내에 렌더링 된 프레임은 파란색으로 표시하였다. 그림 4의 노트북 환경에서는 기존 ofxHapPlayer의 경우 동일한 8K 샘플에서 프레임 드랍이 발생한 프레임 수는 40장으로 크게 증가하여 6.7%의 프레임 드랍률을 보였다. 개발 플레이어의 경우 고성능 데스크톱 환경에 비해 몇몇 프레임의 소요 시간이 증가하여 10ms 수준의 소요 시간이 관찰되었으나, 임계치를 초과하는 프레임 드랍은 확인되지 않았다. 그림 5의 데스크톱 환경에서의 8K 결과를 보면, 기존 ofxHapPlayer에서 총 600장의 프레임 중 프레임 드랍이 발생한 프레임 수는 5장으로 0.8%의 프레임 드랍률이 확인된 반면, 개발 플레이어는 프레임 드랍 없이 모든 프레임이 정상적으로 렌더링 된 것을 확인할 수 있다.

Fig. 4. 
Frame Time Scatter Plot in Laptop Environment (a) ofxHapPlayer (b) Proposed Player ours

Fig. 5. 
Frame Time Scatter Plot in Desktop Environment (a) ofxHapPlayer (b) Proposed Player ours

제안된 플레이어의 다양한 해상도에서의 성능을 평가하기 위해 4K, 8K, 12K, 16K 해상도에서 두 환경 모두에서 테스트를 진행하였다. 그림 6에서 보여지듯이, 노트북 환경에서는 4K, 8K, 12K까지는 프레임 드랍 없이 안정적인 재생이 가능하였으나, 16K 해상도에서는 상당한 프레임 드랍이 발생하였다. 이는 HAP 코덱의 큰 파일 크기로 인한 SSD I/O 성능 제약이 주요 원인으로 분석되며, 테스트에 사용된 노트북의 SSD가 16K 해상도의 높은 데이터 처리량을 안정적으로 지원하지 못하여 패킷 버퍼의 언더런이 발생한 것으로 판단된다. 반면 그림 7에서 확인할 수 있듯이, 데스크톱 환경에서는 4K, 8K, 12K, 16K 해상도 모두에서 0.0%의 프레임 드랍률을 보였다. 산점도에서 확인할 수 있듯이, 해상도가 증가함에 따라 렌더링 시간이 소폭 증가하지만 모든 경우에서 16.6ms 임계치 이하를 유지하여 안정적인 재생이 가능하였다.

Fig. 6. 
Frame Time Scatter Plot by Resolution in Laptop Environment (a) 4K Resolution (b) 8K Resolution (c) 12K Resolution (d) 16K Resolution

Fig. 7. 
Frame Time Scatter Plot by Resolution in Desktop Environment (a) 4K Resolution (b) 8K Resolution (c) 12K Resolution (d) 16K Resolution