Апаратне декодування: що це, принцип роботи та переваги

Що таке апаратне декодування?

Hardware decoding — це процес декомпресії медіаданих, який виконується не на універсальному CPU, а на спеціалізованих інтегральних схемах, інтегрованих у систему-на-чипі (SoC). Такі блоки називаються відеодекодерами або VPU (Video Processing Unit) і є ASIC-прискорювачами, оптимізованими під конкретні алгоритми стиснення.

Сучасні мобільні SoC містять окремі апаратні блоки для кожного популярного кодека. Наприклад, чип Apple A17 Pro включає декодери для H.264, H.265, VP9, AV1 та ProRes. Кожен блок являє собою завершений конвеєр обробки, здатний приймати стиснутий бітовий потік на вході та видавати готові декодовані кадри у форматі YUV або BGRA на виході без участі CPU.

Апаратне декодування стало стандартом у мобільній індустрії з 2012–2013 років, коли Qualcomm Snapdragon 800 та Apple A7 вперше включили виділені блоки декодування H.264. З тих пір технологія еволюціонувала від підтримки одного формату до універсальних мультиформатних блоків, здатних декодувати кілька потоків одночасно — наприклад, для роботи PiP з окремим відеопотоком.

Як працює апаратне декодування?

Процес апаратного декодування кардинально відрізняється від програмного. Замість послідовного виконання інструкцій CPU, апаратний блок реалізує фізичні схеми для кожного етапу декомпресії: ентропійне декодування, зворотне квантування, зворотне DCT та компенсацію руху.

Архітектура апаратного декодера

Типовий апаратний декодер складається з кількох ступенів конвеєра. Перша ступінь — ентропійний декодер, реалізований у вигляді скінченного автомата (FSM) для CABAC або CAVLC. На відміну від програмної реалізації, де кожен біт обробляється умовними переходами, апаратний CABAC використовує паралельні схеми передбачення контексту, що дозволяє обробляти до 2–3 біт за такт замість одного.

Друга ступінь — блок зворотного DCT. Програмне DCT вимагає циклів множення-накопичення на CPU. Апаратна реалізація використовує матричний множник, який обчислює всі 64 коефіцієнти блоку 8x8 за один такт. Апаратне зворотне DCT працює на частоті 400–600 МГц і обробляє до 4 мільйонів макроблоків за секунду, що достатньо для декодування 8K-відео в реальному часі.

Третя ступінь — модуль компенсації руху (MC). Паралельно зі зворотним DCT апаратний блок отримує вектори руху з бітового потоку та витягує опорні області з буфера декодованих кадрів. Буфер DPB (Decoded Picture Buffer) зберігає до 16 опорних кадрів, доступ до яких здійснюється через спеціалізовану кеш-пам'ять з низькою затримкою. Сучасні декодери використовують передбачення з адаптивним згладжуванням та субпіксельною інтерполяцією, що критично важливо для H.265 та AV1.

Взаємодія з системою

Управління апаратним декодером відбувається через DMA-контролер. Додаток передає декодеру вказівник на стиснуті дані в спільній пам'яті, а декодер самостійно читає бітовий потік через прямий доступ до пам'яті. Після завершення декодування кадру переривання сповіщає драйвер, і готовий кадр стає доступним у вихідному пулі буферів. Такий механізм повністю виключає завантаження CPU на етапі обробки даних — процесор лише ініціює декодування та отримує готовий результат.

VideoToolbox та MediaCodec: порівняння платформ

Обидві мобільні платформи надають нативні API для апаратного декодування, але з різними підходами до управління буферами та життєвим циклом декодера. VideoToolbox на iOS тісно інтегрований з Metal для виведення на екран, а MediaCodec на Android використовує Surface для прямого рендерингу.

VideoToolbox — фреймворк для апаратного декодування на iOS та macOS. Він використовує модель асинхронного декодування: VTDecompressionSessionDecodeFrame повертається негайно, а готові кадри надходять через callback на окремій черзі. VideoToolbox автоматично керує пулом піксельних буферів (CVPixelBufferPool) і може перевикористовувати звільнені буфери для нових кадрів. Для HDR-відео VideoToolbox підтримує кольорові простори ITU-R BT.2020 та PQ/HLG EOTF.

MediaCodec використовує синхронну модель з чергами вхідних та вихідних буферів. Додаток циклічно викликає dequeueInputBuffer для відправлення стиснутих даних та dequeueOutputBuffer для отримання декодованого результату. Такий підхід дає розробнику повний контроль над темпом декодування, що важливо для синхронізації аудіо та відео. Для виведення на екран MediaCodec приймає Surface, що дозволяє декодувати безпосередньо в GPU без копіювання через CPU.

Переваги апаратного декодування

Апаратне декодування дає три ключові переваги перед програмним: енергоефективність, продуктивність та стабільність. Кожна з них критично важлива для мобільних пристроїв з обмеженими ресурсами батареї та термальними обмеженнями.

Енергоефективність

