Хардверско декодирање: шта је то, принцип рада и предности

Шта је хардверско декодирање?

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 коефицијента 8×8 блока у једном такту. Хардверско инверзно DCT ради на фреквенцији 400–600 MHz и обрађује до 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 W при декодирању 1080p видеа у реалном времену. За поређење, софтверско декодирање истог стрима на CPU-у троши 1,5–4 W у зависности од архитектуре процесора. Разлика од 5–10 пута директно утиче на време рада на батерији: при гледању видеа, хардверско декодирање омогућава гледање филмова 10–15 сати наспрам 2–4 сата код софтверског декодирања на CPU-у.

Енергетска ефикасност се постиже уском специјализацијом. За разлику од CPU-а који извршава широк спектар инструкција и има сложену логику управљања, хардверски декодер садржи само кола неопходна за одређени алгоритам. Тактна фреквенција таквих блокова износи 200–600 MHz наспрам 2–3 GHz код CPU-а, што смањује динамичку потрошњу енергије пропорционално квадрату напона.

Перформансе и ослобађање топлоте

Хардверско декодирање обезбеђује гарантовану фреквенцију оквира чак и за високе резолуције. Захваљујући цевоводној архитектури, хардверски блок може истовремено да обрађује више фаза декомпресије: док један модул врши ентропијско декодирање за следећи макроблок, други већ примењује инверзни DCT на тренутни. Такав паралелизам је недостижан на CPU-у, где је свака фаза секвенцијална операција.

Ослобађање топлоте хардверског декодера је значајно ниже: типичан блок распршује 0,3–0,8 W топлоте наспрам 2–6 W код CPU-а при софтверском декодирању 4K видеа. То значи да се уређај не прегрева чак ни при дуготрајном гледању, тротлинг не наступа, а корисник добија стабилних 60 FPS без падова. Температура кућишта при хардверском декодирању обично је 5–10 степени нижа него при софтверском, што је посебно важно за таблете без активног хлађења.

Примери кода хардверског декодирања

Размотримо практичну имплементацију хардверског декодирања са обрадом повратних позива на iOS-у кроз VideoToolbox и потпуни цевовод на 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-а са асинхроним callback-ом. 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 чека слободан улазни бафер са тајмаутом; ако бафер није доступан — тренутни оквир се прескаче, што спречава препуњавање реда при неравномерном битрејту.

Када одабрати хардверско декодирање

Хардверско декодирање је оптималан избор за већину продукцијских сценарија, али није универзално решење. Разумевање граница применљивости помаже у избегавању ситуација где недостатак хардверске подршке кодека нарушава корисничко искуство.

Сценарији обавезне употребе

Хардверско декодирање је обавезно у три случаја: дуготрајна репродукција видеа (више од 30 минута), декодирање 4K садржаја и свака апликација усмерена на максимално време рада на батерији. Стриминг сервиси (Netflix, YouTube, Twitch) користе искључиво хардверско декодирање, јер софтверско не може да гарантује стабилну репродукцију при високом битрејту и великој резолуцији. За ове сервисе критична је подршка за DRM (FairPlay, Widevine), која је доступна само кроз хардверски блок који обезбеђује заштићени цевовод од декодера до приказа на екрану.

За игре са интегрисаним видеом (кат сцене, рекламе, унутаригре видео записи) такође се препоручује хардверско декодирање. Савремени гејминг мотори, попут 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 укупно.