Dekodowanie sprzętowe: co to jest, zasada działania i zalety

Co to jest dekodowanie sprzętowe?

Hardware decoding — to proces dekompresji danych multimedialnych wykonywany nie na uniwersalnym CPU, ale na wyspecjalizowanych układach scalonych zintegrowanych z systemem na chipie (SoC). Takie bloki nazywane są dekoderami wideo lub VPU (Video Processing Unit) i stanowią akceleratory ASIC zoptymalizowane pod kątem konkretnych algorytmów kompresji.

Nowoczesne mobilne SoC zawierają oddzielne bloki sprzętowe dla każdego popularnego kodeka. Na przykład układ Apple A17 Pro zawiera dekodery dla H.264, H.265, VP9, AV1 i ProRes. Każdy blok stanowi kompletny potok przetwarzania, zdolny przyjąć skompresowany strumień bitowy na wejściu i dostarczyć gotowe zdekodowane klatki w formacie YUV lub BGRA na wyjściu bez udziału CPU.

Dekodowanie sprzętowe stało się standardem w branży mobilnej w latach 2012–2013, kiedy Qualcomm Snapdragon 800 i Apple A7 po raz pierwszy zawierały dedykowane bloki dekodowania H.264. Od tego czasu technologia ewoluowała od obsługi jednego formatu do uniwersalnych wieloformatowych bloków zdolnych do dekodowania wielu strumieni jednocześnie — na przykład do pracy PiP z oddzielnym strumieniem wideo.

Jak działa dekodowanie sprzętowe?

Proces dekodowania sprzętowego radykalnie różni się od programowego. Zamiast sekwencyjnego wykonywania instrukcji CPU, blok sprzętowy realizuje fizyczne układy dla każdego etapu dekompresji: dekodowanie entropijne, odwrotna kwantyzacja, odwrotne DCT i kompensacja ruchu.

Architektura dekodera sprzętowego

Typowy dekoder sprzętowy składa się z kilku stopni potoku. Pierwszy stopień to dekoder entropijny, zrealizowany jako automat skończony (FSM) dla CABAC lub CAVLC. W przeciwieństwie do implementacji programowej, gdzie każdy bit jest przetwarzany przez instrukcje warunkowe, sprzętowy CABAC wykorzystuje równoległe układy przewidywania kontekstu, co pozwala przetwarzać do 2–3 bitów na takt zamiast jednego.

Drugi stopień to blok odwrotnego DCT. Programowe DCT wymaga pętli mnożenia i akumulacji na CPU. Implementacja sprzętowa wykorzystuje macierzowy mnożnik, który oblicza wszystkie 64 współczynniki bloku 8×8 w jednym takcie. Sprzętowe odwrotne DCT pracuje z częstotliwością 400–600 MHz i przetwarza do 4 milionów makrobloków na sekundę, co wystarcza do dekodowania wideo 8K w czasie rzeczywistym.

Trzeci stopień to moduł kompensacji ruchu (MC). Równolegle z odwrotnym DCT blok sprzętowy otrzymuje wektory ruchu ze strumienia bitowego i pobiera obszary odniesienia z bufora zdekodowanych klatek. Bufor DPB (Decoded Picture Buffer) przechowuje do 16 klatek odniesienia, dostęp do których odbywa się przez wyspecjalizowaną pamięć podręczną o niskim opóźnieniu. Nowoczesne dekodery wykorzystują predykcję z adaptacyjnym wygładzaniem i interpolacją subpikselową, co jest krytyczne dla H.265 i AV1.

Interakcja z systemem

Zarządzanie dekoderem sprzętowym odbywa się przez kontroler DMA. Aplikacja przekazuje dekoderowi wskaźnik do skompresowanych danych w pamięci współdzielonej, a dekoder samodzielnie odczytuje strumień bitowy poprzez bezpośredni dostęp do pamięci. Po zakończeniu dekodowania klatki przerwanie informuje sterownik, a gotowa klatka staje się dostępna w puli buforów wyjściowych. Taki mechanizm całkowicie eliminuje obciążenie CPU na etapie przetwarzania danych — procesor jedynie inicjuje dekodowanie i odbiera gotowy wynik.

VideoToolbox i MediaCodec: porównanie platform