Головна перевага апаратного декодування — радикально нижче енергоспоживання. Типовий апаратний декодер H.264/H.265 споживає 0,2–0,5 Вт при декодуванні 1080p-відео в реальному часі. Для порівняння, програмне декодування того ж потоку на CPU споживає 1,5–4 Вт залежно від архітектури процесора. Різниця в 5–10 разів безпосередньо впливає на час автономної роботи: при перегляді відео апаратне декодування дозволяє дивитися фільми 10–15 годин проти 2–4 годин при програмному декодуванні на CPU.

Енергоефективність досягається за рахунок вузької спеціалізації. На відміну від CPU, який виконує широкий спектр інструкцій та має складну логіку керування, апаратний декодер містить лише схеми, необхідні для конкретного алгоритму. Тактова частота таких блоків становить 200–600 МГц проти 2–3 ГГц у CPU, що знижує динамічне енергоспоживання пропорційно квадрату напруги.

Продуктивність та тепловиділення

Апаратне декодування забезпечує гарантовану частоту кадрів навіть для високих роздільностей. Завдяки конвеєрній архітектурі, апаратний блок може одночасно обробляти кілька етапів декомпресії: поки один модуль виконує ентропійне декодування для наступного макроблока, інший вже застосовує зворотне DCT до поточного. Такий паралелізм недосяжний на CPU, де кожен етап — це послідовна операція.

Тепловиділення апаратного декодера значно нижче: типовий блок розсіює 0,3–0,8 Вт тепла проти 2–6 Вт у CPU при програмному декодуванні 4K-відео. Це означає, що пристрій не перегрівається навіть при тривалому перегляді, троттлінг не настає, і користувач отримує стабільні 60 FPS без просадок. Температура корпусу при апаратному декодуванні зазвичай на 5–10 градусів нижча, ніж при програмному, що особливо важливо для планшетів без активного охолодження.

Приклади коду апаратного декодування

Розглянемо практичну реалізацію апаратного декодування з обробкою колбеків на iOS через VideoToolbox та повний pipeline на Android через MediaCodec.

Повний приклад апаратного декодування на 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 вмикає асинхронний режим — додаток не блокується під час декодування, а отримує кадри через callback. Для H.264 необхідно попередньо створити format description з SPS/PPS NAL-одиниць через CMVideoFormatDescriptionCreateFromH264ParameterSets.

Апаратне декодування на Android з виведенням на Surface

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 створює MediaCodec з прив'язкою до Surface, що забезпечує прямий вивід на екран без копіювання даних через CPU. Параметр mimeType використовує константи MediaFormat: video/avc для H.264, video/hevc для H.265, video/av01 для AV1. Метод dequeueInputBuffer очікує вільний вхідний буфер з таймаутом; якщо буфер не доступний — пропускається поточний кадр, що запобігає переповненню черги при нерівномірному бітрейті.

Коли вибирати апаратне декодування

Апаратне декодування — оптимальний вибір для більшості production-сценаріїв, але не універсальне рішення. Розуміння меж застосовності допомагає уникнути ситуацій, коли відсутність апаратної підтримки кодека ламає користувацький досвід.

Сценарії обов'язкового використання

Апаратне декодування обов'язкове в трьох випадках: тривале відтворення відео (більше 30 хвилин), декодування 4K-контенту, та будь-який додаток, орієнтований на максимальний час автономної роботи. Стрімінгові сервіси (Netflix, YouTube, Twitch) використовують виключно апаратне декодування, оскільки програмне не може гарантувати стабільне відтворення при високому бітрейті та великій роздільності. Для цих сервісів критична підтримка DRM (FairPlay, Widevine), яка доступна лише через апаратний блок, що забезпечує захищений pipeline від декодера до виведення на екран.

Для ігор з інтегрованим відео (кат-сцени, реклама, внутрішньоігрові ролики) також рекомендується апаратне декодування. Сучасні ігрові рушії, такі як Unity та Unreal Engine, мають вбудовану підтримку VideoToolbox та MediaCodec. Апаратне декодування в іграх звільняє CPU для симуляції фізики, AI противників та обробки введення, що підвищує загальну продуктивність.

Обмеження та fallback

Основне обмеження апаратного декодування — залежність від апаратної підтримки формату. Якщо SoC не містить декодер для AV1 (наприклад, пристрої на Snapdragon 8 Gen 1), додаток повинен передбачити програмний fallback через FFmpeg та dav1d. Аналогічна ситуація з H.265 на старих пристроях та ProRes, який підтримується лише на чипах Apple A13+ для декодування. Рекомендується перед початком відтворення перевіряти доступність апаратного декодера потрібного формату та вибирати стратегію декодування динамічно.

Друге обмеження — кількість одночасних декодуючих сесій. Більшість SoC підтримують 1–2 паралельних апаратних декодери. При спробі відкрити третю сесію API поверне помилку, і додаток повинен переключитися на програмне декодування. Кількість сесій залежить від виробника SoC: чипи Apple дозволяють до 4 сесій декодування H.264 на A17 Pro, а Snapdragon 8 Gen 2 — до 2 для H.265 та до 2 для VP9 сумарно.