Decoding i mobilapplikationer: vad det är, grundläggande begrepp och funktionsprincip

Vad är decoding?

Decoding är processen att konvertera komprimerad digital data tillbaka till det ursprungliga okomprimerade formatet. I mediesammanhang återställer avkodning videoramar från den komprimerade bitströmmen som skapats av kodaren. Utan avkodning kan användaren inte se videon eller höra ljudet, eftersom alla moderna mediaformat använder komprimering för att spara bandbredd och diskutrymme.

En typisk videoström i H.264-format med en bithastighet på 5 Mbps tar 100 gånger mindre plats än en okomprimerad RGB-ström med liknande upplösning. Avkodningsalgoritmen måste återställa varje ram till originalupplösning och färgrymd, enligt codec-specifikationen i omvänd ordning jämfört med kodning. För detta bearbetar avkodaren intra-ram (I-frame) och inter-ram (P-frame, B-frame) data.

På mobila enheter kan avkodning ske både på CPU och på dedikerade hårdvarublock. Moderna SoC från Apple (A-serien), Qualcomm (Snapdragon) och MediaTek (Dimensity) innehåller inbyggda avkodare för alla populära format. Videoprocessorn tar över det tunga arbetet med invers diskret cosinustransform och rörelsekompensation, vilket frigör CPU för andra uppgifter.

Hur fungerar avkodning?

Avkodningsprocessen består av flera på varandra följande steg som vänder på kodningsstegen. Först extraheras rubriker och komprimeringsparametrar från bitströmmen — profil, nivå, upplösning, färgrymd. Därefter bearbetar avkodaren sekventiellt de komprimerade makroblocken och tillämpar inversa transformationer på dem.

Steg för avkodning av videoström

Första steget — extrahering av entropikod. Entropiavkodning använder CABAC- eller CAVLC-algoritmer för att återställa koefficienterna för diskret cosinustransform. Detta steg är inte beroende av videoupplösningen — det bearbetar bitströmmen, inte pixlarna, och dess komplexitet bestäms av bithastigheten, inte av ramstorleken.

Andra steget — invers kvantisering och invers DCT. Avkodaren multiplicerar de kvantiserade koefficienterna med kvantiseringssteget, återställer de approximativa värdena för DCT-koefficienterna och tillämpar sedan den inversa DCT-transformen. Invers DCT återställer rumsliga data från frekvensdomänen och bildar ett makroblock av pixlar. För krominans och luminans utförs transformationen oberoende.

Tredje steget — rörelsekompensation. För P- och B-ramar använder avkodaren rörelsevektorer extraherade från bitströmmen och refererar till tidigare avkodade referensramar. Rörelsekompensation skapar en prediktor för det aktuella makroblocket, till vilket restsignalen efter invers DCT läggs till. Resultatet — en fullt återställd ram, redo för utmatning.

// Pseudokod för grundläggande avkodning av videoram
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;
    }
};

I exemplet ovan visas grundstrukturen för en H.264-avkodare. Funktionen decodeNALUnit tar emot en NAL-enhet — grundblocket i den komprimerade H.264-strömmen. Avkodaren parsar sekventiellt rubriken, extraherar skivtypen, tillämpar entropiavkodning, invers kvantisering och invers DCT. För P- och B-skivor utförs dessutom rörelsekompensation med referensramar från DPB-bufferten.

Komprimeringsformat och codecs

Moderna videocodecs skiljer sig åt i komprimeringsalgoritmer, effektivitet och krav på beräkningsresurser. Valet av format påverkar direkt filstorlek, bildkvalitet och energiförbrukning vid avkodning på en mobil enhet.

H.264 är den mest spridda videocodec, som stöds av alla mobila enheter. Dess främsta fördel är universalitet: vilken Android-smartphone och iPhone som helst kan avkoda H.264 hårdvarumässigt. Vid samma bithastighet förlorar dock H.264 i kvalitet jämfört med modernare codecs H.265 och AV1, och kräver 30–50% högre bithastighet för liknande visuell kvalitet.

H.265 ger dubbelt så bra komprimering jämfört med H.264 vid samma kvalitet. Avkodning av H.265 kräver en kraftfullare hårdvaruenhet: VideoToolbox på iOS stöder H.265 från och med iPhone 6 (A8), och Android-enheter från Snapdragon 805 och uppåt. Vid val av H.265 för en mobilapp bör man beakta att äldre enheter kanske inte har hårdvarustöd och kommer att avkoda detta format programvarumässigt, vilket drastiskt ökar energiförbrukningen.

AV1 är en öppen codec från Alliance for Open Media, som ger bäst komprimering bland alla moderna format. AV1 är 30% effektivare än H.265 och 50% effektivare än H.264 vid samma visuella kvalitet. Hårdvaruavkodning av AV1 har bara dykt upp i SoC från 2023+: Apple A17 Pro, Qualcomm Snapdragon 8 Gen 2 och nyare. För äldre enheter är AV1-avkodning endast möjlig programvarumässigt via biblioteket dav1d, vilket skapar en betydande belastning på CPU.

Programvaru- vs hårdvaruavkodning

Valet mellan programvaru- och hårdvaruavkodning är ett viktigt arkitekturbeslut vid utveckling av en mobil mediaspelare. Varje metod har sina för- och nackdelar som måste beaktas vid utformningen av applikationen.

Prestanda och energiförbrukning

