Decoding in mobiele apps: wat het is, basisconcepten en werkingsprincipe

Wat is decoding?

Decoding is het proces van het terugzetten van gecomprimeerde digitale gegevens naar het oorspronkelijke ongecomprimeerde formaat. In de context van media herstelt decodering videoframes uit de gecomprimeerde bitstroom die door de encoder is gemaakt. Zonder decodering kan de gebruiker geen video zien of audio horen, omdat alle moderne mediaformaten compressie gebruiken om bandbreedte en schijfruimte te besparen.

Een typische videostream in H.264-formaat met een bitrate van 5 Mbps neemt 100 keer minder ruimte in dan een ongecomprimeerde RGB-stream met een vergelijkbare resolutie. Het decoderingsalgoritme moet elk frame terugzetten naar de oorspronkelijke resolutie en kleurruimte, volgens de codecspecificatie in omgekeerde volgorde ten opzichte van het coderen. Hiervoor verwerkt de decoder intraframe- (I-frame) en interframegegevens (P-frame, B-frame).

Op mobiele apparaten kan decodering zowel op de CPU als op speciale hardwareblokken plaatsvinden. Moderne SoC's van Apple (A-serie), Qualcomm (Snapdragon) en MediaTek (Dimensity) bevatten ingebouwde decoders voor alle populaire formaten. De videoprocessor neemt het zware werk van inverse discrete cosinustransformatie en bewegingscompensatie over, waardoor de CPU vrijkomt voor andere taken.

Hoe werkt decodering?

Het decoderingsproces bestaat uit verschillende opeenvolgende fasen die de coderingsstappen omkeren. Eerst worden uit de bitstroom de headers en compressieparameters gehaald — profiel, niveau, resolutie, kleurruimte. Vervolgens verwerkt de decoder sequentieel de gecomprimeerde macroblokken en past er inverse transformaties op toe.

Fasen van videostreamdecodering

De eerste fase — het extraheren van de entropiecode. Entropiedecodering gebruikt CABAC- of CAVLC-algoritmen om de coëfficiënten van de discrete cosinustransformatie te herstellen. Deze fase is niet afhankelijk van de videoresolutie — het verwerkt de bitstroom, niet de pixels, en de complexiteit wordt bepaald door de bitrate, niet door de framegrootte.

De tweede fase — inverse kwantisering en inverse DCT. De decoder vermenigvuldigt de gekwantiseerde coëfficiënten met de kwantiseringsstap, herstelt de geschatte waarden van de DCT-coëfficiënten en past vervolgens de inverse DCT-transformatie toe. Inverse DCT herstelt de ruimtelijke gegevens uit het frequentiedomein en vormt een pixelmacroblok. Voor chroma en luma wordt de transformatie onafhankelijk uitgevoerd.

De derde fase — bewegingscompensatie. Voor P- en B-frames gebruikt de decoder bewegingsvectoren die uit de bitstroom zijn geëxtraheerd en verwijst naar eerder gedecodeerde referentieframes. Bewegingscompensatie creëert een voorspeller van het huidige macroblok, waaraan het restsigbaar na inverse DCT wordt toegevoegd. Het resultaat — een volledig hersteld frame, klaar voor weergave.

// Pseudocode voor basisdecodering van een videoframe
struct DecodedFrame {
    uint8_t* y_plane;
    uint8_t* u_plane;
    uint8_t* v_plane;
    int width, height;
};

class Decoder {
public:
    bool decodeNALUnit(const uint8_t* nalUnit, size_t size) {
        if (!parseNALUHeader(nalUnit, size))
            return false;
        
        int sliceType = parseSliceType(nalUnit);
        entropyDecode(nalUnit);
        inverseQuantize();
        inverseDCT();
        
        if (sliceType != I_SLICE)
            motionCompensation();
        
        return true;
    }
};

In het bovenstaande voorbeeld wordt de basisstructuur van een H.264-decoder getoond. De functie decodeNALUnit ontvangt een NAL-eenheid — het basisblok van de gecomprimeerde H.264-stroom. De decoder parseert sequentieel de header, extraheert het slidetype, past entropiedecodering, inverse kwantisering en inverse DCT toe. Voor P- en B-slides wordt aanvullend bewegingscompensatie uitgevoerd met referentieframes uit de DPB-buffer.

Compressieformaten en codecs

Moderne videocodecs verschillen in compressie-algoritmen, efficiëntie en vereisten voor rekenkracht. De keuze van het formaat heeft directe invloed op de bestandsgrootte, beeldkwaliteit en energieverbruik bij decodering op een mobiel apparaat.

H.264 is de meest verspreide videocodec, ondersteund door alle mobiele apparaten. Het belangrijkste voordeel is universaliteit: elke Android-smartphone en iPhone kunnen H.264 hardwarematig decoderen. Bij dezelfde bitrate verliest H.264 echter aan kwaliteit ten opzichte van modernere codecs H.265 en AV1, en vereist 30–50% meer bitrate voor een vergelijkbare visuele kwaliteit.

