Hardware decodering: wat is het, werkingsprincipe en voordelen

Wat is hardware decodering?

Hardware decoding — is het proces van mediadecompressie dat niet op de universele CPU wordt uitgevoerd, maar op gespecialiseerde geïntegreerde schakelingen in de systeem-op-een-chip (SoC). Dergelijke blokken worden videodecoders of VPU (Video Processing Unit) genoemd en zijn ASIC-versnellers geoptimaliseerd voor specifieke compressie-algoritmen.

Moderne mobiele SoC's bevatten aparte hardwareblokken voor elke populaire codec. De Apple A17 Pro-chip bevat bijvoorbeeld decoders voor H.264, H.265, VP9, AV1 en ProRes. Elk blok vormt een complete verwerkingspijplijn die een gecomprimeerde bitstroom kan ontvangen en kant-en-klare gedecodeerde frames in YUV- of BGRA-formaat kan leveren zonder tussenkomst van de CPU.

Hardware decodering werd de standaard in de mobiele industrie rond 2012–2013, toen Qualcomm Snapdragon 800 en Apple A7 voor het eerst speciale H.264-decodeerblokken bevatten. Sindsdien is de technologie geëvolueerd van ondersteuning voor één formaat naar universele multifunctionele blokken die meerdere streams tegelijk kunnen decoderen — bijvoorbeeld voor PiP-werking met een aparte videostream.

Hoe werkt hardware decodering?

Het proces van hardware decodering verschilt fundamenteel van softwarematige decodering. In plaats van het sequentieel uitvoeren van CPU-instructies, implementeert het hardwareblok fysieke schakelingen voor elke decompressiefase: entropiedecodering, inverse kwantisatie, inverse DCT en bewegingscompensatie.

Architectuur van de hardwarematige decoder

Een typische hardwarematige decoder bestaat uit meerdere pijplijntrappen. De eerste trap — de entropiedecoder, geïmplementeerd als een eindige automaat (FSM) voor CABAC of CAVLC. In tegenstelling tot software-implementaties, waar elke bit wordt verwerkt met conditionele sprongen, gebruikt hardware-CABAC parallelle contextvoorspellingsschakelingen, waardoor 2–3 bits per klokcyclus kunnen worden verwerkt in plaats van één.

De tweede trap — het inverse DCT-blok. Software-DCT vereist vermenigvuldigings-accumulatiecycli op de CPU. De hardware-implementatie gebruikt een matrixvermenigvuldiger die alle 64 coëfficiënten van een 8×8-blok in één klokcyclus berekent. Hardwarematige inverse DCT werkt op 400–600 MHz en verwerkt tot 4 miljoen macroblokken per seconde, voldoende voor real-time 8K-videodecodering.

De derde trap — de bewegingscompensatiemodule (MC). Parallel aan de inverse DCT ontvangt het hardwareblok bewegingsvectoren uit de bitstroom en haalt referentiegebieden op uit de buffer van gedecodeerde frames. De DPB-buffer (Decoded Picture Buffer) slaat tot 16 referentieframes op, die worden benaderd via gespecialiseerd cachegeheugen met lage latentie. Moderne decoders gebruiken predictie met adaptieve afvlakking en subpixelinterpolatie, wat cruciaal is voor H.265 en AV1.

Interactie met het systeem

Het beheer van de hardwarematige decoder gebeurt via de DMA-controller. De applicatie geeft de decoder een pointer naar de gecomprimeerde gegevens in het gedeelde geheugen, en de decoder leest zelfstandig de bitstroom via directe geheugentoegang. Na voltooiing van de framedecodering stelt een interrupt de driver op de hoogte, en het voltooide frame wordt beschikbaar in de outputbufferpool. Dit mechanisme elimineert volledig de CPU-belasting tijdens de gegevensverwerking — de processor initieert alleen de decodering en ontvangt het voltooide resultaat.

VideoToolbox en MediaCodec: platformvergelijking

