Decoding sa mga Mobile Application: ano ito, mga pangunahing konsepto at prinsipyo ng paggana

Ano ang decoding?

Decoding ay ang proseso ng pag-convert ng naka-compress na digital data pabalik sa orihinal na hindi naka-compress na format. Sa konteksto ng media, ang decoding ay nagpapanumbalik ng mga video frame mula sa naka-compress na bit stream na ginawa ng encoder. Kung walang decoding, hindi makikita ng user ang video o maririnig ang audio, dahil ang lahat ng modernong media format ay gumagamit ng compression upang makatipid ng bandwidth at espasyo sa disk.

Ang isang tipikal na video stream sa H.264 format na may bitrate na 5 Mbps ay sumasakop ng 100 beses na mas kaunting espasyo kaysa sa isang hindi naka-compress na RGB stream na may katulad na resolution. Ang algorithm ng decoding ay dapat ibalik ang bawat frame pabalik sa orihinal na resolution at color space, sumusunod sa spec ng codec sa reverse order kumpara sa encoding. Para dito, pinoproseso ng decoder ang intra-frame (I-frame) at inter-frame (P-frame, B-frame) na data.

Sa mga mobile device, ang decoding ay maaaring mangyari pareho sa CPU at sa mga dedicated hardware block. Ang mga modernong SoC mula sa Apple (A series), Qualcomm (Snapdragon) at MediaTek (Dimensity) ay naglalaman ng mga built-in decoder para sa lahat ng sikat na format. Ang video processor ay pumapasan sa mabigat na gawain ng inverse discrete cosine transform at motion compensation, pinalalaya ang CPU para sa iba pang mga gawain.

Paano gumagana ang decoding?

Ang proseso ng decoding ay binubuo ng ilang sunud-sunod na yugto na bumabaligtad sa mga hakbang ng encoding. Una, mula sa bit stream ay kinukuha ang mga header at parameter ng compression — profile, level, resolution, color space. Pagkatapos, sequencial na pinoproseso ng decoder ang mga naka-compress na macroblock, inaapply ang inverse transformations sa kanila.

Mga yugto ng decoding ng video stream

Unang yugto — pagkuha ng entropy code. Entropy decoding ay gumagamit ng CABAC o CAVLC algorithm upang ibalik ang coefficients ng discrete cosine transform. Ang yugtong ito ay hindi nakadepende sa resolution ng video — pinoproseso nito ang bit stream, hindi ang mga pixel, at ang complexity nito ay tinutukoy ng bitrate, hindi ng laki ng frame.

Ikalawang yugto — inverse quantization at inverse DCT. I-multiply ng decoder ang quantized coefficients sa quantization step, ibinabalik ang approximate values ng DCT coefficients, pagkatapos ay inaapply ang inverse DCT transform. Inverse DCT ay nagpapanumbalik ng spatial data mula sa frequency domain, na bumubuo ng macroblock ng mga pixel. Para sa chroma at luma, ang transform ay ginagawa nang independyente.

Ikatlong yugto — motion compensation. Para sa P- at B-frames, gumagamit ang decoder ng motion vectors na nakuha mula sa bit stream at tumutukoy sa mga naunang na-decode na reference frame. Motion compensation ay lumilikha ng predictor ng kasalukuyang macroblock, kung saan idinaragdag ang residual signal pagkatapos ng inverse DCT. Resulta — isang ganap na na-restore na frame, handa para sa output.

// Pseudocode ng pangunahing decoding ng video frame
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;
    }
};

Sa halimbawa sa itaas ay ipinapakita ang pangunahing istraktura ng H.264 decoder. Ang function na decodeNALUnit ay tumatanggap ng NAL unit — ang pangunahing bloke ng naka-compress na H.264 stream. Sequencial na ina-parse ng decoder ang header, kinukuha ang slice type, inaapply ang entropy decoding, inverse quantization at inverse DCT. Para sa P- at B-slices, karagdagang ginagawa ang motion compensation gamit ang reference frames mula sa DPB buffer.

Mga format ng compression at codec

Ang mga modernong video codec ay nagkakaiba sa compression algorithm, efficiency at mga kinakailangan sa computing resources. Ang pagpili ng format ay direktang nakakaapekto sa laki ng file, kalidad ng imahe at konsumo ng enerhiya sa decoding sa mobile device.

