Decoding v mobilních aplikacích: co to je, základní pojmy a princip fungování

Co je decoding?

Decoding je proces převodu komprimovaných digitálních dat zpět do původního nekomprimovaného formátu. V kontextu médií dekódování obnovuje video snímky z komprimovaného bitového toku vytvořeného enkodérem. Bez dekódování uživatel nemůže vidět video ani slyšet zvuk, protože všechny moderní mediální formáty používají kompresi pro úsporu šířky pásma a místa na disku.

Typický video tok ve formátu H.264 s bitrate 5 Mb/s zabírá 100krát méně místa než nekomprimovaný RGB tok s podobným rozlišením. Algoritmus dekódování musí obnovit každý snímek zpět na původní rozlišení a barevný prostor, a to podle specifikace kodeku v opačném pořadí vzhledem ke kódování. Za tímto účelem dekodér zpracovává data vnitřních snímků (I-frame) a mezisnímků (P-frame, B-frame).

Na mobilních zařízeních může dekódování probíhat jak na CPU, tak na vyhrazených hardwarových blocích. Moderní SoC od Applu (řada A), Qualcommu (Snapdragon) a MediaTeku (Dimensity) obsahují vestavěné dekodéry pro všechny oblíbené formáty. Video procesor přebírá těžkou práci inverzní diskrétní kosinové transformace a kompenzace pohybu, čímž uvolňuje CPU pro jiné úkoly.

Jak funguje dekódování?

Proces dekódování se skládá z několika po sobě jdoucích fází, které obracejí kroky kódování. Nejprve se z bitového toku extrahují hlavičky a parametry komprese — profil, úroveň, rozlišení, barevný prostor. Poté dekodér postupně zpracovává komprimované makrobloky a aplikuje na ně inverzní transformace.

Fáze dekódování video toku

První fáze — extrakce entropického kódu. Entropické dekódování používá algoritmy CABAC nebo CAVLC k obnovení koeficientů diskrétní kosinové transformace. Tato fáze nezávisí na rozlišení videa — zpracovává bitový tok, nikoli pixely, a její složitost je určena bitrate, nikoli velikostí snímku.

Druhá fáze — inverzní kvantizace a inverzní DCT. Dekodér násobí kvantované koeficienty krokem kvantizace, čímž obnovuje přibližné hodnoty DCT koeficientů, a poté aplikuje inverzní DCT transformaci. Inverzní DCT obnovuje prostorová data z frekvenční domény a vytváří makroblok pixelů. Pro chrominanci a luminanci se transformace provádí nezávisle.

Třetí fáze — kompenzace pohybu. Pro snímky P a B dekodér používá vektory pohybu extrahované z bitového toku a odkazuje se na dříve dekódované referenční snímky. Kompenzace pohybu vytváří prediktor aktuálního makrobloku, k němuž se přidává reziduální signál po inverzní DCT. Výsledkem je plně obnovený snímek připravený k výstupu.

// Pseudokód základního dekódování video snímku
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;
    }
};

Výše uvedený příklad ukazuje základní strukturu dekodéru H.264. Funkce decodeNALUnit přijímá jednotku NAL — základní blok komprimovaného toku H.264. Dekodér postupně parsuje hlavičku, extrahuje typ slice, aplikuje entropické dekódování, inverzní kvantizaci a inverzní DCT. Pro slice P a B se navíc provádí kompenzace pohybu s využitím referenčních snímků z vyrovnávací paměti DPB.

Kompresní formáty a kodeky

Moderní videokodeky se liší kompresními algoritmy, účinností a požadavky na výpočetní zdroje. Volba formátu přímo ovlivňuje velikost souboru, kvalitu obrazu a spotřebu energie při dekódování na mobilním zařízení.

H.264 je nejrozšířenější videokodek podporovaný všemi mobilními zařízeními. Jeho hlavní výhodou je univerzálnost: jakýkoli smartphone s Androidem a iPhone mohou H.264 dekódovat hardwarově. Při stejném bitrate však H.264 ztrácí na kvalitě ve srovnání s modernějšími kodeky H.265 a AV1 a vyžaduje o 30–50 % vyšší bitrate pro podobnou vizuální kvalitu.

H.265 poskytuje dvojnásobně lepší kompresi ve srovnání s H.264 při stejné kvalitě. Dekódování H.265 vyžaduje výkonnější hardwarový blok: VideoToolbox na iOS podporuje H.265 od iPhonu 6 (A8) a zařízení s Androidem od Snapdragonu 805 výše. Při výběru H.265 pro mobilní aplikaci je třeba zvážit, že starší zařízení nemusí mít hardwarovou podporu a budou tento formát dekódovat softwarově, což drasticky zvyšuje spotřebu energie.

AV1 je otevřený kodek od Alliance for Open Media, který poskytuje nejlepší kompresi ze všech moderních formátů. AV1 je o 30 % účinnější než H.265 a o 50 % účinnější než H.264 při stejné vizuální kvalitě. Hardwarové dekódování AV1 se objevilo až v SoC od roku 2023+: Apple A17 Pro, Qualcomm Snapdragon 8 Gen 2 a novější. Pro starší zařízení je dekódování AV1 možné pouze softwarově prostřednictvím knihovny dav1d, což vytváří značné zatížení CPU.

Softwarové vs hardwarové dekódování

Volba mezi softwarovým a hardwarovým dekódováním je klíčové architektonické rozhodnutí při vývoji mobilního mediálního přehrávače. Každý přístup má své výhody a omezení, která je třeba zohlednit při návrhu aplikace.

Výkon a spotřeba energie

