Hardveres dekódolás: mi ez, működési elv és előnyök

Mi a hardveres dekódolás?

Hardware decoding — a médiaadatok dekompressziójának folyamata, amely nem az univerzális CPU-n, hanem a rendszer-chipbe (SoC) integrált speciális integrált áramkörökön történik. Az ilyen blokkokat videódekódereknek vagy VPU-nak (Video Processing Unit) nevezik, és meghatározott tömörítési algoritmusokra optimalizált ASIC-gyorsítók.

A modern mobil SoC-k külön hardverblokkokat tartalmaznak minden népszerű kodekhez. Például az Apple A17 Pro chip dekódereket tartalmaz H.264, H.265, VP9, AV1 és ProRes formátumokhoz. Minden blokk egy teljes feldolgozási csővezetéket alkot, amely képes a tömörített bitfolyamot a bemeneten fogadni és kész dekódolt képkockákat YUV vagy BGRA formátumban a kimeneten szolgáltatni a CPU részvétele nélkül.

A hardveres dekódolás 2012–2013-ban vált szabvánnyá a mobiliparban, amikor a Qualcomm Snapdragon 800 és az Apple A7 először tartalmazott dedikált H.264 dekódoló blokkokat. Azóta a technológia egyetlen formátum támogatásától olyan univerzális, többformátumú blokkokká fejlődött, amelyek egyszerre több folyamot képesek dekódolni — például PiP működéshez külön videófolyammal.

Hogyan működik a hardveres dekódolás?

A hardveres dekódolás folyamata gyökeresen különbözik a szoftverestől. A CPU-utasítások szekvenciális végrehajtása helyett a hardverblokk fizikai áramköröket valósít meg a dekompresszió minden szakaszához: entrópiadekódolás, inverz kvantálás, inverz DCT és mozgáskompenzáció.

A hardveres dekóder architektúrája

Egy tipikus hardveres dekóder több csővezeték-fokozatból áll. Az első fokozat — az entrópiadekóder, amely véges automataként (FSM) van megvalósítva CABAC vagy CAVLC számára. A szoftveres implementációval ellentétben, ahol minden bitet feltételes elágazások dolgoznak fel, a hardveres CABAC párhuzamos kontextus-előrejelző áramköröket használ, lehetővé téve 2–3 bit órajelenkénti feldolgozását egy helyett.

A második fokozat — az inverz DCT blokk. A szoftveres DCT szorzás-akkumulációs ciklusokat igényel a CPU-n. A hardveres megvalósítás egy mátrixszorzót használ, amely a 8×8-as blokk mind a 64 együtthatóját egyetlen órajel alatt számítja ki. A hardveres inverz DCT 400–600 MHz-en működik, és másodpercenként akár 4 millió makroblokkot dolgoz fel, ami elegendő a valós idejű 8K videódekódoláshoz.

A harmadik fokozat — a mozgáskompenzációs (MC) modul. Az inverz DCT-vel párhuzamosan a hardverblokk megkapja a mozgásvektorokat a bitfolyamból, és kivonja a referencia területeket a dekódolt képkockák pufferéből. A DPB puffer (Decoded Picture Buffer) akár 16 referenciakockát tárol, amelyekhez speciális, alacsony késleltetésű gyorsítótáron keresztül lehet hozzáférni. A modern dekóderek adaptív simítással és szubpixel interpolációval történő előrejelzést használnak, ami kritikus a H.265 és AV1 esetében.

Rendszerrel való interakció

A hardveres dekóder vezérlése a DMA-vezérlőn keresztül történik. Az alkalmazás egy mutatót ad át a dekódernek a megosztott memóriában lévő tömörített adatokra, a dekóder pedig önállóan olvassa a bitfolyamot közvetlen memóriaelérésen keresztül. A képkocka dekódolásának befejezése után egy megszakítás értesíti az illesztőprogramot, és a kész képkocka elérhetővé válik a kimeneti pufferpoolban. Ez a mechanizmus teljesen kiküszöböli a CPU terhelését az adatfeldolgozás szakaszában — a processzor csak elindítja a dekódolást és megkapja a kész eredményt.

VideoToolbox és MediaCodec: platformok összehasonlítása

