ผมลดวิดีโอที่ใช้งานจริงจากประมาณ 280 MB เหลือประมาณ 50 MB ด้วย H.264 ได้อย่างไร

ตัวเลขที่ทำให้การปรับแต่งครั้งนี้จับต้องได้จริงในที่สุดนั้นง่ายมาก: วิดีโอที่ใช้งานจริงหนึ่งไฟล์ที่ผมติดตามลดจากประมาณ 280 MB เหลือ 50 MB หลังใช้นโยบาย H.264 ใหม่ เท่ากับเล็กลงประมาณ 5.6 เท่า ประหยัดไปราว 230 MB หรือประมาณ 82% ของขนาดเดิม

ผมไม่ได้ผลลัพธ์นี้จากการย้ายไป AV1, HEVC หรือ VP9 ไฟล์ที่ใช้งานจริงยังคงเป็น H.264 ใน MP4 สิ่งที่เปลี่ยนคือนโยบายรอบโคเดก: ลดพิกเซลที่ไม่จำเป็น ลดตัวอย่างตามเวลาที่ไม่มีประโยชน์ ตั้งเป้าคุณภาพที่ไม่เผื่อมากเกินไป ยอมจ่าย CPU มากขึ้นครั้งเดียวตอนเข้ารหัส และกำหนดข้อจำกัดฝั่งถอดรหัสให้ชัดเจน

นี่เป็นลักษณะงานที่เฉพาะมาก: คลิปภาพวาดและแอนิเมชันสั้น ๆ, ผู้ชมราว 80% ใช้งานผ่านมือถือ, แบนด์วิดท์ เป็นต้นทุนที่เกิดซ้ำ และ การเข้ารหัสล่วงหน้าที่เวลาเข้ารหัส ถูกกว่าการส่งไฟล์ใหญ่เกินจำเป็นซ้ำแล้วซ้ำอีก

นโยบายเก่าและใหม่โดยคร่าว ๆ คือ:

การตั้งค่าเดิม
H.264 Main @ Level 4.0
CRF 19
ค่ากำหนดล่วงหน้า slow
สูงสุด 1920x1080 / 1080x1920
30 fps
refs = 3
เฟรม B = 3
GOP ≈ 2 วินาที
VBV ≈ 10M / 20M

การตั้งค่าใหม่
H.264 Main @ Level 3.1
CRF 28
ค่ากำหนดล่วงหน้า veryslow
เพดานระดับ 720p ไม่ขยายภาพ
CFR ที่มีประโยชน์ ปกติ <= 30 fps
refs = 4
เฟรม B = 5
GOP ≈ 5 วินาที
VBV ≈ 4M / 8M
yuv420p / avc1 / faststart

ผลที่วัดได้: จากประมาณ 280 MB เหลือประมาณ 50 MB

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

การวัด	ก่อน	หลัง	การลดลง
วิดีโอไฟล์เดียวกันโดยตรง	~280 MB	~50 MB	เล็กลง ~5.6× / ลด ~82%
ขั้นก่อนหน้าของไฟล์เดียวกัน	~350 MB	~238 MB	เล็กลง ~1.47× / ลด 32%

แถวแรกคือหลักฐานที่ตรงที่สุดสำหรับชื่อบทความ เป็นวิดีโอไฟล์เดียวกันก่อนและหลังนโยบายใหม่: ประมาณ 280 MB กลายเป็นประมาณ 50 MB ผมหาบันทึกเก่าที่เก็บอัตราบิต/ระยะเวลา ของคู่นี้โดยตรงไม่เจอ จึงไม่แต่งตัวเลขขึ้นมา การเปลี่ยนขนาดเพียงอย่างเดียวก็เพียงพอแล้ว: ไฟล์นี้เล็กลงประมาณ 5.6 เท่า

กรณี ~350→238 MB เป็นขั้นการปรับให้เหมาะสมที่เก่ากว่าของไฟล์เดียวกัน ตอนนั้นผลลัพธ์อยู่ที่ประมาณ 1264×720, 30 fps, ความยาวราว 500 วินาที, ไม่มีเสียง และประมาณ 3.8 Mbps ตัวเลขทางคณิตศาสตร์ตรงกับขนาดจริง: 3.8 Mbps เป็นเวลาประมาณ 500 วินาทีได้ราว 238 MB นั่นลดจาก ~350 MB ไปแล้ว 32% แต่ยังใหญ่เกินเป้าหมายด้านแบนด์วิดท์ของผม

