Hardware Decoding: ano ito, prinsipyo ng paggana at mga benepisyo

Ano ang hardware decoding?

Hardware decoding — ay ang proseso ng decompression ng media data na isinasagawa hindi sa unibersal na CPU, kundi sa mga espesyalisadong integrated circuit na isinama sa system-on-chip (SoC). Ang mga block na ito ay tinatawag na video decoder o VPU (Video Processing Unit) at kumakatawan sa mga ASIC accelerator na na-optimize para sa mga partikular na compression algorithm.

Ang mga modernong mobile SoC ay naglalaman ng hiwalay na hardware block para sa bawat sikat na codec. Halimbawa, ang Apple A17 Pro chip ay may kasamang mga decoder para sa H.264, H.265, VP9, AV1 at ProRes. Ang bawat block ay kumakatawan sa isang kumpletong processing pipeline, na may kakayahang tumanggap ng compressed bit stream sa input at maghatid ng mga ready decoded frame sa YUV o BGRA format sa output nang walang partisipasyon ng CPU.

Ang hardware decoding ay naging pamantayan sa mobile industry noong 2012–2013, nang ang Qualcomm Snapdragon 800 at Apple A7 ay unang nagsama ng mga dedikadong H.264 decoding block. Mula noon, ang teknolohiya ay nag-evolve mula sa suporta ng isang format tungo sa unibersal na multi-format block na may kakayahang mag-decode ng maraming stream nang sabay-sabay — halimbawa, para sa PiP operation na may hiwalay na video stream.

Paano gumagana ang hardware decoding?

Ang proseso ng hardware decoding ay radikal na naiiba sa software decoding. Sa halip na sequential execution ng CPU instructions, ang hardware block ay nag-iimplementa ng mga pisikal na circuit para sa bawat yugto ng decompression: entropy decoding, inverse quantization, inverse DCT, at motion compensation.

Arkitektura ng hardware decoder

Ang tipikal na hardware decoder ay binubuo ng ilang pipeline stages. Ang unang stage — entropy decoder, na na-implementa bilang finite state machine (FSM) para sa CABAC o CAVLC. Hindi tulad ng software implementation kung saan ang bawat bit ay pinoproseso ng conditional jumps, ang hardware CABAC ay gumagamit ng parallel context prediction circuits, na nagpapahintulot sa pagproseso ng 2–3 bits per clock cycle sa halip na isa.

Ang pangalawang stage — inverse DCT block. Ang software DCT ay nangangailangan ng multiplication-accumulation cycles sa CPU. Ang hardware implementation ay gumagamit ng matrix multiplier na kinakalkula ang lahat ng 64 coefficients ng 8×8 block sa isang clock cycle. Ang hardware inverse DCT ay gumagana sa 400–600 MHz at nagpoproseso ng hanggang 4 na milyong macroblock bawat segundo, sapat para sa real-time na 8K video decoding.

Ang pangatlong stage — motion compensation (MC) module. Kaayon ng inverse DCT, ang hardware block ay tumatanggap ng motion vectors mula sa bit stream at kumukuha ng reference areas mula sa buffer ng decoded frames. Ang DPB buffer (Decoded Picture Buffer) ay nag-iimbak ng hanggang 16 reference frames, na ina-access sa pamamagitan ng espesyalisadong cache memory na may mababang latency. Ang mga modernong decoder ay gumagamit ng prediction na may adaptive smoothing at subpixel interpolation, na kritikal para sa H.265 at AV1.

Interaksyon sa system

Ang pamamahala ng hardware decoder ay ginagawa sa pamamagitan ng DMA controller. Ang application ay nagpapadala ng pointer sa compressed data sa shared memory sa decoder, at ang decoder ay independiyenteng nagbabasa ng bit stream sa pamamagitan ng direct memory access. Pagkatapos ng decoding ng frame, isang interrupt ang nag-aabiso sa driver, at ang ready frame ay nagiging available sa output buffer pool. Ang mekanismong ito ay ganap na nag-aalis ng CPU load sa data processing stage — ang processor ay nag-iinitiate lang ng decoding at tumatanggap ng ready result.

VideoToolbox at MediaCodec: paghahambing ng platform

