소프트웨어 디코딩: 개념, 작동 원리 및 사용 사례

소프트웨어 디코딩이란?

Software decoding은 모든 계산 작업이 범용 CPU 코어에서 수행되는 미디어 데이터 압축 해제 방법입니다. 각 코덱에 전용 물리적 블록이 있는 하드웨어 디코딩과 달리, 소프트웨어 디코더는 프로세서 명령을 사용하여 동일한 알고리즘을 실행하는 일반 코드입니다.

소프트웨어 디코더는 특정 CPU 아키텍처에 맞게 최적화된 C/C++로 작성됩니다: 모바일 기기용 ARM NEON SIMD 명령어, 데스크톱용 Intel SSE/AVX. FFmpeg의 libavcodec 라이브러리는 다양한 플랫폼에 맞게 최적화된 수만 줄의 어셈블리 코드를 포함하고 있어, 소프트웨어 디코딩이 강력한 CPU에서 AV1과 같은 무거운 형식에서도 적절한 성능을 달성할 수 있게 합니다.

소프트웨어 디코딩의 주요 장점은 다용도성입니다. 하드웨어 디코더가 4~5개의 주요 형식(H.264, H.265, VP9, AV1)만 지원하는 반면, FFmpeg은 200개 이상의 코덱을 디코딩할 수 있습니다: 최신 AV1 및 H.265부터 구형 Sorenson Spark, RealVideo 및 Motion JPEG까지. 이는 소프트웨어 디코딩을 전문 비디오 편집기, 비디오 감시 시스템 및 특수 플레이어와 같이 비표준 미디어 데이터를 다루는 애플리케이션에 필수적인 도구로 만듭니다.

소프트웨어 디코딩의 작동 방식

소프트웨어 디코딩은 하드웨어 디코딩과 동일한 단계를 따르지만 범용 CPU에서 수행됩니다. 각 단계는 매크로블록 또는 프레임마다 순차적으로 호출되는 함수로 구현됩니다. 주요 차이점은 유연성입니다: 개발자는 파이프라인을 수정하고 디코딩 단계 사이에 필터와 후처리를 추가할 수 있습니다.

소프트웨어 디코더 아키텍처

일반적인 소프트웨어 디코더는 개별 알고리즘 단계를 구현하는 모듈로 구성됩니다. 엔트로피 디코딩 모듈은 비트스트림을 읽고 양자화된 DCT 계수를 복원합니다. H.264의 경우, 이 모듈은 CABAC(컨텍스트 적응형 이진 산술 코딩)를 구현합니다 — 조건부 분기가 있는 복잡한 알고리즘으로 하드웨어 가속이 어렵지만 우수한 분기 예측기가 있는 CPU에서 효율적으로 실행됩니다.

역양자화 모듈은 계수에 양자화 단계를 곱하고, 역 DCT 모듈은 이산 코사인 변환을 적용합니다. 역 DCT의 소프트웨어 구현은 빠른 Chen 알고리즘 또는 Loeffler 알고리즘을 사용하여 8x8 블록에 대한 곱셈-누적 연산 수를 4096에서 256으로 줄입니다. NEON SIMD 명령어(ARM) 또는 SSE(x86)는 명령어당 4~8개의 계수를 처리할 수 있어 스칼라 코드보다 4~8배의 속도 향상을 제공합니다.

움직임 보상 모듈이 가장 메모리를 많이 사용합니다. 움직임 벡터에 따라 참조 프레임에서 영역을 추출하고 서브픽셀 보간을 적용합니다. H.265의 경우 보간 정밀도가 1/8 픽셀에 도달하므로 휘도에는 8탭 FIR 필터, 색차에는 4탭이 필요합니다. 소프트웨어 구현은 캐시에서 많은 양의 참조 프레임 데이터를 로드해야 하므로, CPU에서 고해상도 디코딩 시 움직임 보상이 병목 현상이 됩니다.

모바일 CPU에서의 디코딩 특징

