Decoding у мобилним апликацијама: шта је то, основне концепције и принцип рада

Шта је decoding?

Decoding је процес конверзије компресованих дигиталних података назад у оригинални некомпресовани формат. У контексту медија, декодирање враћа видео оквире из компресованог битстрийма који је креирао енкодер. Без декодирања, корисник не може да види видео или чује аудио, јер сви савремени медијски формати користе компресију за уштеду пропусног опсега и простора на диску.

Типичан видео ток у H.264 формату са битрејтом од 5 Mbps заузима 100 пута мање простора него некомпресовани RGB ток са сличном резолуцијом. Алгоритам декодирања мора да врати сваки оквир у оригиналну резолуцију и простор боја, пратећи спецификацију кодека обрнутим редом у односу на кодирање. За то декодер обрађује унутароквирне (I-frame) и међуоквирне (P-frame, B-frame) податке.

На мобилним уређајима, декодирање може да се одвија и на CPU-у и на наменским хардверским блоковима. Савремени SoC-ови од Apple-а (серија A), Qualcomm-а (Snapdragon) и MediaTek-а (Dimensity) садрже уграђене декодере за све популарне формате. Видео процесор преузима тежак посао инверзне дискретне косинусне трансформације и компензације покрета, ослобађајући CPU за друге задатке.

Како ради декодирање?

Процес декодирања састоји се од неколико узастопних фаза које инвертују кораке кодирања. Прво се из битстрийма издвајају заглавља и параметри компресије — профил, ниво, резолуција, простор боја. Затим декодер секвенцијално обрађује компресоване макроблокове, примењујући на њих инверзне трансформације.

Фазе декодирања видео тока

Прва фаза — издвајање ентропијског кода. Ентропијско декодирање користи CABAC или CAVLC алгоритме за враћање коефицијената дискретне косинусне трансформације. Ова фаза не зависи од резолуције видеа — обрађује битстрим, а не пикселе, а њена сложеност је одређена битрејтом, а не величином оквира.

Друга фаза — инверзна квантизација и инверзна DCT. Декодер множи квантизоване коефицијенте кораком квантизације, враћајући приближне вредности DCT коефицијената, затим примењује инверзну DCT трансформацију. Инверзна DCT враћа просторне податке из фреквенцијског домена, формирајући макроблок пиксела. За хрому и луму, трансформација се извршава независно.

Трећа фаза — компензација покрета. За P- и B-оквире, декoder користи векторе покрета извучене из битстрийма и позива се на претходно декодиране референтне оквире. Компензација покрета креира предиктор тренутног макроблока, коме се додаје резидуални сигнал након инверзне DCT. Резултат — потпуно враћен оквир спреман за приказ.

// Псеудокод основног декодирања видео оквира
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;
    }
};

У наведеном примеру приказана је основна структура H.264 декодера. Функција decodeNALUnit прима NAL јединицу — основни блок компресованог H.264 тока. Декодер секвенцијално парсира заглавље, издваја тип слајса, примењује ентропијско декодирање, инверзну квантизацију и инверзну DCT. За P- и B-слајсеве додатно се извршава компензација покрета коришћењем референтних оквира из DPB бафера.

Формати компресије и кодеци

Савремени видео кодеци се разликују по алгоритмима компресије, ефикасности и захтевима за рачунарским ресурсима. Избор формата директно утиче на величину датотеке, квалитет слике и потрошњу енергије при декодирању на мобилном уређају.

H.264 је најраспрострањенији видео кодек, подржан од свих мобилних уређаја. Његова главна предност је универзалност: било који Android паметни телефон и iPhone могу хардверски да декодирају H.264. Међутим, при истом битрејту, H.264 губи у квалитету у односу на модерније кодека H.265 и AV1, захтевајући 30–50% већи битрејт за аналогни визуелни квалитет.

H.265 обезбеђује двоструко бољу компресију у поређењу са H.264 при истом квалитету. Декодирање H.265 захтева снажнији хардверски блок: VideoToolbox на iOS-у подржава H.265 почев од iPhone 6 (A8), а Android уређаји — са Snapdragon 805 и више. При избору H.265 за мобилну апликацију треба узети у обзир да старији уређаји можда немају хардверску подршку и да ће декодирати овај формат програмски, што драстично повећава потрошњу енергије.

AV1 је отворени кодек од Alliance for Open Media, који обезбеђује најбољу компресију међу свим савременим форматима. AV1 је 30% ефикаснији од H.265 и 50% ефикаснији од H.264 при истом визуелном квалитету. Хардверско декодирање AV1 појавило се само у SoC-овима из 2023+ године: Apple A17 Pro, Qualcomm Snapdragon 8 Gen 2 и новији. За старије уређаје, декодирање AV1 је могуће само програмски преко библиотеке dav1d, што ствара значајно оптерећење на CPU-у.

Програмско vs хардверско декодирање

Избор између програмског и хардверског декодирања је кључна архитектонска одлука при развоју мобилног медија плејера. Сваки приступ има своје предности и ограничења која се морају узети у обзир при пројектовању апликације.

Перформансе и потрошња енергије

