Hårdvaruavkodning: vad det är, funktionsprincip och fördelar

Vad är hårdvaruavkodning?

Hardware decoding — är processen för dekomprimering av mediadata som utförs inte på den universella CPU:n, utan på specialiserade integrerade kretsar integrerade i systemet-på-ett-chip (SoC). Sådana block kallas videoavkodare eller VPU (Video Processing Unit) och är ASIC-acceleratorer optimerade för specifika komprimeringsalgoritmer.

Moderna mobila SoC:er innehåller separata hårdvarublock för varje populär codec. Till exempel innehåller Apple A17 Pro-chippet avkodare för H.264, H.265, VP9, AV1 och ProRes. Varje block utgör en komplett bearbetningspipeline som kan ta emot komprimerad bitström på ingången och leverera färdiga avkodade bildrutor i YUV- eller BGRA-format på utgången utan CPU:ns deltagande.

Hårdvaruavkodning blev standard inom mobilindustrin runt 2012–2013, när Qualcomm Snapdragon 800 och Apple A7 för första gången inkluderade dedikerade H.264-avkodningsblock. Sedan dess har tekniken utvecklats från stöd för ett format till universella flerformsblock som kan avkoda flera strömmar samtidigt — till exempel för PiP-arbete med en separat videoström.

Hur fungerar hårdvaruavkodning?

Processen för hårdvaruavkodning skiljer sig radikalt från mjukvaruavkodning. Istället för sekventiell exekvering av CPU-instruktioner implementerar hårdvarublocket fysiska kretsar för varje dekomprimeringssteg: entropiavkodning, invers kvantisering, invers DCT och rörelsekompensation.

Arkitektur för hårdvaruavkodaren

En typisk hårdvaruavkodare består av flera pipelinesteg. Det första steget — entropiavkodaren, implementerad som en finit tillståndsmaskin (FSM) för CABAC eller CAVLC. Till skillnad från mjukvaruimplementering där varje bit bearbetas med villkorliga hopp, använder hårdvaru-CABAC parallella kontextprediktionskretsar, vilket möjliggör bearbetning av 2–3 bitar per klockcykel istället för en.

Andra steget — invers DCT-block. Mjukvaru-DCT kräver multiplikations-ackumuleringscykler på CPU:n. Hårdvaruimplementeringen använder en matrismultiplikator som beräknar alla 64 koefficienterna för ett 8×8-block i en klockcykel. Hårdvaru-invers DCT arbetar på 400–600 MHz och bearbetar upp till 4 miljoner makroblock per sekund, tillräckligt för realtidsavkodning av 8K-video.

Tredje steget — rörelsekompensationsmodulen (MC). Parallellt med invers DCT tar hårdvarublocket emot rörelsevektorer från bitströmmen och extraherar referensområden från bufferten med avkodade bildrutor. DPB-bufferten (Decoded Picture Buffer) lagrar upp till 16 referensbildrutor, som nås via specialiserat cacheminne med låg latens. Moderna avkodare använder prediktion med adaptiv utjämning och subpixelinterpolation, vilket är kritiskt för H.265 och AV1.

Interaktion med systemet

Hanteringen av hårdvaruavkodaren sker via DMA-kontrollern. Applikationen skickar en pekare till den komprimerade datan i delat minne till avkodaren, och avkodaren läser självständigt bitströmmen via direkt minnesåtkomst. Efter slutförd avkodning av bildrutan meddelar ett avbrott drivrutinen, och den färdiga bildrutan blir tillgänglig i utgångsbuffertpoolen. Denna mekanism eliminerar helt CPU-belastningen i databearbetningssteget — processorn initierar bara avkodningen och tar emot det färdiga resultatet.

VideoToolbox och MediaCodec: plattformsjämförelse

Båda mobilplattformarna tillhandahåller inbyggda API:er för hårdvaruavkodning, men med olika metoder för buffertadministration och avkodarens livscykel. VideoToolbox på iOS är nära integrerat med Metal för utmatning till skärmen, medan MediaCodec på Android använder Surface för direkt rendering.

VideoToolbox — ramverk för hårdvaruavkodning på iOS och macOS. Det använder en asynkron avkodningsmodell: anropet VTDecompressionSessionDecodeFrame returneras omedelbart, och färdiga bildrutor kommer via en callback på en separat kö. VideoToolbox hanterar automatiskt pixelbuffertpoolen (CVPixelBufferPool) och kan återanvända frigjorda buffertar för nya bildrutor. För HDR-video stöder VideoToolbox färgrymderna ITU-R BT.2020 och PQ/HLG EOTF.

MediaCodec använder en synkron modell med köer för in- och utbuffertar. Applikationen anropar cykliskt dequeueInputBuffer för att skicka komprimerad data och dequeueOutputBuffer för att få det avkodade resultatet. Detta tillvägagångssätt ger utvecklaren full kontroll över avkodningshastigheten, vilket är viktigt för synkronisering av ljud och video. För utmatning till skärmen accepterar MediaCodec Surface, vilket möjliggör direkt avkodning på GPU:n utan kopiering via CPU:n.

Fördelar med hårdvaruavkodning

Hårdvaruavkodning ger tre viktiga fördelar jämfört med mjukvaruavkodning: energieffektivitet, prestanda och stabilitet. Var och en är kritisk för mobila enheter med begränsade batteriresurser och termiska begränsningar.

Energieffektivitet

Den största fördelen med hårdvaruavkodning — radikalt lägre energiförbrukning. En typisk hårdvaruavkodare för H.264/H.265 förbrukar 0,2–0,5 W vid avkodning av 1080p-video i realtid. Som jämförelse förbrukar mjukvaruavkodning av samma ström på CPU:n 1,5–4 W beroende på processorarkitektur. Skillnaden på 5–10 gånger påverkar direkt batteritiden: vid videotittande möjliggör hårdvaruavkodning 10–15 timmars filmtittande jämfört med 2–4 timmar vid mjukvaruavkodning på CPU:n.

