Decoding در برنامه‌های موبایل: چیست، مفاهیم پایه و اصل کار

Decoding چیست؟

Decoding فرآیند تبدیل داده‌های دیجیتال فشرده به فرمت فشرده‌نشده اصلی است. در زمینه رسانه، دیکدینگ فریم‌های ویدیو را از جریان بیت فشرده ایجاد شده توسط انکودر بازیابی می‌کند. بدون دیکدینگ، کاربر نمی‌تواند ویدیو را ببیند یا صدا را بشنود، زیرا تمام فرمت‌های مدرن رسانه برای صرفه‌جویی در پهنای باند و فضای دیسک از فشرده‌سازی استفاده می‌کنند.

یک جریان ویدیوی معمولی در فرمت H.264 با بیت‌ریت 5 مگابیت بر ثانیه 100 برابر کمتر از یک جریان RGB فشرده‌نشده با رزولوشن مشابه فضا اشغال می‌کند. الگوریتم دیکدینگ باید هر فریم را به رزولوشن و فضای رنگی اصلی بازگرداند و طبق مشخصات کدک به ترتیب معکوس نسبت به کدگذاری عمل کند. برای این کار، دیکدر داده‌های درون‌فریمی (I-frame) و بین‌فریمی (P-frame, B-frame) را پردازش می‌کند.

در دستگاه‌های موبایل، دیکدینگ می‌تواند هم روی CPU و هم روی بلوک‌های سخت‌افزاری اختصاصی انجام شود. SoCهای مدرن اپل (سری A)، کوالکام (Snapdragon) و مدیاتک (Dimensity) حاوی دیکدرهای داخلی برای همه فرمت‌های محبوب هستند. پردازنده ویدیو کار سنگین تبدیل کسینوسی گسسته معکوس و جبران حرکت را بر عهده می‌گیرد و CPU را برای وظایف دیگر آزاد می‌کند.

دیکدینگ چگونه کار می‌کند؟

فرآیند دیکدینگ از چند مرحله متوالی تشکیل شده است که مراحل کدگذاری را معکوس می‌کنند. ابتدا هدرها و پارامترهای فشرده‌سازی — پروفایل، سطح، رزولوشن، فضای رنگی — از جریان بیت استخراج می‌شوند. سپس دیکدر به ترتیب ماکروبلاک‌های فشرده را پردازش می‌کند و تبدیل‌های معکوس را روی آنها اعمال می‌کند.

مراحل دیکدینگ جریان ویدیو

مرحله اول — استخراج کد آنتروپی. دیکدینگ آنتروپی از الگوریتم‌های CABAC یا CAVLC برای بازیابی ضرایب تبدیل کسینوسی گسسته استفاده می‌کند. این مرحله به رزولوشن ویدیو بستگی ندارد — جریان بیت را پردازش می‌کند، نه پیکسل‌ها، و پیچیدگی آن با بیت‌ریت تعیین می‌شود، نه اندازه فریم.

مرحله دوم — کوانتیزه‌سازی معکوس و DCT معکوس. دیکدر ضرایب کوانتیزه شده را در گام کوانتیزه‌سازی ضرب می‌کند و مقادیر تقریبی ضرایب DCT را بازیابی می‌کند، سپس تبدیل DCT معکوس را اعمال می‌کند. DCT معکوس داده‌های مکانی را از حوزه فرکانس بازیابی می‌کند و یک ماکروبلاک پیکسل تشکیل می‌دهد. برای کرومینانس و لومینانس، تبدیل به طور مستقل انجام می‌شود.

مرحله سوم — جبران حرکت. برای فریم‌های P و B، دیکدر از بردارهای حرکت استخراج شده از جریان بیت استفاده می‌کند و به فریم‌های مرجع قبلاً دیکد شده ارجاع می‌دهد. جبران حرکت یک پیش‌بین برای ماکروبلاک جاری ایجاد می‌کند که سیگنال باقی‌مانده پس از 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 ایجاد می‌کند.

دیکدینگ نرم‌افزاری در مقابل سخت‌افزاری

انتخاب بین دیکدینگ نرم‌افزاری و سخت‌افزاری یک تصمیم معماری کلیدی در توسعه پخش‌کننده رسانه موبایل است. هر رویکرد مزایا و محدودیت‌های خاص خود را دارد که باید در طراحی برنامه در نظر گرفته شود.

عملکرد و مصرف انرژی

دیکدینگ سخت‌افزاری روی بلوک‌های تخصصی پردازش ویدیو انجام می‌شود که انرژی قابل توجهی کمتری نسبت به CPU هنگام انجام همان کار مصرف می‌کنند. طبق داده‌های Qualcomm، دیکدر سخت‌افزاری H.265 در پخش ویدیوی 4K، 5–10 برابر کمتر از دیکدینگ نرم‌افزاری روی CPU Snapdragon 8 Gen 1 انرژی مصرف می‌کند. این موضوع برای دستگاه‌های موبایل که هر میلی‌وات بر عمر باتری تأثیر می‌گذارد، حیاتی است.

