Hardwarové dekódování: co to je, princip fungování a výhody

Co je hardwarové dekódování?

Hardware decoding — je proces dekomprese multimediálních dat prováděný nikoli na univerzálním CPU, ale na specializovaných integrovaných obvodech integrovaných do systému-na-čipu (SoC). Takové bloky se nazývají videodekodéry nebo VPU (Video Processing Unit) a představují ASIC akcelerátory optimalizované pro konkrétní kompresní algoritmy.

Moderní mobilní SoC obsahují samostatné hardwarové bloky pro každý populární kodek. Například čip Apple A17 Pro zahrnuje dekodéry pro H.264, H.265, VP9, AV1 a ProRes. Každý blok představuje kompletní zpracovatelské potrubí schopné přijmout komprimovaný bitový tok na vstupu a dodat hotové dekódované snímky ve formátu YUV nebo BGRA na výstupu bez účasti CPU.

Hardwarové dekódování se stalo standardem v mobilním průmyslu v letech 2012–2013, kdy Qualcomm Snapdragon 800 a Apple A7 poprvé zahrnovaly vyhrazené bloky pro dekódování H.264. Od té doby se technologie vyvinula od podpory jednoho formátu k univerzálním víceformátovým blokům schopným dekódovat více toků současně — například pro práci PiP s odděleným videotokem.

Jak funguje hardwarové dekódování?

Proces hardwarového dekódování se zásadně liší od softwarového. Místo sekvenčního provádění instrukcí CPU implementuje hardwarový blok fyzické obvody pro každou fázi dekomprese: entropické dekódování, inverzní kvantizaci, inverzní DCT a kompenzaci pohybu.

Architektura hardwarového dekodéru

Typický hardwarový dekodér se skládá z několika stupňů potrubí. První stupeň — entropický dekodér, implementovaný jako konečný automat (FSM) pro CABAC nebo CAVLC. Na rozdíl od softwarové implementace, kde je každý bit zpracováván podmíněnými skoky, používá hardwarový CABAC paralelní obvody pro predikci kontextu, což umožňuje zpracovávat 2–3 bity za takt místo jednoho.

Druhý stupeň — blok inverzního DCT. Softwarové DCT vyžaduje cykly násobení-akumulace na CPU. Hardwarová implementace používá maticový násobič, který vypočítá všech 64 koeficientů bloku 8×8 v jednom taktu. Hardwarové inverzní DCT pracuje na frekvenci 400–600 MHz a zpracovává až 4 miliony makrobloků za sekundu, což je dostatečné pro dekódování videa 8K v reálném čase.

Třetí stupeň — modul kompenzace pohybu (MC). Paralelně s inverzním DCT přijímá hardwarový blok vektory pohybu z bitového toku a extrahuje referenční oblasti z bufferu dekódovaných snímků. Buffer DPB (Decoded Picture Buffer) ukládá až 16 referenčních snímků, přístup k nimž je realizován prostřednictvím specializované vyrovnávací paměti s nízkou latencí. Moderní dekodéry používají predikci s adaptivním vyhlazováním a subpixelovou interpolací, což je kritické pro H.265 a AV1.

Interakce se systémem

Řízení hardwarového dekodéru probíhá prostřednictvím řadiče DMA. Aplikace předá dekodéru ukazatel na komprimovaná data ve sdílené paměti a dekodér samostatně čte bitový tok prostřednictvím přímého přístupu do paměti. Po dokončení dekódování snímku přerušení informuje ovladač a hotový snímek je k dispozici ve fondu výstupních bufferů. Tento mechanismus zcela eliminuje zatížení CPU ve fázi zpracování dat — procesor pouze iniciuje dekódování a obdrží hotový výsledek.

VideoToolbox a MediaCodec: srovnání platforem

Obě mobilní platformy poskytují nativní API pro hardwarové dekódování, ale s odlišnými přístupy ke správě bufferů a životnímu cyklu dekodéru. VideoToolbox na iOS je úzce integrován s Metal pro výstup na obrazovku, zatímco MediaCodec na Androidu používá Surface pro přímé vykreslování.

VideoToolbox — framework pro hardwarové dekódování na iOS a macOS. Používá asynchronní model dekódování: volání VTDecompressionSessionDecodeFrame se okamžitě vrátí a hotové snímky přicházejí prostřednictvím callbacku v samostatné frontě. VideoToolbox automaticky spravuje fond pixelových bufferů (CVPixelBufferPool) a může uvolněné buffery znovu použít pro nové snímky. Pro HDR video podporuje VideoToolbox barevné prostory ITU-R BT.2020 a PQ/HLG EOTF.

MediaCodec používá synchronní model s frontami vstupních a výstupních bufferů. Aplikace cyklicky volá dequeueInputBuffer pro odeslání komprimovaných dat a dequeueOutputBuffer pro získání dekódovaného výsledku. Tento přístup dává vývojáři plnou kontrolu nad rychlostí dekódování, což je důležité pro synchronizaci zvuku a videa. Pro výstup na obrazovku MediaCodec přijímá Surface, což umožňuje přímé dekódování na GPU bez kopírování přes CPU.

Výhody hardwarového dekódování

Hardwarové dekódování poskytuje tři klíčové výhody oproti softwarovému: energetickou účinnost, výkon a stabilitu. Každá z nich je kritická pro mobilní zařízení s omezenými bateriovými zdroji a tepelnými omezeními.

Energetická účinnost