Apple A17 또는 Qualcomm Snapdragon 8 Gen 2와 같은 최신 모바일 프로세서는 프레임 드롭 없이 1080p H.264의 소프트웨어 디코딩에 충분한 성능을 가진 6~8개의 코어를 갖추고 있습니다. 그러나 4K 콘텐츠, 특히 H.265 및 AV1 형식의 경우 CPU에서의 소프트웨어 디코딩이 어려울 수 있습니다: 모든 코어의 일반적인 부하가 70~90%에 도달하여 멀티태스킹에 중요합니다. 빅 코어(Apple Performance, Qualcomm Kryo Prime)는 소형 에너지 효율 코어보다 약 4~5배의 성능을 제공하지만 비례적으로 더 많은 전력을 소비합니다.

인기 있는 소프트웨어 디코더

소프트웨어 디코더 시장에는 각자의 틈새에 맞게 최적화된 여러 주요 라이브러리가 있습니다. 디코더 선택은 필요한 형식, 플랫폼 및 라이선스 제약 조건에 따라 달라집니다.

FFmpeg / libavcodec

FFmpeg은 업계에서 소프트웨어 디코딩의 사실상 표준입니다. libavcodec 라이브러리에는 모든 주요 코덱과 대부분의 희귀 코덱에 대한 디코더가 포함되어 있으며, 모든 컨테이너(MP4, MKV, AVI, MOV, WebM)를 지원하고 모든 플랫폼에서 실행됩니다. FFmpeg은 LGPL/GPL에 따라 라이선스가 부여되므로 상업적 사용을 위한 라이선스 조건을 준수해야 합니다. 모바일 기기에서 FFmpeg은 래퍼를 통해 사용됩니다: iOS 및 Android용 ffmpeg-kit, React Native용 mobile-ffmpeg.

Dav1d — 최적화된 AV1 디코더

Dav1d는 VideoLAN(VLC 개발자)의 소프트웨어 AV1 디코더로, SIMD 최적화와 함께 C로 작성되었습니다. 주요 목표는 하드웨어 지원 없이 CPU에서 AV1을 가능한 가장 빠르게 소프트웨어 디코딩하는 것입니다. Dav1d는 공격적인 최적화(수동 캐시 관리, 후처리 필터용 JIT 컴파일, 중요한 함수의 벡터화) 덕분에 Alliance for Open Media의 참조 libaom 디코더보다 30~50% 빠릅니다.

모바일 기기에서 dav1d는 플래그십 SoC(Apple A16+, Snapdragon 8 Gen 2+)에서 1080p AV1을 실시간으로 디코딩할 수 있지만, 4K에는 강력한 CPU가 필요합니다. 예를 들어, Apple M1에서 소프트웨어 dav1d는 4K AV1에 대해 약 60FPS에 도달하는 반면, Snapdragon 8 Gen 2에서는 약 35FPS에 도달합니다. 모바일 기기에서 안정적인 4K AV1 재생을 위해서는 여전히 하드웨어 지원이 권장됩니다.

소프트웨어와 하드웨어 디코딩 비교

소프트웨어와 하드웨어 디코딩 사이의 선택은 호환성과 효율성 간의 절충입니다. 아래 표는 주요 특성에 대한 자세한 비교를 제공합니다.

소프트웨어 디코딩은 최대의 유연성을 제공합니다: 개발자는 알고리즘을 수정하고, 사용자 정의 필터를 추가하고, 자체 처리 파이프라인을 구현할 수 있습니다. 예를 들어, 비디오 편집 애플리케이션에서는 각 디코딩 단계를 색상 보정 또는 효과 오버레이를 위해 GPU로 리디렉션할 수 있습니다 — 이는 디코딩에 대한 소프트웨어 제어가 있을 때만 가능합니다.

그러나 유연성의 대가는 전력 소비입니다. 3000~5000mAh 배터리를 장착한 모바일 기기의 경우, 지속적인 소프트웨어 디코딩은 시청 시간을 10~15시간(하드웨어)에서 2~4시간으로 단축시킵니다. 45~50도까지의 CPU 가열은 스로틀링(과열 방지를 위한 프로세서 주파수 감소)을 유발하여 프레임 드롭과 사용자 경험 저하를 초래할 수 있습니다.

