Decoding di Aplikasi Seluler: apa itu, konsep dasar dan prinsip kerja

Apa itu decoding?

Decoding adalah proses mengubah data digital terkompresi kembali ke format tidak terkompresi asli. Dalam konteks media, decoding mengembalikan bingkai video dari aliran bit terkompresi yang dibuat oleh encoder. Tanpa decoding, pengguna tidak dapat melihat video atau mendengar audio, karena semua format media modern menggunakan kompresi untuk menghemat bandwidth dan ruang disk.

Aliran video tipikal dalam format H.264 dengan bitrate 5 Mbps memakan ruang 100 kali lebih sedikit daripada aliran RGB tidak terkompresi dengan resolusi serupa. Algoritma decoding harus mengembalikan setiap bingkai kembali ke resolusi dan ruang warna asli, mengikuti spesifikasi codec dalam urutan terbalik terhadap pengkodean. Untuk ini, decoder memproses data intra-frame (I-frame) dan inter-frame (P-frame, B-frame).

Di perangkat seluler, decoding dapat terjadi baik pada CPU maupun pada blok perangkat keras khusus. SoC modern dari Apple (seri A), Qualcomm (Snapdragon) dan MediaTek (Dimensity) mengandung decoder bawaan untuk semua format populer. Prosesor video mengambil alih pekerjaan berat transformasi kosinus diskrit terbalik dan kompensasi gerakan, membebaskan CPU untuk tugas-tugas lain.

Bagaimana cara kerja decoding?

Proses decoding terdiri dari beberapa tahap berurutan yang membalikkan langkah-langkah pengkodean. Pertama, dari aliran bit diekstrak header dan parameter kompresi — profil, level, resolusi, ruang warna. Kemudian decoder secara berurutan memproses makroblok terkompresi, menerapkan transformasi terbalik padanya.

Tahapan decoding aliran video

Tahap pertama — ekstraksi kode entropi. Decoding entropi menggunakan algoritma CABAC atau CAVLC untuk mengembalikan koefisien transformasi kosinus diskrit. Tahap ini tidak bergantung pada resolusi video — ia memproses aliran bit, bukan piksel, dan kompleksitasnya ditentukan oleh bitrate, bukan ukuran bingkai.

Tahap kedua — kuantisasi terbalik dan DCT terbalik. Decoder mengalikan koefisien terkuantisasi dengan langkah kuantisasi, mengembalikan nilai perkiraan koefisien DCT, kemudian menerapkan transformasi DCT terbalik. DCT terbalik mengembalikan data spasial dari domain frekuensi, membentuk makroblok piksel. Untuk krominansi dan luminansi, transformasi dilakukan secara independen.

Tahap ketiga — kompensasi gerakan. Untuk bingkai P dan B, decoder menggunakan vektor gerakan yang diekstrak dari aliran bit dan merujuk ke bingkai referensi yang telah didecode sebelumnya. Kompensasi gerakan membuat prediktor makroblok saat ini, yang ditambahkan sinyal residu setelah DCT terbalik. Hasilnya — bingkai yang sepenuhnya dipulihkan, siap untuk ditampilkan.

// Pseudocode decoding dasar bingkai video
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;
    }
};

Dalam contoh di atas ditunjukkan struktur dasar decoder H.264. Fungsi decodeNALUnit menerima unit NAL — blok dasar aliran H.264 terkompresi. Decoder secara berurutan mengurai header, mengekstrak jenis slice, menerapkan decoding entropi, kuantisasi terbalik dan DCT terbalik. Untuk slice P dan B, kompensasi gerakan juga dilakukan menggunakan bingkai referensi dari buffer DPB.

Format kompresi dan codec

Codec video modern berbeda dalam algoritma kompresi, efisiensi dan persyaratan sumber daya komputasi. Pemilihan format secara langsung mempengaruhi ukuran file, kualitas gambar dan konsumsi energi saat decoding pada perangkat seluler.