Ang parehong mobile platform ay nagbibigay ng native API para sa hardware decoding, ngunit may magkaibang approach sa buffer management at lifecycle ng decoder. Ang VideoToolbox sa iOS ay malapit na isinama sa Metal para sa output sa screen, habang ang MediaCodec sa Android ay gumagamit ng Surface para sa direct rendering.

VideoToolbox — framework para sa hardware decoding sa iOS at macOS. Gumagamit ito ng asynchronous decoding model: ang tawag na VTDecompressionSessionDecodeFrame ay agad na bumabalik, at ang mga ready frame ay dumarating sa pamamagitan ng callback sa isang hiwalay na queue. Awtomatikong pinamamahalaan ng VideoToolbox ang pixel buffer pool (CVPixelBufferPool) at maaaring muling gamitin ang mga liberated buffer para sa mga bagong frame. Para sa HDR video, sinusuportahan ng VideoToolbox ang color spaces na ITU-R BT.2020 at PQ/HLG EOTF.

MediaCodec ay gumagamit ng synchronous model na may input at output buffer queues. Ang application ay paikot na tumatawag ng dequeueInputBuffer para magpadala ng compressed data at dequeueOutputBuffer para makuha ang decoded result. Ang approach na ito ay nagbibigay sa developer ng buong kontrol sa decoding rate, na mahalaga para sa audio at video synchronization. Para sa output sa screen, ang MediaCodec ay tumatanggap ng Surface, na nagpapahintulot ng direktang decoding sa GPU nang walang pagkopya sa pamamagitan ng CPU.

Mga benepisyo ng hardware decoding

Ang hardware decoding ay nagbibigay ng tatlong pangunahing benepisyo kumpara sa software: energy efficiency, performance, at stability. Ang bawat isa ay kritikal para sa mga mobile device na may limitadong resources ng baterya at thermal constraints.

Energy efficiency

Ang pangunahing benepisyo ng hardware decoding — radikal na mas mababang konsumo ng kuryente. Ang tipikal na hardware H.264/H.265 decoder ay kumokonsumo ng 0.2–0.5 W kapag nagde-decode ng 1080p video sa real-time. Para sa paghahambing, ang software decoding ng parehong stream sa CPU ay kumokonsumo ng 1.5–4 W depende sa processor architecture. Ang pagkakaiba ng 5–10 beses ay direktang nakakaapekto sa buhay ng baterya: kapag nanonood ng video, ang hardware decoding ay nagpapahintulot ng 10–15 oras na panonood ng pelikula kumpara sa 2–4 na oras sa software decoding sa CPU.

Ang energy efficiency ay nakakamit sa pamamagitan ng makitid na espesyalisasyon. Hindi tulad ng CPU na nagpapatupad ng malawak na hanay ng instructions at may kumplikadong control logic, ang hardware decoder ay naglalaman lamang ng mga circuit na kinakailangan para sa isang partikular na algorithm. Ang clock frequency ng mga block na ito ay 200–600 MHz kumpara sa 2–3 GHz ng CPU, na nagpapababa ng dynamic power consumption nang proporsyonal sa square ng voltage.

Performance at heat dissipation

Ang hardware decoding ay nagtitiyak ng garantisadong frame rate kahit para sa matataas na resolution. Dahil sa pipeline architecture, ang hardware block ay maaaring magproseso ng maraming decompression stages nang sabay-sabay: habang ang isang module ay nagsasagawa ng entropy decoding para sa susunod na macroblock, ang isa ay nag-aapply na ng inverse DCT sa kasalukuyan. Ang parallelism na ito ay hindi makakamit sa CPU, kung saan ang bawat stage ay isang sequential operation.

Ang heat dissipation ng hardware decoder ay makabuluhang mas mababa: ang tipikal na block ay nagdi-dissipate ng 0.3–0.8 W na init kumpara sa 2–6 W ng CPU sa software decoding ng 4K video. Ito ay nangangahulugan na ang device ay hindi nag-o-overheat kahit sa matagal na panonood, walang throttling na nagaganap, at ang user ay nakakakuha ng stable na 60 FPS nang walang pagbaba. Ang temperatura ng casing sa hardware decoding ay karaniwang 5–10 degrees na mas mababa kaysa sa software, na lalong mahalaga para sa mga tablet na walang active cooling.

Mga halimbawa ng code ng hardware decoding

Tingnan natin ang praktikal na implementasyon ng hardware decoding na may callback processing sa iOS sa pamamagitan ng VideoToolbox at kumpletong pipeline sa Android sa pamamagitan ng MediaCodec.

