Giải mã phần cứng: khái niệm, nguyên lý hoạt động và lợi ích

Giải mã phần cứng là gì?

Hardware decoding là quá trình giải nén dữ liệu đa phương tiện được thực hiện không phải trên CPU đa năng, mà trên các mạch tích hợp chuyên dụng được tích hợp trong hệ thống trên chip (SoC). Các khối này được gọi là bộ giải mã video hoặc VPU (Video Processing Unit) và là bộ tăng tốc ASIC được tối ưu hóa cho các thuật toán nén cụ thể.

SoC di động hiện đại chứa các khối phần cứng riêng biệt cho mỗi codec phổ biến. Ví dụ, chip Apple A17 Pro bao gồm bộ giải mã cho H.264, H.265, VP9, AV1 và ProRes. Mỗi khối là một đường ống xử lý hoàn chỉnh có thể nhận luồng bit nén ở đầu vào và cung cấp các khung hình đã giải mã sẵn sàng ở định dạng YUV hoặc BGRA ở đầu ra mà không cần CPU tham gia.

Giải mã phần cứng đã trở thành tiêu chuẩn trong ngành công nghiệp di động vào năm 2012–2013, khi Qualcomm Snapdragon 800 và Apple A7 lần đầu tiên bao gồm các khối giải mã H.264 chuyên dụng. Kể từ đó, công nghệ đã phát triển từ hỗ trợ một định dạng duy nhất thành các khối đa định dạng phổ quát có khả năng giải mã nhiều luồng đồng thời — ví dụ, cho PiP với luồng video riêng biệt.

Giải mã phần cứng hoạt động như thế nào?

Quá trình giải mã phần cứng khác biệt hoàn toàn so với giải mã phần mềm. Thay vì thực thi lệnh CPU tuần tự, khối phần cứng thực hiện các mạch vật lý cho mỗi giai đoạn giải nén: giải mã entropy, lượng tử hóa ngược, DCT ngược và bù chuyển động.

Kiến trúc bộ giải mã phần cứng

Một bộ giải mã phần cứng điển hình bao gồm nhiều giai đoạn đường ống. Giai đoạn đầu tiên là bộ giải mã entropy, được triển khai như một máy trạng thái hữu hạn (FSM) cho CABAC hoặc CAVLC. Không giống như triển khai phần mềm nơi mỗi bit được xử lý với các rẽ nhánh có điều kiện, CABAC phần cứng sử dụng các mạch dự đoán ngữ cảnh song song, cho phép xử lý 2–3 bit mỗi chu kỳ thay vì một.

Giai đoạn thứ hai là khối DCT ngược. DCT phần mềm yêu cầu vòng lặp nhân-tích lũy trên CPU. Triển khai phần cứng sử dụng bộ nhân ma trận tính toán tất cả 64 hệ số của khối 8x8 trong một chu kỳ. DCT ngược phần cứng hoạt động ở 400–600 MHz và xử lý tới 4 triệu macroblock mỗi giây, đủ cho giải mã video 8K thời gian thực.

Giai đoạn thứ ba là mô-đun bù chuyển động (MC). Song song với DCT ngược, khối phần cứng nhận vectơ chuyển động từ luồng bit và trích xuất vùng tham chiếu từ bộ đệm khung hình đã giải mã. Bộ đệm DPB (Decoded Picture Buffer) lưu trữ tới 16 khung tham chiếu, được truy cập thông qua bộ nhớ đệm chuyên dụng có độ trễ thấp. Bộ giải mã hiện đại sử dụng dự đoán với làm mịn thích ứng và nội suy subpixel, điều này rất quan trọng đối với H.265 và AV1.

Tương tác với hệ thống

Việc quản lý bộ giải mã phần cứng diễn ra thông qua bộ điều khiển DMA. Ứng dụng truyền con trỏ đến dữ liệu nén trong bộ nhớ dùng chung cho bộ giải mã và bộ giải mã tự đọc luồng bit thông qua truy cập bộ nhớ trực tiếp. Sau khi hoàn tất giải mã khung hình, một ngắt thông báo cho trình điều khiển và khung hình sẵn sàng có sẵn trong nhóm bộ đệm đầu ra. Cơ chế này loại bỏ hoàn toàn tải CPU trong quá trình xử lý dữ liệu — bộ xử lý chỉ khởi tạo giải mã và nhận kết quả cuối cùng.

VideoToolbox và MediaCodec: so sánh nền tảng