H.264 ay ang pinakalaganap na video codec, suportado ng lahat ng mobile device. Ang pangunahing bentahe nito ay universalidad: anumang Android smartphone at iPhone ay maaaring mag-decode ng H.264 sa hardware. Gayunpaman, sa parehong bitrate, ang H.264 ay natalo sa kalidad kumpara sa mas modernong codec na H.265 at AV1, nangangailangan ng 30–50% mas maraming bitrate para sa katulad na visual na kalidad.

H.265 ay nagbibigay ng dalawang beses na mas mahusay na compression kumpara sa H.264 sa parehong kalidad. Ang decoding ng H.265 ay nangangailangan ng mas malakas na hardware block: VideoToolbox sa iOS ay sumusuporta sa H.265 simula sa iPhone 6 (A8), at Android devices — mula Snapdragon 805 pataas. Sa pagpili ng H.265 para sa mobile application, dapat isaalang-alang na ang mga lumang device ay maaaring walang hardware support at ide-decode ang format na ito sa software, na drastic na nagpapataas ng konsumo ng enerhiya.

AV1 ay isang open codec mula sa Alliance for Open Media, na nagbibigay ng pinakamahusay na compression sa lahat ng modernong format. Ang AV1 ay 30% mas efficient kaysa sa H.265 at 50% mas efficient kaysa sa H.264 sa parehong visual na kalidad. Hardware decoding ng AV1 ay lumitaw lamang sa SoC ng 2023+: Apple A17 Pro, Qualcomm Snapdragon 8 Gen 2 at mas bago. Para sa mas lumang device, ang AV1 decoding ay posible lamang sa software sa pamamagitan ng library dav1d, na lumilikha ng malaking load sa CPU.

Software vs hardware decoding

Ang pagpili sa pagitan ng software at hardware decoding ay isang pangunahing architectural decision sa pag-develop ng mobile media player. Ang bawat approach ay may kanya-kanyang advantages at limitations na dapat isaalang-alang sa pag-design ng application.

Performance at konsumo ng enerhiya

Ang hardware decoding ay ginagawa sa specialized video processing blocks na kumokonsumo ng makabuluhang mas kaunting enerhiya kaysa CPU sa paggawa ng parehong gawain. Ayon sa data ng Qualcomm, ang hardware H.265 decoder ay kumokonsumo ng 5–10 beses na mas kaunting enerhiya kaysa software decoding sa CPU Snapdragon 8 Gen 1 sa pag-playback ng 4K video. Ito ay kritikal para sa mga mobile device kung saan ang bawat milliwatt ay nakakaapekto sa buhay ng baterya.

Ang software decoding, sa kabilang banda, ay nagbibigay ng maximum flexibility. FFmpeg kasama ang library libavcodec ay sumusuporta sa dose-dosenang codec at container, kabilang ang mga bihira at luma na format na walang hardware support. Maaaring baguhin ng developer ang pipeline ng decoding, magdagdag ng post-processing at filters on the fly, na imposible sa paggamit ng closed hardware blocks.

Kailan pumili ng software decoding

Ang software decoding ay makatwiran sa ilang scenarios: sa pag-playback ng mga bihirang format (ProRes, DNxHD, Motion JPEG), kapag kinakailangan ang tumpak na kontrol sa bawat yugto ng pagpoproseso ng frame, at gayundin sa AV1 decoding sa mga device na walang hardware support. libavcodec mula sa FFmpeg ay nagbibigay-daan sa decoding ng halos anumang kilalang format, na ginagawa itong de facto standard para sa universal media player.

Ang limitasyon ng software decoding ay heat generation. Ang tuloy-tuloy na decoding ng 4K video sa CPU ay maaaring magpainit ng device hanggang 45–50 degrees sa loob ng 10–15 minuto, na nagdudulot ng thermal throttling at pagbaba ng frame rate. Sa mga device na walang active cooling (tablet, telepono), ito ay lalong kapansin-pansin. Ang konsumo ng kuryente ng CPU sa software decoding ay maaaring umabot ng 3–5 W kumpara sa 0.3–0.5 W sa hardware decoding ng parehong stream.

Kailan pumili ng hardware decoding

