Nếu bạn đang tạo video, chuyển đổi tệp có sẵn hoặc chuẩn bị nội dung video cho một website, một trong những quyết định quan trọng nhất là chọn đúng định dạng và thiết lập nén. Tệp nhỏ nhất chưa chắc đã là tệp phù hợp nhất. Video còn phải phát ổn định trên trình duyệt, hoạt động trên điện thoại, giải mã hiệu quả và giữ được chất lượng hình ảnh đủ tốt cho mục đích sử dụng.
Tôi đã tìm hiểu MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, các preset của bộ mã hóa x264, khả năng tương thích với trình duyệt, giải mã phần cứng trên thiết bị di động và các phương pháp đo chất lượng video. Tôi cũng tiến hành thử nghiệm nén thực tế: mã hóa cùng một video nguồn ở nhiều mức CRF, sau đó so sánh bằng mắt và bằng các phép đo khách quan.
Cuối cùng, tôi quyết định ưu tiên MP4 với H.264 khi cần một tệp video duy nhất có thể chạy trên phạm vi trình duyệt, điện thoại và ứng dụng bên ngoài rộng nhất trong thực tế.
Với các video ngắn chủ yếu xem trên điện thoại, nơi tốc độ tải và dung lượng nhỏ quan trọng hơn việc giữ lại từng chi tiết li ti, tôi chọn x264 CRF 30. Trong quá trình thử nghiệm, tôi không nhận thấy khác biệt đáng kể giữa CRF 22 và 30 khi phát bình thường, kể cả trên màn hình máy tính lớn.
Tuy nhiên, quyết định này có một giới hạn rất quan trọng: CRF 30 không phải là mức tôi khuyến nghị cho phim điện ảnh, các sản phẩm video cao cấp hoặc cảnh quay đòi hỏi độ trung thực hình ảnh tối đa. Với những trường hợp đó, mức thận trọng hơn đáng kể, thường quanh CRF 20, có thể là điểm bắt đầu tốt hơn. Tôi chưa tiến hành nghiên cứu tương đương trên phim dài hoặc cảnh quay điện ảnh chất lượng cao, vì vậy cần xem các mức này là điểm khởi đầu để tự thử nghiệm.
Bài viết giải thích cơ sở kỹ thuật của lựa chọn trên, kết quả nén thực tế, những giới hạn của kết quả và cách chọn định dạng cùng thiết lập chất lượng phù hợp cho dự án của bạn.
1. Định dạng chứa video và codec là hai khái niệm khác nhau
Trước khi so sánh MP4 và WebM, cần hiểu rõ sự khác nhau giữa định dạng chứa và codec.
Định dạng chứa đóng gói video, âm thanh, dấu thời gian và siêu dữ liệu trong một tệp. Codec video quyết định cách các khung hình được nén và giải mã.
Chẳng hạn, tệp MP4 có thể chứa video H.264, HEVC hoặc AV1. Dù có cùng phần mở rộng, những cách kết hợp này vẫn có đặc tính nén và yêu cầu thiết bị khác nhau.
| Thành phần | Ví dụ | Mục đích |
|---|---|---|
| Định dạng chứa video | MP4, WebM, MOV, MKV | Đóng gói video, âm thanh và dữ liệu thời gian |
| Codec video | H.264, HEVC, VP9, AV1 | Nén và giải nén các khung hình video |
| Codec âm thanh | AAC, Opus, MP3 | Nén và giải nén âm thanh |
| Bộ mã hóa video | x264, x265, SVT-AV1, libvpx-vp9 | Thực hiện quá trình nén video |
Đổi tên tệp từ .webm thành .mp4 không chuyển đổi codec video. Tương tự, đưa AV1 vào tệp MP4 không khiến video chạy được trên thiết bị không hỗ trợ giải mã AV1.
Khi nói đến khả năng tương thích của video, hãy luôn xét cả tổ hợp: định dạng chứa, codec video, codec âm thanh, profile codec, độ sâu bit và môi trường phát.
2. MP4 và WebM: Định dạng nào phù hợp hơn cho video trên web?
Cả MP4 lẫn WebM đều là định dạng chứa video hiện đại và có giá trị sử dụng thực tế. Không có định dạng nào luôn vượt trội, vì đặc điểm của chúng phụ thuộc vào codec bên trong.
MP4 với H.264: Khả năng tương thích thực tế rộng nhất
MP4 chứa video H.264 và âm thanh AAC có lịch sử tương thích cực kỳ rộng rãi. Tổ hợp này được hỗ trợ bởi các trình duyệt máy tính và di động phổ biến, trình phát video của hệ điều hành cùng nhiều ứng dụng bên thứ ba.
Nó cũng thường được các bộ giải mã video phần cứng trên điện thoại và máy tính hỗ trợ. Giải mã bằng phần cứng có thể giảm tải CPU, giúp phát video hiệu quả hơn và tiết kiệm điện năng so với giải mã bằng phần mềm.
Nhược điểm chính là hiệu quả nén. Các codec mới hơn thường đạt được chất lượng cảm nhận tương đương ở bitrate thấp hơn.
Tuy vậy, H.264 vẫn là lựa chọn rất tốt khi khả năng phát ổn định quan trọng hơn việc tạo ra tệp nhỏ nhất có thể.
WebM với VP9: Nén hiệu quả, phù hợp với trình duyệt
WebM thường chứa video VP8, VP9 hoặc AV1, còn âm thanh thường được mã hóa bằng Opus hoặc Vorbis.
VP9 thường nén hiệu quả hơn H.264 khi so sánh ở chất lượng hình ảnh tương đương. Nó được hỗ trợ rộng rãi trên các trình duyệt hiện nay, bao gồm cả các phiên bản Safari hiện đại.
Sẽ không chính xác nếu khẳng định Safari hoàn toàn không hỗ trợ WebM hay VP9. Khả năng tương thích của trình duyệt đã cải thiện đáng kể theo thời gian.
Hạn chế đáng quan tâm hơn nằm ngoài trình duyệt. Ứng dụng có sẵn của hệ điều hành, thiết bị cũ và phần mềm bên thứ ba có thể xử lý WebM không nhất quán bằng MP4/H.264 thông thường.
Với ứng dụng chỉ chạy trong trình duyệt và có thể kiểm soát khả năng phát, WebM là một phương án đáng cân nhắc. Còn nếu người truy cập có thể tải video về và mở bằng bất kỳ phần mềm nào, MP4/H.264 vẫn dễ dự đoán hơn.
Khác biệt trong thực tế
| Yêu cầu | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| Phát trên trình duyệt hiện đại | Xuất sắc | Rất tốt |
| Hỗ trợ trình duyệt và thiết bị cũ | Nhìn chung rộng hơn | Phụ thuộc vào môi trường nhiều hơn |
| Khả năng mở tệp đã tải xuống | Nhìn chung tốt hơn | Khó đoán hơn giữa các ứng dụng hệ điều hành |
| Hiệu quả nén | Tốt | Thường tốt hơn |
| Giải mã bằng phần cứng | Rất phổ biến | Khá phổ biến nhưng tùy thiết bị |
| Phù hợp nhất | Một tệp tương thích rộng rãi | Phân phối video web hiệu quả cho nhóm thiết bị đã biết |
Vấn đề không phải WebM có tốt hay không. Câu hỏi là liệu lợi ích nén của nó có xứng đáng với những đánh đổi về tương thích trong môi trường cụ thể của bạn hay không.
3. H.264, H.265, VP9 và AV1: Nên chọn codec nào?
Mỗi codec video phổ biến có điểm cân bằng riêng giữa hiệu quả nén, chi phí mã hóa, hỗ trợ phần cứng, tương thích phần mềm và vấn đề cấp phép.
| Codec | Hiệu quả nén | Khả năng tương thích thực tế | Ứng dụng phổ biến |
|---|---|---|---|
| H.264 / AVC | Tốt | Xuất sắc | Video web thông thường, phát trên di động, tải xuống |
| H.265 / HEVC | Thường tốt hơn H.264 | Tùy môi trường | Thiết bị Apple tương thích, môi trường kiểm soát được, video độ phân giải cao |
| VP9 | Thường tốt hơn H.264 | Rất tốt trên trình duyệt hiện đại | Phân phối video qua trình duyệt |
| AV1 | Có tiềm năng nén cực kỳ hiệu quả | Ngày càng tốt nhưng còn hạn chế ở thiết bị cũ | Streaming hiện đại và thiết bị tương thích |
Đây là đánh giá mang tính định tính, không phải bảng xếp hạng bitrate đúng cho mọi trường hợp. Hiệu quả thực tế còn phụ thuộc vào nội dung video, cách triển khai bộ mã hóa, mục tiêu chất lượng, preset mã hóa và phương pháp đo.
H.264: Trưởng thành, giải mã nhanh và được hỗ trợ rộng rãi
H.264 đã được tối ưu hóa rất nhiều và được hỗ trợ bởi một lượng lớn phần cứng lẫn phần mềm. Độ trưởng thành của nó là lợi thế khi video cần phát ổn định mà không đòi hỏi ứng dụng chuyên dụng.
Điểm yếu là các codec mới hơn thường có thể nén video hiệu quả hơn. H.264 còn liên quan đến bằng sáng chế và điều kiện cấp phép, cần được xem xét trong những trường hợp phân phối thương mại phù hợp.
H.265 / HEVC: Nén tốt hơn nhưng phải đánh đổi về tương thích
HEVC có thể giảm bitrate đáng kể so với H.264 ở chất lượng tương tự. Nó đặc biệt hấp dẫn với nội dung độ phân giải cao và những môi trường có thể kiểm soát thiết bị sử dụng.
Nhiều thiết bị Apple hỗ trợ HEVC rất tốt. Tuy nhiên, mức độ hỗ trợ của trình duyệt và ứng dụng ngoài khác nhau tùy hệ điều hành và các thành phần giải mã đã cài đặt. Vấn đề cấp phép cũng cần được cân nhắc.
HEVC có thể là lựa chọn rất tốt, nhưng tôi sẽ không tự động dùng nó làm định dạng tải xuống duy nhất cho một website phục vụ nhiều loại người dùng.
VP9: Một lựa chọn mở và thực dụng
VP9 có hiệu quả nén tốt và tương thích rộng trên trình duyệt hiện đại. Đây là phương án hấp dẫn khi video chỉ được phát trong trình duyệt và môi trường phát có thể dự đoán được.
Điểm bất lợi lớn nhất trong trường hợp của tôi là sự thiếu chắc chắn khi người dùng tải video về hoặc mở bằng ứng dụng hệ điều hành có thể không hỗ trợ WebM hay VP9 một cách nhất quán.
AV1: Nén rất hiệu quả nhưng phần cứng chưa hỗ trợ phổ quát
AV1 là một trong những codec video hiện đại nhiều triển vọng nhất. Nó có thể giảm bitrate đáng kể so với codec cũ, đồng thời khả năng hỗ trợ giải mã phần cứng vẫn tiếp tục mở rộng.
Dù vậy, thiết bị cũ có thể không có bộ giải mã AV1 hoặc phải giải mã bằng phần mềm. Giải mã video độ phân giải cao bằng phần mềm có thể tiêu tốn nhiều tài nguyên CPU và pin hơn, thậm chí gây lỗi phát trên các thiết bị yếu.
Nếu kiểm soát được môi trường phát, AV1 rất đáng được đánh giá nghiêm túc. Nếu một tệp phải hoạt động trên cả thiết bị cũ lẫn mới và các trình phát bên ngoài thông thường, H.264 vẫn là lựa chọn mặc định an toàn hơn.
Hướng dẫn về codec video của MDN cung cấp thông tin hữu ích về các codec này và những yêu cầu đối với trình duyệt.
4. Một định dạng video hay nhiều phiên bản?
Đây là một trong những quyết định quan trọng nhất về kiến trúc phân phối video.
Nếu có thể tạo nhiều phiên bản, website có thể cung cấp AV1 hoặc VP9 cho thiết bị tương thích và dùng H.264 dự phòng cho các môi trường khác. Cách này giúp tăng hiệu quả nén mà vẫn giữ được phạm vi hỗ trợ phát rộng rãi.
Tuy nhiên, duy trì nhiều phiên bản kéo theo độ phức tạp cao hơn ở khâu mã hóa, lưu trữ, bộ nhớ đệm, kiểm tra và chọn phiên bản khi phát.
Nếu bạn cần đúng một tệp video thành phẩm cho mỗi tệp nguồn, chiến lược ưu tiên tương thích thường phù hợp hơn.
Tôi chọn MP4/H.264 vì muốn có một tệp duy nhất chạy được trên các trình duyệt lớn, điện thoại và những quy trình mở video đã tải xuống phổ biến mà không phải phụ thuộc vào định dạng thay thế.
Điều đó không có nghĩa MP4/H.264 nén tốt nhất. Đây là quyết định đề cao khả năng phát dễ dự đoán hơn lợi thế dung lượng tiềm năng của codec mới.
5. Vì sao video dành cho điện thoại có những ưu tiên khác?
Cách nén video cần phản ánh đúng cách người dùng thực sự xem nội dung.
Clip ngắn chủ yếu xem trên điện thoại có yêu cầu khác với phim dài xem trên TV lớn. Ở trường hợp đầu, tải nhanh và ít tốn dữ liệu di động có thể đáng giá hơn việc giữ lại những chi tiết hình ảnh rất tinh tế. Ở trường hợp sau, chất lượng hình ảnh có thể là ưu tiên cao nhất.
Với video ngắn hướng đến thiết bị di động, tệp nhỏ hơn có thể đem lại nhiều lợi ích:
- Cần truyền ít dữ liệu hơn trước khi bắt đầu phát.
- Có thể tải xuống nhanh hơn khi kết nối bị hạn chế.
- Chiếm ít bộ nhớ thiết bị hơn.
- Người dùng tiêu thụ ít dữ liệu di động hơn.
- Việc phát có thể ổn định hơn khi băng thông hạn chế nếu bitrate của video sau mã hóa thấp hơn.
Tuy nhiên, tệp nhỏ hơn không đảm bảo video sẽ không bao giờ phải chờ tải hoặc bị đứng. Biến động đường truyền, bitrate đỉnh, cách máy chủ phản hồi, bộ đệm phát và năng lực giải mã của thiết bị đều có ảnh hưởng.
Khả năng tương thích trên điện thoại phụ thuộc vào nhiều thứ hơn phần mở rộng của tệp: giải mã phần cứng, profile và level codec, độ sâu bit, lấy mẫu phụ màu, độ phân giải, tốc độ khung hình và bitrate đỉnh. Video hiển thị rộng 390 pixel CSS có thể chiếm số pixel vật lý lớn hơn đáng kể trên màn hình điện thoại mật độ điểm ảnh cao. Vì thế, xem một khung hình đã thu nhỏ về chiều rộng 390 pixel không nhất thiết tương đương với xem video gốc trên chính điện thoại đó. Hãy thử trên thiết bị thật và trong điều kiện phát thực tế.
CRF điều khiển chất lượng chứ không đặt giới hạn bitrate tối đa chính xác. Một video phức tạp vẫn có thể xuất hiện những đỉnh bitrate cao dù dung lượng tổng thể tương đối nhỏ. Nếu việc phát ổn định trên kết nối đặc biệt chậm là bắt buộc, hãy cân nhắc giới hạn bitrate hoặc VBV rõ ràng, giới hạn độ phân giải phù hợp và thử nghiệm trong điều kiện mạng thực tế.
Nguyên tắc cốt lõi rất đơn giản: hãy tối ưu cho trải nghiệm xem dự kiến, thay vì chạy theo một mục tiêu chất lượng tối đa trừu tượng.
6. Hiểu về CRF của x264: Giá trị thấp cho chất lượng cao hơn, giá trị cao cho tệp nhỏ hơn
Sau khi chọn H.264, bước tiếp theo là xác định mức độ nén mạnh đến đâu.
Trong x264, Constant Rate Factor, viết tắt là CRF, kiểm soát sự đánh đổi giữa chi tiết hình ảnh giữ lại được và kích thước tệp.
CRF thấp hơn thường cho chất lượng cao hơn và tệp lớn hơn. CRF cao hơn thường tạo tệp nhỏ hơn nhưng mất nhiều chất lượng hơn do nén.
CRF không đặt ra bitrate hay dung lượng đầu ra chính xác. Bộ mã hóa phân bổ bit dựa vào đặc điểm của video nguồn, vì vậy cảnh đơn giản và cảnh có nhiều chi tiết có thể tạo ra những tệp chênh lệch lớn về dung lượng dù cùng CRF.
CRF cũng không quyết định khả năng tương thích cơ bản của bộ giải mã. Hai video H.264 được mã hóa đúng ở CRF 22 và CRF 30 có thể có cùng codec, profile, level, định dạng pixel, kích thước khung hình và tốc độ khung hình.
Khác biệt chủ yếu nằm ở chất lượng nén và đặc điểm bitrate.
Điều quan trọng là không thể so sánh trực tiếp các giá trị CRF giữa những bộ mã hóa codec khác nhau. CRF 30 trong x264 không tương đương về chất lượng hình ảnh với CRF 30 trong bộ mã hóa AV1.
7. Thử nghiệm nén thực tế của tôi: CRF từ 22 đến 32
Tôi muốn xác định có thể nén mạnh đến mức nào trước khi sự khác biệt trở nên đáng kể lúc phát video bình thường.
Tôi lấy một video ngắn đã được nén từ trước và tạo các tệp H.264 để so sánh ở CRF 22, 24, 26, 28, 29, 30, 31 và 32.
Các đặc tính quan trọng của video đều được giữ nguyên, gồm độ phân giải, tốc độ khung hình, thời lượng và số lượng khung hình. Tôi cũng giữ nhất quán thiết lập bộ mã hóa để đánh giá riêng tác động của việc thay đổi CRF.
Kết quả cho thấy dung lượng tệp khác nhau đáng kể.
| CRF | Kích thước xấp xỉ so với tệp gốc | Ý nghĩa |
|---|---|---|
| 22 | 63% | Nén thận trọng hơn, giữ lại nhiều chi tiết hơn |
| 24 | 49% | Tệp nhỏ hơn, chất lượng giảm thêm một chút |
| 26 | 38% | Tiết kiệm thêm dung lượng trong khi vẫn giữ được khá nhiều chi tiết |
| 28 | 30% | Đầu ra gọn nhẹ, mức tương đồng với nguồn vẫn tương đối cao |
| 29 | 26% | Nén mạnh tay hơn |
| 30 | 23% | Mức cân bằng tôi chọn cho nội dung thử nghiệm này |
| 31 | 21% | Tiết kiệm thêm dung lượng nhưng độ trung thực so với nguồn thấp hơn |
| 32 | 19% | Tệp nhỏ nhất trong thử nghiệm và mức suy giảm chất lượng đo được lớn nhất |
Các tỷ lệ phần trăm này chỉ dựa trên nguồn đã thử nghiệm và không được hiểu là mức tiết kiệm điển hình cho mọi video. Tỷ lệ trong bảng được làm tròn độc lập; muốn tính chính xác mức tiết kiệm tương đối, hãy dùng dung lượng tệp gốc của từng kết quả thay vì lấy các con số đã làm tròn chia cho nhau.
Điều bất ngờ nhất là tôi không nhận ra khác biệt hình ảnh đáng kể giữa CRF 22 và CRF 30 khi phát bình thường, ngay cả trên màn hình máy tính lớn.
Tôi còn xem các phiên bản nén mạnh hơn, bao gồm CRF 32, mà không nhận thấy khác biệt đáng kể khi phát clip cụ thể đó theo cách thông thường.
Quan sát này rất quan trọng vì những video ấy chủ yếu dành cho màn hình điện thoại nhỏ hơn. Nếu sự suy giảm chất lượng không gây khó chịu ngay trên màn hình máy tính của tôi, tôi không có nhiều lý do để chấp nhận tệp lớn hơn đáng kể chỉ để giữ những chi tiết không cải thiện trải nghiệm xem mà tôi hướng tới.
Tuy nhiên, đây là quan sát chủ quan trên một loại nội dung nguồn. Nó không chứng minh rằng mọi người dùng, mọi điện thoại hay mọi video đều cho kết quả giống nhau. Màn hình điện thoại mật độ điểm ảnh cao và khoảng cách nhìn gần vẫn có thể để lộ lỗi nén, nhất là ở chi tiết nhỏ hoặc vùng chuyển màu.
8. Các phép đo khách quan xác nhận chất lượng thực sự bị suy giảm
Không nhìn thấy sự khác biệt khi phát không có nghĩa hai video giống hệt nhau về mặt toán học.
Tôi còn so sánh đầu ra mã hóa bằng các phép đo chất lượng hình ảnh khách quan. Khi CRF tăng, độ tương đồng với nguồn giảm.
Trong phép so sánh được giảm kích thước nhất quán nhằm mô phỏng gần đúng màn hình điện thoại mật độ điểm ảnh cao, các giá trị SSIM tiêu biểu là:
| CRF | SSIM xấp xỉ | Kích thước đầu ra so với CRF 28 |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
Xu hướng rất rõ: nén mạnh hơn khiến độ trung thực đo được của video sau mã hóa giảm. Quan sát kỹ còn cho thấy những khác biệt nhỏ ở nét mảnh và bề mặt có họa tiết.
Dù vậy, trải nghiệm xem thông thường trên nguồn thử nghiệm vẫn rất tương đồng. Đó chính là lý do cần kết hợp các phép đo khách quan với đánh giá chủ quan.
SSIM đo độ giống nhau của hình ảnh, không phản ánh toàn bộ trải nghiệm thị giác của con người. Nó không thể xét đầy đủ lỗi nén theo thời gian, độ sắc nét cảm nhận được, cách chuyển động hiển thị hay tầm quan trọng chủ quan của từng chi tiết.
VMAF là một chỉ số hữu ích khác để đánh giá chất lượng theo cảm nhận. Netflix đã phát hành các mô hình VMAF v1 vào tháng Sáu năm 2026, trong đó có mô hình được thiết kế cho điều kiện xem trên điện thoại. Những mô hình này công nhận rõ rằng chất lượng cảm nhận phụ thuộc một phần vào kích thước màn hình và khoảng cách xem tương đối.
Trong nghiên cứu, một mẫu được mã hóa với thiết lập thận trọng có VMAF trung bình được báo cáo khoảng 95, nhưng tôi không có chuỗi kết quả VMAF nhất quán cho toàn bộ các mức CRF nén mạnh. Vì thế, tôi không dùng VMAF để khẳng định CRF 30 hoặc 32 đạt một ngưỡng chất lượng phổ quát nào.
Kết luận thực tế hẹp hơn: video ngắn trong thử nghiệm chịu được mức nén H.264 rất mạnh mà trải nghiệm phát thông thường vẫn gần như không thay đổi.
9. Vì sao tôi chọn CRF 30 cho video ngắn trên điện thoại?
Sau khi so sánh các tệp, tôi quyết định dùng CRF 30 cho những video ngắn tương tự, chủ yếu xem trên thiết bị di động.
Lý do khá đơn giản:
- Đây là những video ngắn, không hướng tới chất lượng hình ảnh điện ảnh.
- Tốc độ tải và dung lượng tải xuống nhỏ là những yếu tố quan trọng.
- Tôi không nhìn ra khác biệt đáng kể giữa CRF 22 và 30 trên màn hình máy tính lớn.
- CRF 30 tạo ra tệp nhỏ hơn rất nhiều so với các thiết lập thận trọng.
- CRF 32 cũng chấp nhận được về mặt hình ảnh trên mẫu thử, nhưng khiến tôi kém tự tin hơn với nội dung phức tạp.
So với CRF 28, CRF 30 giảm khoảng 21% dung lượng đầu ra thử nghiệm. So với CRF 22, mức giảm vượt quá 60%.
Đối với clip ngắn dành cho điện thoại, nơi mục tiêu là hình ảnh dễ xem, tải nhanh và tiêu thụ băng thông hợp lý, tôi thấy đây là sự đánh đổi xứng đáng.
Nhưng điều kiện áp dụng vô cùng quan trọng: tôi chọn 30 dựa vào mục đích xem thực tế và kết quả của nội dung đã thử, chứ không phải vì 30 vốn là giá trị CRF tốt nhất cho điện thoại.
Điện thoại không bắt buộc phải dùng CRF 30. Nó hoàn toàn có thể hiển thị tốt video được mã hóa ở chất lượng cao hơn nhiều. CRF 30 là lựa chọn có chủ đích: chấp nhận giảm một phần độ trung thực so với nguồn để có tệp nhỏ hơn, khi sự đánh đổi đó phù hợp.
Trước khi áp dụng cho một bộ sưu tập gồm nhiều loại nội dung khác hẳn nhau, tôi sẽ thử nhiều clip đại diện, bao gồm chuyển động khó, cảnh tối, vùng chuyển màu, chữ và họa tiết tinh xảo.
10. Vì sao tôi không khuyên dùng CRF 30 cho phim hoặc video chất lượng cao?
Đây là giới hạn quan trọng nhất của thử nghiệm.
Đừng áp dụng máy móc kết quả CRF 30 của tôi cho phim dài, nội dung video cao cấp, cảnh quay chuyên nghiệp hoặc video dự kiến xem trên màn hình lớn.
Những loại nội dung đó có thể chứa vùng chuyển màu tinh tế, hạt phim, cảnh thiếu sáng, chuyển động phức tạp, bề mặt nhiều chi tiết nhỏ và màu sắc được chỉnh sửa kỹ lưỡng. Giữ được những chi tiết ấy có thể quan trọng hơn việc tiết kiệm một lượng băng thông tương đối nhỏ.
Với video 1080p chất lượng cao thông thường, tôi sẽ bắt đầu ở thiết lập x264 thận trọng hơn nhiều, khoảng CRF 20, rồi thử các mức cao và thấp hơn tùy theo nội dung.
Một khoảng khởi đầu hợp lý có thể là CRF 18–22 khi ưu tiên độ trung thực hình ảnh, dù mức thích hợp vẫn có thể nằm ngoài khoảng này tùy độ phân giải, nội dung và yêu cầu.
Đề xuất này phù hợp với các hướng dẫn mã hóa thường được công bố. Ví dụ, tài liệu về chất lượng của HandBrake khuyến nghị khoảng RF 20–24 cho nhiều trường hợp mã hóa x264 1080p.
Tôi chưa thực hiện cùng kiểu nghiên cứu có kiểm soát trên phim dài hoặc cảnh quay điện ảnh cao cấp. Vì vậy, tôi không thể khẳng định CRF 20 luôn tối ưu, CRF 22 lúc nào cũng đủ hoặc một bộ phim cụ thể chắc chắn sẽ trông không đạt ở CRF 30.
Cách làm đúng là chọn những cảnh tiêu biểu, mã hóa ở nhiều mức chất lượng, so sánh trên màn hình dự kiến sử dụng và xác định thời điểm việc nén thêm bắt đầu gây suy giảm hình ảnh có thể nhìn thấy.
Nếu video sẽ được lưu trữ lâu dài, chỉnh sửa tiếp hoặc dùng làm nguồn cho những lần mã hóa khác, hãy giữ riêng bản gốc chất lượng cao với phiên bản phân phối đã nén.
11. Vì sao tôi dùng preset veryslow của x264?
CRF kiểm soát một khía cạnh của chất lượng nén, còn preset x264 quyết định bộ mã hóa dành bao nhiêu công sức để tìm cách mã hóa hiệu quả.
x264 cung cấp các preset từ rất nhanh đến rất chậm. Nhìn chung, preset chậm hơn tốn nhiều thời gian CPU hơn nhưng có thể nén hiệu quả hơn ở chất lượng hình ảnh tương đương.
Tôi so sánh preset medium và veryslow trên cùng nguồn. Với thiết lập chất lượng đã thử, veryslow tạo tệp nhỏ hơn.
Với quy trình mã hóa ngoại tuyến một lần rồi dùng lại thành phẩm nhiều lần, thời gian xử lý thêm có thể hoàn toàn xứng đáng.
Đó là lý do tôi chọn -preset veryslow.
Dù vậy, đây không phải lựa chọn tối ưu trong mọi tình huống. Nếu cần xử lý video ngay lập tức, tài nguyên CPU đắt đỏ hoặc phải giải quyết khối lượng tồn đọng cực lớn, slow hay medium có thể cân bằng tốt hơn về vận hành.
Preset chủ yếu thay đổi độ phức tạp mã hóa và hiệu quả nén. Nó không biến H.264 thành codec khác hay tự khiến tệp đầu ra không tương thích với điện thoại.
12. Với video anime, tôi dùng tùy chọn animation của x264
Khi nguồn là hoạt hình vẽ tay hoặc hình ảnh phong cách anime, tôi sử dụng -tune animation với x264.
Thiết lập này khác với CRF. Một tùy chọn tune thay đổi một số quyết định của bộ mã hóa cho phù hợp với đặc điểm hình ảnh cụ thể. Tune animation hướng đến nội dung có nét vẽ, vùng màu phẳng và chuyển động cách điệu.
Vì vậy, tôi ưu tiên:
- Anime hoặc hoạt hình vẽ tay:
-preset veryslow -tune animation. - Video quay thực tế thông thường: không tự động bật tune animation; hãy bắt đầu với thiết lập mặc định của bộ mã hóa hoặc đánh giá riêng một tune phù hợp.
Cần hiểu đúng tác dụng của tùy chọn này. -tune animation không đảm bảo chất lượng nhìn bằng mắt tốt hơn hay dung lượng nhỏ hơn. Nó thay đổi cách bộ mã hóa hoạt động và kết quả phụ thuộc vào nội dung.
Tôi đã thực hiện một phép so sánh riêng ở cùng CRF với tune animation. Trong phép thử ấy, bật tune khiến tệp lớn hơn khoảng 6% và tăng nhẹ độ tương đồng hình ảnh đo được. Khác biệt nhìn bằng mắt rất nhỏ.
Phép so sánh chính về dung lượng ở CRF 22–32 được thực hiện khi không bật tune animation. Do đó, không thể mặc nhiên cho rằng dung lượng và tỷ lệ nén chính xác trong thử nghiệm ấy sẽ giữ nguyên khi bật -tune animation.
Dù vậy, với video anime, tôi thích dùng tune dành riêng cho hoạt hình và đánh giá dung lượng cùng chất lượng nhận được như một phần của cấu hình mã hóa cho loại nội dung đó.
Cần xem việc tinh chỉnh bộ mã hóa là điều chỉnh theo từng loại nội dung, chứ không phải cách nâng chất lượng hiệu quả trong mọi trường hợp.
13. Thiết lập FFmpeg tôi đề xuất cho video anime ngắn chủ yếu xem trên điện thoại
Với video anime SDR thông thường thực sự cần chuyển mã, lệnh sau thể hiện cấu hình tôi sẽ dùng làm điểm khởi đầu:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4Lệnh này thể hiện rõ các lựa chọn chính:
-c:v libx264sử dụng bộ mã hóa H.264 bằng phần mềm.-preset veryslowưu tiên hiệu quả nén hơn tốc độ mã hóa.-tune animationbật các điều chỉnh dành cho hoạt hình.-crf 30áp dụng mục tiêu chất lượng không đổi ở mức nén mạnh đã chọn cho loại video ngắn này.-profile:v highchọn profile H.264 được nhiều thiết bị hiện đại hỗ trợ.-pix_fmt yuv420pxuất video 8-bit 4:2:0.-map 0:v:0chọn luồng video đầu tiên.-map '0:a:0?'chọn luồng âm thanh đầu tiên nếu có.-c:a aac -b:a 128kmã hóa âm thanh AAC thông thường khi nguồn có âm thanh.-movflags +faststartđưa siêu dữ liệu khởi tạo MP4 về gần đầu tệp.
Đây chỉ là ví dụ, không phải lệnh dùng chung cho mọi đầu vào. Đặc điểm cụ thể của video nguồn có thể đòi hỏi xử lý thêm.
Đặc biệt, không nên tùy tiện chuyển nội dung HDR và 10-bit sang SDR 8-bit nếu không quản lý màu sắc phù hợp: kết quả có thể sai màu, mất chi tiết vùng sáng hoặc xuất hiện các dải màu rõ rệt. Siêu dữ liệu xoay hình, tốc độ khung hình biến đổi, tỷ lệ khung hình theo điểm ảnh, nguồn video quét xen kẽ, cách bố trí âm thanh bất thường và giới hạn độ phân giải không tương thích cũng cần được chú ý.
Nếu tốc độ khung hình và kích thước nguồn đã phù hợp, giữ nguyên chúng thường giúp so sánh dễ hơn và tránh thay đổi tỷ lệ hoặc chuyển động không cần thiết. Đừng ép nguồn có tốc độ khung hình biến đổi về tốc độ cố định trừ khi bắt buộc, vì quá trình chuyển đổi có thể thêm khung hình trùng hoặc bỏ khung hình. Khi đổi kích thước, cần giữ đúng tỷ lệ hiển thị và đảm bảo các chiều tương thích với định dạng pixel 4:2:0 đã chọn. Độ phân giải, tốc độ khung hình hoặc level H.264 quá cao có thể vượt giới hạn giải mã của thiết bị cũ, vì vậy đôi khi muốn tương thích phải chủ động giảm độ phân giải hoặc tốc độ khung hình.
14. Điểm khởi đầu FFmpeg thận trọng hơn cho video chất lượng cao
Nếu độ trung thực hình ảnh quan trọng hơn dung lượng đáng kể, hãy bắt đầu với CRF thấp hơn và đánh giá kết quả.
Ví dụ, lệnh dưới đây là một điểm khởi đầu thử nghiệm hợp lý cho video SDR quay thực tế thông thường:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4Preset slow trong ví dụ là lựa chọn khởi đầu thực dụng cho nhiều mục đích, không phải lời khẳng định nó tốt hơn veryslow. Dùng veryslow cũng hợp lý nếu có thể chấp nhận thời gian mã hóa lâu hơn.
Cấu hình chất lượng cao này là đề xuất cần thử nghiệm, không phải thiết lập đã được chứng minh bằng thử nghiệm video ngắn của tôi.
Với video cao cấp, hãy thử CRF khoảng 18, 20 và 22 rồi chọn theo chất lượng nhìn thấy được. Hạt phim hoặc chuyển động phức tạp có thể cần thiết lập khác; bản gốc lưu trữ lâu dài cũng có thể cần nén nhẹ hơn nhiều.
15. Đừng mã hóa lại video nếu không có lý do
Nén video mất dữ liệu luôn có cái giá của nó. Mã hóa lại một tệp đã nén có thể tạo thêm lỗi hình ảnh, ngay cả khi bản mới trông tương tự bản nguồn.
Trước khi chuyển mã, hãy tự hỏi tệp gốc đã đáp ứng yêu cầu của bạn về tương thích, dung lượng và chất lượng hay chưa.
Nếu tệp đã chứa video H.264 và âm thanh AAC tương thích, đồng thời không cần chỉnh sửa hình ảnh, sao chép trực tiếp các luồng dữ liệu có thể tốt hơn việc mã hóa mất dữ liệu thêm một lần nữa.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4Thao tác này sao chép các luồng dữ liệu đã nén mà không mã hóa lại. Nó có thể thay đổi cách sắp xếp trong định dạng chứa, đồng thời tránh một lần suy giảm chất lượng mới do nén video.
Thông thường, cách này sẽ không giảm dung lượng nhiều như khi mã hóa lại với chất lượng thấp hơn.
Nếu video hiện tại đã nhỏ gọn, tương thích và có chất lượng hình ảnh chấp nhận được, giữ nguyên nó có thể chính là cách tối ưu tốt nhất.
16. Kiểm tra video sau mã hóa, đừng chỉ dựa vào dung lượng tệp
FFmpeg chạy xong với mã thoát thành công không tự động chứng minh video đáp ứng mọi yêu cầu.
Trước tiên, hãy kiểm tra các luồng dữ liệu đầu ra bằng FFprobe:
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4Xác minh codec, định dạng pixel, kích thước khung hình, tốc độ khung hình, thời lượng và các luồng âm thanh.
Tiếp theo, giải mã toàn bộ tệp đầu ra để phát hiện một số dạng hỏng dữ liệu hoặc lỗi giải mã:
ffmpeg -v error -xerror -i output.mp4 -f null -Trong các thử nghiệm nén, hãy so sánh những đầu ra được tạo từ cùng một nguồn. Giữ cố định các biến quan trọng và mỗi lần chỉ thay đổi một thiết lập chính.
Xem video đang chuyển động, kiểm tra chi tiết nhỏ, chú ý vùng chuyển màu, vùng tối, vật thể chuyển động và chữ.
Nếu có thể, hãy dùng những chỉ số khách quan như SSIM, PSNR hoặc VMAF để bổ sung cho việc đánh giá bằng mắt. Đừng coi một điểm số cao riêng lẻ là bằng chứng tất cả lỗi nén đều không thể nhìn thấy.
Cuối cùng, hãy thử video trên các thiết bị đại diện cho người xem và trong quy trình mở tệp đã tải về. Thông tin hỗ trợ của trình duyệt rất hữu ích, nhưng kiểm tra phát thực tế đặc biệt quan trọng nếu ưu tiên hàng đầu là khả năng tương thích.
17. Đảm bảo tệp MP4 được phân phối đúng cách
Thiết lập mã hóa tốt không thể bù đắp cho hệ thống phân phối video trên web kém.
Để phát MP4 theo cách tải dần thông thường, hãy cấu hình đúng header Content-Type: video/mp4 và hỗ trợ yêu cầu HTTP theo phạm vi byte khi cần tải từng phần hoặc tua đến vị trí khác trong video.
Tùy chọn FFmpeg +faststart chuyển thông tin khởi tạo MP4 về gần đầu tệp thông thường. Điều này giúp tải dần để phát, nhưng không cải thiện chất lượng hình ảnh hay giảm bitrate.
Một phần tử video HTML đơn giản có thể phân phối tệp H.264 MP4:
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>Thuộc tính preload chỉ là gợi ý cho trình duyệt chứ không phải giới hạn tải dữ liệu nghiêm ngặt. Chính sách tự phát của trình duyệt cũng có thể yêu cầu video tắt tiếng hoặc không có âm thanh.
Nếu trang có nhiều video, hãy tránh tải tất cả ngay lập tức. Chỉ tải khi cần có thể giảm lượng dữ liệu di động sử dụng và cải thiện cảm giác phản hồi của trang.
Với clip ngắn trên điện thoại, tối ưu thời điểm tải video có thể quan trọng không kém việc giảm dung lượng tệp sau mã hóa.
18. Nên chọn định dạng và chất lượng video nào?
Câu trả lời phụ thuộc vào điều bạn muốn tối ưu.
| Mục tiêu của bạn | Điểm khởi đầu được đề xuất |
|---|---|
| Một video tương thích rộng rãi để xem trên web và tải về | MP4 + H.264 + AAC nếu có âm thanh |
| Phân phối qua trình duyệt hiện đại với nhiều định dạng | AV1 hoặc VP9, có H.264 dự phòng |
| Nén tối đa trên các thiết bị hỗ trợ | Đánh giá AV1 |
| Môi trường phát được kiểm soát và hỗ trợ HEVC | Cân nhắc MP4 + HEVC |
| Clip ngắn chủ yếu xem trên điện thoại, ưu tiên dung lượng | Cân nhắc x264 CRF 30 sau khi thử nghiệm trên các mẫu đại diện |
| Anime hoặc hoạt hình vẽ tay | Đánh giá x264 với -tune animation |
| Phim chất lượng cao hoặc video cao cấp | Bắt đầu ở CRF thận trọng hơn, gần 20, rồi thử nghiệm |
| Mã hóa ngoại tuyến khi thời gian CPU ít quan trọng hơn | Cân nhắc x264 slow hoặc veryslow |
| Xử lý nhanh khi tài nguyên CPU hạn chế | Cân nhắc x264 medium hoặc slow |
| Video hiện có đã đáp ứng yêu cầu | Giữ nguyên hoặc đổi định dạng chứa mà không mã hóa lại |
| Lưu trữ lâu dài hoặc chỉnh sửa về sau | Giữ riêng bản gốc chất lượng cao với các tệp phân phối |
19. Quyết định cuối cùng của tôi và điều thử nghiệm thực sự chứng minh
Sau khi nghiên cứu định dạng video, khả năng tương thích, hiệu quả mã hóa và kết quả nén thực tế, tôi chọn một cấu hình phân phối thực dụng cho video ngắn chủ yếu xem trên điện thoại.
Định dạng tôi chọn là MP4 với H.264, bởi khả năng tương thích dễ dự đoán trên trình duyệt, điện thoại, các tệp tải xuống và ứng dụng bên ngoài quan trọng hơn việc có được tệp nhỏ nhất nhờ codec mới.
Bộ mã hóa tôi chọn là libx264 với preset veryslow, vì video có thể được mã hóa ngoại tuyến và thời gian xử lý tăng thêm vẫn chấp nhận được.
Với video anime, tôi dùng tune animation, đồng thời hiểu rằng tùy chọn này thay đổi hoạt động của bộ mã hóa và không đảm bảo tệp nhỏ hơn hoặc chất lượng hình ảnh luôn tốt hơn.
Với video ngắn dành cho điện thoại, tôi chọn CRF 30 vì kết quả so sánh cho thấy dung lượng giảm đáng kể mà không xuất hiện khác biệt hình ảnh đáng kể khi phát bình thường, kể cả khi đối chiếu trên màn hình máy tính lớn.
Kết quả ấy không có nghĩa CRF 30 là thiết lập lý tưởng cho phim hoặc cảnh quay chất lượng cao. Với nội dung coi trọng chi tiết nhỏ, vùng chuyển màu, hạt phim và độ trung thực tổng thể, tôi sẽ bắt đầu thử quanh CRF 20 hoặc mức thận trọng thích hợp khác. Tôi chưa thực hiện nghiên cứu có kiểm soát tương ứng trên cảnh quay điện ảnh nên không coi con số đó là mức tối ưu đã được chứng minh qua thực nghiệm.
Kết luận quan trọng nhất là không tồn tại một codec, định dạng hay giá trị CRF duy nhất tốt nhất cho mọi video.
Nếu ưu tiên khả năng tương thích tối đa và chỉ muốn có một tệp, MP4/H.264 là lựa chọn mặc định đáng tin cậy. Nếu có thể cung cấp các định dạng dự phòng và muốn nén tốt hơn, hãy tìm hiểu VP9 và AV1. Nếu mã hóa video ngắn chủ yếu xem trên điện thoại, hãy kiểm tra xem CRF cao hơn có tạo ra tệp đủ nhỏ mà vẫn giữ được trải nghiệm mong muốn hay không. Nếu mã hóa phim hoặc cảnh quay cao cấp, hãy dùng thiết lập chất lượng thận trọng hơn và kiểm tra kỹ kết quả.
Hãy xác định yêu cầu phát trước, chọn codec sau và quyết định chất lượng nén cuối cùng. Tiếp đó, thử nghiệm trên đúng những thiết bị và điều kiện thực sự quan trọng. Cách này đáng tin cậy hơn việc chọn một codec hay giá trị CRF chỉ vì nó mới hơn, nén hiệu quả hơn hoặc thường được người khác khuyến nghị.