การถอดรหัสด้วยฮาร์ดแวร์: คืออะไร หลักการทำงาน และข้อดี

การถอดรหัสด้วยฮาร์ดแวร์คืออะไร?

Hardware decoding คือกระบวนการคลาย compression ข้อมูลมัลติมีเดียที่ดำเนินการไม่ใช่บน CPU วัตถุประสงค์ทั่วไป แต่บนวงจรรวมเฉพาะที่ถูกรวมไว้ในระบบบนชิป (SoC) บล็อกดังกล่าวเรียกว่าตัวถอดรหัสวิดีโอหรือ VPU (Video Processing Unit) และเป็นตัวเร่ง ASIC ที่ปรับให้เหมาะสมสำหรับอัลกอริทึมการบีบอัดเฉพาะ

SoC มือถือสมัยใหม่ประกอบด้วยบล็อกฮาร์ดแวร์แยกต่างหากสำหรับโคเดกยอดนิยมแต่ละตัว ตัวอย่างเช่น ชิป Apple A17 Pro รวมตัวถอดรหัสสำหรับ H.264, H.265, VP9, AV1 และ ProRes แต่ละบล็อกคือไปป์ไลน์การประมวลผลที่สมบูรณ์ซึ่งสามารถรับบิตสตรีมที่บีบอัดที่อินพุตและส่งออกเฟรมที่ถอดรหัสพร้อมในรูปแบบ YUV หรือ BGRA ที่เอาต์พุตโดยไม่ต้องใช้ CPU

การถอดรหัสด้วยฮาร์ดแวร์กลายเป็นมาตรฐานในอุตสาหกรรมมือถือในปี 2012–2013 เมื่อ Qualcomm Snapdragon 800 และ Apple A7 รวมบล็อกการถอดรหัส H.264 เฉพาะเป็นครั้งแรก ตั้งแต่นั้นมา เทคโนโลยี ได้พัฒนาจากการรองรับรูปแบบเดียวไปเป็นบล็อกหลายรูปแบบสากลที่สามารถถอดรหัสหลายสตรีมพร้อมกัน — ตัวอย่างเช่น สำหรับ PiP ที่มีสตรีมวิดีโอแยกต่างหาก

การถอดรหัสด้วยฮาร์ดแวร์ทำงานอย่างไร?

กระบวนการถอดรหัสด้วยฮาร์ดแวร์แตกต่างอย่างสิ้นเชิงจากการถอดรหัสด้วยซอฟต์แวร์ แทนที่จะดำเนินการตามคำสั่ง CPU ตามลำดับ บล็อกฮาร์ดแวร์ใช้วงจรทางกายภาพสำหรับแต่ละขั้นตอนของการคลาย compression: การถอดรหัสเอนโทรปี การหาปริมาณกลับ การแปลง DCT กลับ และการชดเชยการเคลื่อนไหว

สถาปัตยกรรมตัวถอดรหัสด้วยฮาร์ดแวร์

ตัวถอดรหัสด้วยฮาร์ดแวร์ทั่วไปประกอบด้วยหลายขั้นตอนของไปป์ไลน์ ขั้นตอนแรกคือ ตัวถอดรหัสเอนโทรปี ซึ่งใช้งานเป็นเครื่องสถานะจำกัด (FSM) สำหรับ CABAC หรือ CAVLC ต่างจากการใช้งานซอฟต์แวร์ที่แต่ละบิตถูกประมวลผลด้วยการแตกแขนงแบบมีเงื่อนไข CABAC ของฮาร์ดแวร์ใช้วงจรทำนายบริบทแบบขนาน ทำให้สามารถประมวลผลได้ 2–3 บิตต่อรอบแทนที่จะเป็นหนึ่ง

ขั้นตอนที่สองคือบล็อก DCT กลับ การแปลง DCT ของซอฟต์แวร์ต้องใช้ลูปการคูณและสะสมบน CPU การใช้งานฮาร์ดแวร์ใช้ตัวคูณเมทริกซ์ที่คำนวณค่าสัมประสิทธิ์ทั้งหมด 64 ตัวของบล็อก 8x8 ในรอบเดียว การแปลง DCT กลับด้วยฮาร์ดแวร์ ทำงานที่ 400–600 MHz และประมวลผลได้ถึง 4 ล้านมาโครบล็อกต่อวินาที ซึ่งเพียงพอสำหรับการถอดรหัสวิดีโอ 8K แบบเรียลไทม์