H.265 biedt twee keer betere compressie in vergelijking met H.264 bij dezelfde kwaliteit. Decodering van H.265 vereist een krachtigere hardware-eenheid: VideoToolbox op iOS ondersteunt H.265 vanaf iPhone 6 (A8), en Android-apparaten vanaf Snapdragon 805 en hoger. Bij het kiezen van H.265 voor een mobiele app moet men er rekening mee houden dat oudere apparaten mogelijk geen hardware-ondersteuning hebben en dit formaat softwarematig zullen decoderen, wat het energieverbruik drastisch verhoogt.

AV1 is een open codec van Alliance for Open Media, die de beste compressie biedt van alle moderne formaten. AV1 is 30% efficiënter dan H.265 en 50% efficiënter dan H.264 bij dezelfde visuele kwaliteit. Hardwarematige AV1-decodering is pas verschenen in SoC's van 2023+: Apple A17 Pro, Qualcomm Snapdragon 8 Gen 2 en nieuwer. Voor oudere apparaten is AV1-decodering alleen softwarematig mogelijk via de bibliotheek dav1d, wat een aanzienlijke belasting voor de CPU vormt.

Softwarematige vs hardwarematige decodering

De keuze tussen softwarematige en hardwarematige decodering is een cruciale architectuurbeslissing bij het ontwikkelen van een mobiele mediaspeler. Elke benadering heeft zijn voor- en nadelen waarmee rekening moet worden gehouden bij het ontwerpen van de applicatie.

Prestaties en energieverbruik

Hardwarematige decodering wordt uitgevoerd op gespecialiseerde videoverwerkingsblokken die aanzienlijk minder energie verbruiken dan de CPU bij het uitvoeren van dezelfde taak. Volgens gegevens van Qualcomm verbruikt een hardwarematige H.265-decoder 5–10 keer minder energie dan softwarematige decodering op een Snapdragon 8 Gen 1 CPU bij het afspelen van 4K-video. Dit is kritiek voor mobiele apparaten waar elke milliwatt de batterijduur beïnvloedt.

Softwarematige decodering biedt daarentegen maximale flexibiliteit. FFmpeg met de bibliotheek libavcodec ondersteunt tientallen codecs en containers, waaronder zeldzame en verouderde formaten die geen hardware-ondersteuning hebben. De ontwikkelaar kan de decoderingspijplijn aanpassen, nabewerking en filters in realtime toevoegen, wat onmogelijk is bij het gebruik van gesloten hardwareblokken.

Wanneer softwarematige decodering kiezen

Softwarematige decodering is gerechtvaardigd in verschillende scenario's: bij het afspelen van zeldzame formaten (ProRes, DNxHD, Motion JPEG), wanneer nauwkeurige controle over elke fase van frameverwerking nodig is, en ook bij AV1-decodering op apparaten zonder hardware-ondersteuning. libavcodec uit FFmpeg maakt het mogelijk vrijwel elk bekend formaat te decoderen, wat het de de facto standaard maakt voor universele mediaspelers.

De beperking van softwarematige decodering is warmteontwikkeling. Continue decodering van 4K-video op de CPU kan het apparaat in 10–15 minuten tot 45–50 graden verhitten, wat leidt tot throttling en vermindering van de framerate. Op apparaten zonder actieve koeling (tablets, telefoons) is dit bijzonder merkbaar. Het energieverbruik van de CPU bij softwarematige decodering kan 3–5 W bereiken tegenover 0,3–0,5 W bij hardwarematige decodering van dezelfde stroom.

Wanneer hardwarematige decodering kiezen

Hardwarematige decodering is de standaardkeuze voor elke productiemediaspeler. Het zorgt voor stabiele 60 frames/s voor 4K-video met een minimaal energieverbruik. VideoToolbox op iOS en MediaCodec op Android bieden native API's voor hardwarematige decodering die automatisch de optimale verwerkingseenheid selecteren op basis van codec en resolutie.

Platform-API's nemen het beheer van framebuffers (surface pool op Android, CVPixelBufferPool op iOS), synchronisatie met het beeldscherm en geheugenoptimalisatie over. De ontwikkelaar hoeft alleen de decoder met de juiste parameters te openen en kant-en-klare frames te ontvangen. Hardwarematige decodering ondersteunt een end-to-end-pijplijn met minimale vertraging: van ontvangst van de bitstroom tot weergave op het scherm duurt het 5–15 ms tegenover 30–80 ms bij softwarematige decodering.

Voorbeelden van decodeercode

Laten we de praktische implementatie van decodering op beide mobiele platforms bekijken. Op iOS wordt hardwarematige decodering uitgevoerd via VideoToolbox, en softwarematige via FFmpeg. Op Android wordt MediaCodec gebruikt voor hardwarematige decodering.