Cả hai nền tảng di động đều cung cấp API gốc cho giải mã phần cứng, nhưng với các cách tiếp cận khác nhau để quản lý bộ đệm và vòng đời bộ giải mã. VideoToolbox trên iOS được tích hợp chặt chẽ với Metal để xuất ra màn hình, trong khi MediaCodec trên Android sử dụng Surface để kết xuất trực tiếp.

VideoToolbox là framework cho giải mã phần cứng trên iOS và macOS. Nó sử dụng mô hình giải mã bất đồng bộ: VTDecompressionSessionDecodeFrame trả về ngay lập tức và các khung hình sẵn sàng đến qua callback trên một hàng đợi riêng. VideoToolbox tự động quản lý nhóm bộ đệm pixel (CVPixelBufferPool) và có thể tái sử dụng bộ đệm đã giải phóng cho các khung hình mới. Đối với video HDR, VideoToolbox hỗ trợ không gian màu ITU-R BT.2020 và EOTF PQ/HLG.

MediaCodec sử dụng mô hình đồng bộ với hàng đợi bộ đệm đầu vào và đầu ra. Ứng dụng gọi theo chu kỳ dequeueInputBuffer để gửi dữ liệu nén và dequeueOutputBuffer để nhận kết quả đã giải mã. Cách tiếp cận này cho nhà phát triển toàn quyền kiểm soát tốc độ giải mã, điều này quan trọng cho đồng bộ hóa âm thanh và video. Để xuất ra màn hình, MediaCodec chấp nhận Surface, cho phép giải mã trực tiếp trên GPU mà không cần sao chép qua CPU.

Lợi ích của giải mã phần cứng

Giải mã phần cứng mang lại ba lợi ích chính so với phần mềm: hiệu suất năng lượng, hiệu năng và độ ổn định. Mỗi lợi ích đều quan trọng đối với thiết bị di động có tài nguyên pin hạn chế và ràng buộc nhiệt.

Hiệu suất năng lượng

Lợi ích chính của giải mã phần cứng là mức tiêu thụ điện năng thấp hơn triệt để. Một bộ giải mã phần cứng H.264/H.265 điển hình tiêu thụ 0,2–0,5W khi giải mã video 1080p theo thời gian thực. So sánh, giải mã phần mềm cùng luồng trên CPU tiêu thụ 1,5–4W tùy thuộc vào kiến trúc bộ xử lý. Sự khác biệt 5–10 lần ảnh hưởng trực tiếp đến thời lượng pin: với giải mã phần cứng, phát video cho phép xem phim 10–15 giờ so với 2–4 giờ với giải mã phần mềm trên CPU.

Hiệu suất năng lượng đạt được thông qua chuyên môn hóa hẹp. Không giống như CPU thực thi nhiều lệnh và có logic điều khiển phức tạp, bộ giải mã phần cứng chỉ chứa các mạch cần thiết cho một thuật toán cụ thể. Tần số xung nhịp của các khối này là 200–600 MHz so với 2–3 GHz của CPU, giúp giảm tiêu thụ điện năng động tỷ lệ với bình phương điện áp.

Hiệu năng và tản nhiệt

Giải mã phần cứng cung cấp tốc độ khung hình đảm bảo ngay cả cho độ phân giải cao. Nhờ kiến trúc đường ống, khối phần cứng có thể xử lý đồng thời nhiều giai đoạn giải nén: trong khi một mô-đun thực hiện giải mã entropy cho macroblock tiếp theo, mô-đun khác đã áp dụng DCT ngược cho macroblock hiện tại. Sự song song như vậy không thể đạt được trên CPU, nơi mỗi giai đoạn là một hoạt động tuần tự.

Tản nhiệt của bộ giải mã phần cứng thấp hơn đáng kể: một khối điển hình tỏa ra 0,3–0,8W nhiệt so với 2–6W của CPU khi giải mã video 4K. Điều này có nghĩa là thiết bị không quá nóng ngay cả khi xem kéo dài, không xảy ra hiện tượng giảm tốc và người dùng nhận được 60 FPS ổn định không bị sụt. Nhiệt độ vỏ khi giải mã phần cứng thường thấp hơn 5–10 độ so với giải mã phần mềm, điều này đặc biệt quan trọng đối với máy tính bảng không có làm mát chủ động.

Ví dụ mã giải mã phần cứng

