دیکدینگ سخت‌افزاری: چیست، اصل کار و مزایا

دیکدینگ سخت‌افزاری چیست؟

Hardware decoding — فرآیند فشردگی‌زدایی داده‌های رسانه‌ای است که نه روی CPU عمومی، بلکه روی مدارهای مجتمع تخصصی یکپارچه در سیستم-روی-تراشه (SoC) انجام می‌شود. این بلوک‌ها دیکدرهای ویدئو یا VPU (Video Processing Unit) نامیده می‌شوند و شتاب‌دهنده‌های ASIC بهینه‌سازی شده برای الگوریتم‌های فشرده‌سازی خاص هستند.

SoCهای مدرن موبایل شامل بلوک‌های سخت‌افزاری جداگانه برای هر کدک محبوب هستند. مثلاً تراشه Apple A17 Pro شامل دیکدرهایی برای H.264، H.265، VP9، AV1 و ProRes است. هر بلوک یک خط لوله پردازش کامل را تشکیل می‌دهد که قادر است جریان بیت فشرده را در ورودی دریافت کرده و فریم‌های دیکد شده آماده در قالب YUV یا BGRA را در خروجی بدون دخالت CPU تحویل دهد.

دیکدینگ سخت‌افزاری در سال‌های ۲۰۱۲–۲۰۱۳ به استانداردی در صنعت موبایل تبدیل شد، زمانی که Qualcomm Snapdragon 800 و Apple A7 برای اولین بار بلوک‌های اختصاصی دیکدینگ H.264 را شامل شدند. از آن زمان، فناوری از پشتیبانی از یک فرمت به بلوک‌های چندفرمتی جهانی که قادر به دیکدینگ همزمان چندین جریان هستند تکامل یافته است — مثلاً برای کار PiP با جریان ویدئوی جداگانه.

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

فرآیند دیکدینگ سخت‌افزاری تفاوت اساسی با نرم‌افزاری دارد. به جای اجرای ترتیبی دستورالعمل‌های CPU، بلوک سخت‌افزاری مدارهای فیزیکی را برای هر مرحله از فشردگی‌زدایی پیاده‌سازی می‌کند: دیکدینگ آنتروپی، کمی‌سازی معکوس، DCT معکوس و جبران حرکت.

معماری دیکدر سخت‌افزاری

یک دیکدر سخت‌افزاری معمولی از چندین مرحله خط لوله تشکیل شده است. مرحله اول — دیکدر آنتروپی، به صورت ماشین حالت محدود (FSM) برای CABAC یا CAVLC پیاده‌سازی شده است. برخلاف پیاده‌سازی نرم‌افزاری که در آن هر بیت با انتقال‌های شرطی پردازش می‌شود، CABAC سخت‌افزاری از مدارهای پیش‌بینی زمینه موازی استفاده می‌کند که امکان پردازش ۲–۳ بیت در هر تیک را به جای یک بیت فراهم می‌کند.

مرحله دوم — بلوک DCT معکوس. DCT نرم‌افزاری نیازمند حلقه‌های ضرب-انباشت روی CPU است. پیاده‌سازی سخت‌افزاری از یک ضرب‌کننده ماتریسی استفاده می‌کند که تمام ۶۴ ضریب بلوک ۸×۸ را در یک تیک محاسبه می‌کند. DCT معکوس سخت‌افزاری با فرکانس ۴۰۰–۶۰۰ مگاهرتز کار می‌کند و تا ۴ میلیون ماکروبلوک در ثانیه پردازش می‌کند که برای دیکدینگ ویدئوی ۸K در زمان واقعی کافی است.

مرحله سوم — ماژول جبران حرکت (MC). به موازات DCT معکوس، بلوک سخت‌افزاری بردارهای حرکت را از جریان بیت دریافت کرده و نواحی مرجع را از بافر فریم‌های دیکد شده استخراج می‌کند. بافر DPB (Decoded Picture Buffer) تا ۱۶ فریم مرجع را ذخیره می‌کند که دسترسی به آنها از طریق حافظه نهان تخصصی با تأخیر کم انجام می‌شود. دیکدرهای مدرن از پیش‌بینی با هموارسازی تطبیقی و درون‌یابی زیرپیکسلی استفاده می‌کنند که برای H.265 و AV1 حیاتی است.