Hårdvaruavkodning utförs på specialiserade videobearbetningsblock som förbrukar betydligt mindre energi än CPU när de utför samma uppgift. Enligt data från Qualcomm förbrukar en hårdvaruavkodare för H.265 5–10 gånger mindre energi än programvaruavkodning på en Snapdragon 8 Gen 1 CPU vid uppspelning av 4K-video. Detta är kritiskt för mobila enheter där varje milliwatt påverkar batteritiden.

Programvaruavkodning ger å andra sidan maximal flexibilitet. FFmpeg med biblioteket libavcodec stöder dussintals codecs och containrar, inklusive sällsynta och föråldrade format som saknar hårdvarustöd. Utvecklaren kan modifiera avkodningspipelinen, lägga till efterbehandling och filter i farten, vilket är omöjligt vid användning av slutna hårdvarublock.

När man ska välja programvaruavkodning

Programvaruavkodning är motiverad i flera scenarier: vid uppspelning av sällsynta format (ProRes, DNxHD, Motion JPEG), när exakt kontroll över varje steg av rambearbetning krävs, samt vid AV1-avkodning på enheter utan hårdvarustöd. libavcodec från FFmpeg gör det möjligt att avkoda praktiskt taget alla kända format, vilket gör det till de facto-standard för universella mediaspelare.

Begränsningen med programvaruavkodning är värmeutveckling. Kontinuerlig avkodning av 4K-video på CPU kan värma enheten till 45–50 grader på 10–15 minuter, vilket leder till throttling och minskad bildfrekvens. På enheter utan aktiv kylning (surfplattor, telefoner) är detta särskilt märkbart. CPU:s energiförbrukning vid programvaruavkodning kan nå 3–5 W jämfört med 0,3–0,5 W vid hårdvaruavkodning av samma ström.

När man ska välja hårdvaruavkodning

Hårdvaruavkodning är standardvalet för alla produktionsmediaspelare. Den ger stabila 60 bilder/s för 4K-video med minimal energiförbrukning. VideoToolbox på iOS och MediaCodec på Android tillhandahåller inbyggda API:er för hårdvaruavkodning som automatiskt väljer den optimala bearbetningsenheten beroende på codec och upplösning.

Plattforms-API:erna hanterar rambuffertar (surface pool på Android, CVPixelBufferPool på iOS), synkronisering med displayen och minnesoptimering. Utvecklaren behöver bara öppna avkodaren med rätt parametrar och ta emot färdiga ramar. Hårdvaruavkodning stöder end-to-end-pipeline med minimal latens: från mottagning av bitström till visning på skärmen tar det 5–15 ms jämfört med 30–80 ms vid programvaruavkodning.

Exempel på avkodningskod

Låt oss titta på praktisk implementering av avkodning på båda mobila plattformarna. På iOS utförs hårdvaruavkodning via VideoToolbox och programvaruavkodning via FFmpeg. På Android används MediaCodec för hårdvaruavkodning.

Hårdvaruavkodning på iOS med 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

Koden visar initiering av en hårdvaruavkodare för H.264 på iOS. VTDecompressionSessionCreate skapar en avkodningssession och VTCreate anropar en callback när en färdig ram dyker upp. Sessionen använder automatiskt hårdvarublocket om det är tillgängligt för den angivna codec. För mottagning av avkodade ramar i CVPixelBuffer-format används en callback som överför varje färdig ram med minimal latens.

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

På Android använder MediaCodec Surface för utmatning istället för en pixelbuffer, vilket minimerar kopiering av data mellan GPU och CPU. Avkodaren väljer automatiskt hårdvarublocket (OMX-komponent) baserat på codec-typen. För H.264 används OMX.google.h264.decoder, som kan vara både hårdvara och programvara beroende på tillverkarens implementering.

Hur man väljer avkodare för en mobilapp

Valet av avkodningsstrategi beror på applikationens målgrupp, de format som stöds och prestandakraven. Den optimala lösningen innefattar ofta en hybridmetod: hårdvaruavkodning för huvudformaten (H.264, H.265) med programvarufallback för sällsynta codecs.

Urvalsstrategi efter prioriteringar

Om applikationen är inriktad på maximal kompatibilitet — använd H.264, som garanterat avkodas hårdvarumässigt på alla enheter. För videostreamingtjänster är H.265 med hårdvarustöd på enheter efter 2016 motiverad. AV1 är valet för tjänster där bandbreddsbesparing är viktig: YouTube, Netflix och andra stora plattformar implementerar aktivt AV1 för att minska CDN-kostnader samtidigt som kvaliteten bibehålls.

Kritisk parameter — avkodarens bufferstorlek. Hårdvaruavkodare har en fast bufferpool (vanligtvis 4–16 ramar). Vid uppspelning av en ström med hög bithastighet kan buffertarna svämma över, vilket leder till att ramar hoppas över. MediaCodec tillhandahåller metoden getOutputFrameRate för att bestämma avkodarens faktiska prestanda på en specifik enhet, och VideoToolbox möjliggör realtidsprioritetskontroll via kVTDecodeFrame_EnableAsynchronousDecompression.

Termisk throttling är en annan faktor. Även hårdvaruavkodning kan värma enheten vid långvarig uppspelning av 4K HDR-video. Det rekommenderas att övervaka temperaturen via ProcessInfo på iOS och BatteryManager på Android, och sänka kvaliteten eller upplösningen på strömmen vid överhettning. Detta är särskilt kritiskt för spel och streamingappar med långa tittarsessioner.