Hãy xem xét triển khai thực tế của giải mã phần cứng với xử lý callback trên iOS qua VideoToolbox và đường ống hoàn chỉnh trên Android qua MediaCodec.

Ví dụ giải mã phần cứng hoàn chỉnh trên 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
        )
    }
}

Mã tạo phiên giải mã VideoToolbox với callback bất đồng bộ. VTDecompressionSessionCreate tự động phát hiện bộ giải mã phần cứng khả dụng dựa trên CMVideoFormatDescription được cung cấp. Cờ kVTDecodeFrame_EnableAsynchronousDecompression bật chế độ bất đồng bộ — ứng dụng không bị chặn trong quá trình giải mã và nhận khung hình qua callback. Đối với H.264, trước tiên bạn phải tạo mô tả định dạng từ các đơn vị NAL SPS/PPS qua CMVideoFormatDescriptionCreateFromH264ParameterSets.

Giải mã phần cứng trên Android với đầu ra 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)
        }
    }
}

Mã Kotlin tạo MediaCodec liên kết với Surface, đảm bảo đầu ra trực tiếp ra màn hình mà không sao chép dữ liệu qua CPU. Tham số mimeType sử dụng hằng số MediaFormat: video/avc cho H.264, video/hevc cho H.265, video/av01 cho AV1. Phương thức dequeueInputBuffer chờ bộ đệm đầu vào khả dụng với thời gian chờ; nếu không có bộ đệm khả dụng, khung hình hiện tại bị bỏ qua, ngăn tràn hàng đợi khi tốc độ bit không đồng đều.

Khi nào chọn giải mã phần cứng

Giải mã phần cứng là lựa chọn tối ưu cho hầu hết các kịch bản sản xuất, nhưng không phải là giải pháp phổ quát. Hiểu ranh giới áp dụng giúp tránh các tình huống thiếu hỗ trợ codec phần cứng làm hỏng trải nghiệm người dùng.

Các kịch bản sử dụng bắt buộc

Giải mã phần cứng là bắt buộc trong ba trường hợp: phát video kéo dài (hơn 30 phút), giải mã nội dung 4K và bất kỳ ứng dụng nào tập trung vào thời lượng pin tối đa. Các dịch vụ phát trực tuyến (Netflix, YouTube, Twitch) chỉ sử dụng giải mã phần cứng, vì phần mềm không thể đảm bảo phát lại ổn định ở tốc độ bit cao và độ phân giải lớn. Đối với các dịch vụ này, hỗ trợ DRM (FairPlay, Widevine) rất quan trọng, chỉ khả dụng thông qua khối phần cứng cung cấp đường ống được bảo vệ từ bộ giải mã đến đầu ra màn hình.

Đối với trò chơi có video tích hợp (cảnh cắt, quảng cáo, video trong game), giải mã phần cứng cũng được khuyến nghị. Các engine trò chơi hiện đại như Unity và Unreal Engine có hỗ trợ tích hợp cho VideoToolbox và MediaCodec. Giải mã phần cứng trong trò chơi giải phóng CPU cho mô phỏng vật lý, AI đối thủ và xử lý đầu vào, cải thiện hiệu năng tổng thể.

Giới hạn và dự phòng

Giới hạn chính của giải mã phần cứng là phụ thuộc vào hỗ trợ định dạng phần cứng. Nếu SoC không chứa bộ giải mã cho AV1 (ví dụ: thiết bị trên Snapdragon 8 Gen 1), ứng dụng phải cung cấp dự phòng phần mềm qua FFmpeg và dav1d. Tình huống tương tự áp dụng cho H.265 trên thiết bị cũ và ProRes, chỉ được hỗ trợ trên chip Apple A13+ để giải mã. Khuyến nghị kiểm tra khả dụng của bộ giải mã phần cứng cho định dạng yêu cầu trước khi bắt đầu phát và chọn chiến lược giải mã một cách động.

Giới hạn thứ hai là số lượng phiên giải mã đồng thời. Hầu hết SoC hỗ trợ 1–2 bộ giải mã phần cứng song song. Khi cố mở phiên thứ ba, API sẽ trả về lỗi và ứng dụng phải chuyển sang giải mã phần mềm. Số lượng phiên phụ thuộc vào nhà sản xuất SoC: chip Apple cho phép tới 4 phiên giải mã H.264 trên A17 Pro, trong khi Snapdragon 8 Gen 2 hỗ trợ tới 2 cho H.265 và tới 2 cho VP9 tổng cộng.