2 คะแนน โดย GN⁺ 2024-06-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • H.264 ซึ่งใช้ในวิดีโออินเทอร์เน็ต, Blu-ray, โทรศัพท์มือถือ, กล้องรักษาความปลอดภัย และโดรน เป็นมาตรฐานการบีบอัดวิดีโอที่พัฒนาขึ้นเพื่อส่งวิดีโอแบบฟูลโมชั่นด้วยแบนด์วิดท์ที่สมเหตุสมผล
  • วิดีโอ 1080p 60Hz แบบไม่บีบอัดมีข้อมูลดิบประมาณ 370MB/s จากการคำนวณ 1920×1080×60×3 ทำให้แผ่น Blu-ray 50GB บรรจุได้เพียงราว 2 นาทีเท่านั้น
  • หัวใจของการบีบอัดคือ lossy compression ซึ่งลดรายละเอียดที่สังเกตเห็นได้น้อย และลดปริมาณข้อมูลด้วยการแปลงเป็นโดเมนความถี่, quantization และ chroma subsampling
  • การบีบอัดตามแกนเวลาแบ่งเฟรมออกเป็น I-frame, P-frame และ B-frame แล้วใช้เวกเตอร์การเคลื่อนที่ของ macroblock ขนาด 16×16 พิกเซลเพื่อกู้คืนเฉพาะส่วนที่เปลี่ยน แทนการเก็บทั้งเฟรม
  • ในตัวอย่าง วิดีโอ H.264 ความยาว 5 วินาที 60fps จำนวน 300 เฟรมมีขนาด 175KB ขณะที่สกรีนช็อต PNG เพียงภาพเดียวมีขนาด 1015KB และวิดีโอต้นฉบับ 1.2GB ถูกลดเหลือ 175KB

ข้อมูลที่ H.264 พยายามลด

  • H.264 เป็นมาตรฐานโคเดกบีบอัดวิดีโอที่ใช้กันอย่างแพร่หลายในวิดีโออินเทอร์เน็ต, Blu-ray, โทรศัพท์มือถือ, กล้องรักษาความปลอดภัย, โดรน ฯลฯ
  • เป้าหมายคือการลดแบนด์วิดท์ที่จำเป็นต่อ การส่งวิดีโอแบบฟูลโมชั่น
  • แนวคิดจำนวนมากที่กล่าวถึงในที่นี้ใช้ได้ไม่เพียงกับ H.264 แต่ยังใช้กับการบีบอัดวิดีโอโดยรวมด้วย

ทำไมวิดีโอแบบไม่บีบอัดจึงมีขนาดใหญ่เกินไป

  • ไฟล์วิดีโอแบบไม่บีบอัดอย่างง่ายคืออาร์เรย์ของบัฟเฟอร์ 2D ที่เก็บข้อมูลพิกเซลของแต่ละเฟรม และมองได้ว่าเป็นอาร์เรย์ไบต์ 3D ที่มีมิติเชิงพื้นที่ 2 มิติและมิติเวลา 1 มิติ
  • แต่ละพิกเซลใช้ 3 ไบต์ สำหรับแม่สี 3 สี ได้แก่ แดง เขียว และน้ำเงิน
  • วิดีโอ 1080p 60Hz สร้างข้อมูลดิบประมาณ 370MB/s จากการคำนวณต่อไปนี้
    • 1920 × 1080 × 60 × 3
  • ด้วยขนาดระดับนี้ แผ่น Blu-ray 50GB จะบรรจุได้เพียงราว 2 นาที และการย้ายหรือจัดเก็บก็ทำได้ยาก

วิดีโอ 5 วินาทีที่เล็กกว่าภาพ PNG หนึ่งภาพ

  • ตัวอย่างหน้าจอโฮมเพจของ Apple แสดงผลของการบีบอัด H.264 ได้อย่างเข้าใจง่าย
  • วิดีโอ 5 วินาที 60fps มี 300 เฟรม แต่ขนาดไฟล์อยู่ที่ประมาณ 1 ใน 5 ของเฟรม PNG เพียงเฟรมเดียว
  • เมื่อดูเผิน ๆ วิดีโอที่ควรมีข้อมูลมากกว่า 300 เท่ากลับมีขนาดเล็กกว่า จึงทำให้ H.264 ดูมีประสิทธิภาพกว่า PNG มาก

ข้อมูลที่ทิ้งไปด้วย lossy compression

  • H.264 เป็นโคเดกแบบ lossy compression ที่ทิ้งบิตที่สำคัญน้อยกว่าและเก็บไว้เฉพาะบิตที่สำคัญ
  • PNG เป็นโคเดกแบบ lossless compression จึงสามารถกู้คืนภาพต้นฉบับจากภาพที่เข้ารหัสแล้วได้ในระดับบิตต่อบิต
  • H.264 ไม่ได้ลดข้อมูลด้วยการตัดภาพหรือทิ้งบางควอดแรนต์ แต่ลด ข้อมูลรายละเอียด เหมือนอัลกอริทึมภาพแบบ lossy อื่น ๆ
  • ในภาพตัวอย่าง รายละเอียดอย่างรูบนตะแกรงลำโพงของ MacBook Pro จะหายไป แต่ถ้าไม่ขยายดูก็ยากที่จะสังเกตเห็นความต่าง
  • เพียงขั้นตอนนี้อย่างเดียวก็ลดภาพลงเหลือประมาณ 7% ของขนาดต้นฉบับแล้ว