Mindkét mobil platform natív API-t biztosít hardveres dekódoláshoz, de eltérő megközelítéssel a pufferek kezelésében és a dekóder életciklusában. A VideoToolbox iOS-ben szorosan integrálva van a Metallel a képernyőre történő kiadáshoz, míg a MediaCodec Androidon a Surface-t használja közvetlen rendereléshez.

VideoToolbox — keretrendszer hardveres dekódoláshoz iOS-en és macOS-en. Aszinkron dekódolási modellt használ: a VTDecompressionSessionDecodeFrame hívás azonnal visszatér, a kész képkockák pedig callback-en keresztül érkeznek egy külön várakozási sorban. A VideoToolbox automatikusan kezeli a pixelpuffer poolt (CVPixelBufferPool), és újra felhasználhatja a felszabadított puffereket új képkockákhoz. HDR videó esetén a VideoToolbox támogatja az ITU-R BT.2020 színtereket és a PQ/HLG EOTF-et.

MediaCodec szinkron modellt használ bemeneti és kimeneti puffer sorokkal. Az alkalmazás ciklikusan hívja a dequeueInputBuffer-t a tömörített adatok küldéséhez és a dequeueOutputBuffer-t a dekódolt eredmény lekéréséhez. Ez a megközelítés teljes ellenőrzést ad a fejlesztőnek a dekódolási sebesség felett, ami fontos az audio és video szinkronizálásához. Képernyőre történő kiadáshoz a MediaCodec elfogadja a Surface-t, lehetővé téve a közvetlen dekódolást a GPU-n a CPU-n keresztüli másolás nélkül.

A hardveres dekódolás előnyei

A hardveres dekódolás három kulcsfontosságú előnyt kínál a szoftveressel szemben: energiahatékonyság, teljesítmény és stabilitás. Mindegyik kritikus a korlátozott akkumulátor-erőforrásokkal és termikus korlátokkal rendelkező mobil eszközök számára.

Energiahatékonyság

A hardveres dekódolás fő előnye — radikálisan alacsonyabb energiafogyasztás. Egy tipikus hardveres H.264/H.265 dekóder 0,2–0,5 W-ot fogyaszt 1080p videó valós idejű dekódolásakor. Összehasonlításképpen: ugyanazon folyam szoftveres dekódolása a CPU-n 1,5–4 W-ot fogyaszt a processzor architektúrájától függően. Az 5–10-szeres különbség közvetlenül befolyásolja az akkumulátor élettartamát: videónézéskor a hardveres dekódolás 10–15 órás filmnézést tesz lehetővé, szemben a CPU-n történő szoftveres dekódolás 2–4 órájával.

Az energiahatékonyság szűk specializációval érhető el. Ellentétben a CPU-val, amely az utasítások széles skáláját hajtja végre és összetett vezérlési logikával rendelkezik, a hardveres dekóder csak az adott algoritmushoz szükséges áramköröket tartalmazza. Az órajel frekvenciája az ilyen blokkoknak 200–600 MHz, szemben a CPU 2–3 GHz-ével, ami a dinamikus energiafogyasztást a feszültség négyzetével arányosan csökkenti.

Teljesítmény és hőtermelés

A hardveres dekódolás garantált képkockasebességet biztosít még nagy felbontások esetén is. A csővezeték-architektúrának köszönhetően a hardverblokk egyszerre több dekompressziós szakaszt képes feldolgozni: míg az egyik modul entrópiadekódolást végez a következő makroblokkhoz, addig a másik már az inverz DCT-t alkalmazza az aktuálisra. Ez a párhuzamosság elérhetetlen a CPU-n, ahol minden szakasz szekvenciális művelet.

A hardveres dekóder hőtermelése jelentősen alacsonyabb: egy tipikus blokk 0,3–0,8 W hőt disszipál, szemben a CPU 2–6 W-jával a 4K videó szoftveres dekódolásakor. Ez azt jelenti, hogy az eszköz nem melegszik túl még hosszabb nézés során sem, nem következik be throttling, és a felhasználó stabil 60 FPS-t kap csökkenések nélkül. A ház hőmérséklete hardveres dekódolásnál általában 5–10 fokkal alacsonyabb, mint szoftveresnél, ami különösen fontos az aktív hűtés nélküli tabletek esetében.

Hardveres dekódolás kódpéldák

Vizsgáljuk meg a hardveres dekódolás gyakorlati megvalósítását callback feldolgozással iOS-en a VideoToolbox-on keresztül és a teljes csővezetéket Androidon a MediaCodec-en keresztül.

