모바일 앱의 디코딩: 개념, 기본 개념 및 작동 원리

디코딩이란?

디코딩은 압축된 디지털 데이터를 원래의 비압축 형식으로 다시 변환하는 프로세스입니다. 미디어의 맥락에서 디코딩은 인코더가 생성한 압축 비트스트림에서 비디오 프레임을 복원합니다. 디코딩이 없으면 사용자는 비디오를 보거나 오디오를 들을 수 없습니다. 모든 최신 미디어 형식이 대역폭과 디스크 공간을 절약하기 위해 압축을 사용하기 때문입니다.

5Mbps 비트레이트의 H.264 형식 일반 비디오 스트림은 동일한 해상도의 비압축 RGB 스트림보다 100배 적은 공간을 차지합니다. 디코딩 알고리즘은 인코딩에 대해 역순으로 코덱 사양을 따라 각 프레임을 원래 해상도와 색 공간으로 복원해야 합니다. 이를 위해 디코더는 인트라 프레임(I-프레임) 및 인터 프레임(P-프레임, B-프레임) 데이터를 처리합니다.

모바일 장치에서 디코딩은 CPU 또는 전용 하드웨어 블록에서 수행될 수 있습니다. Apple(A 시리즈), Qualcomm(Snapdragon) 및 MediaTek(Dimensity)의 최신 SoC에는 모든 인기 형식에 대한 내장 디코더가 포함되어 있습니다. 비디오 프로세서는 역이산 코사인 변환 및 움직임 보상의 무거운 작업을 처리하여 CPU를 다른 작업에 사용할 수 있게 합니다.

디코딩의 작동 방식

디코딩 프로세스는 인코딩 단계를 역전시키는 여러 순차적 단계로 구성됩니다. 먼저 비트스트림에서 헤더 및 압축 매개변수(프로필, 레벨, 해상도, 색 공간)가 추출됩니다. 그런 다음 디코더는 압축된 매크로블록을 순차적으로 처리하여 역변환을 적용합니다.

비디오 스트림 디코딩 단계

첫 번째 단계는 엔트로피 코드 추출입니다. 엔트로피 디코딩은 CABAC 또는 CAVLC 알고리즘을 사용하여 이산 코사인 변환 계수를 복원합니다. 이 단계는 비디오 해상도에 의존하지 않습니다. 픽셀이 아닌 비트 스트림을 처리하며, 복잡성은 프레임 크기가 아닌 비트레이트에 의해 결정됩니다.

두 번째 단계는 역양자화 및 역DCT입니다. 디코더는 양자화된 계수에 양자화 단계를 곱하여 근사 DCT 계수 값을 복원한 다음 역DCT 변환을 적용합니다. 역DCT는 주파수 영역에서 공간 데이터를 복원하여 픽셀의 매크로블록을 형성합니다. 변환은 크로마와 루마에 대해 독립적으로 수행됩니다.

세 번째 단계는 움직임 보상입니다. P-프레임 및 B-프레임의 경우 디코더는 비트스트림에서 추출된 움직임 벡터를 사용하고 이전에 디코딩된 참조 프레임을 참조합니다. 움직임 보상은 현재 매크로블록에 대한 예측자를 생성하며, 역DCT 후 잔차 신호가 추가됩니다. 결과는 출력 준비가 된 완전히 복원된 프레임입니다.

// 비디오 프레임 디코딩의 기본 의사 코드
struct DecodedFrame {
    uint8_t* y_plane;
    uint8_t* u_plane;
    uint8_t* v_plane;
    int width, height;
};

class Decoder {
public:
    bool decodeNALUnit(const uint8_t* nalUnit, size_t size) {
        if (!parseNALUHeader(nalUnit, size))
            return false;
        
        int sliceType = parseSliceType(nalUnit);
        entropyDecode(nalUnit);
        inverseQuantize();
        inverseDCT();
        
        if (sliceType != I_SLICE)
            motionCompensation();
        
        return true;
    }
};