Hlavní výhoda hardwarového dekódování — radikálně nižší spotřeba energie. Typický hardwarový dekodér H.264/H.265 spotřebuje 0,2–0,5 W při dekódování videa 1080p v reálném čase. Pro srovnání, softwarové dekódování stejného toku na CPU spotřebuje 1,5–4 W v závislosti na architektuře procesoru. Rozdíl 5–10krát přímo ovlivňuje výdrž baterie: při sledování videa umožňuje hardwarové dekódování sledovat filmy 10–15 hodin oproti 2–4 hodinám při softwarovém dekódování na CPU.

Energetické účinnosti je dosaženo úzkou specializací. Na rozdíl od CPU, který provádí širokou škálu instrukcí a má složitou řídicí logiku, obsahuje hardwarový dekodér pouze obvody potřebné pro konkrétní algoritmus. Frekvence těchto bloků je 200–600 MHz oproti 2–3 GHz CPU, což snižuje dynamickou spotřebu energie úměrně druhé mocnině napětí.

Výkon a tepelné vyzařování

Hardwarové dekódování zajišťuje garantovanou snímkovou frekvenci i pro vysoká rozlišení. Díky architektuře potrubí může hardwarový blok zpracovávat několik fází dekomprese současně: zatímco jeden modul provádí entropické dekódování pro následující makroblok, jiný již aplikuje inverzní DCT na aktuální. Takový paralelismus je na CPU nedosažitelný, kde je každá fáze sekvenční operací.

Tepelné vyzařování hardwarového dekodéru je výrazně nižší: typický blok rozptyluje 0,3–0,8 W tepla oproti 2–6 W CPU při softwarovém dekódování videa 4K. To znamená, že se zařízení nepřehřívá ani při dlouhodobém sledování, nedochází k throttlingu a uživatel získává stabilních 60 FPS bez poklesů. Teplota skříně při hardwarovém dekódování je obvykle o 5–10 stupňů nižší než při softwarovém, což je důležité zejména pro tablety bez aktivního chlazení.

Příklady kódu hardwarového dekódování

Podívejme se na praktickou implementaci hardwarového dekódování se zpracováním callbacků na iOS přes VideoToolbox a kompletní potrubí na Androidu přes MediaCodec.

Kompletní příklad hardwarového dekódování na 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
        )
    }
}

Kód vytváří relaci dekódování VideoToolbox s asynchronním callbackem. VTDecompressionSessionCreate automaticky určuje dostupný hardwarový dekodér na základě předaného CMVideoFormatDescription. Příznak kVTDecodeFrame_EnableAsynchronousDecompression aktivuje asynchronní režim — aplikace není během dekódování blokována, ale přijímá snímky prostřednictvím callbacku. Pro H.264 je třeba předem vytvořit popis formátu z jednotek NAL SPS/PPS pomocí CMVideoFormatDescriptionCreateFromH264ParameterSets.

Hardwarové dekódování na Androidu s výstupem na 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)
        }
    }
}

Kód v Kotlinu vytváří MediaCodec s vazbou na Surface, což zajišťuje přímý výstup na obrazovku bez kopírování dat přes CPU. Parametr mimeType používá konstanty MediaFormat: video/avc pro H.264, video/hevc pro H.265, video/av01 pro AV1. Metoda dequeueInputBuffer čeká na volný vstupní buffer s timeoutem; pokud buffer není k dispozici — aktuální snímek je přeskočen, což zabraňuje přetečení fronty při nerovnoměrném bitrate.

Kdy zvolit hardwarové dekódování

Hardwarové dekódování je optimální volbou pro většinu produkčních scénářů, ale není univerzálním řešením. Pochopení hranic použitelnosti pomáhá vyhnout se situacím, kdy nedostatek hardwarové podpory kodeku kazí uživatelský zážitek.

Scénáře povinného použití

Hardwarové dekódování je povinné ve třech případech: dlouhodobé přehrávání videa (více než 30 minut), dekódování obsahu 4K a jakákoli aplikace zaměřená na maximální výdrž baterie. Streamovací služby (Netflix, YouTube, Twitch) používají výhradně hardwarové dekódování, protože softwarové nemůže zaručit stabilní přehrávání při vysokém bitrate a velkém rozlišení. Pro tyto služby je kritická podpora DRM (FairPlay, Widevine), která je dostupná pouze prostřednictvím hardwarového bloku zajišťujícího chráněné potrubí od dekodéru k zobrazení.

Pro hry s integrovaným videem (cut-scény, reklamy, vnitroherní videa) se také doporučuje hardwarové dekódování. Moderní herní enginy, jako Unity a Unreal Engine, mají vestavěnou podporu pro VideoToolbox a MediaCodec. Hardwarové dekódování ve hrách uvolňuje CPU pro simulaci fyziky, AI protivníků a zpracování vstupu, což zvyšuje celkový výkon.

Omezení a fallback

Hlavní omezení hardwarového dekódování — závislost na hardwarové podpoře formátu. Pokud SoC neobsahuje dekodér pro AV1 (například zařízení na Snapdragon 8 Gen 1), musí aplikace zajistit softwarový fallback přes FFmpeg a dav1d. Podobná situace je s H.265 na starších zařízeních a ProRes, který je podporován pouze na čipech Apple A13+ pro dekódování. Doporučuje se před zahájením přehrávání zkontrolovat dostupnost hardwarového dekodéru požadovaného formátu a dynamicky zvolit strategii dekódování.

Druhé omezení — počet současných dekódovacích relací. Většina SoC podporuje 1–2 paralelní hardwarové dekodéry. Při pokusu o otevření třetí relace API vrátí chybu a aplikace musí přejít na softwarové dekódování. Počet relací závisí na výrobci SoC: čipy Apple povolují až 4 relace dekódování H.264 na A17 Pro a Snapdragon 8 Gen 2 — až 2 pro H.265 a až 2 pro VP9 celkem.