Beide mobiele platforms bieden native API's voor hardware decodering, maar met verschillende benaderingen voor bufferbeheer en de levenscyclus van de decoder. VideoToolbox op iOS is nauw geïntegreerd met Metal voor weergave op het scherm, terwijl MediaCodec op Android Surface gebruikt voor directe rendering.

VideoToolbox — framework voor hardware decodering op iOS en macOS. Het gebruikt een asynchroon decodemodel: de aanroep VTDecompressionSessionDecodeFrame keert onmiddellijk terug, en voltooide frames komen via een callback op een aparte wachtrij. VideoToolbox beheert automatisch de pixelbufferpool (CVPixelBufferPool) en kan vrijgegeven buffers hergebruiken voor nieuwe frames. Voor HDR-video ondersteunt VideoToolbox de kleurruimten ITU-R BT.2020 en PQ/HLG EOTF.

MediaCodec gebruikt een synchroon model met wachtrijen voor invoer- en uitvoerbuffers. De applicatie roept cyclisch dequeueInputBuffer aan om gecomprimeerde gegevens te verzenden en dequeueOutputBuffer om het gedecodeerde resultaat te ontvangen. Deze benadering geeft de ontwikkelaar volledige controle over het decoderingstempo, wat belangrijk is voor audio-video synchronisatie. Voor weergave op het scherm accepteert MediaCodec Surface, waardoor directe decodering op de GPU mogelijk is zonder kopiëren via de CPU.

Voordelen van hardware decodering

Hardware decodering biedt drie belangrijke voordelen ten opzichte van software: energie-efficiëntie, prestaties en stabiliteit. Elk ervan is cruciaal voor mobiele apparaten met beperkte batterijbronnen en thermische beperkingen.

Energie-efficiëntie

Het belangrijkste voordeel van hardware decodering — aanzienlijk lager energieverbruik. Een typische hardwarematige H.264/H.265-decoder verbruikt 0,2–0,5 W bij het decoderen van 1080p-video in real-time. Ter vergelijking: softwarematige decodering van dezelfde stroom op de CPU verbruikt 1,5–4 W, afhankelijk van de processorarchitectuur. Het verschil van 5–10 keer heeft directe invloed op de batterijduur: bij het bekijken van video maakt hardware decodering 10–15 uur films kijken mogelijk tegenover 2–4 uur bij softwarematige decodering op de CPU.

Energie-efficiëntie wordt bereikt door nauwe specialisatie. In tegenstelling tot de CPU, die een breed scala aan instructies uitvoert en complexe besturingslogica heeft, bevat de hardwarematige decoder alleen de schakelingen die nodig zijn voor een specifiek algoritme. De klokfrequentie van dergelijke blokken is 200–600 MHz tegenover 2–3 GHz van de CPU, wat het dynamische energieverbruik proportioneel verlaagt met het kwadraat van de spanning.

Prestaties en warmteontwikkeling

Hardware decodering garandeert een stabiele framesnelheid, zelfs voor hoge resoluties. Dankzij de pijplijnarchitectuur kan het hardwareblok meerdere decompressiefasen tegelijk verwerken: terwijl de ene module entropiedecodering uitvoert voor het volgende macroblok, past een andere al inverse DCT toe op het huidige. Deze parallelliteit is onbereikbaar op de CPU, waar elke fase een sequentiële bewerking is.

De warmteontwikkeling van de hardwarematige decoder is aanzienlijk lager: een typisch blok dissipeert 0,3–0,8 W warmte tegenover 2–6 W van de CPU bij softwarematige 4K-videodecodering. Dit betekent dat het apparaat niet oververhit raakt, zelfs niet bij langdurig kijken, er treedt geen throttling op en de gebruiker krijgt stabiele 60 FPS zonder dalingen. De behuizingstemperatuur bij hardware decodering is meestal 5–10 graden lager dan bij softwarematig, wat vooral belangrijk is voor tablets zonder actieve koeling.

Codevoorbeelden van hardware decodering

Laten we de praktische implementatie van hardware decodering met callback-verwerking op iOS via VideoToolbox en de volledige pijplijn op Android via MediaCodec bekijken.