ขั้นตอนที่สามคือโมดูลชดเชยการเคลื่อนไหว (MC) พร้อมกันกับการแปลง DCT กลับ บล็อกฮาร์ดแวร์รับเวกเตอร์การเคลื่อนไหวจากบิตสตรีมและดึงพื้นที่อ้างอิงจากบัฟเฟอร์เฟรมที่ถอดรหัสแล้ว บัฟเฟอร์ DPB (Decoded Picture Buffer) จัดเก็บเฟรมอ้างอิงได้ถึง 16 เฟรม ซึ่งเข้าถึงผ่านหน่วยความจำแคชเฉพาะที่มีความหน่วงต่ำ ตัวถอดรหัสสมัยใหม่ใช้การทำนายด้วยการปรับให้เรียบแบบปรับค่าได้และการประมาณค่าระดับต่ำกว่าพิกเซล ซึ่งสำคัญสำหรับ H.265 และ AV1

การโต้ตอบกับระบบ

การจัดการตัวถอดรหัสด้วยฮาร์ดแวร์เกิดขึ้นผ่านตัวควบคุม DMA แอปพลิเคชันส่งตัวชี้ไปยังข้อมูลที่บีบอัดในหน่วยความจำที่ใช้ร่วมกันให้กับตัวถอดรหัส และตัวถอดรหัสอ่านบิตสตรีมผ่านการเข้าถึงหน่วยความจำโดยตรง เมื่อการถอดรหัสเฟรมเสร็จสมบูรณ์ สัญญาณขัดจังหวะ จะแจ้งให้ไดรเวอร์ทราบ และเฟรมที่พร้อมจะพร้อมใช้งานในพูลบัฟเฟอร์เอาต์พุต กลไกนี้กำจัดโหลดของ CPU อย่างสมบูรณ์ในระหว่างการประมวลผลข้อมูล — โปรเซสเซอร์เริ่มต้นการถอดรหัสเท่านั้นและรับผลลัพธ์สุดท้าย

VideoToolbox และ MediaCodec: เปรียบเทียบแพลตฟอร์ม

ทั้งสองแพลตฟอร์มมือถือมี API ดั้งเดิมสำหรับการถอดรหัสด้วยฮาร์ดแวร์ แต่มีแนวทางที่แตกต่างกันในการจัดการบัฟเฟอร์และวงจรชีวิตของตัวถอดรหัส VideoToolbox บน iOS ถูกรวมเข้ากับ Metal อย่างแน่นหนาสำหรับเอาต์พุตจอแสดงผล ในขณะที่ MediaCodec บน Android ใช้ Surface สำหรับการเรนเดอร์โดยตรง

VideoToolbox คือเฟรมเวิร์กสำหรับการถอดรหัสด้วยฮาร์ดแวร์บน iOS และ macOS ใช้โมเดลการถอดรหัสแบบอะซิงโครนัส: VTDecompressionSessionDecodeFrame ส่งคืนทันที และเฟรมที่พร้อมมาถึงผ่านการเรียกกลับในคิวแยกต่างหาก VideoToolbox จัดการพูลบัฟเฟอร์พิกเซล (CVPixelBufferPool) โดยอัตโนมัติและสามารถใช้บัฟเฟอร์ที่ปล่อยแล้วซ้ำสำหรับเฟรมใหม่ สำหรับวิดีโอ HDR VideoToolbox รองรับพื้นที่สี ITU-R BT.2020 และ EOTF PQ/HLG

MediaCodec ใช้โมเดลแบบซิงโครนัสกับคิวบัฟเฟอร์อินพุตและเอาต์พุต แอปพลิเคชันเรียกใช้ dequeueInputBuffer เพื่อส่งข้อมูลที่บีบอัดและ dequeueOutputBuffer เพื่อรับผลลัพธ์ที่ถอดรหัสแล้วเป็นวัฏจักร วิธีการนี้ทำให้ผู้พัฒนาควบคุม จังหวะการถอดรหัส ได้อย่างสมบูรณ์ ซึ่งสำคัญสำหรับการซิงโครไนซ์เสียงและวิดีโอ สำหรับเอาต์พุตจอแสดงผล MediaCodec ยอมรับ Surface ซึ่งช่วยให้ถอดรหัสบน GPU โดยตรงโดยไม่ต้องคัดลอกผ่าน CPU

ข้อดีของการถอดรหัสด้วยฮาร์ดแวร์

การถอดรหัสด้วยฮาร์ดแวร์มีข้อดีหลักสามประการเมื่อเทียบกับซอฟต์แวร์: ประสิทธิภาพการใช้พลังงาน ประสิทธิภาพ และความเสถียร แต่ละข้อมีความสำคัญอย่างยิ่งสำหรับอุปกรณ์มือถือที่มีทรัพยากรแบตเตอรี่จำกัดและข้อจำกัดด้านความร้อน

ประสิทธิภาพการใช้พลังงาน