การตรวจสอบ คลังเก่ายังแสดงด้วยว่า H.264 ที่มีขนาดใหญ่มากไม่ได้เป็นค่าผิดปกติเพียงไฟล์เดียว ในการตรวจสอบครั้งหนึ่งมีวิดีโอ ระบบใช้งานจริง 238 ไฟล์ รวม 6.37 GB: H.264 117 ไฟล์และ AV1 121 ไฟล์ โดย 101 ไฟล์มีขนาดอย่างน้อย 20 MB และ 34 ไฟล์อย่างน้อย 50 MB ตัวอย่าง H.264 ขนาดใหญ่บางส่วนคือ:

ขนาด	ระยะเวลา	อัตราบิตเฉลี่ย
121.0 MB	4:25	3.83 Mbps
101.2 MB	5:19	2.659 Mbps
92.78 MB	4:44	2.735 Mbps
90.10 MB	3:55	3.206 Mbps
89.74 MB	4:41	2.676 Mbps

ไฟล์เหล่านี้เป็นคนละเนื้อหา ดังนั้นตารางนี้ใช้เป็นบริบท ไม่ใช่การทดสอบ การเปรียบเทียบก่อนและหลังโดยตรง แต่ตารางยืนยันได้ว่าตัวอย่างเก่าที่ 3.8 Mbps ไม่ใช่กรณีหลุดเพียงครั้งเดียว เพราะ H.264 ขนาดใหญ่หลายไฟล์ในคลังเดิมอยู่แถวประมาณ 2.6–3.8 Mbps จริง

การปรับให้เล็กลงที่สำคัญที่สุดไม่ใช่แฟล็กของ FFmpeg

การเปลี่ยนแปลงที่ใหญ่ที่สุดคือวิธีที่ผมคิดเรื่องต้นทุน

การเข้ารหัสเกิดขึ้นครั้งเดียว แต่การส่งไฟล์เกิดขึ้นทุกครั้งที่มีคนขอไฟล์

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

นี่คือเหตุผลที่ -preset veryslow เหมาะกับผม ผมยอมจ่าย CPU ครั้งเดียว หาก x264 ใช้เวลานั้นค้นหาการแทนข้อมูลที่มีประสิทธิภาพกว่า เบราว์เซอร์ไม่ได้ทำการค้นหาของตัวเข้ารหัสซ้ำ มันเพียงถอดรหัสบิตสตรีมที่เสร็จแล้ว

กฎจึงง่ายมาก: ยอมใช้การประมวลผลกับขั้นตอนที่เกิดครั้งเดียว และประหยัดทุกไบต์ในขั้นตอนที่เกิดซ้ำ

ทำไมผมยังใช้ H.264 แทนที่จะไล่ตามโคเดกใหม่ที่สุด

ผมไม่ได้อ้างว่า H.264 เป็นโคเดกที่บีบอัดได้ดีที่สุดในปัจจุบัน เพราะไม่ใช่ โคเดกใหม่กว่าน่าสนใจมากเมื่อระบบส่งสื่อสามารถเก็บหลายเวอร์ชันและเลือกเวอร์ชันที่เหมาะกับอุปกรณ์แต่ละเครื่องได้

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

สำหรับงานนี้ H.264 ใน MP4 ยังเป็นตัวเลือกพื้นฐานที่ปลอดภัยมาก ปัจจุบัน Apple แนะนำให้นักพัฒนาเว็บใช้ ไฟล์ MP4 ที่เข้ารหัสด้วย H.264 สำหรับวิดีโอแบบคงที่ใน Safari เอกสารปัจจุบันของ Android ระบุ H.264 ใน MP4 และกำหนดให้มีตัวถอดรหัส โปรไฟล์ Main ตั้งแต่ Android 6.0 เป็นต้นไป คำแนะนำการเล่น H.264 ยังระบุ 1280×720 ที่ 30 fps สำหรับ HD พร้อมหมายเหตุว่าอุปกรณ์บางรุ่นไม่รองรับ HD ดู รูปแบบสื่อที่ Android รองรับ