เอนโทรปีและการกำจัดความซ้ำซ้อน

  • เอนโทรปีของข้อมูล คือจำนวนบิตที่จำเป็นต่อการแทนข้อมูลหนึ่ง ๆ และไม่เหมือนกับขนาดดิบของชุดข้อมูล
  • สามารถเข้าใจได้ว่าเป็นจำนวนบิตขั้นต่ำที่ต้องใช้แทนสถานะที่เป็นไปได้ เช่น ผลการโยนเหรียญ
  • หากโยนเหรียญ 10 ครั้งแล้วออกหัวทั้งหมด แทนที่จะเขียนว่า HHHHHHHHHH ก็สามารถเขียนว่า “หัวทั้งหมด 10 ครั้ง” เพื่อให้สั้นลงได้
  • กระบวนการนี้ลดเฉพาะการแทนค่าโดยไม่เปลี่ยนตัวข้อมูลเอง จึงเป็นการกำจัด ความซ้ำซ้อน
  • ตัวเข้ารหัสแบบ lossless สำหรับวัตถุประสงค์ทั่วไปลักษณะนี้เรียกว่า entropy encoder

โดเมนความถี่และ quantization

  • ข้อมูลที่เปลี่ยนไปตามพื้นที่หรือเวลาสามารถแปลงไปยังระบบพิกัดอื่นได้ และค่าความสว่างของภาพก็สามารถแทนใน โดเมนความถี่ ได้เช่นกัน
  • ในโดเมนความถี่ องค์ประกอบความถี่ต่ำจะอยู่ใกล้ศูนย์กลาง ส่วนองค์ประกอบความถี่สูงจะอยู่บริเวณขอบ
  • ลวดลายรายละเอียดเล็ก ๆ อย่างตะแกรงละเอียดในภาพจัดเป็น องค์ประกอบความถี่สูง ส่วนการเปลี่ยนแปลงของสีและความสว่างแบบค่อยเป็นค่อยไปจัดเป็นองค์ประกอบความถี่ต่ำ
  • หากมาสก์ขอบของภาพในโดเมนความถี่ ก็สามารถทิ้งข้อมูลความถี่สูงได้ และเมื่อแปลงกลับไปเป็นระบบพิกัด x-y ปกติ จะได้ภาพที่คล้ายต้นฉบับแต่มีรายละเอียดน้อยลง
  • การเปลี่ยนขนาดมาสก์ช่วยปรับระดับรายละเอียดของภาพผลลัพธ์ได้
  • ในตัวอย่าง แม้เอนโทรปีของข้อมูลจะเหลือเพียงประมาณ 2% ของต้นฉบับ แต่ถ้าไม่ขยายดูก็ยากที่จะสังเกตเห็นความต่าง
  • ใน lossy compression กระบวนการนี้เรียกว่า quantization

Chroma subsampling

  • ดวงตาและสมองของมนุษย์ตรวจจับการเปลี่ยนแปลงของความสว่างได้ดี แต่แยกแยะความแตกต่างเล็กน้อยของสีได้ค่อนข้างไม่ดี
  • ในสัญญาณทีวี ข้อมูลสี RGB จะถูกแปลงเป็น Y+Cb+Cr
    • Y: luminance หรือความสว่างแบบขาวดำโดยแท้จริง
    • Cb, Cr: chroma difference หรือองค์ประกอบสี
  • RGB และ YCbCr เทียบเท่ากันในแง่เอนโทรปีของข้อมูล
  • ในยุคทีวีขาวดำมีเพียงสัญญาณ Y และเมื่อทีวีสีเกิดขึ้น ก็ใช้วิธีเข้ารหัสข้อมูลสีเป็น Cb และ Cr แล้วส่งไปพร้อมกับ Y
  • ทีวีขาวดำดูเฉพาะองค์ประกอบ Y ส่วนทีวีสีใช้องค์ประกอบ chroma เพิ่มเติมและแปลงกลับเป็น RGB ภายใน
  • วิธีที่ใช้ใน H.264 คือเก็บองค์ประกอบ Y ที่ความละเอียดเต็ม และเก็บองค์ประกอบ C ที่ หนึ่งในสี่ของความละเอียด
  • Chroma subsampling ทิ้งข้อมูลสีบางส่วน เพื่อลดแบนด์วิดท์รวมลง ครึ่งหนึ่ง ขณะที่ยังคงความแตกต่างทางสายตาให้น้อย
  • เทคนิคนี้ไม่ใช่ฟีเจอร์เฉพาะของ H.264 และถูกใช้อย่างแพร่หลายมาหลายสิบปีแล้ว