Hardwarové dekódování se provádí na specializovaných blocích pro zpracování videa, které spotřebovávají výrazně méně energie než CPU při provádění stejného úkolu. Podle údajů Qualcommu spotřebovává hardwarový dekodér H.265 5–10krát méně energie než softwarové dekódování na CPU Snapdragon 8 Gen 1 při přehrávání 4K videa. To je kritické pro mobilní zařízení, kde každý miliwatt ovlivňuje výdrž baterie.

Softwarové dekódování naopak poskytuje maximální flexibilitu. FFmpeg s knihovnou libavcodec podporuje desítky kodeků a kontejnerů, včetně vzácných a zastaralých formátů, které nemají hardwarovou podporu. Vývojář může upravit pipeline dekódování, přidávat post-processing a filtry za běhu, což není možné při použití uzavřených hardwarových bloků.

Kdy zvolit softwarové dekódování

Softwarové dekódování je opodstatněné v několika scénářích: při přehrávání vzácných formátů (ProRes, DNxHD, Motion JPEG), při potřebě přesné kontroly nad každou fází zpracování snímku, a také při dekódování AV1 na zařízeních bez hardwarové podpory. libavcodec z FFmpegu umožňuje dekódovat prakticky jakýkoli známý formát, což z něj činí de facto standard pro univerzální mediální přehrávače.

Omezením softwarového dekódování je tepelný výkon. Nepřetržité dekódování 4K videa na CPU může zahřát zařízení na 45–50 stupňů během 10–15 minut, což vede k throttlingu a snížení snímkové frekvence. Na zařízeních bez aktivního chlazení (tablety, telefony) je to obzvláště patrné. Spotřeba energie CPU při softwarovém dekódování může dosahovat 3–5 W oproti 0,3–0,5 W při hardwarovém dekódování stejného toku.

Kdy zvolit hardwarové dekódování

Hardwarové dekódování je výchozí volbou pro jakýkoli produkční mediální přehrávač. Poskytuje stabilních 60 snímků/s pro 4K video s minimální spotřebou energie. VideoToolbox na iOS a MediaCodec na Androidu poskytují nativní API pro hardwarové dekódování, která automaticky vybírají optimální blok zpracování v závislosti na kodeku a rozlišení.

API platforem přebírají správu snímkových bufferů (surface pool na Androidu, CVPixelBufferPool na iOS), synchronizaci s displejem a optimalizaci paměti. Vývojář stačí otevřít dekodér s potřebnými parametry a přijímat hotové snímky. Hardwarové dekódování podporuje end-to-end pipeline s minimální latencí: od příjmu bitového toku po zobrazení na obrazovce uběhne 5–15 ms oproti 30–80 ms při softwarovém dekódování.

Příklady kódu dekódování

Podívejme se na praktickou implementaci dekódování na obou mobilních platformách. Na iOS se hardwarové dekódování provádí přes VideoToolbox a softwarové přes FFmpeg. Na Androidu se pro hardwarové dekódování používá MediaCodec.

Hardwarové dekódování na iOS s 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

Kód demonstruje inicializaci hardwarového dekodéru H.264 na iOS. VTDecompressionSessionCreate vytváří relaci dekódování a VTCreate volá callback při objevení hotového snímku. Relace automaticky používá hardwarový blok, pokud je pro daný kodek k dispozici. Pro příjem dekódovaných snímků ve formátu CVPixelBuffer se používá callback, který předává každý hotový snímek s minimální latencí.

Hardwarové dekódování na Androidu s 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);
}

Na Androidu MediaCodec používá pro výstup Surface namísto pixelového bufferu, což minimalizuje kopírování dat mezi GPU a CPU. Dekodér automaticky vybírá hardwarový blok (komponentu OMX) na základě typu kodeku. Pro H.264 se používá OMX.google.h264.decoder, který může být v závislosti na implementaci výrobce jak hardwarový, tak softwarový.

Jak vybrat dekodér pro mobilní aplikaci

Výběr strategie dekódování závisí na cílové skupině aplikace, podporovaných formátech a požadavcích na výkon. Optimální řešení často zahrnuje hybridní přístup: hardwarové dekódování pro hlavní formáty (H.264, H.265) s softwarovým fallbackem pro vzácné kodeky.

Strategie výběru podle priorit

Pokud je aplikace zaměřena na maximální kompatibilitu — použijte H.264, který je zaručeně hardwarově dekódovatelný na jakémkoli zařízení. Pro služby streamování videa je opodstatněný H.265 s hardwarovou podporou na zařízeních po roce 2016. AV1 je volbou pro služby, kde je důležitá úspora šířky pásma: YouTube, Netflix a další velké platformy aktivně zavádějí AV1 pro snížení nákladů na CDN při zachování kvality.

Kritický parametr — velikost bufferu dekodéru. Hardwarové dekodéry mají pevný fond bufferů (obvykle 4–16 snímků). Při přehrávání toku s vysokým bitrate mohou buffery přetékat, což vede k přeskakování snímků. MediaCodec poskytuje metodu getOutputFrameRate pro určení skutečného výkonu dekodéru na konkrétním zařízení a VideoToolbox umožňuje řízení priority v reálném čase prostřednictvím kVTDecodeFrame_EnableAsynchronousDecompression.

Tepelný throttling je dalším faktorem. I hardwarové dekódování může zahřívat zařízení při dlouhodobém přehrávání 4K HDR videa. Doporučuje se sledovat teplotu prostřednictvím ProcessInfo na iOS a BatteryManager na Androidu a při přehřívání snižovat kvalitu nebo rozlišení toku. To je zvláště kritické pro hry a streamovací aplikace s dlouhými sledovacími sezeními.