تعامل با سیستم

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

VideoToolbox و MediaCodec: مقایسه پلتفرم‌ها

هر دو پلتفرم موبایل API بومی برای دیکدینگ سخت‌افزاری ارائه می‌دهند، اما با رویکردهای متفاوت به مدیریت بافرها و چرخه عمر دیکدر. VideoToolbox در iOS با Metal برای خروجی به صفحه نمایش یکپارچه شده است و MediaCodec در Android از Surface برای رندرینگ مستقیم استفاده می‌کند.

VideoToolbox — فریم‌ورکی برای دیکدینگ سخت‌افزاری در iOS و macOS. از مدل دیکدینگ ناهمگام استفاده می‌کند: فراخوانی VTDecompressionSessionDecodeFrame بلافاصله بازمی‌گردد و فریم‌های آماده از طریق callback در صف جداگانه ارسال می‌شوند. VideoToolbox به طور خودکار استخر بافرهای پیکسلی (CVPixelBufferPool) را مدیریت کرده و می‌تواند بافرهای آزاد شده را برای فریم‌های جدید مجدداً استفاده کند. برای ویدئوی HDR، VideoToolbox از فضاهای رنگی ITU-R BT.2020 و PQ/HLG EOTF پشتیبانی می‌کند.

MediaCodec از مدل همگام با صف‌های بافر ورودی و خروجی استفاده می‌کند. برنامه به صورت چرخه‌ای dequeueInputBuffer را برای ارسال داده‌های فشرده و dequeueOutputBuffer را برای دریافت نتیجه دیکد شده فراخوانی می‌کند. این رویکرد به توسعه‌دهنده کنترل کامل بر سرعت دیکدینگ می‌دهد که برای همگام‌سازی صدا و ویدئو مهم است. برای خروجی به صفحه، MediaCodec Surface را می‌پذیرد که امکان دیکدینگ مستقیم روی GPU بدون کپی از طریق CPU را فراهم می‌کند.

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

دیکدینگ سخت‌افزاری سه مزیت کلیدی نسبت به نرم‌افزاری دارد: بهره‌وری انرژی، عملکرد و پایداری. هر یک از آنها برای دستگاه‌های موبایل با منابع باتری محدود و محدودیت‌های حرارتی حیاتی است.

بهره‌وری انرژی

مزیت اصلی دیکدینگ سخت‌افزاری — مصرف انرژی به طور چشمگیری کمتر است. یک دیکدر سخت‌افزاری معمولی H.264/H.265 هنگام دیکدینگ ویدئوی ۱۰۸۰p در زمان واقعی ۰.۲–۰.۵ وات مصرف می‌کند. برای مقایسه، دیکدینگ نرم‌افزاری همان جریان روی CPU بسته به معماری پردازنده ۱.۵–۴ وات مصرف می‌کند. تفاوت ۵–۱۰ برابر مستقیماً بر عمر باتری تأثیر می‌گذارد: هنگام تماشای ویدئو، دیکدینگ سخت‌افزاری امکان تماشای ۱۰–۱۵ ساعت فیلم را می‌دهد در مقابل ۲–۴ ساعت با دیکدینگ نرم‌افزاری روی CPU.

بهره‌وری انرژی از طریق تخصصی‌سازی محدود به دست می‌آید. برخلاف CPU که طیف گسترده‌ای از دستورالعمل‌ها را اجرا کرده و منطق کنترل پیچیده‌ای دارد، دیکدر سخت‌افزاری فقط شامل مدارهای لازم برای الگوریتم خاص است. فرکانس کلاک چنین بلوک‌هایی ۲۰۰–۶۰۰ مگاهرتز در مقابل ۲–۳ گیگاهرتز CPU است که مصرف انرژی دینامیک را به نسبت مربع ولتاژ کاهش می‌دهد.

