하드웨어 디코딩: 개념, 작동 원리 및 장점

하드웨어 디코딩이란?

Hardware decoding은 범용 CPU가 아닌 시스템온칩(SoC)에 통합된 특수 집적 회로에서 미디어 데이터를 압축 해제하는 프로세스입니다. 이러한 블록을 비디오 디코더 또는 VPU(Video Processing Unit)라고 하며 특정 압축 알고리즘에 최적화된 ASIC 가속기입니다.

최신 모바일 SoC에는 각 인기 코덱에 대한 별도의 하드웨어 블록이 포함되어 있습니다. 예를 들어 Apple A17 Pro 칩에는 H.264, H.265, VP9, AV1 및 ProRes용 디코더가 포함되어 있습니다. 각 블록은 입력에서 압축된 비트스트림을 받아 CPU 개입 없이 출력에서 YUV 또는 BGRA 형식의 준비된 디코딩 프레임을 제공할 수 있는 완전한 처리 파이프라인입니다.

하드웨어 디코딩은 Qualcomm Snapdragon 800과 Apple A7이 처음으로 전용 H.264 디코딩 블록을 포함한 2012–2013년에 모바일 업계의 표준이 되었습니다. 그 이후로 이 기술은 단일 포맷 지원에서 여러 스트림을 동시에 디코딩할 수 있는 범용 멀티 포맷 블록으로 발전했습니다 — 예를 들어 별도의 비디오 스트림으로 PiP를 위한 것입니다.

하드웨어 디코딩의 작동 방식

하드웨어 디코딩 프로세스는 소프트웨어 디코딩과 근본적으로 다릅니다. 순차적 CPU 명령 실행 대신 하드웨어 블록은 압축 해제의 각 단계(엔트로피 디코딩, 역양자화, 역DCT, 움직임 보상)에 대한 물리적 회로를 구현합니다.

하드웨어 디코더 아키텍처

일반적인 하드웨어 디코더는 여러 파이프라인 단계로 구성됩니다. 첫 번째 단계는 CABAC 또는 CAVLC용 유한 상태 기계(FSM)로 구현된 엔트로피 디코더입니다. 각 비트가 조건부 분기로 처리되는 소프트웨어 구현과 달리 하드웨어 CABAC은 병렬 컨텍스트 예측 회로를 사용하여 사이클당 1비트 대신 2–3비트를 처리할 수 있습니다.

두 번째 단계는 역DCT 블록입니다. 소프트웨어 DCT는 CPU에서 곱셈-누산 루프가 필요합니다. 하드웨어 구현은 8x8 블록의 64개 계수를 모두 한 사이클에 계산하는 행렬 곱셈기를 사용합니다. 하드웨어 역DCT는 400–600MHz로 작동하며 초당 최대 400만 개의 매크로블록을 처리하여 실시간 8K 비디오 디코딩에 충분합니다.

세 번째 단계는 움직임 보상(MC) 모듈입니다. 역DCT와 병렬로 하드웨어 블록은 비트스트림에서 움직임 벡터를 수신하고 디코딩된 프레임 버퍼에서 참조 영역을 추출합니다. DPB 버퍼(Decoded Picture Buffer)는 최대 16개의 참조 프레임을 저장하며 특수 저지연 캐시 메모리를 통해 액세스됩니다. 최신 디코더는 적응형 스무딩 및 서브픽셀 보간을 사용한 예측을 사용하며 이는 H.265 및 AV1에 중요합니다.

시스템 상호 작용

하드웨어 디코더 관리는 DMA 컨트롤러를 통해 이루어집니다. 애플리케이션은 공유 메모리의 압축된 데이터에 대한 포인터를 디코더에 전달하고 디코더는 직접 메모리 액세스를 통해 비트스트림을 읽습니다. 프레임 디코딩이 완료되면 인터럽트가 드라이버에 알리고 준비된 프레임을 출력 버퍼 풀에서 사용할 수 있습니다. 이 메커니즘은 데이터 처리 중 CPU 부하를 완전히 제거합니다 — 프로세서는 디코딩을 시작하고 최종 결과만 받습니다.

VideoToolbox와 MediaCodec: 플랫폼 비교

두 모바일 플랫폼 모두 하드웨어 디코딩을 위한 네이티브 API를 제공하지만 버퍼 관리 및 디코더 수명 주기에 대한 접근 방식이 다릅니다. iOS의 VideoToolbox는 디스플레이 출력을 위해 Metal과 긴밀하게 통합되어 있는 반면 Android의 MediaCodec은 직접 렌더링을 위해 Surface를 사용합니다.

VideoToolbox는 iOS 및 macOS용 하드웨어 디코딩 프레임워크입니다. 비동기 디코딩 모델을 사용합니다. VTDecompressionSessionDecodeFrame이 즉시 반환되고 준비된 프레임이 별도의 큐에서 콜백을 통해 도착합니다. VideoToolbox는 픽셀 버퍼 풀(CVPixelBufferPool)을 자동으로 관리하고 해제된 버퍼를 새 프레임에 재사용할 수 있습니다. HDR 비디오의 경우 VideoToolbox는 ITU-R BT.2020 색 공간과 PQ/HLG EOTF를 지원합니다.