Хардверско декодирање се извршава на специјализованим блоковима за обраду видеа који троше значајно мање енергије од CPU-а при извршавању истог задатка. Према подацима Qualcomm-а, хардверски H.265 декoder троши 5–10 пута мање енергије од програмског декодирања на Snapdragon 8 Gen 1 CPU-у при репродукцији 4K видеа. Ово је критично за мобилне уређаје где сваки миливат утиче на време рада батерије.

Програмско декодирање, насупрот томе, даје максималну флексибилност. FFmpeg са библиотеком libavcodec подржава десетине кодека и контејнера, укључујући ретке и застареле формате који немају хардверску подршку. Програмер може да модификује ток декодирања, додаје пост-обраду и филтере у лету, што је немогуће при коришћењу затворених хардверских блокова.

Када одабрати програмско декодирање

Програмско декодирање је оправдано у неколико сценарија: при репродукцији ретких формата (ProRes, DNxHD, Motion JPEG), када је потребна прецизна контрола над сваком фазом обраде оквира, као и при декодирању AV1 на уређајима без хардверске подршке. libavcodec из састава FFmpeg-а омогућава декодирање практично било ког познатог формата, што га чини де факто стандардом за универзалне медија плејере.

Ограничење програмског декодирања је топлотно зрачење. Непрекидно декодирање 4K видеа на CPU-у може да загреје уређај на 45–50 степени за 10–15 минута, што доводи до троттлинга и смањења фреквенције кадрова. На уређајима без активног хлађења (таблети, телефони) ово је посебно приметно. Потрошња енергије CPU-а при програмском декодирању може да достигне 3–5 W наспрам 0,3–0,5 W при хардверском декодирању истог тока.

Када одабрати хардверско декодирање

Хардверско декодирање је подразумевани избор за било који продукцијски медија плејер. Обезбеђује стабилних 60 кадрова/с за 4K видео уз минималну потрошњу енергије. VideoToolbox на iOS-у и MediaCodec на Android-у пружају изворне API-је за хардверско декодирање који аутоматски бирају оптимални блок обраде у зависности од кодека и резолуције.

Платформски API-ји преузимају управљање баферима оквира (surface pool на Android-у, CVPixelBufferPool на iOS-у), синхронизацију са дисплејом и оптимизацију меморије. Програмеру је довољно да отвори декoder са потребним параметрима и прима готове оквире. Хардверско декодирање подржава ток од краја до краја са минималним кашњењем: од пријема битстрийма до приказа на екрану прође 5–15 ms наспрам 30–80 ms при програмском декодирању.

Примери кода декодирања

Размотримо практичну имплементацију декодирања на обе мобилне платформе. На iOS-у, хардверско декодирање се извршава преко VideoToolbox-а, а програмско — преко FFmpeg-а. На Android-у се користи MediaCodec за хардверско декодирање.

Хардверско декодирање на iOS-у са 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

Код демонстрира иницијализацију хардверског H.264 декодера на iOS-у. VTDecompressionSessionCreate креира сесију декодирања, а VTCreate позива повратни позив када се појави готов оквир. Сесија аутоматски користи хардверски блок, ако је доступан за наведени кодек. За пријем декодираних оквира у CVPixelBuffer формату користи се повратни позив који преноси сваки готов оквир са минималним кашњењем.

Хардверско декодирање на Android-у са 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);
}

На Android-у, MediaCodec користи за излаз Surface, а не пикселни бафер, што минимизира копирање података између GPU-а и CPU-а. Декoder аутоматски бира хардверски блок (OMX компоненту) на основу типа кодека. За H.264 се користи OMX.google.h264.decoder, који може бити и хардверски и програмски у зависности од имплементације произвођача.

Како одабрати декодер за мобилну апликацију

Избор стратегије декодирања зависи од циљне публике апликације, подржаних формата и захтева за перформансама. Оптимално решење често укључује хибридни приступ: хардверско декодирање за основне формате (H.264, H.265) са програмским fallback-ом за ретке кодека.

Стратегија избора по приоритетима

Ако је апликација оријентисана на максималну компатибилност — користите H.264, који се гарантовано хардверски декодира на било ком уређају. За видео стриминг сервисе оправдан је H.265 са хардверском подршком на уређајима после 2016. године. AV1 је избор за сервисе где је уштеда пропусног опсега важна: YouTube, Netflix и друге велике платформе активно уводе AV1 за смањење трошкова CDN-а уз задржавање квалитета.

Критични параметар — величина бафера декодера. Хардверски декодери имају фиксни пул бафера (обично 4–16 оквира). При репродукцији тока са високим битрејтом, бафери се могу препунити, што доводи до прескакања оквира. MediaCodec пружа метод getOutputFrameRate за одређивање стварних перформанси декодера на одређеном уређају, а VideoToolbox омогућава контролу приоритета у реалном времену преко kVTDecodeFrame_EnableAsynchronousDecompression.

Топлотни троттлинг је још један фактор. Чак и хардверско декодирање може загрејати уређај при дуготрајној репродукцији 4K HDR видеа. Препоручује се праћење температуре преко ProcessInfo на iOS-у и BatteryManager на Android-у, снижавајући квалитет или резолуцију тока при прегревању. Ово је посебно критично за игре и стриминг апликације са дугим сесијама гледања.