عملکرد و تولید حرارت

دیکدینگ سخت‌افزاری نرخ فریم تضمینی حتی برای تفکیک‌پذیری‌های بالا ارائه می‌دهد. به لطف معماری خط لوله، بلوک سخت‌افزاری می‌تواند همزمان چندین مرحله فشردگی‌زدایی را پردازش کند: در حالی که یک ماژول دیکدینگ آنتروپی را برای ماکروبلوک بعدی انجام می‌دهد، ماژول دیگر DCT معکوس را روی ماکروبلوک فعلی اعمال می‌کند. این موازی‌سازی در CPU که هر مرحله یک عملیات ترتیبی است غیرقابل دستیابی است.

تولید حرارت دیکدر سخت‌افزاری به طور قابل توجهی کمتر است: یک بلوک معمولی ۰.۳–۰.۸ وات حرارت در مقابل ۲–۶ وات CPU در دیکدینگ نرم‌افزاری ویدئوی ۴K تولید می‌کند. این بدان معناست که دستگاه حتی در تماشای طولانی مدت داغ نمی‌کند، تروتلینگ رخ نمی‌دهد و کاربر ۶۰ FPS پایدار بدون افت دریافت می‌کند. دمای بدنه در دیکدینگ سخت‌افزاری معمولاً ۵–۱۰ درجه کمتر از نرم‌افزاری است که به ویژه برای تبلت‌های بدون خنک‌کننده فعال مهم است.

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

پیاده‌سازی عملی دیکدینگ سخت‌افزاری با پردازش callback در iOS از طریق VideoToolbox و خط لوله کامل در Android از طریق MediaCodec را بررسی می‌کنیم.

نمونه کامل دیکدینگ سخت‌افزاری در iOS

import VideoToolbox
import CoreMedia

class HardwareDecoder {
    var session: VTDecompressionSession?
    
    func setup() {
        let formatDesc = createFormatDescription()
        var callback = VTDecompressionOutputCallbackRecord(
            decompressionOutputCallback: decodingCallback,
            decompressionOutputRefCon: nil
        )
        VTDecompressionSessionCreate(
            allocator: nil,
            videoFormatDescription: formatDesc,
            videoDecoderSpecification: nil,
            destinationImageBufferAttributes: nil,
            outputCallback: &callback,
            decompressionSessionOut: &session
        )
    }
    
    func decode(sampleBuffer: CMSampleBuffer) {
        VTDecompressionSessionDecodeFrame(
            session!, sampleBuffer: sampleBuffer,
            flags: ._EnableAsynchronousDecompression,
            frameRefcon: nil, infoFlagsOut: nil
        )
    }
}

کد یک جلسه دیکدینگ VideoToolbox با callback ناهمگام ایجاد می‌کند. VTDecompressionSessionCreate به طور خودکار دیکدر سخت‌افزاری موجود را بر اساس CMVideoFormatDescription ارسالی تعیین می‌کند. پرچم kVTDecodeFrame_EnableAsynchronousDecompression حالت ناهمگام را فعال می‌کند — برنامه در طول دیکدینگ مسدود نمی‌شود و فریم‌ها را از طریق callback دریافت می‌کند. برای H.264 لازم است از طریق CMVideoFormatDescriptionCreateFromH264ParameterSets از واحدهای NAL SPS/PPS description format ایجاد شود.

دیکدینگ سخت‌افزاری در Android با خروجی روی Surface

class HardwareDecoder(private val surface: Surface) {
    private var mediaCodec: MediaCodec? = null
    
    fun initDecoder(mimeType: String, width: Int, height: Int) {
        mediaCodec = MediaCodec.createDecoderByType(mimeType)
        val format = MediaFormat.createVideoFormat(mimeType, width, height)
        
        mediaCodec?.configure(format, surface, null, 0)
        mediaCodec?.start()
    }
    