위 예제는 H.264 디코더의 기본 구조를 보여줍니다. decodeNALUnit 함수는 NAL 유닛(압축 H.264 스트림의 기본 블록)을 받습니다. 디코더는 헤더를 순차적으로 파싱하고, 슬라이스 유형을 추출하고, 엔트로피 디코딩, 역양자화 및 역DCT를 적용합니다. P-슬라이스 및 B-슬라이스의 경우 DPB 버퍼의 참조 프레임을 사용하여 움직임 보상이 추가로 수행됩니다.

압축 형식 및 코덱

최신 비디오 코덱은 압축 알고리즘, 효율성 및 계산 리소스 요구 사항이 다릅니다. 형식 선택은 모바일 장치에서 디코딩 중 파일 크기, 이미지 품질 및 전력 소비에 직접적인 영향을 미칩니다.

H.264는 가장 널리 사용되는 비디오 코덱으로, 모든 모바일 장치에서 지원됩니다. 주요 장점은 보편성입니다. 모든 Android 스마트폰과 iPhone이 H.264를 하드웨어 디코딩할 수 있습니다. 그러나 동일한 비트레이트에서 H.264는 H.265 및 AV1과 같은 최신 코덱보다 품질이 떨어지며, 유사한 시각적 품질을 위해 30~50% 더 높은 비트레이트가 필요합니다.

H.265는 동일한 품질에서 H.264보다 두 배의 압축을 제공합니다. H.265 디코딩에는 더 강력한 하드웨어 블록이 필요합니다. iOS의 VideoToolbox는 iPhone 6(A8)부터 H.265를 지원하고, Android 기기는 Snapdragon 805 이상부터 지원합니다. 모바일 앱에 H.265를 선택할 때는 구형 장치에 하드웨어 지원이 없을 수 있으며 소프트웨어로 이 형식을 디코딩하여 전력 소비가 급증할 수 있음을 고려해야 합니다.

AV1은 Alliance for Open Media의 오픈 코덱으로, 모든 최신 형식 중 최고의 압축을 제공합니다. AV1은 동일한 시각적 품질에서 H.265보다 30%, H.264보다 50% 더 효율적입니다. 하드웨어 AV1 디코딩은 2023년 이후 SoC(Apple A17 Pro, Qualcomm Snapdragon 8 Gen 2 이상)에서만 등장했습니다. 구형 장치의 경우 AV1 디코딩은 dav1d 라이브러리를 통한 소프트웨어 방식으로만 가능하며, CPU에 상당한 부하를 발생시킵니다.

소프트웨어 vs 하드웨어 디코딩

소프트웨어 디코딩과 하드웨어 디코딩 사이의 선택은 모바일 미디어 플레이어를 개발할 때 중요한 아키텍처 결정입니다. 각 접근 방식에는 장점과 제한 사항이 있으며, 애플리케이션 설계 시 고려해야 합니다.

성능 및 전력 소비

하드웨어 디코딩은 동일한 작업을 수행할 때 CPU보다 훨씬 적은 에너지를 소비하는 전용 비디오 처리 블록에서 수행됩니다. Qualcomm에 따르면, 4K 비디오 재생 시 하드웨어 H.265 디코더는 Snapdragon 8 Gen 1 CPU의 소프트웨어 디코딩보다 5~10배 적은 에너지를 소비합니다. 이는 모든 밀리와트가 배터리 수명에 영향을 미치는 모바일 장치에서 중요합니다.

반면 소프트웨어 디코딩은 최대의 유연성을 제공합니다. FFmpeg와 libavcodec 라이브러리는 하드웨어 지원이 없는 희귀 및 구식 형식을 포함한 수십 개의 코덱과 컨테이너를 지원합니다. 개발자는 디코딩 파이프라인을 수정하고 실시간으로 후처리 및 필터를 추가할 수 있으며, 이는 폐쇄형 하드웨어 블록을 사용할 때는 불가능합니다.