MediaCodec은 입력 및 출력 버퍼 큐와 함께 동기 모델을 사용합니다. 애플리케이션은 압축된 데이터를 보내기 위해 dequeueInputBuffer를, 디코딩된 결과를 받기 위해 dequeueOutputBuffer를 주기적으로 호출합니다. 이 접근 방식은 개발자에게 디코딩 속도에 대한 완전한 제어권을 제공하며 이는 오디오-비디오 동기화에 중요합니다. 디스플레이 출력을 위해 MediaCodec은 Surface를 허용하므로 CPU 복사 없이 직접 GPU 디코딩이 가능합니다.

하드웨어 디코딩의 장점

하드웨어 디코딩은 소프트웨어에 비해 세 가지 주요 이점을 제공합니다: 에너지 효율성, 성능 및 안정성. 각각은 제한된 배터리 리소스와 열적 제약이 있는 모바일 장치에 매우 중요합니다.

에너지 효율성

하드웨어 디코딩의 주요 장점은 근본적으로 낮은 전력 소비입니다. 일반적인 H.264/H.265 하드웨어 디코더는 실시간으로 1080p 비디오를 디코딩할 때 0.2–0.5W를 소비합니다. 이에 비해 CPU에서 동일한 스트림의 소프트웨어 디코딩은 프로세서 아키텍처에 따라 1.5–4W를 소비합니다. 5–10배 차이는 배터리 수명에 직접적인 영향을 미칩니다: 하드웨어 디코딩을 사용하면 CPU의 소프트웨어 디코딩으로 2–4시간인 반면 10–15시간 동안 영화를 시청할 수 있습니다.

에너지 효율성은 좁은 전문화를 통해 달성됩니다. 광범위한 명령을 실행하고 복잡한 제어 로직을 가진 CPU와 달리 하드웨어 디코더는 특정 알고리즘에 필요한 회로만 포함합니다. 이러한 블록의 클록 주파수는 CPU의 2–3GHz에 비해 200–600MHz로 전압의 제곱에 비례하여 동적 전력 소비를 줄입니다.

성능 및 방열

하드웨어 디코딩은 고해상도에서도 보장된 프레임 속도를 제공합니다. 파이프라인 아키텍처 덕분에 하드웨어 블록은 여러 압축 해제 단계를 동시에 처리할 수 있습니다: 한 모듈이 다음 매크로블록에 대한 엔트로피 디코딩을 수행하는 동안 다른 모듈은 이미 현재 매크로블록에 역DCT를 적용합니다. 이러한 병렬 처리는 각 단계가 순차 작업인 CPU에서는 달성할 수 없습니다.

하드웨어 디코더의 방열은 현저히 낮습니다: 4K 비디오 디코딩 중 일반적인 블록은 CPU의 2–6W에 비해 0.3–0.8W의 열을 방출합니다. 이는 장시간 시청 중에도 장치가 과열되지 않고 스로틀링이 발생하지 않으며 사용자가 드롭 없이 안정적인 60FPS를 얻을 수 있음을 의미합니다. 하드웨어 디코딩 중 케이스 온도는 일반적으로 소프트웨어 디코딩보다 5–10도 낮으며 이는 능동 냉각이 없는 태블릿에 특히 중요합니다.

하드웨어 디코딩 코드 예제

VideoToolbox를 통한 iOS의 콜백 처리와 MediaCodec을 통한 Android의 전체 파이프라인을 사용한 하드웨어 디코딩의 실제 구현을 살펴보겠습니다.

iOS의 전체 하드웨어 디코딩 예제

import VideoToolbox
import CoreMedia

class HardwareDecoder {
    var session: VTDecompressionSession?
    
    func setup() {
        let formatDesc = createFormatDescription()
        var callback = VTDecompressionOutputCallbackRecord(
            decompressionOutputCallback: decodingCallback,
            decompressionOutputRefCon: nil
        )
        VTDecompressionSessionCreate(
            allocator: nil,
            videoFormatDescription: formatDesc,
            videoDecoderSpecification: nil,
            destinationImageBufferAttributes: nil,
            outputCallback: &callback,
            decompressionSessionOut: &session
        )
    }
    
    func decode(sampleBuffer: CMSampleBuffer) {
        VTDecompressionSessionDecodeFrame(
            session!, sampleBuffer: sampleBuffer,
            flags: ._EnableAsynchronousDecompression,
            frameRefcon: nil, infoFlagsOut: nil
        )
    }
}