소프트웨어 디코딩 코드 예제

두 모바일 플랫폼에서 소프트웨어 디코딩의 실제 구현을 살펴보겠습니다. iOS에서는 FFmpeg을 통해 소프트웨어 디코딩이 사용되고, Android에서는 Java/Kotlin 래퍼와 함께 동일한 라이브러리를 통해 사용됩니다.

C언어에서 FFmpeg을 사용한 소프트웨어 디코딩

extern "C" {
    #include <libavcodec/avcodec.h>
    #include <libavformat/avformat.h>
    #include <libswscale/swscale.h>
}

class SoftwareDecoder {
    AVCodecContext* codecCtx;
    
public:
    bool init(const char* filename) {
        AVFormatContext* fmtCtx = nullptr;
        avformat_open_input(&fmtCtx, filename, nullptr, nullptr);
        avformat_find_stream_info(fmtCtx, nullptr);
        
        int videoStream = av_find_best_stream(
            fmtCtx, AVMEDIA_TYPE_VIDEO, -1, -1, nullptr, 0
        );
        
        AVCodec* decoder = avcodec_find_decoder(
            fmtCtx->streams[videoStream]->codecpar->codec_id
        );
        
        codecCtx = avcodec_alloc_context3(decoder);
        avcodec_parameters_to_context(codecCtx,
            fmtCtx->streams[videoStream]->codecpar);
        avcodec_open2(codecCtx, decoder, nullptr);
        return true;
    }
    
    AVFrame* decodePacket(AVPacket* packet) {
        avcodec_send_packet(codecCtx, packet);
        AVFrame* frame = av_frame_alloc();
        int ret = avcodec_receive_frame(codecCtx, frame);
        return (ret >= 0) ? frame : nullptr;
    }
};

이 코드는 소프트웨어 디코딩을 위한 최소한의 FFmpeg 파이프라인을 보여줍니다. avformat_open_input은 파일을 열고 컨테이너 형식을 결정하며, avcodec_find_decoder는 모든 코덱에 적합한 디코더를 자동으로 찾습니다. decodePacket 메서드는 새로운 API(avcodec_send_packet / avcodec_receive_frame)를 사용하며, 실시간 애플리케이션을 위해 AV_CODEC_FLAG_LOW_DELAY 플래그를 활성화한 멀티스레드 디코딩을 지원합니다.

mobile-ffmpeg을 사용한 Kotlin에서의 소프트웨어 디코딩

class SoftwareDecoder(private val context: Context) {
    fun decodeVideo(inputPath: String, outputFolder: String) {
        val cmd = "-i $inputPath -vf fps=1 $outputFolder/frame_%04d.jpg"
        FFmpegExecutor(context).executeCommand(cmd) { rc ->
            Log.d("Decoder", "Finished with rc: $rc")
        }
    }
    
    fun getFrameCount(filePath: String): Int {
        val probe = MediaMetadataRetriever()
        probe.setDataSource(filePath)
        val duration = probe.extractMetadata(
            MediaMetadataRetriever.METADATA_KEY_DURATION
        )?.toIntOrNull() ?: 0
        val fps = probe.extractMetadata(
            MediaMetadataRetriever.METADATA_KEY_VIDEO_FRAME_COUNT
        )?.toIntOrNull() ?: 0
        probe.release()
        return fps
    }
}

Kotlin 예제는 비디오에서 초당 한 프레임을 추출하기 위해 FFmpegExecutor를 사용합니다. -vf fps=1 매개변수는 60프레임 중 59프레임을 건너뛰는 필터를 생성하여 CPU 부하를 줄입니다. 이 접근 방식은 모바일 애플리케이션에서 미리보기 및 플레이스홀더를 만드는 데 유용합니다. 실시간 소프트웨어 디코딩을 위해서는 JNI를 통해 직접 저수준 libavcodec API를 사용하는 것이 좋습니다.