ไม่ได้หมายความว่าอุปกรณ์สมัยใหม่จำกัดอยู่ที่ โปรไฟล์ Main หรือ ระดับ 3.1 ตัวอย่างเช่น แนวทาง HLS ของ Apple โดยทั่วไปแนะนำ โปรไฟล์ High มากกว่า Main หรือ โปรไฟล์ Baseline ผมเลือก Main@3.1 เพราะต้องการกรอบความซับซ้อนของตัวถอดรหัสที่ค่อนข้างต่ำสำหรับ MP4 แบบไฟล์เดียว ไม่ใช่เพราะ Apple บังคับให้ใช้

ผมหยุดเข้ารหัสพิกเซลที่ไม่จำเป็น

ความละเอียดเป็นหนึ่งในตัวแปรที่ส่งผลมากที่สุด เพดานของผมอยู่ที่ประมาณ 1280×720 สำหรับแนวนอน, 720×1280 สำหรับแนวตั้ง และราว 960×960 สำหรับภาพสี่เหลี่ยมหรือวัสดุที่มีหลายแนว

กฎที่สำคัญกว่าคือ อย่าขยายภาพเพียงเพื่อให้ถึงเพดาน

ถ้าต้นฉบับเป็น 900×600 การขยายเป็น 1280×720 ไม่ได้สร้างรายละเอียดที่หายไปกลับมา มีเพียงตัวอย่างภาพมากขึ้นให้ตัวเข้ารหัสต้องอธิบาย ต้นฉบับ 1920×1080 อาจลดลงมาอยู่ระดับ 720p ได้ ส่วนต้นฉบับ 900×600 ก็อยู่ใกล้ 900×600 ต่อไปได้ เพดานคือค่าสูงสุด ไม่ใช่เป้าหมาย

ฟังดูง่าย แต่การตัดพิกเซลที่ไม่จำเป็นออกอาจช่วยได้มากกว่าการปรับค่าตัวเข้ารหัสที่ซับซ้อนหลายอย่าง

เพดานนี้ไม่ได้เลือกเพียงเพราะเป็นตัวเลขกลม ๆ เฟรม 1920×1080 มี 2,073,600 พิกเซล ส่วน 1280×720 มี 921,600 พิกเซล ดังนั้นการลดจาก 1080p เป็น 720p จะตัดตัวอย่างเชิงพื้นที่ออกประมาณ 55.6% ตั้งแต่ก่อนที่ตัวเข้ารหัสจะเริ่มตัดสินใจเรื่องการบีบอัด

ผมเคยพิจารณาใช้ 540p เป็นค่าทั่วไปด้วย แต่ 960×540 มีเพียง 518,400 พิกเซล น้อยกว่า 1280×720 ถึง 43.75% จึงเหลือตัวอย่างของ 720p เพียง 56.25% สำหรับภาพวาด ตัวอย่างเหล่านี้ใช้เก็บรายละเอียดของเส้นบาง ดวงตา เส้นผม นิ้ว ใบหน้า และขอบที่คม หากยังต้องลดขนาดอีก ผมจะลองเพิ่ม CRF เล็กน้อยก่อน แทนที่จะทิ้งข้อมูลเชิงพื้นที่อีก 43.75% แบบไม่วัดผล การควอนไทซ์แก้ใหม่ได้ในการเข้ารหัสครั้งถัดไป แต่รายละเอียดที่หายไปจากการลดความละเอียดแล้วไม่สามารถเรียกคืนได้

ดังนั้นระดับ 720p คือเพดานทั่วไปแบบระมัดระวังของผม ไม่ใช่คำกล่าวว่า 540p ไม่ดี สำหรับไฟล์หนึ่งไฟล์ รุ่น 540p ที่วัดจริงอาจดีกว่าได้ เพียงแต่ผมไม่ทำให้การตัดข้อมูลเชิงพื้นที่ที่ย้อนกลับไม่ได้เช่นนี้เป็นกฎของทั้งคลังโดยไม่มีข้อมูลรองรับ

ผมหยุดจ่ายแบนด์วิดท์ให้เฟรมที่ต้นฉบับไม่ได้มีจริง