دیکدینگ نرم‌افزاری در مقابل، حداکثر انعطاف‌پذیری را ارائه می‌دهد. FFmpeg با کتابخانه libavcodec از ده‌ها کدک و کانتینر از جمله فرمت‌های نادر و قدیمی که پشتیبانی سخت‌افزاری ندارند، پشتیبانی می‌کند. توسعه‌دهنده می‌تواند خط لوله دیکدینگ را تغییر دهد، پس‌پردازش و فیلترها را در لحظه اضافه کند که با استفاده از بلوک‌های سخت‌افزاری بسته امکان‌پذیر نیست.

چه زمانی دیکدینگ نرم‌افزاری را انتخاب کنیم

دیکدینگ نرم‌افزاری در چند سناریو توجیه‌پذیر است: هنگام پخش فرمت‌های نادر (ProRes، DNxHD، Motion JPEG)، زمانی که کنترل دقیق بر هر مرحله پردازش فریم لازم است، و همچنین هنگام دیکدینگ AV1 در دستگاه‌های بدون پشتیبانی سخت‌افزاری. libavcodec از FFmpeg امکان دیکد کردن تقریباً هر فرمت شناخته شده‌ای را فراهم می‌کند که آن را به استاندارد دوفاکتو برای پخش‌کننده‌های جهانی رسانه تبدیل می‌کند.

محدودیت دیکدینگ نرم‌افزاری — تولید گرما است. دیکدینگ مداوم ویدیوی 4K روی CPU می‌تواند دستگاه را در 10–15 دقیقه به 45–50 درجه برساند که منجر به throttling و کاهش نرخ فریم می‌شود. در دستگاه‌های بدون خنک‌کننده فعال (تبلت‌ها، تلفن‌ها) این موضوع به ویژه قابل توجه است. مصرف برق CPU در دیکدینگ نرم‌افزاری می‌تواند به 3–5 وات برسد در مقایسه با 0.3–0.5 وات در دیکدینگ سخت‌افزاری همان جریان.

چه زمانی دیکدینگ سخت‌افزاری را انتخاب کنیم

دیکدینگ سخت‌افزاری انتخاب پیش‌فرض برای هر پخش‌کننده رسانه تولیدی است. این روش 60 فریم بر ثانیه پایدار برای ویدیوی 4K با حداقل مصرف انرژی تضمین می‌کند. VideoToolbox در iOS و MediaCodec در Android APIهای بومی برای دیکدینگ سخت‌افزاری ارائه می‌دهند که بسته به کدک و رزولوشن به طور خودکار بلوک پردازش بهینه را انتخاب می‌کنند.

APIهای پلتفرمی مدیریت بافر فریم‌ها (surface pool در Android، CVPixelBufferPool در iOS)، همگام‌سازی با نمایشگر و بهینه‌سازی حافظه را بر عهده می‌گیرند. توسعه‌دهنده فقط باید دیکدر را با پارامترهای مورد نیاز باز کند و فریم‌های آماده را دریافت کند. دیکدینگ سخت‌افزاری از خط لوله سرتاسری با حداقل تأخیر پشتیبانی می‌کند: از دریافت جریان بیت تا نمایش روی صفحه 5–15 میلی‌ثانیه در مقایسه با 30–80 میلی‌ثانیه در دیکدینگ نرم‌افزاری.

نمونه کد دیکدینگ

بیایید پیاده‌سازی عملی دیکدینگ را در هر دو پلتفرم موبایل بررسی کنیم. در 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 با ظاهر شدن فریم آماده، callback را فراخوانی می‌کند. جلسه به طور خودکار از بلوک سخت‌افزاری استفاده می‌کند اگر برای کدک مشخص شده در دسترس باشد. برای دریافت فریم‌های دیکد شده در قالب CVPixelBuffer از callback استفاده می‌شود که هر فریم آماده را با حداقل تأخیر ارسال می‌کند.

دیکدینگ سخت‌افزاری در 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 را به حداقل می‌رساند. دیکدر به طور خودکار بلوک سخت‌افزاری (کامپوننت 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 را فراهم می‌کند.

throttling حرارتی عامل دیگری است. حتی دیکدینگ سخت‌افزاری نیز می‌تواند دستگاه را در پخش طولانی مدت ویدیوی 4K HDR گرم کند. توصیه می‌شود دما را از طریق ProcessInfo در iOS و BatteryManager در Android نظارت کنید و در صورت گرم شدن بیش از حد، کیفیت یا رزولوشن جریان را کاهش دهید. این موضوع به ویژه برای بازی‌ها و برنامه‌های پخش با جلسات تماشای طولانی حیاتی است.