dav1d를 사용한 소프트웨어 AV1 디코딩

#include <dav1d/dav1d.h>

int decode_av1_frame(const uint8_t* data, size_t size) {
    Dav1dContext* ctx = nullptr;
    Dav1dSettings settings = { 0 };
    dav1d_default_settings(&settings);
    settings.n_threads = 4;
    dav1d_open(&ctx, &settings);
    
    Dav1dData dav1d_data = { 0 };
    dav1d_data_wrap(&dav1d_data, data, size, nullptr, nullptr);
    
    Dav1dPicture pic = { 0 };
    if (dav1d_send_data(ctx, &dav1d_data) == 0) {
        dav1d_get_picture(ctx, &pic);
    }
    
    dav1d_close(&ctx);
    return pic.p.w;
}

Dav1d는 최소한의 API를 제공합니다: dav1d_open은 지정된 스레드 수로 디코더 컨텍스트를 생성하고, dav1d_send_data는 압축된 비트스트림을 받아들이며, dav1d_get_picture는 YUV420 형식으로 디코딩된 프레임을 반환합니다. 모바일 기기의 경우 최적의 스레드 수(n_threads)는 성능 CPU 코어 수에서 1을 뺀 값으로, UI 스레드에 리소스를 남겨둡니다. Dav1d는 메모리 관리 및 GPU로 프레임 전송 시 불필요한 복사를 방지하기 위해 Dav1dPicAllocator도 지원합니다.

소프트웨어 디코딩을 사용해야 하는 경우

더 높은 전력 소비에도 불구하고, 하드웨어 디코딩이 필요한 기능을 제공할 수 없는 여러 시나리오에서 소프트웨어 디코딩은 필수적입니다. 이러한 시나리오를 이해하면 개발자가 아키텍처 결정을 내리는 데 도움이 됩니다.

희귀 및 레거시 형식

하드웨어 디코더는 최신 형식만 지원합니다. 애플리케이션이 아카이브 녹화, 비디오 감시(MJPEG, H.263), 전문 코덱(ProRes, DNxHD, CineForm) 또는 타사 소스의 콘텐츠로 작업하는 경우 — FFmpeg을 통한 소프트웨어 디코딩이 유일한 옵션입니다. ProRes는 하드웨어 지원이 있는 Apple A13+ 칩을 제외한 모든 기기에서 소프트웨어로만 디코딩됩니다. H.263의 경우 최신 SoC에는 하드웨어 지원이 없으며 소프트웨어 디코딩만 가능합니다.

사용자 정의 후처리

소프트웨어 디코딩은 각 프레임 처리 단계에 대한 완전한 액세스를 제공합니다. 이는 출력 전에 디코딩된 데이터에 직접 필터(블러, 노이즈 감소, 샤프닝)를 적용해야 하는 애플리케이션에 중요합니다. FFmpeg 필터를 사용하면 복잡한 체인을 구축할 수 있습니다: 디코딩 -> 색상 보정 -> 크기 조정 -> 자막 오버레이 -> 인코딩 — 모든 작업이 단일 라이브러리 내에서 다양한 API 간에 데이터를 전송하지 않고 수행됩니다.

하드웨어 지원이 없는 경우 폴백

권장되는 미디어 플레이어 아키텍처는 하이브리드입니다: 하드웨어 디코딩을 기본으로, 소프트웨어 디코딩을 폴백으로 사용합니다. 재생 전에 애플리케이션은 지정된 코덱에 대한 하드웨어 디코더의 가용성을 확인합니다. 디코더가 없으면 FFmpeg을 통해 소프트웨어 디코딩이 시작됩니다. 이 전략은 주요 형식의 성능을 희생하지 않으면서 최대 호환성을 보장합니다. 하드웨어 지원은 동일한 모델의 기기에서도 SoC 개정판에 따라 다를 수 있으므로 가용성 확인은 시작할 때마다 수행해야 합니다.