소프트웨어 디코딩을 선택해야 하는 경우

소프트웨어 디코딩은 여러 시나리오에서 정당화됩니다. 희귀 형식(ProRes, DNxHD, Motion JPEG) 재생 시, 프레임 처리의 각 단계를 정밀하게 제어해야 하는 경우, 하드웨어 지원이 없는 장치에서 AV1을 디코딩할 때 등입니다. FFmpeg의 libavcodec은 사실상 모든 알려진 형식을 디코딩할 수 있어 범용 미디어 플레이어의 사실상 표준이 되었습니다.

소프트웨어 디코딩의 제한 사항은 열 방출입니다. CPU에서 지속적으로 4K 비디오를 디코딩하면 10~15분 내에 장치가 45~50도까지 가열되어 스로틀링 및 프레임 속도 저하가 발생할 수 있습니다. 능동 냉각이 없는 장치(태블릿, 휴대폰)에서는 특히 두드러집니다. 소프트웨어 디코딩 중 CPU 전력 소비는 동일한 스트림의 하드웨어 디코딩 시 0.3~0.5W와 비교하여 3~5W에 도달할 수 있습니다.

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

하드웨어 디코딩은 모든 프로덕션 미디어 플레이어의 기본 선택입니다. 최소 전력 소비로 4K 비디오에 대해 안정적인 60fps를 제공합니다. iOS의 VideoToolbox와 Android의 MediaCodec은 코덱 및 해상도에 따라 최적의 처리 블록을 자동으로 선택하는 하드웨어 디코딩용 네이티브 API를 제공합니다.

플랫폼 API는 프레임 버퍼 관리(Android의 surface pool, iOS의 CVPixelBufferPool), 디스플레이 동기화 및 메모리 최적화를 처리합니다. 개발자는 필요한 매개변수로 디코더를 열고 준비된 프레임을 받기만 하면 됩니다. 하드웨어 디코딩은 최소 지연 시간의 엔드투엔드 파이프라인을 지원합니다. 비트스트림 수신부터 화면 표시까지 5~15ms가 소요되며, 소프트웨어 디코딩의 30~80ms에 비해 우수합니다.

디코딩 코드 예제

두 모바일 플랫폼에서 디코딩의 실제 구현을 살펴보겠습니다. iOS에서 하드웨어 디코딩은 VideoToolbox를 통해, 소프트웨어 디코딩은 FFmpeg를 통해 수행됩니다. Android에서는 하드웨어 디코딩에 MediaCodec이 사용됩니다.

iOS의 VideoToolbox를 사용한 하드웨어 디코딩

@interface VideoDecoder ()
@property (nonatomic) VTDecompressionSessionRef session;
@end

@implementation VideoDecoder

- (void)setupDecoder {
    CMVideoFormatDescriptionRef formatDesc;
    CMVideoCodecType codecType = kCMVideoCodecType_H264;
    
    OSStatus status = CMVideoFormatDescriptionCreate(
        NULL, codecType, 1920, 1080, NULL, &formatDesc
    );
    
    VTDecompressionOutputCallbackRecord callback;
    callback.decompressionOutputCallback = &decodingCallback;
    
    VTDecompressionSessionCreate(NULL, formatDesc, NULL,
        NULL, &callback, &_session);
}

- (void)decodeFrame: (uint8_t*)nalData length:(size_t)size {
    CMBlockBufferRef blockBuffer;
    CMBlockBufferCreateWithMemoryBlock(NULL, nalData,
        size, NULL, NULL, 0, size, 0, &blockBuffer);
    
    CMSampleBufferRef sampleBuffer;
    CMSampleBufferCreate(NULL, blockBuffer, true, NULL,
        NULL, NULL, 1, 0, NULL, 0, NULL, &sampleBuffer);
    
    VTDecompressionSessionDecodeFrame(_session,
        sampleBuffer, 0, NULL, 0);
}