    fun feedFrame(data: ByteArray, pts: Long) {
        val inputIndex = mediaCodec!!.dequeueInputBuffer(TIMEOUT_US)
        if (inputIndex >= 0) {
            val buffer = mediaCodec!!.getInputBuffer(inputIndex)
            buffer?.put(data)
            mediaCodec!!.queueInputBuffer(inputIndex, 0, data.size, pts, 0)
        }
    }
}

کد در Kotlin MediaCodec را با اتصال به Surface ایجاد می‌کند که خروجی مستقیم به صفحه را بدون کپی داده از طریق CPU تضمین می‌کند. پارامتر mimeType از ثابت‌های MediaFormat استفاده می‌کند: video/avc برای H.264، video/hevc برای H.265، video/av01 برای AV1. متد dequeueInputBuffer منتظر بافر ورودی آزاد با timeout می‌ماند؛ اگر بافر در دسترس نباشد — فریم جاری رد می‌شود که از سرریز صف در نرخ بیت ناهموار جلوگیری می‌کند.

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

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

سناریوهای استفاده اجباری

دیکدینگ سخت‌افزاری در سه مورد اجباری است: پخش طولانی مدت ویدئو (بیش از ۳۰ دقیقه)، دیکدینگ محتوای ۴K و هر برنامه‌ای که حداکثر عمر باتری را هدف قرار می‌دهد. سرویس‌های استریمینگ (Netflix، YouTube، Twitch) منحصراً از دیکدینگ سخت‌افزاری استفاده می‌کنند زیرا نرم‌افزاری نمی‌تواند پخش پایدار در نرخ بیت بالا و تفکیک‌پذیری بزرگ را تضمین کند. برای این سرویس‌ها پشتیبانی DRM (FairPlay، Widevine) حیاتی است که فقط از طریق بلوک سخت‌افزاری فراهم کننده خط لوله محافظت شده از دیکدر تا نمایشگر در دسترس است.

برای بازی‌های با ویدئوی یکپارچه (صحنه‌های سینمایی، تبلیغات، ویدئوهای درون‌بازی) نیز دیکدینگ سخت‌افزاری توصیه می‌شود. موتورهای بازی مدرن مانند Unity و Unreal Engine پشتیبانی داخلی از VideoToolbox و MediaCodec دارند. دیکدینگ سخت‌افزاری در بازی‌ها CPU را برای شبیه‌سازی فیزیک، AI دشمنان و پردازش ورودی آزاد می‌کند که عملکرد کلی را افزایش می‌دهد.

محدودیت‌ها و fallback

محدودیت اصلی دیکدینگ سخت‌افزاری — وابستگی به پشتیبانی سخت‌افزاری فرمت است. اگر SoC شامل دیکدر AV1 نباشد (مثلاً دستگاه‌های Snapdragon 8 Gen 1)، برنامه باید fallback نرم‌افزاری از طریق FFmpeg و dav1d را فراهم کند. وضعیت مشابه با H.265 در دستگاه‌های قدیمی و ProRes که فقط روی تراشه‌های Apple A13+ برای دیکدینگ پشتیبانی می‌شود. توصیه می‌شود قبل از شروع پخش، در دسترس بودن دیکدر سخت‌افزاری فرمت مورد نیاز را بررسی کرده و استراتژی دیکدینگ را به صورت پویا انتخاب کنید.

محدودیت دوم — تعداد جلسات همزمان دیکدینگ. اکثر SoCها از ۱–۲ دیکدر سخت‌افزاری موازی پشتیبانی می‌کنند. در تلاش برای باز کردن جلسه سوم، API خطا برمی‌گرداند و برنامه باید به دیکدینگ نرم‌افزاری تغییر وضعیت دهد. تعداد جلسات به سازنده SoC بستگی دارد: تراشه‌های Apple تا ۴ جلسه دیکدینگ H.264 در A17 Pro و Snapdragon 8 Gen 2 تا ۲ جلسه برای H.265 و تا ۲ جلسه برای VP9 مجموعاً اجازه می‌دهند.