Motion compensation และการบีบอัดตามแกนเวลา

  • H.264 เป็นมาตรฐานการบีบอัดแบบ motion compensation
  • นอกเหนือจากการบีบอัดโดเมนเชิงพื้นที่ภายในเฟรมเดี่ยวแล้ว ยังจัดการหลายเฟรมร่วมกันตามแกนเวลา
  • ในวิดีโออย่างการแข่งขันเทนนิสที่กล้องอยู่กับที่และมีเพียงลูกบอลที่เคลื่อนที่ ไม่จำเป็นต้องเก็บฉากหลังทั้งหมดซ้ำทุกครั้ง
  • โดยปกติภาพจะถูกแบ่งเป็น macroblock ขนาด 16×16 พิกเซล และประเมินการเคลื่อนที่ในระดับบล็อกเหล่านี้
  • ประเภทเฟรมแบ่งกว้าง ๆ เป็นสามแบบ
    • I-frame: เฟรมที่มีบิตทั้งหมดที่จำเป็นต่อการสร้างทั้งเฟรม
    • P-frame: เฟรมทำนายที่เข้ารหัสเวกเตอร์การเคลื่อนที่ของแต่ละ macroblock จากเฟรมก่อนหน้า
    • B-frame: เฟรมทำนายสองทิศทางที่ทำนายจากทั้งเฟรมในอดีตและเฟรมในอนาคต
  • ตัวถอดรหัสเริ่มจาก I-frame ล่าสุด แล้วบวกเดลตาของเวกเตอร์การเคลื่อนที่ในเฟรมถัด ๆ ไปเพื่อสร้างเฟรมปัจจุบัน
  • วิดีโอตัวอย่างโฮมเพจของ Apple บีบอัดได้ดีมาก เพราะโดยพื้นฐานแล้วเป็นรูปแบบที่ macroblock เคลื่อนที่จาก I-frame สามเฟรม

เหตุผลที่หยุดชั่วครู่หลังกรอย้อนกลับ

  • อาการที่วิดีโออย่าง YouTube ไม่เล่นต่อทันทีและหยุดชั่วครู่เมื่อกรอย้อนกลับไปไม่กี่วินาที เกี่ยวข้องกับโครงสร้างของ H.264
  • เมื่อผู้ใช้กระโดดไปยังเฟรมใดก็ได้ ตัวถอดรหัสต้องคำนวณใหม่ตั้งแต่ I-frame ที่อยู่ใกล้เคียง
  • จากนั้นต้องสะสมเดลตาของเวกเตอร์การเคลื่อนที่ไปจนถึงเฟรมถัด ๆ ไปเพื่อสร้างเฟรมปัจจุบัน จึงมีต้นทุนการคำนวณสูง
  • วิธีนี้มีประสิทธิภาพด้านพื้นที่สูงมาก แต่ต้องใช้การคำนวณในการถอดรหัส

ขั้นตอนบีบอัดแบบ lossless ขั้นสุดท้าย

  • แม้ I-frame ที่ผ่านขั้นตอน lossy แล้วก็ยังมีข้อมูลซ้ำซ้อนเหลืออยู่
  • เวกเตอร์การเคลื่อนที่ของ macroblock ใน P-frame และ B-frame ก็อาจมีกลุ่มที่มีค่าเดียวกันได้
  • โดยเฉพาะในวิดีโอทดสอบที่ภาพกำลังแพน macroblock หลายบล็อกจะเคลื่อนที่ในปริมาณเท่ากัน
  • Entropy encoder จะจัดการความซ้ำซ้อนเหล่านี้
  • Entropy encoder เป็นตัวเข้ารหัสแบบ lossless สำหรับวัตถุประสงค์ทั่วไป ดังนั้นข้อมูลที่ป้อนเข้าไปจึงสามารถกู้คืนได้

ตัวอย่างอัตราการบีบอัด

  • วิดีโอตัวอย่างต้นฉบับถูกจับภาพที่ความละเอียดไม่เป็นมาตรฐานคือ 1232×1154
  • ที่ความยาว 5 วินาที 60fps ขนาดต้นฉบับอยู่ที่ประมาณ 1.2GB จากการคำนวณต่อไปนี้
    • 1232 × 1154 × 60 × 3 × 5
  • วิดีโอ H.264 ที่บีบอัดแล้วมีขนาด 175KB
  • หากเทียบตามอุปมาเรื่องรถยนต์ในบทความ ก็เหมือนรถหนัก 3000 ปอนด์ถูกลดลงเหลือ 0.4 ปอนด์ หรือ 6.5 ออนซ์
  • คำอธิบายอัตราการบีบอัดนี้เป็นการย่อผลงานวิจัยหลายสิบปีให้ง่ายลงอย่างมาก และอ่านรายละเอียดเพิ่มเติมได้ที่ H.264/MPEG-4 AVC Wikipedia Page