Hardwarematige decodering op iOS met VideoToolbox

@interface VideoDecoder ()
@property (nonatomic) VTDecompressionSessionRef session;
@end

@implementation VideoDecoder

- (void)setupDecoder {
    CMVideoFormatDescriptionRef formatDesc;
    CMVideoCodecType codecType = kCMVideoCodecType_H264;
    
    OSStatus status = CMVideoFormatDescriptionCreate(
        NULL, codecType, 1920, 1080, NULL, &formatDesc
    );
    
    VTDecompressionOutputCallbackRecord callback;
    callback.decompressionOutputCallback = &decodingCallback;
    
    VTDecompressionSessionCreate(NULL, formatDesc, NULL,
        NULL, &callback, &_session);
}

- (void)decodeFrame: (uint8_t*)nalData length:(size_t)size {
    CMBlockBufferRef blockBuffer;
    CMBlockBufferCreateWithMemoryBlock(NULL, nalData,
        size, NULL, NULL, 0, size, 0, &blockBuffer);
    
    CMSampleBufferRef sampleBuffer;
    CMSampleBufferCreate(NULL, blockBuffer, true, NULL,
        NULL, NULL, 1, 0, NULL, 0, NULL, &sampleBuffer);
    
    VTDecompressionSessionDecodeFrame(_session,
        sampleBuffer, 0, NULL, 0);
}

@end

De code toont de initialisatie van een hardwarematige H.264-decoder op iOS. VTDecompressionSessionCreate creëert een decoderingssessie en VTCreate roept een callback aan wanneer een frame gereed is. De sessie gebruikt automatisch de hardware-eenheid indien beschikbaar voor de opgegeven codec. Voor het ontvangen van gedecodeerde frames in CVPixelBuffer-formaat wordt een callback gebruikt die elk gereed frame met minimale vertraging doorgeeft.

Hardwarematige decodering op Android met MediaCodec

MediaCodec decoder = MediaCodec.createDecoderByType("video/avc");
MediaFormat format = MediaFormat.createVideoFormat(
    "video/avc", 1920, 1080
);
format.setInteger(MediaFormat.KEY_FRAME_RATE, 30);

decoder.configure(format, surface, null, 0);
decoder.start();

ByteBuffer[] inputBuffers = decoder.getInputBuffers();
int inputIndex = decoder.dequeueInputBuffer(10000);

if (inputIndex >= 0) {
    ByteBuffer buffer = inputBuffers[inputIndex];
    buffer.clear();
    buffer.put(nalData);
    decoder.queueInputBuffer(inputIndex, 0, nalData.length, pts, 0);
}

Op Android gebruikt MediaCodec voor uitvoer Surface in plaats van een pixelbuffer, wat het kopiëren van gegevens tussen GPU en CPU minimaliseert. De decoder selecteert automatisch de hardware-eenheid (OMX-component) op basis van het codectype. Voor H.264 wordt OMX.google.h264.decoder gebruikt, die zowel hardwarematig als softwarematig kan zijn afhankelijk van de implementatie van de fabrikant.

Hoe kies je een decoder voor een mobiele app

De keuze van de decoderingsstrategie hangt af van de doelgroep van de app, de ondersteunde formaten en de prestatie-eisen. De optimale oplossing omvat vaak een hybride benadering: hardwarematige decodering voor de belangrijkste formaten (H.264, H.265) met softwarematige fallback voor zeldzame codecs.

Keuzestrategie op basis van prioriteiten

Als de app gericht is op maximale compatibiliteit — gebruik H.264, dat gegarandeerd hardwarematig wordt gedecodeerd op elk apparaat. Voor videostreamingdiensten is H.265 met hardware-ondersteuning op apparaten na 2016 gerechtvaardigd. AV1 is de keuze voor diensten waar bandbreedtebesparing belangrijk is: YouTube, Netflix en andere grote platforms implementeren AV1 actief om CDN-kosten te verlagen met behoud van kwaliteit.

Een kritieke parameter is de buffergrootte van de decoder. Hardwarematige decoders hebben een vaste bufferpool (meestal 4–16 frames). Bij het afspelen van een stream met hoge bitrate kunnen de buffers overlopen, wat leidt tot het overslaan van frames. MediaCodec biedt de methode getOutputFrameRate om de werkelijke prestaties van de decoder op een specifiek apparaat te bepalen, en VideoToolbox maakt realtime prioriteitscontrole mogelijk via kVTDecodeFrame_EnableAsynchronousDecompression.

Thermische throttling is een andere factor. Zelfs hardwarematige decodering kan het apparaat verhitten bij langdurig afspelen van 4K HDR-video. Het wordt aanbevolen de temperatuur te controleren via ProcessInfo op iOS en BatteryManager op Android, en de kwaliteit of resolutie van de stream te verlagen bij oververhitting. Dit is vooral kritiek voor games en streaming-apps met lange kijksessies.