코드는 비동기 콜백으로 VideoToolbox 디코딩 세션을 생성합니다. VTDecompressionSessionCreate는 제공된 CMVideoFormatDescription을 기반으로 사용 가능한 하드웨어 디코더를 자동으로 감지합니다. kVTDecodeFrame_EnableAsynchronousDecompression 플래그는 비동기 모드를 활성화합니다 — 애플리케이션이 디코딩 중에 차단되지 않고 콜백을 통해 프레임을 수신합니다. H.264의 경우 먼저 CMVideoFormatDescriptionCreateFromH264ParameterSets를 통해 SPS/PPS NAL 단위에서 형식 설명을 만들어야 합니다.

Surface 출력을 사용한 Android의 하드웨어 디코딩

class HardwareDecoder(private val surface: Surface) {
    private var mediaCodec: MediaCodec? = null
    
    fun initDecoder(mimeType: String, width: Int, height: Int) {
        mediaCodec = MediaCodec.createDecoderByType(mimeType)
        val format = MediaFormat.createVideoFormat(mimeType, width, height)
        
        mediaCodec?.configure(format, surface, null, 0)
        mediaCodec?.start()
    }
    
    fun feedFrame(data: ByteArray, pts: Long) {
        val inputIndex = mediaCodec!!.dequeueInputBuffer(TIMEOUT_US)
        if (inputIndex >= 0) {
            val buffer = mediaCodec!!.getInputBuffer(inputIndex)
            buffer?.put(data)
            mediaCodec!!.queueInputBuffer(inputIndex, 0, data.size, pts, 0)
        }
    }
}

Kotlin 코드는 Surface에 바인딩된 MediaCodec을 생성하여 CPU를 통한 데이터 복사 없이 직접 디스플레이 출력을 보장합니다. mimeType 매개변수는 MediaFormat 상수를 사용합니다: H.264의 경우 video/avc, H.265의 경우 video/hevc, AV1의 경우 video/av01. dequeueInputBuffer 메서드는 타임아웃과 함께 사용 가능한 입력 버퍼를 기다립니다. 버퍼를 사용할 수 없으면 현재 프레임을 건너뛰어 불균일한 비트레이트에서 큐 오버플로를 방지합니다.

하드웨어 디코딩을 선택해야 하는 경우

하드웨어 디코딩은 대부분의 프로덕션 시나리오에 최적의 선택이지만 보편적인 솔루션은 아닙니다. 적용 가능성의 경계를 이해하면 하드웨어 코덱 지원 부족이 사용자 경험을 망치는 상황을 피할 수 있습니다.

필수 사용 시나리오

하드웨어 디코딩은 세 가지 경우에 필수입니다: 장시간 비디오 재생(30분 이상), 4K 콘텐츠 디코딩, 최대 배터리 수명에 중점을 둔 모든 애플리케이션. 스트리밍 서비스(Netflix, YouTube, Twitch)는 독점적으로 하드웨어 디코딩을 사용합니다. 소프트웨어는 높은 비트레이트와 큰 해상도에서 안정적인 재생을 보장할 수 없기 때문입니다. 이러한 서비스의 경우 DRM 지원(FairPlay, Widevine)이 중요하며 이는 디코더에서 디스플레이 출력까지 보호된 파이프라인을 제공하는 하드웨어 블록을 통해서만 사용할 수 있습니다.

통합 비디오(컷신, 광고, 게임 내 시네마틱)가 있는 게임의 경우에도 하드웨어 디코딩이 권장됩니다. Unity 및 Unreal Engine과 같은 최신 게임 엔진에는 VideoToolbox 및 MediaCodec에 대한 내장 지원이 있습니다. 게임에서의 하드웨어 디코딩은 물리 시뮬레이션, 적 AI 및 입력 처리를 위해 CPU를 확보하여 전반적인 성능을 향상시킵니다.

제한 사항 및 폴백

하드웨어 디코딩의 주요 제한 사항은 하드웨어 포맷 지원에 대한 의존성입니다. SoC에 AV1용 디코더가 없는 경우(예: Snapdragon 8 Gen 1 장치), 애플리케이션은 FFmpeg 및 dav1d를 통한 소프트웨어 폴백을 제공해야 합니다. 동일한 상황이 구형 장치의 H.265 및 디코딩을 위해 Apple A13+ 칩에서만 지원되는 ProRes에도 적용됩니다. 재생을 시작하기 전에 필요한 포맷에 대한 하드웨어 디코더의 가용성을 확인하고 디코딩 전략을 동적으로 선택하는 것이 좋습니다.

두 번째 제한 사항은 동시 디코딩 세션 수입니다. 대부분의 SoC는 1–2개의 병렬 하드웨어 디코더를 지원합니다. 세 번째 세션을 열려고 하면 API가 오류를 반환하고 애플리케이션이 소프트웨어 디코딩으로 전환해야 합니다. 세션 수는 SoC 제조업체에 따라 다릅니다: Apple 칩은 A17 Pro에서 최대 4개의 H.264 디코딩 세션을 허용하는 반면 Snapdragon 8 Gen 2는 H.265의 경우 최대 2개, VP9의 경우 총 최대 2개를 지원합니다.