Kumpletong halimbawa ng hardware decoding sa 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
        )
    }
}

Ang code ay gumagawa ng VideoToolbox decoding session na may asynchronous callback. VTDecompressionSessionCreate ay awtomatikong tinutukoy ang available na hardware decoder batay sa ibinigay na CMVideoFormatDescription. Ang flag na kVTDecodeFrame_EnableAsynchronousDecompression ay nag-a-activate ng asynchronous mode — ang application ay hindi na-block sa panahon ng decoding, kundi tumatanggap ng frames sa pamamagitan ng callback. Para sa H.264, kailangan munang gumawa ng format description mula sa SPS/PPS NAL units sa pamamagitan ng CMVideoFormatDescriptionCreateFromH264ParameterSets.

Hardware decoding sa Android na may output sa 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)
        }
    }
}

Ang code sa Kotlin ay gumagawa ng MediaCodec na nakatali sa Surface, na nagbibigay ng direktang output sa screen nang walang pagkopya ng data sa pamamagitan ng CPU. Ang parameter na mimeType ay gumagamit ng MediaFormat constants: video/avc para sa H.264, video/hevc para sa H.265, video/av01 para sa AV1. Ang method na dequeueInputBuffer ay naghihintay ng available na input buffer na may timeout; kung walang available na buffer — ang kasalukuyang frame ay nilalaktawan, na pumipigil sa overflow ng queue sa hindi pantay na bitrate.

Kailan pumili ng hardware decoding

Ang hardware decoding ay ang optimal na pagpipilian para sa karamihan ng production scenarios, ngunit hindi ito universal na solusyon. Ang pag-unawa sa mga hangganan ng applicability ay tumutulong na maiwasan ang mga sitwasyon kung saan ang kakulangan ng hardware support ng codec ay sumisira sa user experience.

Mga scenario ng mandatoryong paggamit

Ang hardware decoding ay mandatory sa tatlong kaso: matagal na pag-playback ng video (higit sa 30 minuto), decoding ng 4K content, at anumang application na nakatuon sa maximum na buhay ng baterya. Ang mga streaming service (Netflix, YouTube, Twitch) ay eksklusibong gumagamit ng hardware decoding, dahil ang software ay hindi makagarantiya ng stable na playback sa mataas na bitrate at malaking resolution. Para sa mga serbisyong ito, ang suporta sa DRM (FairPlay, Widevine) ay kritikal, na available lamang sa pamamagitan ng hardware block na nagbibigay ng secure pipeline mula decoder hanggang display.

Para sa mga laro na may integrated na video (cut-scenes, ads, in-game videos) ay inirerekomenda rin ang hardware decoding. Ang mga modernong game engine tulad ng Unity at Unreal Engine ay may built-in na suporta para sa VideoToolbox at MediaCodec. Ang hardware decoding sa mga laro ay nagpapalaya sa CPU para sa physics simulation, AI ng mga kalaban, at input processing, na nagpapataas ng pangkalahatang performance.

Mga limitasyon at fallback

Ang pangunahing limitasyon ng hardware decoding — pag-asa sa hardware support ng format. Kung ang SoC ay hindi naglalaman ng decoder para sa AV1 (halimbawa, mga device sa Snapdragon 8 Gen 1), ang application ay dapat magbigay ng software fallback sa pamamagitan ng FFmpeg at dav1d. Katulad na sitwasyon sa H.265 sa mga lumang device at ProRes, na sinusuportahan lamang sa Apple A13+ chips para sa decoding. Inirerekomenda na suriin ang availability ng hardware decoder ng kinakailangang format bago magsimula ng playback at pumili ng decoding strategy nang dinamiko.

Ang pangalawang limitasyon — bilang ng sabay-sabay na decoding sessions. Karamihan ng SoC ay sumusuporta ng 1–2 parallel hardware decoders. Sa pagtatangkang magbukas ng ikatlong session, ang API ay magbabalik ng error at ang application ay dapat lumipat sa software decoding. Ang bilang ng sessions ay depende sa manufacturer ng SoC: ang Apple chips ay nagpapahintulot ng hanggang 4 na H.264 decoding session sa A17 Pro, at Snapdragon 8 Gen 2 — hanggang 2 para sa H.265 at hanggang 2 para sa VP9 sa kabuuan.