H.264 adalah codec video paling luas, didukung oleh semua perangkat seluler. Keuntungan utamanya adalah universalitas: smartphone Android dan iPhone mana pun dapat mendecode H.264 secara perangkat keras. Namun, pada bitrate yang sama, H.264 kalah kualitas dibandingkan codec yang lebih modern H.265 dan AV1, membutuhkan 30–50% lebih banyak bitrate untuk kualitas visual yang serupa.

H.265 memberikan kompresi dua kali lebih baik dibandingkan dengan H.264 pada kualitas yang sama. Decoding H.265 membutuhkan blok perangkat keras yang lebih kuat: VideoToolbox di iOS mendukung H.265 mulai dari iPhone 6 (A8), dan perangkat Android — dengan Snapdragon 805 ke atas. Saat memilih H.265 untuk aplikasi seluler, perlu dipertimbangkan bahwa perangkat lama mungkin tidak memiliki dukungan perangkat keras dan akan mendecode format ini secara perangkat lunak, yang secara drastis meningkatkan konsumsi energi.

AV1 adalah codec terbuka dari Alliance for Open Media, yang memberikan kompresi terbaik di antara semua format modern. AV1 30% lebih efisien daripada H.265 dan 50% lebih efisien daripada H.264 pada kualitas visual yang sama. Decoding perangkat keras AV1 baru muncul di SoC tahun 2023+: Apple A17 Pro, Qualcomm Snapdragon 8 Gen 2 dan yang lebih baru. Untuk perangkat yang lebih lama, decoding AV1 hanya mungkin dilakukan secara perangkat lunak melalui pustaka dav1d, yang menciptakan beban signifikan pada CPU.

Decoding perangkat lunak vs perangkat keras

Pilihan antara decoding perangkat lunak dan perangkat keras adalah keputusan arsitektur kunci dalam pengembangan pemutar media seluler. Setiap pendekatan memiliki kelebihan dan keterbatasan yang harus dipertimbangkan saat merancang aplikasi.

Kinerja dan konsumsi energi

Decoding perangkat keras dilakukan pada blok pemrosesan video khusus yang mengkonsumsi energi jauh lebih sedikit daripada CPU saat melakukan tugas yang sama. Menurut data Qualcomm, decoder perangkat keras H.265 mengkonsumsi 5–10 kali lebih sedikit energi daripada decoding perangkat lunak pada CPU Snapdragon 8 Gen 1 saat memutar video 4K. Ini sangat penting untuk perangkat seluler di mana setiap miliwatt mempengaruhi daya tahan baterai.

Decoding perangkat lunak, sebaliknya, memberikan fleksibilitas maksimal. FFmpeg dengan pustaka libavcodec mendukung puluhan codec dan wadah, termasuk format langka dan usang yang tidak memiliki dukungan perangkat keras. Pengembang dapat memodifikasi pipeline decoding, menambahkan pasca-pemrosesan dan filter secara langsung, yang tidak mungkin dilakukan saat menggunakan blok perangkat keras tertutup.

Kapan memilih decoding perangkat lunak

Decoding perangkat lunak dibenarkan dalam beberapa skenario: saat memutar format langka (ProRes, DNxHD, Motion JPEG), saat diperlukan kontrol yang tepat atas setiap tahap pemrosesan bingkai, serta saat decoding AV1 pada perangkat tanpa dukungan perangkat keras. libavcodec dari FFmpeg memungkinkan decoding hampir semua format yang dikenal, menjadikannya standar de facto untuk pemutar media universal.

Keterbatasan decoding perangkat lunak adalah pelepasan panas. Decoding terus-menerus video 4K pada CPU dapat memanaskan perangkat hingga 45–50 derajat dalam 10–15 menit, yang menyebabkan thermal throttling dan penurunan frekuensi bingkai. Pada perangkat tanpa pendinginan aktif (tablet, telepon), ini sangat terlihat. Konsumsi daya CPU saat decoding perangkat lunak dapat mencapai 3–5 W dibandingkan dengan 0,3–0,5 W saat decoding perangkat keras dari aliran yang sama.

Kapan memilih decoding perangkat keras