Energieffektivitet uppnås genom snäv specialisering. Till skillnad från CPU:n, som utför ett brett spektrum av instruktioner och har komplex kontrolllogik, innehåller hårdvaruavkodaren endast de kretsar som är nödvändiga för en specifik algoritm. Klockfrekvensen för sådana block är 200–600 MHz jämfört med CPU:ns 2–3 GHz, vilket minskar den dynamiska energiförbrukningen proportionellt mot kvadraten på spänningen.

Prestanda och värmeutveckling

Hårdvaruavkodning garanterar en stabil bildfrekvens även för höga upplösningar. Tack vare pipelinearkitekturen kan hårdvarublocket bearbeta flera dekomprimeringssteg samtidigt: medan en modul utför entropiavkodning för nästa makroblock, tillämpar en annan redan invers DCT på det aktuella. Denna parallellitet är ouppnåelig på CPU:n, där varje steg är en sekventiell operation.

Värmeutvecklingen från hårdvaruavkodaren är betydligt lägre: ett typiskt block avleder 0,3–0,8 W värme jämfört med CPU:ns 2–6 W vid mjukvaruavkodning av 4K-video. Detta innebär att enheten inte överhettas ens vid långvarigt tittande, ingen throttling uppstår och användaren får stabila 60 FPS utan nedgångar. Kabinettets temperatur vid hårdvaruavkodning är vanligtvis 5–10 grader lägre än vid mjukvaruavkodning, vilket är särskilt viktigt för surfplattor utan aktiv kylning.

Kodexempel för hårdvaruavkodning

Låt oss titta på den praktiska implementeringen av hårdvaruavkodning med callback-bearbetning på iOS via VideoToolbox och den fullständiga pipelinen på Android via MediaCodec.

Fullständigt exempel på hårdvaruavkodning på 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
        )
    }
}

Koden skapar en VideoToolbox-avkodningssession med asynkron callback. VTDecompressionSessionCreate bestämmer automatiskt tillgänglig hårdvaruavkodare baserat på den angivna CMVideoFormatDescription. Flaggan kVTDecodeFrame_EnableAsynchronousDecompression aktiverar asynkront läge — applikationen blockeras inte under avkodning utan tar emot bildrutor via callback. För H.264 måste en formatbeskrivning skapas i förväg från SPS/PPS NAL-enheter via CMVideoFormatDescriptionCreateFromH264ParameterSets.

Hårdvaruavkodning på Android med utmatning till 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)
        }
    }
}

Koden i Kotlin skapar MediaCodec bunden till Surface, vilket möjliggör direkt utmatning till skärmen utan att kopiera data via CPU:n. Parametern mimeType använder MediaFormat-konstanter: video/avc för H.264, video/hevc för H.265, video/av01 för AV1. Metoden dequeueInputBuffer väntar på en ledig inbuffert med time-out; om ingen buffert är tillgänglig — hoppas den aktuella bildrutan över, vilket förhindrar kööversvämning vid ojämn bitrate.

När ska man välja hårdvaruavkodning

Hårdvaruavkodning är det optimala valet för de flesta produktionsscenarier, men ingen universallösning. Att förstå tillämpningsgränserna hjälper till att undvika situationer där bristen på hårdvarustöd för codec förstör användarupplevelsen.

Obligatoriska användningsscenarier

Hårdvaruavkodning är obligatorisk i tre fall: långvarig videouppspelning (mer än 30 minuter), avkodning av 4K-innehåll och alla applikationer som är inriktade på maximal batteritid. Strömningstjänster (Netflix, YouTube, Twitch) använder uteslutande hårdvaruavkodning, eftersom mjukvaruavkodning inte kan garantera stabil uppspelning vid hög bitrate och stor upplösning. För dessa tjänster är DRM-stöd (FairPlay, Widevine) avgörande, vilket endast är tillgängligt via hårdvarublocket som tillhandahåller en skyddad pipeline från avkodare till skärm.

För spel med integrerad video (mellansekvenser, reklam, videor i spelet) rekommenderas också hårdvaruavkodning. Moderna spelmotorer som Unity och Unreal Engine har inbyggt stöd för VideoToolbox och MediaCodec. Hårdvaruavkodning i spel frigör CPU:n för fysiksimulering, AI för fiender och inmatningsbearbetning, vilket ökar den totala prestandan.

Begränsningar och fallback

Den främsta begränsningen med hårdvaruavkodning — beroendet av hårdvarustöd för formatet. Om SoC:n inte innehåller en avkodare för AV1 (t.ex. enheter med Snapdragon 8 Gen 1), måste applikationen tillhandahålla en mjukvaru-fallback via FFmpeg och dav1d. Liknande situation med H.265 på äldre enheter och ProRes, som endast stöds på Apple A13+-chips för avkodning. Det rekommenderas att före uppspelning kontrollera tillgängligheten för hårdvaruavkodaren för det önskade formatet och dynamiskt välja avkodningsstrategi.

Den andra begränsningen — antalet samtidiga avkodningssessioner. De flesta SoC:er stöder 1–2 parallella hårdvaruavkodare. Vid försök att öppna en tredje session returnerar API:t ett fel och applikationen måste växla till mjukvaruavkodning. Antalet sessioner beror på SoC-tillverkaren: Apple-chips tillåter upp till 4 H.264-avkodningssessioner på A17 Pro, och Snapdragon 8 Gen 2 — upp till 2 för H.265 och upp till 2 för VP9 totalt.