1 ความคิดเห็น

 
GN⁺ 2024-06-15
ความเห็นจาก Hacker News
  • AV1 เป็นโคเดกที่มีเรื่องไลเซนส์ดีกว่า และก็เหมือนเวทมนตร์ยิ่งกว่าอีก
    Meta กำลังค่อย ๆ เปลี่ยนให้สตรีม VP9/AV1 เป็นค่าเริ่มต้นสำหรับการสตรีมวิดีโอ: https://www.streamingmedia.com/Producer/Articles/Editorial/F...
    และยังใช้ AV1 กับวิดีโอคอลด้วย: https://engineering.fb.com/2024/03/20/video-engineering/mobi...
    Microsoft ก็เริ่มใช้ AV1 ใน Teams แล้ว และ AV1 มีเครื่องมือการเข้ารหัสวิดีโอที่มีประโยชน์อย่างยิ่งกับการแชร์หน้าจอ: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
    ทุกวันนี้วิดีโอส่วนใหญ่ที่ดูบน YouTube เป็น VP9 หรือ AV1 และมี H.264 โผล่มาให้เห็นเป็นครั้งคราวเท่านั้น
    H.264 คงจะอยู่ไปอีกนานพอสมควร แต่ดูมีโอกาสสูงที่ AV1 จะกลายเป็นค่าเริ่มต้นใหม่ของวิดีโอบนอินเทอร์เน็ต

    • ก็จริง แต่การรองรับ ฮาร์ดแวร์เข้ารหัส/ถอดรหัส ยังแพร่หลายไม่สมบูรณ์
      จากมุมมองของนักพัฒนา ทุกคนต้องเข้าถึงได้ แต่ตอนนี้ยังเป็นช่วงรอให้ความสามารถนี้ลงไปถึงผู้ใช้ส่วนใหญ่
      อยากให้มีคนซื้อฮาร์ดแวร์ที่รองรับการเข้ารหัส/ถอดรหัส AV1 มากขึ้น และน่าจะต้องมีโลโก้แบบ “AV1 inside”
      ตัวอย่างเช่น ในไลน์อัป iPhone ตอนนี้ยังมีเพียง iPhone 15 Pro ที่รองรับการถอดรหัสด้วยฮาร์ดแวร์
    • AV1 นั้นแย่มากจริง ๆ ถ้าจะเข้ารหัสด้วยซอฟต์แวร์
      เคยต้องอัดวิดีโอการสอนแล้วทำเป็นไฟล์ 720p ที่ค่อนข้างเล็กเพื่ออัปโหลด เป็นวิดีโอที่ถ่ายคนซึ่งเคลื่อนไหวช้า ๆ หน้าเส้นสีขาวบางและคมบนกระดานไวท์บอร์ด ภายใต้แสงที่ก้ำกึ่ง ทำให้โปรไฟล์เข้ารหัสเริ่มต้นของ x264 ไม่ค่อยเหมาะ
      ถึงอย่างนั้นก็ยังใช้เวลาปรับแต่งอยู่หนึ่งถึงสองวัน จนทำให้มันรันข้ามคืนหลังวันสอนบนโน้ตบุ๊กที่มีแค่ iGPU ราวปี 2014 แล้วเอาผลลัพธ์ไปอัปโหลดได้ในวันถัดไป
      แต่ฝั่ง libaom กลับประเมินว่าเรนเดอร์วิดีโอยาว 3 ชั่วโมงจะใช้เวลาประมาณหนึ่งสัปดาห์ และค่าเริ่มต้นก็แย่เกินกว่าจะมีเวลามาลองผิดลองถูก
      นี่เป็นเรื่องเมื่อ 4 ปีก่อน ตอนนี้อาจดีขึ้นแล้ว แต่ก็ไม่ถึงกับคาดหวังปาฏิหาริย์
    • ในสเปซสี 8 บิต H.264/5 แทบจะไม่มี บล็อกอาร์ติแฟกต์ เลยในทางปฏิบัติ แต่ AV1 กำจัดสิ่งนี้ได้ยากหากไม่ขยับไปใช้ 10 บิต
      ไม่ได้ถึงขั้นเป็นปัญหาเสมอไป แต่ปัญหาจริงของ AV1 คือการบีบอัดใช้พลังประมวลผลมากเกินไป
    • รู้สึกสลัดไม่หลุดว่าวิดีโอ 720p ส่วนใหญ่ที่ดูบน YouTube ในช่วงไม่กี่ปีมานี้ คุณภาพแย่ลงมาก
      หรือไม่ก็อาจเป็นเพราะสายตาฉันดีขึ้น
      ถ้ามีบทความที่เจาะลึกประเด็นนี้ก็น่าอ่านมาก
    • AV1 ให้ ความเร็วในการเข้ารหัส/ถอดรหัส ได้ไม่เร็วเท่า H.264
  • บทความที่เกี่ยวข้อง:
    H.264 is Magic (2016) - https://news.ycombinator.com/item?id=30710574 - มีนาคม 2022, ความเห็น 219 รายการ
    H.264 is magic (2016) - https://news.ycombinator.com/item?id=19997813 - พฤษภาคม 2019, ความเห็น 180 รายการ
    H.264 is Magic – a technical walkthrough - https://news.ycombinator.com/item?id=17101627 - พฤษภาคม 2018, ความเห็น 1 รายการ
    H.264 is Magic - https://news.ycombinator.com/item?id=12871403 - พฤศจิกายน 2016, ความเห็น 219 รายการ

  • ตอนนี้ผ่านไป 8 ปีแล้วนับจากที่บทความนั้นถูกเขียนขึ้น และ สิทธิบัตร H.264 จำนวนมากก็กำลังจะหมดอายุในไม่ช้า ภายในราว 1-2 ปี: https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...
    เมื่อคิดว่ามาตรฐาน H.264 เวอร์ชันแรกออกมาในปี 2003 และสิทธิบัตรมักมีอายุ 20 ปี ก็ไม่ได้เป็นเรื่องน่าแปลกใจ
    H.263 และ MPEG-4 ASP ซึ่งเป็นอัลกอริทึมรุ่นก่อนหน้า ได้หมดอายุสิทธิบัตรไปแล้วและอยู่ใน public domain

    • อัลกอริทึมรุ่นถัด ๆ ไปก็คงจะถูกนำไปใช้อย่างแพร่หลายในฮาร์ดแวร์ในที่สุด และเราก็น่าจะกลับไปติดอยู่กับ ปัญหาสิทธิบัตร อีกครั้ง
  • แล้ว H.265 ล่ะ? ตัวเลขมากกว่าอยู่หนึ่งนี่? https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding

    • ผมทำงานบีบอัดวิดีโอเป็นโปรเจ็กต์งานอดิเรกอยู่บ่อย ๆ แต่ส่วนใหญ่ก็ยังยึด H.264
      การเข้ารหัส H.265 มีภาระการคำนวณเพิ่มขึ้นมากเกินไปเมื่อเทียบกับขนาดที่ประหยัดได้
      ไฟล์ที่ใช้ H.264 ลดเหลือ 1GB ใน 1 ชั่วโมง พอใช้ H.265 กลับต้องใช้ 12 ชั่วโมงเพื่อลดเหลือ 850MB ประมาณนั้น
      แล้วขึ้นอยู่กับการใช้งานด้วยว่า สุดท้ายอาจยังต้องมีเวอร์ชัน H.264 อยู่ดี เพราะฝั่งไคลเอนต์รองรับได้กว้างกว่ามาก
      ถ้ามีทรัพยากรประมวลผลระดับดาต้าเซ็นเตอร์ หรือทำบริการสตรีมมิงที่การประหยัด 150MB ต่อวิดีโอสะสมแล้วคุ้ม ก็คงไปทาง H.265 แต่ในหลายกรณีจริง ๆ มันยากจะหาเหตุผลมารองรับ
    • ผมค่อนข้างชอบ HEVC/H.265
      มันแทบจะอยู่ระดับเดียวกับ VP9 แต่เพราะ ปัญหาเรื่องไลเซนส์ ก็เลยยังถูกนำไปใช้ได้ยากในหลายที่
      ดูเหมือน VVC/H.266 ก็เจอปัญหาเดียวกัน ส่วน AV1 ก็แทบจะดีพอกันและตอนนี้ก็ถูกรับไปใช้มากกว่ามากแล้ว
    • H.264 ให้ความรู้สึกว่าไปลงตัวมากในเรื่อง สมดุลระหว่างความซับซ้อนกับอัตราการบีบอัด
      codec ที่ใหม่กว่านั้นบีบอัดได้ดีกว่า แต่ความซับซ้อนเพิ่มขึ้นแบบไม่เป็นเชิงเส้น
    • ผมมีวิดีโอเก่าความละเอียดสูงขนาดมหึมาหลายไฟล์ที่อยู่ในฟอร์แมตไม่มีประสิทธิภาพหลายแบบเลยลองทดสอบดู แล้วสุดท้ายก็ re-encode/transcode เป็น H.265 ทั้งหมด
      ขนาดไฟล์เล็กกว่า H.264 มาก
      มาตรฐานก็ใหม่กว่า H.264 อยู่ 10 ปีด้วย โดย H.264 คือปี 2003 และ H.265 คือปี 2013
    • แล้ว VVC(H.266) ล่ะ? https://en.wikipedia.org/wiki/Versatile_Video_Coding
  • สำหรับตัวอย่างที่ว่า “ถ้าโยนเหรียญ 10 ครั้งแล้วออกหัวทั้งหมด ก็ไม่ต้องเขียนว่า HHHHHHHHHH แต่เขียนว่า ‘โยน 10 ครั้งและออกหัวทั้งหมด’ ได้” เหมือนใน สตริง H นั้นจะมีการบีบอัดแบบสูญเสียข้อมูลปนอยู่หน่อย ๆ

    • จริง ๆ แล้ว “โยน 10 ครั้งและออกหัวทั้งหมด” ก็มีจำนวนตัวอักษรมากกว่า เลยไม่ใช่การบีบอัดด้วยซ้ำ
    • แต่ถ้าลองพูดออกเสียงทีละแบบก็ให้ความรู้สึกต่างกัน
  • ผมจำตอนที่ H.264 ออกมาใหม่ ๆ ได้
    ตอนนั้นกำลังอินกับ mplayer มาก เลยโหลดรีลีสใหม่ ๆ มาคอมไพล์เองบ่อย ๆ
    พอได้ไฟล์ H.264 ไฟล์แรกมา mplayer กลับเปิดไม่ได้ เลยต้องไปโหลดเวอร์ชันพัฒนามาคอมไพล์
    มันใช้งานได้ และผมก็ได้รู้อะไรสองอย่าง: คุณภาพภาพน่าทึ่งมาก และ Athlon 1800+ ของผมเอาไม่อยู่
    หลังจากนั้นประสิทธิภาพใน mplayer หรือ libavcodec รุ่นต่อ ๆ มาก็ดีขึ้นมาก แต่ผมยังจำวันนั้นได้อยู่

    • ผมก็เหมือนกัน
      ไม่ได้ใช้ mplayer มานานมากแล้ว แต่ตอนนั้นมันยอดเยี่ยมจริง ๆ
      ผมเคยทำงานที่บริษัทซึ่งพัฒนาผลิตภัณฑ์เกี่ยวกับวิดีโอ แล้วมีอีกบริษัทหนึ่งจากลาสเวกัสมาขาย “video codec เชิงนวัตกรรม” กับเพลเยอร์ให้ผู้บริหารของเรา และถ้าจะใช้ต้องเซ็น NDA ก่อน
      พอลองใช้แล้วมันทำงานเหมือน mplayer มาก เหมือนเกินไปด้วย
      สืบต่ออีกแค่ 5 นาทีก็โป๊ะแตก แล้วผู้บริหารที่จ่ายเงินก้อนโตให้บริษัทนั้นก็เสียหน้าไปตามระเบียบ
      แม้แต่ในสายเทคนิคเอง การหลอก ผู้ตัดสินใจที่ไม่ใช่สายเทคนิค ก็ง่ายอย่างน่าตกใจ
      เพราะความกลัวว่าจะตามคนอื่นไม่ทันมันแรงมาก
      คนฉลาดจะเรียกวิศวกรเก่ง ๆ มาช่วยประเมิน ส่วนพวกที่เข้าข่าย Dunning-Kruger ก็ไปต่อคิวพร้อมกระเป๋าสตางค์
  • มีช่วงหนึ่งในปี 1999 ที่ฉันกำลังจะลาออกจากสตาร์ตอัปที่ถูกซื้อกิจการไป และตอนนั้นฉันทำงานด้าน MPEG encoding
    หนึ่งในบริษัทที่ฉันไปสัมภาษณ์บอกว่าพวกเขาสร้างวิธีบีบอัดวิดีโอแบบใหม่ขึ้นมา และหลังเซ็น NDA ก็ให้ดูคลิปสั้น ๆ ที่เข้ารหัส/ถอดรหัสด้วยซอฟต์แวร์โคเดกแบบไม่เรียลไทม์
    ฉันกำลังสัมภาษณ์ในตำแหน่งคนที่จะไปสร้างเวอร์ชัน ASIC ของอัลกอริทึมนั้น และดูเอาต์พุตแค่ 1–2 นาทีก็พอเดาได้แล้วว่าพวกเขากำลังทำอะไร
    ฉันคิดว่าตัวอย่างนั้นถูกจัดมาให้เข้ากับจุดแข็งของอัลกอริทึม เลยเสนอฉากที่ยากกว่าน่าจะทำให้ดู และอธิบายด้วยว่าจากที่ฉันเห็นมันน่าจะเป็นวิธีแบบไหน
    พวกเขาไม่ยืนยันและไม่ปฏิเสธ แต่เรียกฉันไปสัมภาษณ์รอบสอง
    ในรอบสองฉันคุยกับผู้ก่อตั้งที่เป็นคู่สามีภรรยา CEO/CTO แล้วพบว่าแผนของพวกเขาไม่ใช่ขาย ASIC แต่จะเก็บโคเดกเป็นความลับ แล้วใช้ ASIC ไปสร้างเครือข่ายเคเบิลบน DSL เพื่อกระจายวิดีโอ
    ฉันบอกว่า “มันเหมือนประดิษฐ์คาร์บูเรเตอร์ที่ดีกว่าได้แล้ว แต่กลับจะไปสร้างโรงงานรถยนต์เพื่อแข่งกับ GM” ซึ่งพวกเขาไม่ได้ชอบเท่าไร
    จุดที่เรื่องนี้โยงกับ H.264 คือคำกล่าวอ้างของพวกเขาว่า “การบีบอัดแบบเดิมไปถึงขีดจำกัดแล้ว ดังนั้นมีแค่โคเดกของเราเท่านั้นที่ส่งวิดีโอคุณภาพสูงผ่านสาย DSL ได้”
    ฉันตอบว่าเทคนิคการบีบอัดจะดีขึ้นเรื่อย ๆ และต่อให้ไม่ดีขึ้น เกณฑ์ที่พวกเขาคิดว่าข้ามไม่ได้ก็จะหายไปเองเมื่ออินเทอร์เน็ตที่เร็วขึ้นเข้าถึงบ้านคนทั่วไป
    พวกเขาบอกว่าตามกฎฟิสิกส์ อัตราบิตที่ส่งผ่านสายทองแดงมีขีดจำกัด และเราไปถึงขีดนั้นแล้ว
    ฉันไม่ได้รับข้อเสนองาน และก็ไม่ได้อยากได้ด้วย
    บริษัทนั้นได้เงิน VC ไป แต่ก็ปิดตัวลงในอีกไม่กี่ปีต่อมา ขณะที่คนอื่นสร้างโคเดกที่มีประสิทธิภาพสูงกว่ามาก และการเชื่อมต่ออินเทอร์เน็ต 2Mbps ก็ไม่ใช่ขีดจำกัด
    ตัวอัลกอริทึมจริง ๆ น่าจะมีคณิตศาสตร์ฉลาด ๆ และพลังเชิงอัลกอริทึมอยู่มาก ดังนั้นพวกเขาไม่ได้โง่ทางเทคนิค เพียงแต่ขาดเซนส์ด้านธุรกิจ
    พอเล่าแบบนี้อีกทีก็ฟังเหมือนคนอวดดีรู้ทุกเรื่อง แต่ในชีวิตฉันมีอยู่สองครั้งที่เห็นอะไรบางอย่างแล้วเดา secret sauce ออกได้ภายในไม่กี่วินาที
    ส่วนครั้งที่ฉันโง่นั้นมีมากกว่านี้เยอะ
    อัลกอริทึมนี้ไม่เคยได้รับการยืนยัน แต่ดูจาก silhouette artifacts แล้วค่อนข้างชัด
    MPEG เหมือน JPEG ตรงที่บีบอัดภาพเป็นบล็อกเล็ก ๆ (8x8, 16x16 ฯลฯ) ซึ่งเป็นการจำกัดขอบเขตที่ใช้ประโยชน์จาก spatial redundancy แต่ก็จำกัดต้นทุนการคำนวณในการค้นหาความซ้ำซ้อนนั้นด้วย
    โคเดกของพวกเขาดูคล้ายกับสิ่งที่ Microsoft เคยเสนอไว้กับสถาปัตยกรรมกราฟิก Talisman ในช่วงปลายยุค 1990
    แทนที่จะแบ่งเป็นบล็อกคงที่ มันน่าจะวิเคราะห์ลำดับเฟรมเพื่อหาโซนที่มีความสอดคล้องเชิงโครงสร้างพร้อมขอบเขตกึ่งสุ่ม
    ตัวอย่างเช่น ในการแข่งขันเทนนิส ฉากหลังค่อนข้างใกล้เคียงกับ “วัตถุแข็ง” ดังนั้นถ้ากล้องแพนแล้วพิกเซลหนึ่งขยับ พิกเซลรอบ ๆ ก็น่าจะ undergo spatial transform แบบเดียวกัน
    ส่วนผู้เล่นจะเปลี่ยนไปทุกเฟรม แต่ภายในก้อนนั้นยังมีความสัมพันธ์กันทั้งเรื่องแสงและตำแหน่ง
    หลังระบุโซนเหล่านี้ได้แล้ว พวกเขาก็คงบีบอัดภาพของแต่ละโซนแบบคล้าย JPEG และในเฟรมถัดไปก็วิเคราะห์ว่าโซนหนึ่ง ๆ undergo affine transform หรือทรานส์ฟอร์มที่ทั่วไปกว่านั้นอย่างไร แล้วเข้ารหัสด้วยพารามิเตอร์ไม่กี่ตัว
    นั่นจะเป็นพื้นฐานของการทำนายเฟรมถัดไป และถ้าทำนายได้แม่น ก็ไม่ต้องใช้บิตมากนักเพื่อแก้ความคลาดเคลื่อนของการทำนาย

    • จำชื่อบริษัทกับชื่อผู้ก่อตั้งไม่ได้แล้ว แต่ Google ช่วยหาให้: https://www.zdnet.com/article/high-hopes-for-video-compressi...
      เขาว่าได้เงินลงทุนจาก VC ไป 32 ล้านดอลลาร์ และโผล่ออกจาก stealth mode ในปี 2002
      หลังจากนั้นเกิดอะไรขึ้นฉันหาไม่เจอ
    • มากกว่าจะพูดว่า “ไม่ได้โง่ทางเทคนิค” ฉันคิดว่าถ้าพวกเขาตั้งสมมติฐานว่ามี ขีดจำกัดแบบแข็งตัว ทั้งต่อประสิทธิภาพของโคเดกและแบนด์วิดท์อินเทอร์เน็ต อย่างน้อยก็นับว่าไร้เดียงสาทางเทคนิค
  • บทความนี้ยอดเยี่ยมมาก แต่การเขียนคำว่า Information Entropy แยกเหมือนเป็นศัพท์อีกคำหนึ่งนั้นติดหูพอ ๆ กับพวกสำนวนแนว “ATM machine” เลย
    ตัวบทความดีมาก แต่สำนวนนี้แรงจริง

    • สัญญาณกับ noise ไม่ใช่เรื่องเดียวกันนี่?
    • ถึงอย่างนั้นฉันก็คิดว่า information entropy อธิบายตัวเองได้มากกว่า Shannon entropy
    • ตรงนี้ไม่เกี่ยวโดยตรงก็จริง แต่ในเชิงเทคนิคมันมี thermal entropy ด้วยไม่ใช่หรือ? ไม่ได้หมายถึงข้อมูลอย่างเดียวเสมอไป
  • ในปี 02016 H.264 คือเวทมนตร์ที่ถูกผูกมัดด้วยสิทธิบัตรในหลายประเทศ
    ตอนนี้มาตรฐานถูกเผยแพร่เมื่อเดือนสิงหาคม 02004 หลังผ่านกระบวนการทำมาตรฐานแบบเปิดมา 1 ปี และสิทธิบัตรมีอายุแค่ 20 ปีนับจากวันยื่นคำขอ อีกทั้งสิ่งที่เปิดเผยสู่สาธารณะแล้วก็จดสิทธิบัตรไม่ได้ ดังนั้นส่วนใหญ่จึงหมดอายุไปแล้วหรือจะหมดในอีกไม่กี่เดือน
    ในสหรัฐฯ ถ้าเป็นการเปิดเผยโดยตัวผู้ประดิษฐ์เองจะมีช่วงผ่อนผัน 1 ปี แต่ถ้ามีข้อยกเว้นอย่างอื่นฉันก็อยากฟัง
    userbinator ชี้ไปที่ https://meta.m.wikimedia.org/wiki/Have_the_patents_for_H.264... แต่สิทธิบัตรส่วนใหญ่ในนั้นมีวันลำดับสิทธิก่อนหลังการสรุปมาตรฐาน H.264 จึงอาจไม่จำเป็นต่อการทำ implementation ของ H.264 เอง
    เว้นแต่ว่าจะอ้างว่าในช่วงทำมาตรฐานยังไม่รู้ว่าสามารถ implement ได้ ซึ่งก็ค่อนข้างโน้มน้าวยาก
    สิ่งที่น่าทึ่งคือ ตลอด 20 ปีที่ผ่านมา มีหลายอย่างที่อาจเรียกได้ว่าดีกว่านิดหน่อย แต่จากเกณฑ์ที่ฉันทดสอบด้วย implementation ของ ffmpeg ยังไม่มีอะไรที่ดีกว่ามากอย่างชัดเจน
    ถ้าสถานะ ปลอดสิทธิบัตร ได้รับการยืนยัน ไม่ว่าจะชอบหรือไม่ H.264 ก็น่าจะยิ่งแข็งตัวในฐานะโคเดกมาตรฐานไปอีกพักใหญ่
    AV1 ให้คุณภาพภาพดีกว่านิดหน่อยที่แบนด์วิดท์เท่ากัน แต่ช้ากว่ามาก และยังเสี่ยงต่อสิทธิบัตรที่ยื่นช้าถึงระดับปี 02018

    • งั้นพอพ้นปี 2038 เราก็จะได้ AV1 ที่ปลอดสิทธิบัตร ใช่ไหม!
    • ทำไมถึงเติม 0 ข้างหน้าปีอีกตัว?
  • ประโยคที่ว่า “คุณสั่งให้ดีโคเดอร์กระโดดไปเฟรมตามอำเภอใจ มันเลยต้องเริ่มจาก I-frame ที่ใกล้ที่สุด แล้วคำนวณ motion vector deltas ซ้ำไล่มาจนถึงเฟรมปัจจุบัน จึงค้างไปชั่วคราว” นั้นเป็นเรื่องของปี 2016
    ทุกวันนี้เป็นเพราะ YouTube รู้ว่าคุณใช้ Firefox