Decoding perangkat keras adalah pilihan default untuk pemutar media produksi apa pun. Ini memberikan 60 bingkai/dtk yang stabil untuk video 4K dengan konsumsi energi minimal. VideoToolbox di iOS dan MediaCodec di Android menyediakan API asli untuk decoding perangkat keras yang secara otomatis memilih blok pemrosesan optimal tergantung pada codec dan resolusi.

API platform menangani pengelolaan buffer bingkai (surface pool di Android, CVPixelBufferPool di iOS), sinkronisasi dengan layar dan optimalisasi memori. Pengembang cukup membuka decoder dengan parameter yang diperlukan dan menerima bingkai yang sudah jadi. Decoding perangkat keras mendukung pipeline ujung-ke-ujung dengan latensi minimal: dari penerimaan aliran bit hingga tampilan di layar membutuhkan waktu 5–15 ms dibandingkan dengan 30–80 ms pada decoding perangkat lunak.

Contoh kode decoding

Mari kita lihat implementasi praktis decoding di kedua platform seluler. Di iOS, decoding perangkat keras dilakukan melalui VideoToolbox, dan decoding perangkat lunak melalui FFmpeg. Di Android, MediaCodec digunakan untuk decoding perangkat keras.

Decoding perangkat keras di iOS dengan 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

Kode menunjukkan inisialisasi decoder perangkat keras H.264 di iOS. VTDecompressionSessionCreate membuat sesi decoding, dan VTCreate memanggil callback ketika bingkai siap muncul. Sesi secara otomatis menggunakan blok perangkat keras jika tersedia untuk codec yang ditentukan. Untuk menerima bingkai yang didecode dalam format CVPixelBuffer, digunakan callback yang mengirimkan setiap bingkai siap dengan latensi minimal.

Decoding perangkat keras di Android dengan 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);
}

Di Android, MediaCodec menggunakan Surface untuk keluaran, bukan buffer piksel, yang meminimalkan penyalinan data antara GPU dan CPU. Decoder secara otomatis memilih blok perangkat keras (komponen OMX) berdasarkan jenis codec. Untuk H.264, digunakan OMX.google.h264.decoder, yang bisa berupa perangkat keras atau perangkat lunak tergantung pada implementasi produsen.

Cara memilih decoder untuk aplikasi seluler

Pemilihan strategi decoding tergantung pada audiens target aplikasi, format yang didukung dan persyaratan kinerja. Solusi optimal sering kali mencakup pendekatan hibrida: decoding perangkat keras untuk format utama (H.264, H.265) dengan fallback perangkat lunak untuk codec langka.

Strategi pemilihan berdasarkan prioritas

Jika aplikasi berorientasi pada kompatibilitas maksimal — gunakan H.264, yang dijamin akan didecode secara perangkat keras di perangkat mana pun. Untuk layanan streaming video, H.265 dengan dukungan perangkat keras pada perangkat setelah 2016 dibenarkan. AV1 adalah pilihan untuk layanan di mana penghematan bandwidth penting: YouTube, Netflix dan platform besar lainnya secara aktif mengimplementasikan AV1 untuk mengurangi biaya CDN sambil mempertahankan kualitas.

Parameter kritis — ukuran buffer decoder. Decoder perangkat keras memiliki kumpulan buffer tetap (biasanya 4–16 bingkai). Saat memutar aliran dengan bitrate tinggi, buffer dapat meluap, yang menyebabkan bingkai terlewat. MediaCodec menyediakan metode getOutputFrameRate untuk menentukan kinerja aktual decoder pada perangkat tertentu, dan VideoToolbox memungkinkan kontrol prioritas real-time melalui kVTDecodeFrame_EnableAsynchronousDecompression.

Thermal throttling adalah faktor lain. Bahkan decoding perangkat keras dapat memanaskan perangkat saat pemutaran video 4K HDR yang berkepanjangan. Disarankan untuk memantau suhu melalui ProcessInfo di iOS dan BatteryManager di Android, menurunkan kualitas atau resolusi aliran saat terlalu panas. Ini sangat penting untuk game dan aplikasi streaming dengan sesi menonton yang panjang.