Ang hardware decoding ay ang default na pagpipilian para sa anumang production media player. Ito ay nagbibigay ng stable na 60 frames/sec para sa 4K video na may minimal na konsumo ng enerhiya. VideoToolbox sa iOS at MediaCodec sa Android ay nagbibigay ng native API para sa hardware decoding na automatic na pumipili ng optimal processing block depende sa codec at resolution.

Ang platform API ay humahawak ng pamamahala ng frame buffers (surface pool sa Android, CVPixelBufferPool sa iOS), synchronization sa display at memory optimization. Kailangan lang buksan ng developer ang decoder na may tamang parameters at tumanggap ng mga ready frame. Hardware decoding ay sumusuporta sa end-to-end pipeline na may minimal latency: mula sa pagtanggap ng bit stream hanggang sa display sa screen ay 5–15 ms kumpara sa 30–80 ms sa software decoding.

Mga halimbawa ng code ng decoding

Tingnan natin ang praktikal na implementasyon ng decoding sa parehong mobile platform. Sa iOS, ang hardware decoding ay ginagawa sa pamamagitan ng VideoToolbox, at software decoding — sa pamamagitan ng FFmpeg. Sa Android, ginagamit ang MediaCodec para sa hardware decoding.

Hardware decoding sa iOS gamit ang 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

Ang code ay nagpapakita ng initialization ng H.264 hardware decoder sa iOS. VTDecompressionSessionCreate ay lumilikha ng decoding session, at VTCreate ay tumatawag ng callback kapag may lumitaw na ready frame. Ang session ay automatic na gumagamit ng hardware block kung available para sa specified codec. Para sa pagtanggap ng decoded frames sa CVPixelBuffer format, ginagamit ang callback na nagpapadala ng bawat ready frame na may minimal latency.

Hardware decoding sa Android gamit ang 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);
}

Sa Android, ang MediaCodec ay gumagamit ng Surface para sa output, hindi pixel buffer, na nagmi-minimize ng pag-copy ng data sa pagitan ng GPU at CPU. Automatic na pumipili ang decoder ng hardware block (OMX component) batay sa uri ng codec. Para sa H.264, ginagamit ang OMX.google.h264.decoder, na maaaring parehong hardware at software depende sa implementasyon ng manufacturer.

Paano pumili ng decoder para sa mobile application

Ang pagpili ng decoding strategy ay depende sa target audience ng application, supported format at performance requirements. Ang optimal solution ay kadalasang may kasamang hybrid approach: hardware decoding para sa mga pangunahing format (H.264, H.265) na may software fallback para sa mga bihirang codec.

Strategy ng pagpili ayon sa priorities

Kung ang application ay nakatutok sa maximum compatibility — gamitin ang H.264, na guaranteed na ide-decode sa hardware sa anumang device. Para sa video streaming services, ang H.265 na may hardware support sa mga device pagkatapos ng 2016 ay makatwiran. AV1 ay pagpipilian para sa mga serbisyo kung saan mahalaga ang pagtitipid ng bandwidth: YouTube, Netflix at iba pang malalaking platform ay aktibong nagpapatupad ng AV1 para mabawasan ang gastos sa CDN habang pinapanatili ang kalidad.

Ang kritikal na parameter — buffer size ng decoder. Ang mga hardware decoder ay may fixed buffer pool (karaniwang 4–16 frames). Sa pag-playback ng high-bitrate stream, ang buffers ay maaaring mapuno, na nagdudulot ng paglaktaw ng frames. MediaCodec ay nagbibigay ng getOutputFrameRate method para sa pagtukoy ng actual performance ng decoder sa specific device, at ang VideoToolbox ay nagpapahintulot ng realtime priority control sa pamamagitan ng kVTDecodeFrame_EnableAsynchronousDecompression.

Ang thermal throttling ay isa pang factor. Kahit ang hardware decoding ay maaaring magpainit ng device sa matagal na pag-playback ng 4K HDR video. Inirerekomenda na subaybayan ang temperatura sa pamamagitan ng ProcessInfo sa iOS at BatteryManager sa Android, ibababa ang kalidad o resolution ng stream kapag sobrang init. Ito ay lalong kritikal para sa mga laro at streaming application na may mahabang panonood.