Teljes hardveres dekódolási példa iOS-en

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
        )
    }
}

A kód létrehoz egy VideoToolbox dekódoló munkamenetet aszinkron callback-kel. VTDecompressionSessionCreate automatikusan meghatározza a rendelkezésre álló hardveres dekódert a megadott CMVideoFormatDescription alapján. A kVTDecodeFrame_EnableAsynchronousDecompression zászló aktiválja az aszinkron módot — az alkalmazás nem blokkolódik dekódolás közben, hanem callback-en keresztül kapja a képkockákat. H.264 esetén előzetesen létre kell hozni a formátumleírást az SPS/PPS NAL egységekből a CMVideoFormatDescriptionCreateFromH264ParameterSets segítségével.

Hardveres dekódolás Androidon Surface kimenettel

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)
        }
    }
}

A Kotlin kód egy MediaCodec-et hoz létre Surface-hez kötve, ami közvetlen képernyőre történő kimenetet biztosít adatok CPU-n keresztüli másolása nélkül. A mimeType paraméter a MediaFormat konstansokat használja: video/avc H.264-hez, video/hevc H.265-höz, video/av01 AV1-hez. A dequeueInputBuffer metódus egy szabad bemeneti pufferre vár időkorláttal; ha a puffer nem elérhető — az aktuális képkocka kimarad, megakadályozva a sor túlcsordulását egyenetlen bitrátánál.

Mikor válasszuk a hardveres dekódolást

A hardveres dekódolás az optimális választás a legtöbb termelési forgatókönyvhöz, de nem univerzális megoldás. Az alkalmazhatóság határainak megértése segít elkerülni azokat a helyzeteket, ahol a kodek hardveres támogatásának hiánya rontja a felhasználói élményt.

Kötelező használati forgatókönyvek

A hardveres dekódolás három esetben kötelező: hosszú idejű videolejátszás (több mint 30 perc), 4K tartalom dekódolása, és bármely alkalmazás, amely a maximális akkumulátor-élettartamra törekszik. Streaming szolgáltatások (Netflix, YouTube, Twitch) kizárólag hardveres dekódolást használnak, mivel a szoftveres nem tud stabil lejátszást garantálni magas bitrátánál és nagy felbontásnál. Ezeknél a szolgáltatásoknál kritikus a DRM-támogatás (FairPlay, Widevine), amely csak a hardverblokkon keresztül érhető el, biztosítva a védett csővezetéket a dekódertől a kijelzőig.

Az integrált videót tartalmazó játékokhoz (átvezető jelenetek, reklámok, játékon belüli videók) szintén ajánlott a hardveres dekódolás. A modern játékmotorok, mint a Unity és az Unreal Engine, beépített támogatással rendelkeznek a VideoToolbox és MediaCodec számára. A hardveres dekódolás a játékokban felszabadítja a CPU-t a fizikai szimuláció, az ellenséges AI és a bevitel feldolgozása számára, ami növeli az általános teljesítményt.

Korlátozások és fallback

A hardveres dekódolás fő korlátozása — a formátum hardveres támogatásától való függés. Ha a SoC nem tartalmaz dekódert AV1-hez (például Snapdragon 8 Gen 1 eszközök), az alkalmazásnak szoftveres fallback-et kell biztosítania FFmpeg és dav1d segítségével. Hasonló a helyzet a H.265-tel régebbi eszközökön és a ProRes-szel, amely csak Apple A13+ chipeken támogatott dekódoláshoz. Ajánlott a lejátszás megkezdése előtt ellenőrizni a kívánt formátum hardveres dekódolójának elérhetőségét és dinamikusan kiválasztani a dekódolási stratégiát.

A második korlátozás — az egyidejű dekódoló munkamenetek száma. A legtöbb SoC 1–2 párhuzamos hardveres dekódert támogat. Egy harmadik munkamenet megnyitásának kísérletekor az API hibát ad vissza, és az alkalmazásnak szoftveres dekódolásra kell váltania. A munkamenetek száma a SoC gyártójától függ: az Apple chipek legfeljebb 4 H.264 dekódoló munkamenetet engedélyeznek az A17 Pro-n, a Snapdragon 8 Gen 2 pedig legfeljebb 2-t H.265-höz és legfeljebb 2-t VP9-hez összesen.