Volledig voorbeeld van hardware decodering op 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
        )
    }
}

De code maakt een VideoToolbox-decodeersessie met asynchrone callback. VTDecompressionSessionCreate bepaalt automatisch de beschikbare hardwarematige decoder op basis van de doorgegeven CMVideoFormatDescription. De vlag kVTDecodeFrame_EnableAsynchronousDecompression activeert de asynchrone modus — de applicatie wordt niet geblokkeerd tijdens het decoderen, maar ontvangt frames via een callback. Voor H.264 moet vooraf een format description worden gemaakt van SPS/PPS NAL-eenheden via CMVideoFormatDescriptionCreateFromH264ParameterSets.

Hardware decodering op Android met uitvoer naar 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)
        }
    }
}

De Kotlin-code maakt een MediaCodec gekoppeld aan Surface, wat directe uitvoer naar het scherm mogelijk maakt zonder gegevenskopiëring via de CPU. De parameter mimeType gebruikt MediaFormat-constanten: video/avc voor H.264, video/hevc voor H.265, video/av01 voor AV1. De methode dequeueInputBuffer wacht op een vrije invoerbuffer met een time-out; als er geen buffer beschikbaar is — wordt het huidige frame overgeslagen, wat overloop van de wachtrij bij ongelijkmatige bitrate voorkomt.

Wanneer hardware decodering kiezen

Hardware decodering is de optimale keuze voor de meeste productiescenario's, maar geen universele oplossing. Inzicht in de toepassingsgrenzen helpt situaties te voorkomen waarin het ontbreken van hardware-ondersteuning van de codec de gebruikerservaring verstoort.

Verplichte gebruiksscenario's

Hardware decodering is verplicht in drie gevallen: langdurige videoweergave (meer dan 30 minuten), decodering van 4K-inhoud en elke applicatie gericht op maximale batterijduur. Streamingdiensten (Netflix, YouTube, Twitch) gebruiken uitsluitend hardware decodering, omdat softwarematige decodering geen stabiele weergave kan garanderen bij hoge bitrate en grote resolutie. Voor deze diensten is DRM-ondersteuning (FairPlay, Widevine) essentieel, die alleen beschikbaar is via het hardwareblok dat een beveiligde pijplijn van decoder naar weergave biedt.

Voor games met geïntegreerde video (tussenfilmpjes, advertenties, in-game video's) wordt ook hardware decodering aanbevolen. Moderne game-engines zoals Unity en Unreal Engine hebben ingebouwde ondersteuning voor VideoToolbox en MediaCodec. Hardware decodering in games bevrijdt de CPU voor fysicasimulatie, AI van tegenstanders en invoerverwerking, wat de algehele prestaties verhoogt.

Beperkingen en fallback

De belangrijkste beperking van hardware decodering — afhankelijkheid van hardware-ondersteuning van het formaat. Als de SoC geen decoder voor AV1 bevat (bijv. apparaten op Snapdragon 8 Gen 1), moet de applicatie een software-fallback voorzien via FFmpeg en dav1d. Een vergelijkbare situatie geldt voor H.265 op oudere apparaten en ProRes, dat alleen wordt ondersteund voor decodering op Apple A13+-chips. Het wordt aanbevolen om voor het starten van de weergave de beschikbaarheid van de hardwarematige decoder van het vereiste formaat te controleren en de decodeerstrategie dynamisch te kiezen.

De tweede beperking — het aantal gelijktijdige decodeersessies. De meeste SoC's ondersteunen 1–2 parallelle hardwarematige decoders. Bij een poging een derde sessie te openen, retourneert de API een fout en moet de applicatie overschakelen naar softwarematige decodering. Het aantal sessies hangt af van de SoC-fabrikant: Apple-chips staan tot 4 H.264-decodeersessies toe op de A17 Pro, en Snapdragon 8 Gen 2 — tot 2 voor H.265 en tot 2 voor VP9 in totaal.