Obie platformy mobilne udostępniają natywne API do dekodowania sprzętowego, ale z różnym podejściem do zarządzania buforami i cyklem życia dekodera. VideoToolbox na iOS jest ściśle zintegrowany z Metal do wyświetlania na ekranie, a MediaCodec na Android używa Surface do bezpośredniego renderowania.

VideoToolbox — framework do dekodowania sprzętowego na iOS i macOS. Używa modelu asynchronicznego dekodowania: wywołanie VTDecompressionSessionDecodeFrame zwraca natychmiast, a gotowe klatki przychodzą przez callback w oddzielnej kolejce. VideoToolbox automatycznie zarządza pulą buforów pikseli (CVPixelBufferPool) i może ponownie wykorzystywać zwolnione bufory dla nowych klatek. Dla wideo HDR VideoToolbox obsługuje przestrzenie kolorów ITU-R BT.2020 oraz PQ/HLG EOTF.

MediaCodec używa synchronicznego modelu z kolejkami buforów wejściowych i wyjściowych. Aplikacja cyklicznie wywołuje dequeueInputBuffer w celu wysłania skompresowanych danych i dequeueOutputBuffer w celu uzyskania zdekodowanego wyniku. Takie podejście daje programiście pełną kontrolę nad tempem dekodowania, co jest ważne dla synchronizacji audio i wideo. Do wyświetlania na ekranie MediaCodec akceptuje Surface, co pozwala dekodować bezpośrednio na GPU bez kopiowania przez CPU.

Zalety dekodowania sprzętowego

Dekodowanie sprzętowe daje trzy kluczowe zalety w porównaniu z programowym: energooszczędność, wydajność i stabilność. Każda z nich jest krytyczna dla urządzeń mobilnych o ograniczonych zasobach baterii i ograniczeniach termicznych.

Energooszczędność

Główną zaletą dekodowania sprzętowego jest radykalnie niższy pobór mocy. Typowy sprzętowy dekoder H.264/H.265 pobiera 0,2–0,5 W podczas dekodowania wideo 1080p w czasie rzeczywistym. Dla porównania, programowe dekodowanie tego samego strumienia na CPU pobiera 1,5–4 W w zależności od architektury procesora. Różnica 5–10 razy bezpośrednio wpływa na czas pracy na baterii: podczas oglądania wideo dekodowanie sprzętowe pozwala oglądać filmy 10–15 godzin wobec 2–4 godzin przy dekodowaniu programowym na CPU.

Energooszczędność osiągana jest dzięki wąskiej specjalizacji. W przeciwieństwie do CPU, który wykonuje szeroki zakres instrukcji i ma złożoną logikę sterowania, dekoder sprzętowy zawiera tylko układy niezbędne dla konkretnego algorytmu. Częstotliwość taktowania takich bloków wynosi 200–600 MHz wobec 2–3 GHz CPU, co zmniejsza dynamiczny pobór mocy proporcjonalnie do kwadratu napięcia.

Wydajność i generowanie ciepła

Dekodowanie sprzętowe zapewnia gwarantowaną liczbę klatek na sekundę nawet dla wysokich rozdzielczości. Dzięki architekturze potokowej blok sprzętowy może jednocześnie przetwarzać kilka etapów dekompresji: podczas gdy jeden moduł wykonuje dekodowanie entropijne dla następnego makrobloku, inny już stosuje odwrotne DCT do bieżącego. Taki równoległość jest nieosiągalna na CPU, gdzie każdy etap to operacja sekwencyjna.

Generowanie ciepła przez dekoder sprzętowy jest znacznie niższe: typowy blok rozprasza 0,3–0,8 W ciepła wobec 2–6 W CPU przy programowym dekodowaniu wideo 4K. Oznacza to, że urządzenie nie przegrzewa się nawet podczas długotrwałego oglądania, throttling nie występuje, a użytkownik otrzymuje stabilne 60 FPS bez spadków. Temperatura obudowy przy dekodowaniu sprzętowym jest zwykle o 5–10 stopni niższa niż przy programowym, co jest szczególnie ważne dla tabletów bez aktywnego chłodzenia.

Przykłady kodu dekodowania sprzętowego