อัตราเฟรมเป็นตัวคูณอีกตัว หากแอนิเมชันมีสถานะภาพที่มีความหมายประมาณ 16 ภาพต่อวินาที การเก็บเป็น 30 หรือ 60 fps ไม่ได้ทำให้การเคลื่อนไหวดีขึ้นโดยอัตโนมัติ ส่วนใหญ่แค่เพิ่มตัวอย่างตามเวลาที่ซ้ำหรือสร้างขึ้นใหม่ ซึ่งยังต้องถูกเข้ารหัสอยู่ดี

นโยบายของผมคือรักษาจังหวะที่มีประโยชน์ของต้นฉบับ และโดยปกติไม่เกิน 30 fps สำหรับสื่อแบบนี้ 12, 15, 16, 18, 20, 24, 25 หรือ 30 fps ล้วนสมเหตุผลได้ หากตรงกับจังหวะของต้นฉบับจริง

ผมยังชอบเอาต์พุตที่มีอัตราเฟรมคงที่และสะอาด VFR ไม่ได้มีปัญหาในตัวเอง แต่ CFR ทำให้การจัดการ ตราประทับเวลา, จำนวนเฟรม, การตรวจระยะเวลา, การเลื่อนตำแหน่ง และการตรวจสอบภายหลังในระบบของผมง่ายกว่า

หลักทั่วไปสำคัญกว่าค่า FPS ค่าใดค่าหนึ่ง: อย่าเสียแบนด์วิดท์ให้ข้อมูลตามเวลาที่ต้นฉบับไม่ได้มี

CRF 28 เป็นค่าที่เหมาะกับงานของผม ไม่ใช่เลขมหัศจรรย์

ผมไม่ต้องการบังคับทุกคลิปไปยังบิตเรตเป้าหมายเดียวกัน ภาพวาดที่แทบไม่ขยับกับฉากที่มีการเคลื่อนไหวซับซ้อนไม่ต้องใช้จำนวนบิตเท่ากันเพื่อให้ดูยอมรับได้

ดังนั้นผมใช้โหมด CRF ของ x264 และสำหรับงานภาพวาดที่ให้ความสำคัญกับแบนด์วิดท์นี้ ผมลงตัวที่ประมาณ -crf 28 FFmpeg อธิบาย CRF ใน libx264 ว่าเป็นการควบคุมอัตราบิตแบบคุณภาพคงที่ ดู เอกสารโคเดกของ FFmpeg

CRF 28 ค่อนข้างแรงโดยตั้งใจ ผมจะไม่คัดลอกค่านี้ไปใช้กับฟิล์มเกรน วิดีโอจากกล้องที่มีนอยส์ ตัวอักษรบนหน้าจอขนาดเล็กมาก หรืองานที่ให้ความสำคัญกับความเที่ยงตรงของภาพมากกว่าแบนด์วิดท์

ผมไม่มีคะแนนการรับรู้สากลที่พิสูจน์ว่า CRF 28 โปร่งใสทางภาพ สิ่งที่พูดได้จากงานของผมแคบกว่านั้น: ไฟล์เล็กลงอย่างมากและยังดูเป็นธรรมชาติสำหรับผมเมื่อเล่นตามปกติ นี่เป็นข้อสังเกตจากการใช้งานจริง ไม่ใช่คำอ้างว่า CRF 28 ไม่มีการสูญเสียที่มองเห็นได้

veryslow แพงสำหรับตัวเข้ารหัส ไม่ได้แปลว่าแพงสำหรับตัวถอดรหัส

พรีเซ็ตของผมคือ -preset veryslow พรีเซ็ตที่ช้ากว่าเปิดโอกาสให้ x264 ค้นหาการทำนายและการเข้ารหัสที่มีประสิทธิภาพกว่า ต้นทุนคือเวลาและ CPU ฝั่งเข้ารหัส

จุดที่ต้องแยกให้ออกคือ งานที่ตัวเข้ารหัสทำกับความซับซ้อนของตัวถอดรหัสไม่ใช่เรื่องเดียวกัน

ผมปล่อยให้ x264 ใช้เวลาค้นหาได้มาก แล้วจำกัดบิตสตรีมที่เสร็จแล้วแยกต่างหาก ข้อตกลงเอาต์พุตแบบอนุรักษ์นิยมของผมคือ:

H.264 โปรไฟล์ Main
Level 3.1
yuv420p 8 บิต
avc1
refs = 4
เฟรม B = 5
B-pyramid = normal
GOP แบบเปิด = ปิดใช้งาน

FFmpeg แยก CRF, พรีเซ็ต, การปรับจูน, ข้อจำกัดของโปรไฟล์, เฟรมอ้างอิง และ B-เฟรม ออกจากกัน ผมก็มองแบบนั้น: ให้ตัวเข้ารหัสค้นหาอย่างหนัก แต่ทำให้ฝั่งการเล่นเป็นเรื่องธรรมดา

GOP และ VBV เป็นราวกันตก ไม่ใช่ตัวควบคุมคุณภาพหลัก

สำหรับคลิปแบบโปรเกรสซีฟสั้นเหล่านี้ ผมใช้ GOP สูงสุดประมาณห้าวินาที: ราว -g 150 ที่ 30 fps, -g 120 ที่ 24 fps หรือ -g 80 ที่ 16 fps

นี่เป็นค่าที่เลือกสำหรับงานของผม ไม่ใช่กฎทั่วไป การสตรีมแบบปรับตัวมีข้อจำกัดต่างกัน ตัวอย่างเช่น แนวทางการสร้าง HLS ของ Apple แนะนำ IDR ทุกสองวินาที ผมไม่ยกกฎ HLS นั้นมาใช้ตรง ๆ กับไฟล์ MP4 แบบคงที่และโปรเกรสซีฟสั้น

ผมยังใช้ค่าประมาณนี้:

-maxrate:v 4M
-bufsize:v 8M

ค่าเหล่านี้เป็นเพดานป้องกันบิตเรตพุ่งผิดปกติ ไม่ได้หมายความว่า “เข้ารหัสทุกอย่างที่ 4 Mbps” CRF ยังเป็นตัวจัดสรรบิตตามปกติ ดังนั้นคลิปที่เข้ารหัสง่ายก็ยังเล็กได้มาก

ผมทำให้คอนเทนเนอร์ MP4 เรียบง่ายด้วย

ผมกำหนด avc1 อย่างชัดเจน เอกสาร HLS ปัจจุบันของ Apple แนะนำรูปแบบตัวอย่างอย่าง avc1 แทน avc3 นี่ไม่ใช่เหตุผลที่ไฟล์เล็กลง แต่สอดคล้องกับเป้าหมายที่จะสร้าง H.264 ใน MP4 แบบทั่วไป

ผมยังใช้ -movflags +faststart ด้วย เอกสารรูปแบบของ FFmpeg ระบุว่า faststart ย้ายดัชนี moov ของ MP4 ไปไว้ต้นไฟล์ ข้อกำหนด การส่งผ่าน HTTP ของ Android สำหรับ MPEG-4 ก็ระบุว่า moov ต้องอยู่ก่อน mdat หลัง ftyp

ftyp
moov
mdat

Faststart ไม่ได้เพิ่มประสิทธิภาพการบีบอัด มันแค่ทำให้การเล่นผ่าน HTTP แบบโปรเกรสซีฟราบรื่นขึ้น

สำหรับเอาต์พุต SDR ทั่วไป ผมใช้ yuv420p แบบ 8 บิต และส่งสัญญาณ BT.709 ด้วยช่วงวิดีโอแบบจำกัด ถ้าคลิปไม่มีเสียง ผมไม่สร้างแทร็กเสียงขึ้นมาเอง สำหรับเนื้อหาภาพวาดนี้ผมยังใช้ -tune animation ด้วย แต่ถือว่าเป็นค่าที่เลือกตามชนิดเนื้อหา ไม่ใช่ส่วนหนึ่งของข้อกำหนดความเข้ากันได้ทั่วไป

โปรไฟล์ FFmpeg หลัก

สำหรับต้นฉบับภาพวาด 30 fps ส่วนหลักของคำสั่งมีหน้าตาประมาณนี้:

ffmpeg -i input \
  -c:v libx264 \
  -preset veryslow \
  -tune animation \
  -crf 28 \
  -profile:v main \
  -level:v 3.1 \
  -pix_fmt yuv420p \
  -tag:v avc1 \
  -refs 4 \
  -bf 5 \
  -g 150 \
  -maxrate:v 4M \
  -bufsize:v 8M \
  -x264-params "open-gop=0:b-pyramid=normal:nal-hrd=none" \
  -color_range tv \
  -color_primaries bt709 \
  -color_trc bt709 \
  -colorspace bt709 \
  -an \
  -movflags +faststart \
  output.mp4

ผมตั้งใจไม่เขียนค่าตายตัวให้ขั้นตอนการปรับขนาดและอัตราเฟรมไว้ตรงนี้ ต้นฉบับ 900×600 ไม่ควรถูกขยายเพียงเพราะเพดานคือ 1280×720 และแอนิเมชันที่มีอัตราเฟรมต่ำตามธรรมชาติก็ไม่ควรถูกบังคับเป็น 30 fps เพียงเพราะตัวอย่างใช้ -g 150

คำสั่งเป็นเพียงการนำแนวทางไปใช้งาน ไม่ใช่ตัวแนวทางเอง

ทำไมไฟล์จึงเล็กลงหลายเท่า

ไม่มีแฟล็กมหัศจรรย์

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

นี่คือเหตุผลที่คำว่า “ไฟล์นี้เป็น H.264” บอกขนาดของมันได้น้อยอย่างน่าประหลาด การเข้ารหัส H.264 สองชุดจากต้นฉบับเดียวกันอาจมีขนาดต่างกันมาก เพราะชื่อโคเดกไม่ได้บอกความละเอียด อัตราเฟรม วิธีควบคุมบิตเรต พรีเซ็ต โครงสร้าง GOP โปรไฟล์ หรือการเตรียมต้นฉบับ

ในกรณีของผม การเปลี่ยนการตัดสินใจรอบโคเดกสำคัญกว่าการเปลี่ยนโคเดก

ผลลัพธ์นี้ไม่ได้พิสูจน์อะไรบ้าง

ผมไม่ได้แยกทดสอบทุกค่าในการทดลองแบบควบคุม จึงไม่สามารถบอกอย่างซื่อสัตย์ได้ว่าความประหยัดกี่เปอร์เซ็นต์มาจาก veryslow, CRF 28, การลดความละเอียด หรือการลดอัตราเฟรมแต่ละอย่าง

ผมก็ไม่อาจอ้างว่าเอาต์พุต CRF 28 ทุกไฟล์ดูไม่ต่างจากต้นฉบับ “ไม่เห็นคุณภาพลดลงอย่างชัดเจน” คือสิ่งที่ผมสังเกตกับงานภาพวาดประเภทนี้ที่ขนาดรับชมทั่วไป ไม่ใช่การรับประกันทางวิทยาศาสตร์สำหรับวิดีโอทุกชนิด

และผมไม่ได้บอกว่า H.264 ไฟล์เดียวเป็นสถาปัตยกรรมที่ถูกต้องสำหรับทุกเว็บไซต์ การมีหลายเวอร์ชัน การสตรีมแบบปรับตัว, HDR, 4K และการเลือกโคเดกตามอุปกรณ์ล้วนเปลี่ยนข้อแลกเปลี่ยน

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

ผลลัพธ์นี้เปลี่ยนแนวทางการปรับให้เหมาะสมของผมอย่างไร

เมื่อก่อนผมมองการปรับวิดีโอให้เล็กลงเป็นปัญหาการตั้งค่าตัวเข้ารหัสเป็นหลัก ตอนนี้ผมมองเป็นปัญหาต้นทุนตลอดอายุของไฟล์

ตัวเข้ารหัสอาจทำงานครั้งเดียว แต่ไบต์อาจวิ่งผ่านเครือข่ายเป็นพันหรือเป็นล้านครั้ง

นั่นเปลี่ยนความหมายของคำว่า “แพง”

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

โคเดกยังคงเรียบง่าย: H.264 ใน MP4 สิ่งที่ปรับให้ดีขึ้นอยู่รอบตัวมัน

สำหรับงานแบบนี้ บทเรียนชัดกว่าค่า FFmpeg ค่าใดค่าหนึ่ง: ปรับต้นทุนที่ต้องจ่ายซ้ำให้ต่ำลง ไม่ใช่ต้นทุนที่จ่ายเพียงครั้งเดียว