ส่วนแรก:
อะไร ตัวแปลงสัญญาณวิดีโอคือชิ้นส่วนของซอฟต์แวร์/ฮาร์ดแวร์ที่บีบอัดและ/หรือขยายขนาดวิดีโอดิจิทัล
สำหรับสิ่งที่? แม้จะมีข้อจำกัดบางประการทั้งในแง่ของแบนด์วิธและ
และในแง่ของพื้นที่จัดเก็บข้อมูล ตลาดต้องการวิดีโอคุณภาพสูงขึ้นเรื่อยๆ คุณจำได้ไหมว่าในโพสต์ล่าสุดเราคำนวณขั้นต่ำที่ต้องการสำหรับ 30 เฟรมต่อวินาที 24 บิตต่อพิกเซลด้วยความละเอียด 480x240 ได้อย่างไร เราได้รับ 82,944 Mbit/s โดยไม่มีการบีบอัด ปัจจุบันการบีบอัดเป็นวิธีเดียวในการส่งสัญญาณ HD/FullHD/4K ไปยังหน้าจอโทรทัศน์และอินเทอร์เน็ต สิ่งนี้สำเร็จได้อย่างไร? ตอนนี้เรามาดูวิธีการหลักโดยย่อ
การแปลจัดทำขึ้นโดยได้รับการสนับสนุนจากซอฟต์แวร์ EDISONเราหมั้นกันแล้ว และ .
Codec กับคอนเทนเนอร์
ข้อผิดพลาดทั่วไปที่มือใหม่ทำคือสร้างความสับสนให้กับตัวแปลงสัญญาณวิดีโอดิจิทัลและคอนเทนเนอร์วิดีโอดิจิทัล คอนเทนเนอร์เป็นรูปแบบที่แน่นอน Wrapper ที่มีข้อมูลเมตาของวิดีโอ (และอาจเป็นเสียง) วิดีโอที่บีบอัดถือได้ว่าเป็นเพย์โหลดของคอนเทนเนอร์
โดยทั่วไปแล้ว นามสกุลของไฟล์วิดีโอจะระบุประเภทของคอนเทนเนอร์ ตัวอย่างเช่น ไฟล์ video.mp4 อาจเป็นคอนเทนเนอร์ MPEG-4 ส่วนที่ 14และไฟล์ชื่อ video.mkv มีแนวโน้มมากที่สุด . คุณสามารถใช้ตัวแปลงสัญญาณและคอนเทนเนอร์เพื่อให้มั่นใจได้อย่างสมบูรณ์ หรือ .
บิตของประวัติศาสตร์
ก่อนที่เราจะไปถึง อย่างไรเรามาเจาะลึกประวัติศาสตร์กันสักหน่อยเพื่อทำความเข้าใจตัวแปลงสัญญาณรุ่นเก่าๆ ให้ดีขึ้นอีกหน่อย
ตัวแปลงสัญญาณวิดีโอ H.261 ปรากฏในปี 1990 (ในทางเทคนิค - ในปี 1988) และถูกสร้างขึ้นเพื่อทำงานที่อัตราการถ่ายโอนข้อมูล 64 Kbps บริษัทได้ใช้แนวคิดต่างๆ เช่น การสุ่มตัวอย่างสี, Macroblocks ฯลฯ ไปแล้ว มาตรฐานตัวแปลงสัญญาณวิดีโอเผยแพร่ในปี 1995 H.263ซึ่งพัฒนามาจนถึงปี พ.ศ. 2001
รุ่นแรกสร้างเสร็จเมื่อปี พ.ศ.2003 H.264 / AVC. ในปีเดียวกันนั้น TrueMotion ได้เปิดตัวตัวแปลงสัญญาณวิดีโอแบบสูญเสียฟรีที่เรียกว่า VP3. Google ซื้อบริษัทในปี 2008 โดยเปิดตัว VP8 ปีเดียวกัน ในเดือนธันวาคม พ.ศ. 2012 Google ได้เปิดตัว VP9และได้รับการสนับสนุนในตลาดเบราว์เซอร์ประมาณ XNUMX/XNUMX (รวมถึงอุปกรณ์มือถือ)
AV1 เป็นตัวแปลงสัญญาณวิดีโอโอเพ่นซอร์สฟรีใหม่ที่พัฒนาโดย พันธมิตรเพื่อสื่อเปิด (เอโอมีเดีย) ซึ่งรวมถึงบริษัทที่มีชื่อเสียงที่สุด เช่น Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel และ Cisco เวอร์ชันแรกของตัวแปลงสัญญาณ 0.1.0 เผยแพร่เมื่อวันที่ 7 เมษายน 2016
กำเนิด AV1
ในต้นปี 2015 Google กำลังทำงานอยู่ VP10Xiph (ซึ่งเป็นของ Mozilla) กำลังทำงานอยู่ Daalaและ Cisco ได้สร้างตัวแปลงสัญญาณวิดีโอฟรีของตัวเองที่เรียกว่า ธ อร์.
แล้วก็ MPEG แอลเอ ประกาศขีดจำกัดรายปีเป็นครั้งแรกสำหรับ HEVC (H.265) และค่าธรรมเนียมสูงกว่า H.8 ถึง 264 เท่า แต่ในไม่ช้าพวกเขาก็เปลี่ยนกฎอีกครั้ง:
ไม่มีขีดจำกัดรายปี
ค่าธรรมเนียมเนื้อหา (0,5% ของรายได้) และ
ค่าธรรมเนียมต่อหน่วยสูงกว่า H.10 ประมาณ 264 เท่า
พันธมิตรเพื่อสื่อเปิด ถูกสร้างขึ้นโดยบริษัทจากสาขาต่างๆ: ผู้ผลิตอุปกรณ์ (Intel, AMD, ARM, Nvidia, Cisco), ผู้ให้บริการเนื้อหา (Google, Netflix, Amazon), ผู้สร้างเบราว์เซอร์ (Google, Mozilla) และอื่นๆ
บริษัทต่างๆ มีเป้าหมายร่วมกัน นั่นคือตัวแปลงสัญญาณวิดีโอที่ไม่มีค่าลิขสิทธิ์ จากนั้นจะปรากฏขึ้น AV1 ด้วยใบอนุญาตสิทธิบัตรที่ง่ายกว่ามาก Timothy B. Terryberry นำเสนอผลงานที่น่าทึ่งซึ่งกลายเป็นที่มาของแนวคิด AV1 ในปัจจุบันและรูปแบบการให้สิทธิ์ใช้งาน
คุณจะแปลกใจเมื่อรู้ว่าคุณสามารถวิเคราะห์ตัวแปลงสัญญาณ AV1 ผ่านเบราว์เซอร์ได้ (ผู้สนใจสามารถเข้าไปที่).
ตัวแปลงสัญญาณสากล
มาดูกลไกหลักที่เป็นรากฐานของตัวแปลงสัญญาณวิดีโอสากล แนวคิดเหล่านี้ส่วนใหญ่มีประโยชน์และใช้ในตัวแปลงสัญญาณสมัยใหม่ เช่น VP9, AV1 и HEVC. ฉันขอเตือนคุณว่าหลายสิ่งที่อธิบายไว้จะง่ายขึ้น บางครั้งตัวอย่างในโลกแห่งความเป็นจริง (เช่นเดียวกับ H.264) จะถูกนำมาใช้เพื่อสาธิตเทคโนโลยี
ขั้นตอนที่ 1 - การแยกภาพ
ขั้นตอนแรกคือการแบ่งเฟรมออกเป็นหลายส่วน ส่วนย่อย และอื่นๆ
เพื่ออะไร? มีสาเหตุหลายประการ เมื่อเราแบ่งภาพ เราสามารถทำนายเวกเตอร์การเคลื่อนไหวได้แม่นยำยิ่งขึ้นโดยใช้ส่วนเล็กๆ สำหรับชิ้นส่วนเล็กๆ ที่เคลื่อนไหว สำหรับพื้นหลังแบบคงที่ คุณสามารถจำกัดตัวเองให้อยู่ในส่วนที่ใหญ่ขึ้นได้
โดยทั่วไปตัวแปลงสัญญาณจะจัดระเบียบส่วนเหล่านี้ออกเป็นส่วนๆ (หรือส่วนต่างๆ) บล็อกขนาดใหญ่ (หรือบล็อกแผนผังการเขียนโค้ด) และส่วนย่อยหลายๆ ส่วน ขนาดสูงสุดของพาร์ติชันเหล่านี้จะแตกต่างกันไป HEVC ตั้งค่าเป็น 64x64 ในขณะที่ AVC ใช้ 16x16 และพาร์ติชันย่อยสามารถแบ่งได้สูงสุดขนาด 4x4
จำประเภทเฟรมจากบทความที่แล้วได้ไหม?! เช่นเดียวกันนี้สามารถนำไปใช้กับบล็อกได้ ดังนั้นเราจึงสามารถมี I-fragment, B-block, P-macroblock เป็นต้น
สำหรับผู้ที่ต้องการฝึกดูวิธีการแบ่งภาพออกเป็นส่วนและส่วนย่อย ในการทำเช่นนี้คุณสามารถใช้อันที่กล่าวถึงแล้วในบทความก่อนหน้านี้ (อันที่จ่ายแต่มีเวอร์ชั่นทดลองใช้ฟรีที่จำกัดแค่ 10 เฟรมแรก) ส่วนที่วิเคราะห์ที่นี่ VP9:
ขั้นตอนที่ 2 - การพยากรณ์
เมื่อเรามีส่วนต่างๆ แล้ว เราก็สามารถพยากรณ์ทางโหราศาสตร์ได้ สำหรับ การคาดการณ์ของอินเตอร์ จะต้องโอน เวกเตอร์การเคลื่อนไหว และส่วนที่เหลือ และสำหรับการคาดการณ์ INTRA จะมีการส่งข้อมูล ทิศทางการคาดการณ์ และส่วนที่เหลือ
ขั้นตอนที่ 3 - การเปลี่ยนแปลง
เมื่อเรามีบล็อกที่เหลือ (ส่วนที่คาดการณ์ → ส่วนจริง) ก็เป็นไปได้ที่จะแปลงในลักษณะที่เรารู้ว่าพิกเซลใดที่สามารถละทิ้งได้ในขณะที่ยังคงคุณภาพโดยรวมไว้ มีการเปลี่ยนแปลงบางอย่างที่ให้ลักษณะการทำงานที่แน่นอน
แม้ว่าจะมีวิธีอื่น แต่เรามาดูรายละเอียดเพิ่มเติมกันดีกว่า การแปลงโคไซน์แบบไม่ต่อเนื่อง (DCT - จาก การแปลงโคไซน์แบบไม่ต่อเนื่อง). หน้าที่หลักของ DCT:
- แปลงบล็อกพิกเซลให้เป็นบล็อกค่าสัมประสิทธิ์ความถี่ที่มีขนาดเท่ากัน
- ควบแน่นพลังเพื่อช่วยขจัดความซ้ำซ้อนเชิงพื้นที่
- ให้การพลิกกลับได้
2 กุมภาพันธ์ 2017 Sintra R.J. (Cintra, RJ) และ Bayer F.M. (Bayer FM) ตีพิมพ์บทความเกี่ยวกับการแปลงแบบ DCT สำหรับการบีบอัดภาพที่ต้องใช้การเพิ่มเพียง 14 ครั้ง
ไม่ต้องกังวลหากคุณไม่เข้าใจประโยชน์ของแต่ละรายการ ตอนนี้เรามาใช้ตัวอย่างที่เฉพาะเจาะจงเพื่อดูมูลค่าที่แท้จริงของพวกเขา
ลองใช้บล็อกพิกเซลขนาด 8x8 นี้:
บล็อกนี้ถูกเรนเดอร์เป็นรูปภาพขนาด 8 x 8 พิกเซลต่อไปนี้:
ใช้ DCT กับบล็อกพิกเซลนี้และรับค่าสัมประสิทธิ์บล็อก 8x8:
และถ้าเราแสดงค่าสัมประสิทธิ์บล็อกนี้ เราจะได้ภาพต่อไปนี้:
อย่างที่คุณเห็น มันดูไม่เหมือนภาพต้นฉบับ คุณจะเห็นว่าค่าสัมประสิทธิ์แรกแตกต่างจากค่าสัมประสิทธิ์อื่นๆ มาก สัมประสิทธิ์แรกนี้เรียกว่าสัมประสิทธิ์ DC ซึ่งแสดงถึงตัวอย่างทั้งหมดในอาร์เรย์อินพุต ซึ่งคล้ายกับค่าเฉลี่ย
บล็อกสัมประสิทธิ์นี้มีคุณสมบัติที่น่าสนใจ: แยกส่วนประกอบความถี่สูงออกจากส่วนประกอบความถี่ต่ำ
ในภาพ พลังงานส่วนใหญ่จะมุ่งไปที่ความถี่ที่ต่ำกว่า ดังนั้นหากคุณแปลงภาพเป็นส่วนประกอบความถี่ของภาพและละทิ้งค่าสัมประสิทธิ์ความถี่ที่สูงกว่า คุณสามารถลดปริมาณข้อมูลที่จำเป็นในการอธิบายภาพได้โดยไม่ทำให้คุณภาพของภาพมากเกินไป
ความถี่หมายถึงความเร็วของสัญญาณที่เปลี่ยนแปลง
เรามาลองใช้ความรู้ที่ได้รับในกรณีทดสอบโดยการแปลงภาพต้นฉบับเป็นความถี่ (บล็อกของสัมประสิทธิ์) โดยใช้ DCT แล้วละทิ้งส่วนหนึ่งของค่าสัมประสิทธิ์ที่สำคัญน้อยที่สุดไป
ขั้นแรกเราแปลงเป็นโดเมนความถี่
ต่อไปเราจะทิ้งส่วน (67%) ของสัมประสิทธิ์ ซึ่งส่วนใหญ่เป็นส่วนล่างขวา
สุดท้าย เราสร้างภาพขึ้นใหม่จากกลุ่มสัมประสิทธิ์ที่ถูกทิ้งไปนี้ (จำไว้ว่ามันจะต้องกลับด้านได้) และเปรียบเทียบกับภาพต้นฉบับ
เราเห็นว่ามันคล้ายกับภาพต้นฉบับ แต่มีความแตกต่างจากภาพต้นฉบับมากมาย เราโยนออกไป 67,1875% และยังคงมีบางอย่างที่คล้ายกับของดั้งเดิม เป็นไปได้ที่จะละทิ้งค่าสัมประสิทธิ์อย่างรอบคอบมากขึ้นเพื่อให้ได้ภาพที่มีคุณภาพดียิ่งขึ้น แต่นั่นเป็นหัวข้อถัดไป
แต่ละค่าสัมประสิทธิ์ถูกสร้างขึ้นโดยใช้พิกเซลทั้งหมด
สิ่งสำคัญ: แต่ละค่าสัมประสิทธิ์ไม่ได้แมปกับหนึ่งพิกเซลโดยตรง แต่เป็นผลรวมถ่วงน้ำหนักของพิกเซลทั้งหมด กราฟที่น่าทึ่งนี้แสดงวิธีคำนวณค่าสัมประสิทธิ์ที่หนึ่งและที่สองโดยใช้น้ำหนักที่ไม่ซ้ำกันสำหรับแต่ละดัชนี
คุณยังสามารถลองแสดงภาพ DCT ได้โดยดูจากการสร้างภาพอย่างง่ายตามนั้น ตัวอย่างเช่น นี่คือสัญลักษณ์ A ที่สร้างขึ้นโดยใช้น้ำหนักสัมประสิทธิ์แต่ละค่า:
ขั้นตอนที่ 4 - การหาปริมาณ
หลังจากที่เราทิ้งค่าสัมประสิทธิ์บางส่วนในขั้นตอนก่อนหน้าแล้ว ในขั้นตอนสุดท้าย (การเปลี่ยนแปลง) เราจะดำเนินการหาปริมาณรูปแบบพิเศษ ในขั้นตอนนี้ ข้อมูลสูญหายก็ยอมรับได้ หรือพูดง่ายๆ ก็คือ เราจะหาปริมาณสัมประสิทธิ์เพื่อให้ได้การบีบอัด
คุณจะหาจำนวนบล็อกของสัมประสิทธิ์ได้อย่างไร? วิธีที่ง่ายที่สุดวิธีหนึ่งคือการหาปริมาณสม่ำเสมอ เมื่อเราหาบล็อกมาหารด้วยค่าเดียว (คูณ 10) แล้วปัดเศษผลลัพธ์
เราจะย้อนกลับกลุ่มสัมประสิทธิ์นี้ได้ไหม? ใช่ เราทำได้ โดยคูณด้วยค่าเดียวกันกับที่เราหาร
วิธีนี้ไม่ใช่วิธีที่ดีที่สุดเนื่องจากไม่ได้คำนึงถึงความสำคัญของแต่ละสัมประสิทธิ์ เราสามารถใช้เมทริกซ์ของควอนไทเซอร์แทนค่าเดียว และเมทริกซ์นี้สามารถใช้ประโยชน์จากคุณสมบัติ DCT โดยการหาปริมาณส่วนใหญ่ของมุมขวาล่างและส่วนน้อยของด้านซ้ายบน
ขั้นตอนที่ 5 - การเข้ารหัสเอนโทรปี
เมื่อเราวัดปริมาณข้อมูลแล้ว (บล็อกรูปภาพ แฟรกเมนต์ เฟรม) เรายังคงสามารถบีบอัดข้อมูลได้โดยไม่สูญเสียคุณภาพ มีอัลกอริธึมวิธีมากมายในการบีบอัดข้อมูล เราจะมาดูบางส่วนโดยย่อ เพื่อความเข้าใจที่ลึกซึ้งยิ่งขึ้น คุณสามารถอ่านหนังสือการทำความเข้าใจการบีบอัด: การบีบอัดข้อมูลสำหรับนักพัฒนาสมัยใหม่ ("")
การเข้ารหัสวิดีโอโดยใช้ VLC
สมมติว่าเรามีตัวละครมากมาย: a, e, r и t. ความน่าจะเป็น (ตั้งแต่ 0 ถึง 1) ความถี่ที่อักขระแต่ละตัวปรากฏในสตรีมจะแสดงในตารางนี้
| a | e | r | t | |
|---|---|---|---|---|
| ความน่าจะเป็น | 0,3 | 0,3 | 0,2 | 0,2 |
เราสามารถกำหนดรหัสไบนารี่ที่ไม่ซ้ำกัน (ควรเป็นรหัสขนาดเล็ก) ให้กับรหัสที่มีแนวโน้มมากที่สุด และรหัสที่ใหญ่กว่าให้กับรหัสที่มีโอกาสน้อยกว่า
| a | e | r | t | |
|---|---|---|---|---|
| ความน่าจะเป็น | 0,3 | 0,3 | 0,2 | 0,2 |
| รหัสไบนารี่ | 0 | 10 | 110 | 1110 |
เราบีบอัดสตรีม โดยสมมติว่าเราจะใช้เงิน 8 บิตสำหรับอักขระแต่ละตัว หากไม่มีการบีบอัด จะต้องใช้ 24 บิตต่ออักขระ หากคุณแทนที่อักขระแต่ละตัวด้วยรหัส คุณจะได้รับส่วนลด!
ขั้นตอนแรกคือการเข้ารหัสอักขระ eซึ่งเท่ากับ 10 และอักขระตัวที่สองคือ aซึ่งถูกเพิ่มเข้ามา (ไม่ใช่ในทางคณิตศาสตร์): [10][0] และสุดท้ายคืออักขระตัวที่สาม tซึ่งทำให้บิตสตรีมที่ถูกบีบอัดสุดท้ายของเราเท่ากับ [10][0][1110] หรือ 1001110ซึ่งใช้พื้นที่เพียง 7 บิต (พื้นที่น้อยกว่าเดิม 3,4 เท่า)
โปรดทราบว่าแต่ละรหัสจะต้องเป็นรหัสที่ไม่ซ้ำกันและมีคำนำหน้า จะช่วยคุณค้นหาตัวเลขเหล่านี้ แม้ว่าวิธีนี้จะไม่ได้ไร้ข้อบกพร่อง แต่ก็มีตัวแปลงสัญญาณวิดีโอที่ยังคงเสนอวิธีการบีบอัดแบบอัลกอริธึมนี้
ทั้งตัวเข้ารหัสและตัวถอดรหัสจะต้องมีสิทธิ์เข้าถึงตารางสัญลักษณ์ด้วยรหัสไบนารี่ ดังนั้นจึงจำเป็นต้องส่งตารางเป็นอินพุตด้วย
การเข้ารหัสทางคณิตศาสตร์
สมมติว่าเรามีตัวละครมากมาย: a, e, r, s и tและความน่าจะเป็นจะแสดงอยู่ในตารางนี้
| a | e | r | s | t | |
|---|---|---|---|---|---|
| ความน่าจะเป็น | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
เมื่อใช้ตารางนี้ เราจะสร้างช่วงที่มีอักขระที่เป็นไปได้ทั้งหมด โดยจัดเรียงตามจำนวนที่มากที่สุด
ตอนนี้ขอเข้ารหัสสตรีมของอักขระสามตัว: กิน.
ขั้นแรกให้เลือกอักขระตัวแรก eซึ่งอยู่ในช่วงย่อยตั้งแต่ 0,3 ถึง 0,6 (ไม่รวม) เรานำช่วงย่อยนี้มาหารอีกครั้งในสัดส่วนเท่าเดิม แต่สำหรับช่วงใหม่นี้
มาเขียนโค้ดสตรีมของเราต่อไป กิน. ตอนนี้ใช้ตัวละครที่สอง aซึ่งอยู่ในช่วงย่อยใหม่ตั้งแต่ 0,3 ถึง 0,39 จากนั้นจึงนำอักขระตัวสุดท้ายของเรา t และทำซ้ำขั้นตอนเดิมอีกครั้ง เราจะได้ช่วงย่อยสุดท้ายจาก 0,354 ถึง 0,372
เราเพียงแค่ต้องเลือกตัวเลขในช่วงย่อยสุดท้ายตั้งแต่ 0,354 ถึง 0,372 ลองเลือก 0,36 (แต่คุณสามารถเลือกหมายเลขอื่นในช่วงย่อยนี้ได้) ด้วยหมายเลขนี้เท่านั้นที่เราจะสามารถกู้คืนสตรีมดั้งเดิมของเราได้ ราวกับว่าเรากำลังลากเส้นภายในช่วงเพื่อเข้ารหัสสตรีมของเรา
การดำเนินการย้อนกลับ (นั่นคือ ถอดรหัส) ง่ายดายพอๆ กัน: ด้วยหมายเลข 0,36 และช่วงเริ่มต้นของเรา เราก็สามารถดำเนินการตามกระบวนการเดียวกันได้ แต่ตอนนี้ เมื่อใช้หมายเลขนี้ เราจะระบุสตรีมที่เข้ารหัสโดยใช้หมายเลขนี้
ในช่วงแรก เราจะสังเกตเห็นว่าหมายเลขของเราสอดคล้องกับสไลซ์ ดังนั้นนี่คืออักขระตัวแรกของเรา ตอนนี้เราแบ่งช่วงย่อยนี้อีกครั้งโดยทำตามขั้นตอนเดิม ที่นี่คุณจะเห็นว่า 0,36 สอดคล้องกับสัญลักษณ์ aและหลังจากทำซ้ำขั้นตอนนี้ เราก็มาถึงอักขระตัวสุดท้าย t (สร้างสตรีมที่เข้ารหัสดั้งเดิมของเรา กิน).
ทั้งตัวเข้ารหัสและตัวถอดรหัสต้องมีตารางความน่าจะเป็นของสัญลักษณ์ ดังนั้นจึงจำเป็นต้องส่งตารางดังกล่าวในข้อมูลอินพุตด้วย
ค่อนข้างสง่างามใช่มั้ย? ใครก็ตามที่คิดวิธีแก้ปัญหานี้ขึ้นมาก็ฉลาดจริงๆ ตัวแปลงสัญญาณวิดีโอบางตัวใช้เทคนิคนี้ (หรืออย่างน้อยก็เสนอให้เป็นตัวเลือก)
แนวคิดคือการบีบอัดบิตสตรีมเชิงปริมาณโดยไม่สูญเสียคุณภาพ แน่นอนว่าบทความนี้ขาดรายละเอียด เหตุผล ข้อดีข้อเสีย ฯลฯ มากมาย แต่ถ้าคุณเป็น Developer คุณควรรู้มากกว่านี้ ตัวแปลงสัญญาณใหม่พยายามใช้อัลกอริธึมการเข้ารหัสเอนโทรปีที่แตกต่างกัน เช่น เอเอ็นเอส.
ขั้นตอนที่ 6 - รูปแบบบิตสตรีม
หลังจากทำทั้งหมดนี้แล้ว สิ่งที่เหลืออยู่คือการแกะเฟรมที่บีบอัดออกในบริบทของขั้นตอนที่ดำเนินการ ตัวถอดรหัสจะต้องได้รับการแจ้งอย่างชัดเจนถึงการตัดสินใจของตัวเข้ารหัส ตัวถอดรหัสจะต้องได้รับข้อมูลที่จำเป็นทั้งหมด: ความลึกของบิต สเปซสี ความละเอียด ข้อมูลการทำนาย (เวกเตอร์การเคลื่อนไหว การทำนายทิศทาง INTER) โปรไฟล์ ระดับ อัตราเฟรม ประเภทเฟรม หมายเลขเฟรม และอื่นๆ อีกมากมาย
เราจะดูบิตสตรีมอย่างรวดเร็ว H.264. ขั้นตอนแรกของเราคือการสร้างบิตสตรีม H.264 ขั้นต่ำ (โดยค่าเริ่มต้น FFmpeg จะเพิ่มตัวเลือกการเข้ารหัสทั้งหมด เช่น เซ นาล — เราจะพบว่ามีอะไรเพิ่มเติมอีกเล็กน้อย) เราสามารถทำได้โดยใช้พื้นที่เก็บข้อมูลและ FFmpeg ของเราเอง
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
คำสั่งนี้จะสร้างบิตสตรีมดิบ H.264 ด้วยเฟรมเดียว ความละเอียด 64×64 พร้อมปริภูมิสี YUV420. ในกรณีนี้ รูปภาพต่อไปนี้จะถูกใช้เป็นเฟรม
บิตสตรีม H.264
มาตรฐาน AVC (H.264) กำหนดว่าข้อมูลจะถูกส่งในรูปแบบมาโครเฟรม (ในแง่เครือข่าย) เรียกว่า นัล (นี่คือระดับนามธรรมของเครือข่าย) เป้าหมายหลักของ NAL คือการนำเสนอวิดีโอที่ "เหมาะกับเว็บ" มาตรฐานนี้ควรใช้กับทีวี (แบบสตรีม) อินเทอร์เน็ต (แบบแพ็คเก็ต)
มีเครื่องหมายการซิงโครไนซ์เพื่อกำหนดขอบเขตขององค์ประกอบ NAL โทเค็นการซิงค์แต่ละรายการมีค่า 0x00 0x00 0x01, ยกเว้นอันแรกซึ่งเท่ากับ 0x00 0x00 0x00 0x01. ถ้าเราเปิดตัว การถ่ายโอนข้อมูล สำหรับบิตสตรีม H.264 ที่สร้างขึ้น เราจะระบุรูปแบบ NAL อย่างน้อยสามรูปแบบที่จุดเริ่มต้นของไฟล์
ตามที่ระบุไว้ ตัวถอดรหัสจะต้องรู้ไม่เพียงแต่ข้อมูลภาพ แต่ยังรวมถึงรายละเอียดของวิดีโอ เฟรม สี พารามิเตอร์ที่ใช้ และอื่นๆ อีกมากมาย ไบต์แรกของ NAL แต่ละตัวจะกำหนดหมวดหมู่และประเภทของมัน
| ตัวระบุประเภท NAL | ลักษณะ |
|---|---|
| 0 | ประเภทที่ไม่รู้จัก |
| 1 | ส่วนของภาพที่เข้ารหัสโดยไม่มี IDR |
| 2 | ส่วนข้อมูลชิ้นที่เข้ารหัส A |
| 3 | ส่วนข้อมูลชิ้นที่เข้ารหัส B |
| 4 | ส่วนข้อมูลชิ้นที่เข้ารหัส C |
| 5 | ส่วน IDR ที่เข้ารหัสของอิมเมจ IDR |
| 6 | ข้อมูลเพิ่มเติมเกี่ยวกับส่วนขยาย SEI |
| 7 | ชุดพารามิเตอร์ลำดับ SPS |
| 8 | ชุดพารามิเตอร์รูปภาพ PPS |
| 9 | ตัวคั่นการเข้าถึง |
| 10 | สิ้นสุดลำดับ |
| 11 | สิ้นสุดเธรด |
| ... | ... |
โดยทั่วไปแล้ว NAL แรกของ bitstream คือ SPS. NAL ประเภทนี้มีหน้าที่แจ้งเกี่ยวกับตัวแปรการเข้ารหัสทั่วไป เช่น โปรไฟล์ ระดับ ความละเอียด ฯลฯ
หากเราข้ามเครื่องหมายการซิงค์ตัวแรก เราสามารถถอดรหัสไบต์แรกเพื่อดูว่า NAL ประเภทใดเป็นลำดับแรก
ตัวอย่างเช่น ไบต์แรกหลังจากโทเค็นการซิงค์คือ 01100111โดยที่บิตแรก (0) อยู่ในช่อง forbidden_zero_bit. 2 บิตถัดไป (11) บอกเราถึงสนาม nal_ref_idc, ซึ่งระบุว่า NAL นี้เป็นฟิลด์อ้างอิงหรือไม่ และอีก 5 บิตที่เหลือ (00111) บอกเราถึงสนาม nal_unit_type, ในกรณีนี้คือบล็อก SPS (7) นาล.
ไบต์ที่สอง (ไบนารี=01100100, ฐานสิบหก=0x64, ธันวาคม=100) ใน SPS NAL คือฟิลด์ โปรไฟล์_idc, ซึ่งแสดงโปรไฟล์ที่ตัวเข้ารหัสใช้ ในกรณีนี้ มีการใช้โปรไฟล์สูงที่จำกัด (นั่นคือ โปรไฟล์สูงที่ไม่มีการรองรับ B-segment แบบสองทิศทาง)
หากดูจากสเปคบิตสตรีมแล้ว H.264 สำหรับ SPS NAL เราจะค้นหาค่าต่างๆ มากมายสำหรับชื่อพารามิเตอร์ หมวดหมู่ และคำอธิบาย ตัวอย่างเช่นลองดูที่ทุ่งนา pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
| ชื่อพารามิเตอร์ | หมวดหมู่ | ลักษณะ |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | คุณ(v) |
| pic_height_in_map_units_minus_1 | 0 | คุณ(v) |
หากเราทำการคำนวณทางคณิตศาสตร์ด้วยค่าของฟิลด์เหล่านี้เราจะได้รับการแก้ปัญหา หนึ่งสามารถแสดง 1920 x 1080 โดยใช้ pic_width_in_mbs_minus_1 ด้วยค่า 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920) อีกครั้ง เพื่อประหยัดพื้นที่ แทนที่จะเข้ารหัส 1920 เราทำโดยใช้ 119
หากเราตรวจสอบวิดีโอที่เราสร้างขึ้นในรูปแบบไบนารีต่อไป (เช่น: xxd -b -c 11 โวลต์/minimal_yuv420.h264) จากนั้นคุณสามารถไปที่ NAL สุดท้ายซึ่งก็คือเฟรมนั้นเอง
ที่นี่เราเห็นค่า 6 ไบต์แรก: 01100101 10001000 10000100 00000000 00100001 11111111. เนื่องจากเป็นที่ทราบกันว่าไบต์แรกระบุประเภท NAL ในกรณีนี้ (00101) เป็นส่วน IDR (5) จากนั้นคุณสามารถสำรวจเพิ่มเติมได้:
การใช้ข้อมูลข้อกำหนดจะสามารถถอดรหัสประเภทแฟรกเมนต์ได้ (ชิ้น_ประเภท) และหมายเลขเฟรม (frame_num) ท่ามกลางสาขาที่สำคัญอื่นๆ
เพื่อให้ได้ค่าของบางฟิลด์ (ue(v), me(v), se(v) หรือ te(v)) เราจำเป็นต้องถอดรหัสแฟรกเมนต์โดยใช้ตัวถอดรหัสพิเศษตาม . วิธีนี้จะมีประสิทธิภาพมากในการเข้ารหัสค่าตัวแปร โดยเฉพาะอย่างยิ่งเมื่อมีค่าเริ่มต้นจำนวนมาก
ความหมาย ชิ้น_ประเภท и frame_num ของวิดีโอนี้คือ 7 (I-fragment) และ 0 (เฟรมแรก)
สตรีมบิตถือได้ว่าเป็นโปรโตคอล หากคุณต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับบิตสตรีม คุณควรดูข้อมูลจำเพาะ ไอทู H.264. นี่คือแผนภาพมาโครที่แสดงตำแหน่งของข้อมูลภาพ (YUV ในรูปแบบการบีบอัด)
บิตสตรีมอื่นๆ สามารถตรวจสอบได้ เช่น VP9, H.265 (HEVC) หรือแม้แต่บิตสตรีมใหม่ที่ดีที่สุดของเรา AV1. พวกเขาทั้งหมดคล้ายกันหรือไม่? ไม่ แต่เมื่อคุณเข้าใจอย่างน้อยหนึ่งข้อแล้ว คุณจะเข้าใจส่วนที่เหลือได้ง่ายขึ้นมาก
อยากฝึกไหม? สำรวจบิตสตรีม H.264
คุณสามารถสร้างวิดีโอเฟรมเดียวและใช้ MediaInfo เพื่อตรวจสอบบิตสตรีมได้ H.264. ในความเป็นจริง ไม่มีอะไรขัดขวางคุณจากการดูซอร์สโค้ดที่วิเคราะห์สตรีมบิต H.264 (AVC).
สำหรับการปฏิบัติคุณสามารถใช้ Intel Video Pro Analyzer ได้ (ฉันบอกไปแล้วเหรอว่าโปรแกรมต้องเสียเงิน แต่มีรุ่นทดลองใช้ฟรีโดยจำกัด 10 เฟรม)
ทบทวน
โปรดทราบว่าตัวแปลงสัญญาณสมัยใหม่จำนวนมากใช้โมเดลเดียวกันกับที่เราเพิ่งศึกษา ที่นี่เรามาดูบล็อกไดอะแกรมของตัวแปลงสัญญาณวิดีโอกัน ธ อร์. ประกอบด้วยขั้นตอนทั้งหมดที่เราผ่าน ประเด็นทั้งหมดของโพสต์นี้คืออย่างน้อยก็ช่วยให้คุณมีความเข้าใจที่ดีขึ้นเกี่ยวกับนวัตกรรมและเอกสารประกอบในด้านนี้
ก่อนหน้านี้ มีการคำนวณว่าจะต้องมีพื้นที่ดิสก์ 139 GB เพื่อจัดเก็บไฟล์วิดีโอที่มีความยาวหนึ่งชั่วโมงที่คุณภาพ 720p และ 30 fps หากคุณใช้วิธีการที่กล่าวถึงในบทความนี้ (การคาดการณ์ระหว่างเฟรมและภายใน การแปลง การหาปริมาณ การเข้ารหัสเอนโทรปี ฯลฯ ) คุณสามารถบรรลุผลสำเร็จ (ตามความจริงที่ว่าเราใช้ 0,031 บิตต่อพิกเซล) วิดีโอที่ค่อนข้าง คุณภาพน่าพอใจเนื้อที่เพียง 367,82 MB ไม่ใช่หน่วยความจำ 139 GB
H.265 มีอัตราการบีบอัดที่ดีกว่า H.264 อย่างไร
ตอนนี้เรารู้มากขึ้นเกี่ยวกับวิธีการทำงานของตัวแปลงสัญญาณแล้ว ก็ง่ายกว่าที่จะเข้าใจว่าตัวแปลงสัญญาณรุ่นใหม่สามารถให้ความละเอียดสูงขึ้นโดยใช้บิตน้อยลงได้อย่างไร
ถ้าคุณเปรียบเทียบ AVC и HEVCควรจำไว้ว่านี่เป็นทางเลือกระหว่างโหลด CPU และอัตราส่วนการบีบอัดที่มากขึ้นเสมอ
HEVC มีตัวเลือกส่วน (และส่วนย่อย) มากกว่า AVCทิศทางการทำนายภายในเพิ่มเติม การเข้ารหัสเอนโทรปีที่ได้รับการปรับปรุง และอื่นๆ มีการปรับปรุงทั้งหมดนี้แล้ว H.265 สามารถบีบอัดได้มากกว่า 50% H.264.
ส่วนแรก:
ที่มา: will.com