Rozważmy praktyczną implementację dekodowania sprzętowego z obsługą callbacków na iOS przez VideoToolbox i pełny pipeline na Android przez MediaCodec.

Pełny przykład dekodowania sprzętowego 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
        )
    }
}

Kod tworzy sesję dekodowania VideoToolbox z asynchronicznym callbackiem. VTDecompressionSessionCreate automatycznie określa dostępny dekoder sprzętowy na podstawie przekazanego CMVideoFormatDescription. Flaga kVTDecodeFrame_EnableAsynchronousDecompression włącza tryb asynchroniczny — aplikacja nie blokuje się podczas dekodowania, a otrzymuje klatki przez callback. Dla H.264 należy wcześniej utworzyć format description z jednostek NAL SPS/PPS przez CMVideoFormatDescriptionCreateFromH264ParameterSets.

Dekodowanie sprzętowe na Android z wyjściem 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)
        }
    }
}

Kod w Kotlin tworzy MediaCodec z przypisaniem do Surface, co zapewnia bezpośrednie wyjście na ekran bez kopiowania danych przez CPU. Parametr mimeType używa stałych MediaFormat: video/avc dla H.264, video/hevc dla H.265, video/av01 dla AV1. Metoda dequeueInputBuffer oczekuje na wolny bufor wejściowy z timeoutem; jeśli bufor nie jest dostępny — pomijana jest bieżąca klatka, co zapobiega przepełnieniu kolejki przy nierównomiernym bitrate.

Kiedy wybrać dekodowanie sprzętowe

Dekodowanie sprzętowe jest optymalnym wyborem dla większości scenariuszy produkcyjnych, ale nie jest uniwersalnym rozwiązaniem. Zrozumienie granic zastosowania pomaga uniknąć sytuacji, w których brak sprzętowego wsparcia kodeka psuje doświadczenie użytkownika.

Scenariusze obowiązkowego użycia

Dekodowanie sprzętowe jest obowiązkowe w trzech przypadkach: długotrwałe odtwarzanie wideo (ponad 30 minut), dekodowanie treści 4K oraz każda aplikacja nastawiona na maksymalny czas pracy na baterii. Serwisy streamingowe (Netflix, YouTube, Twitch) używają wyłącznie dekodowania sprzętowego, ponieważ programowe nie może zagwarantować stabilnego odtwarzania przy wysokim bitrate i dużej rozdzielczości. Dla tych serwisów krytyczne jest wsparcie DRM (FairPlay, Widevine), które jest dostępne tylko przez blok sprzętowy zapewniający chroniony potok od dekodera do wyświetlacza.

Dla gier ze zintegrowanym wideo (cut-scenki, reklamy, przerywniki) również zaleca się dekodowanie sprzętowe. Nowoczesne silniki gier, takie jak Unity i Unreal Engine, mają wbudowane wsparcie dla VideoToolbox i MediaCodec. Dekodowanie sprzętowe w grach uwalnia CPU do symulacji fizyki, AI przeciwników i przetwarzania wejścia, co zwiększa ogólną wydajność.

Ograniczenia i fallback

Główne ograniczenie dekodowania sprzętowego — zależność od sprzętowego wsparcia formatu. Jeśli SoC nie zawiera dekodera dla AV1 (np. urządzenia na Snapdragon 8 Gen 1), aplikacja musi przewidzieć programowy fallback przez FFmpeg i dav1d. Analogiczna sytuacja z H.265 na starych urządzeniach i ProRes, który jest obsługiwany tylko na układach Apple A13+ do dekodowania. Zaleca się przed rozpoczęciem odtwarzania sprawdzać dostępność dekodera sprzętowego wymaganego formatu i wybierać strategię dekodowania dynamicznie.

Drugie ograniczenie — liczba równoczesnych sesji dekodujących. Większość SoC obsługuje 1–2 równoległych dekoderów sprzętowych. Przy próbie otwarcia trzeciej sesji API zwróci błąd, a aplikacja musi przełączyć się na programowe dekodowanie. Liczba sesji zależy od producenta SoC: układy Apple pozwalają na do 4 sesji dekodowania H.264 na A17 Pro, a Snapdragon 8 Gen 2 — do 2 dla H.265 i do 2 dla VP9 łącznie.