ข้อได้เปรียบหลักของการถอดรหัสด้วยฮาร์ดแวร์คือการใช้พลังงานที่ต่ำกว่าโดยสิ้นเชิง ตัวถอดรหัสด้วยฮาร์ดแวร์ H.264/H.265 ทั่วไปใช้พลังงาน 0.2–0.5W เมื่อถอดรหัสวิดีโอ 1080p แบบเรียลไทม์ ในทางเปรียบเทียบ การถอดรหัสด้วยซอฟต์แวร์ของสตรีมเดียวกันบน CPU ใช้พลังงาน 1.5–4W ขึ้นอยู่กับสถาปัตยกรรมของโปรเซสเซอร์ ความแตกต่าง 5–10 เท่า ส่งผลโดยตรงต่ออายุการใช้งานแบตเตอรี่: ด้วยการถอดรหัสด้วยฮาร์ดแวร์ การเล่นวิดีโอช่วยให้ดูหนังได้ 10–15 ชั่วโมง เทียบกับ 2–4 ชั่วโมงด้วยการถอดรหัสด้วยซอฟต์แวร์บน CPU

ประสิทธิภาพการใช้พลังงานทำได้ผ่านความเชี่ยวชาญเฉพาะทางที่แคบ ต่างจาก CPU ที่ดำเนินการตามคำสั่งที่หลากหลายและมีตรรกะการควบคุมที่ซับซ้อน ตัวถอดรหัสด้วยฮาร์ดแวร์มีเฉพาะวงจรที่จำเป็นสำหรับอัลกอริทึมเฉพาะเท่านั้น ความถี่สัญญาณนาฬิกา ของบล็อกดังกล่าวคือ 200–600 MHz เทียบกับ 2–3 GHz ของ CPU ซึ่งลดการใช้พลังงานแบบไดนามิกตามสัดส่วนกำลังสองของแรงดันไฟฟ้า

ประสิทธิภาพและการระบายความร้อน

การถอดรหัสด้วยฮาร์ดแวร์ให้อัตราเฟรมที่รับประกันแม้สำหรับความละเอียดสูง ต้องขอบคุณสถาปัตยกรรมไปป์ไลน์ บล็อกฮาร์ดแวร์สามารถประมวลผลหลายขั้นตอนของการคลาย compression พร้อมกัน: ขณะที่โมดูลหนึ่งทำการถอดรหัสเอนโทรปีสำหรับมาโครบล็อกถัดไป อีกโมดูลหนึ่งก็ใช้การแปลง DCT กลับกับมาโครบล็อกปัจจุบันแล้ว ความขนานดังกล่าว ไม่สามารถทำได้บน CPU ซึ่งแต่ละขั้นตอนเป็นการดำเนินการตามลำดับ

การระบายความร้อนของตัวถอดรหัสด้วยฮาร์ดแวร์ต่ำกว่าอย่างมีนัยสำคัญ: บล็อกทั่วไประบายความร้อน 0.3–0.8W เทียบกับ 2–6W ของ CPU ในระหว่างการถอดรหัสวิดีโอ 4K ซึ่งหมายความว่าอุปกรณ์ไม่ร้อนเกินไปแม้ในระหว่างการรับชมเป็นเวลานาน ไม่เกิดการลดประสิทธิภาพ และผู้ใช้ได้รับ 60 FPS ที่เสถียรโดยไม่ลดลง อุณหภูมิของตัวเครื่อง ระหว่างการถอดรหัสด้วยฮาร์ดแวร์มักจะต่ำกว่าการถอดรหัสด้วยซอฟต์แวร์ 5–10 องศา ซึ่งสำคัญโดยเฉพาะสำหรับแท็บเล็ตที่ไม่มีการระบายความร้อนแบบแอคทีฟ

ตัวอย่างโค้ดการถอดรหัสด้วยฮาร์ดแวร์

มาดูการใช้งานจริงของการถอดรหัสด้วยฮาร์ดแวร์พร้อมการจัดการการเรียกกลับบน 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 พร้อมการเรียกกลับแบบอะซิงโครนัส VTDecompressionSessionCreate ตรวจพบตัวถอดรหัสด้วยฮาร์ดแวร์ที่มีอยู่โดยอัตโนมัติตาม CMVideoFormatDescription ที่ให้ไว้ แฟล็ก kVTDecodeFrame_EnableAsynchronousDecompression เปิดใช้งานโหมดอะซิงโครนัส — แอปพลิเคชันไม่ถูกบล็อกระหว่างการถอดรหัสและรับเฟรมผ่านการเรียกกลับ สำหรับ H.264 ก่อนอื่นคุณต้องสร้างคำอธิบายรูปแบบจากหน่วย NAL SPS/PPS ผ่าน CMVideoFormatDescriptionCreateFromH264ParameterSets