@end

코드는 iOS에서 H.264 하드웨어 디코더의 초기화를 보여줍니다. VTDecompressionSessionCreate는 디코딩 세션을 생성하고, VTCreate는 준비된 프레임이 나타날 때 콜백을 호출합니다. 세션은 지정된 코덱에 사용 가능한 경우 자동으로 하드웨어 블록을 사용합니다. CVPixelBuffer 형식으로 디코딩된 프레임을 얻기 위해 각 준비된 프레임을 최소 지연으로 전달하는 콜백이 사용됩니다.

Android의 MediaCodec을 사용한 하드웨어 디코딩

MediaCodec decoder = MediaCodec.createDecoderByType("video/avc");
MediaFormat format = MediaFormat.createVideoFormat(
    "video/avc", 1920, 1080
);
format.setInteger(MediaFormat.KEY_FRAME_RATE, 30);

decoder.configure(format, surface, null, 0);
decoder.start();

ByteBuffer[] inputBuffers = decoder.getInputBuffers();
int inputIndex = decoder.dequeueInputBuffer(10000);

if (inputIndex >= 0) {
    ByteBuffer buffer = inputBuffers[inputIndex];
    buffer.clear();
    buffer.put(nalData);
    decoder.queueInputBuffer(inputIndex, 0, nalData.length, pts, 0);
}

Android에서 MediaCodec은 픽셀 버퍼 대신 출력에 Surface를 사용하여 GPU와 CPU 간의 데이터 복사를 최소화합니다. 디코더는 코덱 유형에 따라 자동으로 하드웨어 블록(OMX 구성 요소)을 선택합니다. H.264의 경우 OMX.google.h264.decoder가 사용되며, 제조업체의 구현에 따라 하드웨어 또는 소프트웨어일 수 있습니다.

모바일 앱용 디코더 선택 방법

디코딩 전략의 선택은 애플리케이션의 대상 사용자, 지원 형식 및 성능 요구 사항에 따라 달라집니다. 최적의 솔루션에는 주요 형식(H.264, H.265)의 하드웨어 디코딩과 희귀 코덱용 소프트웨어 폴백을 결합한 하이브리드 접근 방식이 포함되는 경우가 많습니다.

우선순위 기반 선택 전략

애플리케이션이 최대 호환성을 목표로 하는 경우 모든 장치에서 하드웨어 디코딩이 보장되는 H.264를 사용합니다. 비디오 스트리밍 서비스의 경우 2016년 이후 장치에서 하드웨어 지원이 있는 H.265가 적합합니다. AV1은 대역폭 절약이 중요한 서비스에 적합합니다. YouTube, Netflix 및 기타 대형 플랫폼은 품질을 유지하면서 CDN 비용을 줄이기 위해 AV1을 적극적으로 채택하고 있습니다.

중요한 매개변수는 디코더의 버퍼 크기입니다. 하드웨어 디코더는 고정 버퍼 풀(일반적으로 4~16프레임)을 가지고 있습니다. 높은 비트레이트 스트림 재생 시 버퍼가 오버플로되어 프레임 드롭이 발생할 수 있습니다. MediaCodec은 특정 장치의 실제 디코더 성능을 확인하는 getOutputFrameRate 메서드를 제공하며, VideoToolbox는 kVTDecodeFrame_EnableAsynchronousDecompression을 통해 실시간 우선순위를 제어할 수 있습니다.

열 스로틀링도 또 다른 요소입니다. 장시간 4K HDR 비디오 재생 시 하드웨어 디코딩도 장치를 가열할 수 있습니다. iOS의 ProcessInfo 및 Android의 BatteryManager를 통해 온도를 모니터링하고 과열 시 품질이나 스트림 해상도를 낮추는 것이 좋습니다. 이는 긴 시청 세션이 있는 게임 및 스트리밍 애플리케이션에서 특히 중요합니다.