การถอดรหัสด้วยฮาร์ดแวร์บน 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 รอคิวบัฟเฟอร์อินพุตที่ว่างพร้อมการหมดเวลา หากไม่มีบัฟเฟอร์ว่าง เฟรมปัจจุบันจะถูกข้ามไป ป้องกันการล้นของคิวระหว่างอัตราบิตที่ไม่สม่ำเสมอ

เมื่อใดควรเลือกการถอดรหัสด้วยฮาร์ดแวร์

การถอดรหัสด้วยฮาร์ดแวร์เป็นตัวเลือกที่เหมาะสมที่สุดสำหรับสถานการณ์การผลิตส่วนใหญ่ แต่ไม่ใช่โซลูชันสากล การทำความเข้าใจขอบเขตของการนำไปใช้ช่วยหลีกเลี่ยงสถานการณ์ที่การขาดการรองรับโคเดกด้วยฮาร์ดแวร์ทำลายประสบการณ์ผู้ใช้

สถานการณ์การใช้งานที่จำเป็น

การถอดรหัสด้วยฮาร์ดแวร์จำเป็นในสามกรณี: การเล่นวิดีโอเป็นเวลานาน (มากกว่า 30 นาที), การถอดรหัสเนื้อหา 4K, และแอปพลิเคชันใดๆ ที่มุ่งเน้นอายุการใช้งานแบตเตอรี่สูงสุด บริการสตรีมมิ่ง (Netflix, YouTube, Twitch) ใช้การถอดรหัสด้วยฮาร์ดแวร์เท่านั้น เนื่องจากซอฟต์แวร์ไม่สามารถรับประกันการเล่นที่เสถียรที่อัตราบิตสูงและความละเอียดใหญ่ สำหรับบริการเหล่านี้ การรองรับ DRM (FairPlay, Widevine) มีความสำคัญ ซึ่งมีให้ผ่านบล็อกฮาร์ดแวร์ที่ให้ไปป์ไลน์ที่ได้รับการป้องกันจากตัวถอดรหัสไปยังเอาต์พุตจอแสดงผลเท่านั้น

สำหรับเกมที่มีวิดีโอในตัว (ฉากตัด โฆษณา ภาพยนตร์ในเกม) ก็แนะนำให้ใช้การถอดรหัสด้วยฮาร์ดแวร์เช่นกัน เอ็นจินเกมสมัยใหม่อย่าง Unity และ Unreal Engine มีการรองรับในตัวสำหรับ VideoToolbox และ MediaCodec การถอดรหัสด้วยฮาร์ดแวร์ ในเกมช่วยปลดปล่อย CPU สำหรับการจำลองฟิสิกส์ AI ศัตรู และการประมวลผลอินพุต ซึ่งช่วยปรับปรุงประสิทธิภาพโดยรวม

ข้อจำกัดและทางเลือกสำรอง

ข้อจำกัดหลักของการถอดรหัสด้วยฮาร์ดแวร์คือการพึ่งพาการรองรับรูปแบบของฮาร์ดแวร์ หาก SoC ไม่มีตัวถอดรหัสสำหรับ AV1 (ตัวอย่างเช่น อุปกรณ์บน Snapdragon 8 Gen 1) แอปพลิเคชันต้องมีทางเลือกสำรองด้วยซอฟต์แวร์ผ่าน FFmpeg และ dav1d สถานการณ์เดียวกันนี้ใช้กับ H.265 บนอุปกรณ์เก่าและ ProRes ซึ่งรองรับเฉพาะบนชิป Apple A13+ สำหรับการถอดรหัส ขอแนะนำให้ตรวจสอบความพร้อมของตัวถอดรหัสด้วยฮาร์ดแวร์สำหรับรูปแบบที่ต้องการก่อนเริ่มเล่นและเลือกกลยุทธ์การถอดรหัสแบบไดนามิก

ข้อจำกัดที่สองคือจำนวนเซสชันการถอดรหัสพร้อมกัน SoC ส่วนใหญ่รองรับตัวถอดรหัสด้วยฮาร์ดแวร์แบบขนาน 1–2 ตัว เมื่อพยายามเปิดเซสชันที่สาม API จะส่งคืนข้อผิดพลาดและแอปพลิเคชันต้องเปลี่ยนเป็นการถอดรหัสด้วยซอฟต์แวร์ จำนวนเซสชัน ขึ้นอยู่กับผู้ผลิต SoC: ชิป Apple อนุญาตให้มีเซสชันการถอดรหัส H.264 สูงสุด 4 เซสชันบน A17 Pro ในขณะที่ Snapdragon 8 Gen 2 รองรับสูงสุด 2 สำหรับ H.265 และสูงสุด 2 สำหรับ VP9 รวม