Vài nguyên tắc khi encode với x264

Để bản encode bằng x264 đạt chất lượng chấp nhận được thực sự không khó, chỉ cần tuân theo vài nguyên tắc hết sức cơ bản. Đáng tiếc vẫn có người không nắm được.

Trước hết cần làm rõ chất lượng "chấp nhận được" là chất lượng người đánh giá thấy... chấp nhận được. Nghĩa là nó mang tính cảm tính. "Chấp nhận được" với người này có thể là phải gần giống y chang source nhưng với người khác lại là tồn tại một số hay thậm chí nhiều artifact nhưng có thể bỏ quá, và khoảng giữa đó.

Lưu ý: Các nguyên tắc nêu dưới đây chưa tính đến chất lượng source. Chúng chỉ đảm bảo chất lượng "chấp nhận được" khi so sánh giữa source (dùng làm input) với output, trong khi output tốt hay xấu còn tùy vào source. Bài viết không bàn đến việc nâng cao chất lượng source cũng như cách đánh giá chất lượng một bản encode.

Các nguyên tắc chung:

• Dùng tune phù hợp với kiểu source cần encode.

• Dùng preset chậm nhất có thể chấp nhận được (tùy vào thời gian encode mong muốn, năng lực xử lý máy tính...) nhưng không cần dùng tới placebo, trừ khi không ngại việc phí thời gian cho thêm một tý chất lượng. Đối với các bản encode mong muốn dùng để lưu trữ, tốt nhất đừng nên dùng preset nhanh hơn medium, trừ khi không ngại tốn dung lượng. (Nếu cảm thấy preset medium vẫn quá chậm thì đừng nên encode. Cũng nên biết rằng nếu quan tâm đến chất lượng thì 5 fps chưa gọi là chậm).

• Encode ở chế độ CRF, trừ khi thật sự cần phải xác định dung lượng. CRF giúp cho các bản encode có chất lượng đồng đều, đồng thời tiết kiệm thời gian (hoặc nếu không cần thời gian tiết kiệm được có thể dùng preset chậm hơn). Chọn một giá trị CRF phù hợp bằng cách encode thử một số nội dung ở CRF khá thấp, ví dụ 15, sau đó tăng dần lên đến mức artifact bắt đầu gây khó chịu (hoặc chất lượng không còn "chấp nhận được") nhằm xác định giá trị CRF mong muốn. Sau đó cứ việc dùng giá trị CRF đó cho những source khác có độ phức tạp tương đương. Khi encode cho số đông, cố gắng chọn giá trị trung hòa giữa chất lượng và dung lượng, sao cho cả hai có thể "chấp nhận được" với đa số.

• Nên nhớ 3 điều sau có mối tương quan chặt chẽ: chất lượng, thời gian encode, dung lượng. Cùng chất lượng, thời gian encode tỷ lệ nghịch với dung lượng. Cùng thời gian encode, chất lượng tỷ lệ thuận với dung lượng. Cùng dung lượng, chất lượng tỷ lệ thuận với thời gian encode.

• Chỉ tùy chỉnh các parameter khi biết rõ chúng sẽ tác động thế nào lên sản phẩm cuối. Nếu không cứ để mặc định. (Nghĩa là đừng nên copypasta random settings thu nhặt được từ các tut/guide). Nên tham khảo cách dùng các parameter này từ các nguồn đáng tin cậy, ví dụ từ --fullhelp, từ trang này, từ các post của các thành viên uy tín của Doom9, Doom10...

• Nếu source là anime nên dùng 10-bit trừ khi thực sự quan tâm đến vấn đề tương thích.

Tại sao "pirate" chủ yếu dùng x264?

Các người làm trong lĩnh vực authoring khi được hỏi sao không sử dụng x264 thường cho rằng như thế không "pro", không chuyên nghiệp. Họ viện nhiều cớ này nọ để thoái thác, như x264 không bằng một số sản phẩm chuyên nghiệp ở bitrate cao, khách hàng sẽ không hài lòng khi biết họ dùng phần mềm miễn phí (tâm lý "tiền nào của nấy"), việc sử dụng x264 không tiết kiệm nhiều chi phí trong khi đòi hỏi nhân viên phải được đào tạo lại (lý do x264 khó sử dụng và không đảm bảo tạo ra stream tương thích với chuẩn), x264 không kèm theo đầy đủ công cụ cho toàn bộ quá trình authoring như các sản phẩm chuyên nghiệp...

Tôi không muốn bàn đến những điều này. Từng sử dụng thử MainConcept tôi thừa nhận x264 tồn tại một vài yếu điểm so với MC ở mức bitrate cao, chẳng hạn vấn đề banding, hoặc cảnh chuyển động nhanh, tuy nhiên vì bitrate cao nên chênh lệch giữa chúng cũng rất khó nhận thấy. Và đúng rằng x264 không hỗ trợ tốt các công đoạn mà authouring đòi hỏi. Cho nên không phải nói rằng họ không có lý. Điều làm tôi khó chịu nhất là họ thường xuyên dùng luận điệu rằng x264 chỉ và sẽ chỉ phổ biến trong giới pirate là vì nó miễn phí nên giúp cho việc pirate phim thuận lợi hơn. Cực kỳ lố bịch! Vì sao? Vì nó áp dụng lên "pirate"! Pirate không quan tâm chuyện miễn phí hay không, nếu muốn họ có thể pirate hoặc thậm chí mua phần mềm chuyên nghiệp nếu thật sự cần thiết*. Điều làm cho x264 trở nên phổ biến đối với người dùng thông thường và "pirate" là vì trên thực tế họ thấy rằng x264 thể hiện chất lượng ưu việt hơn hẳn các H.264 encoder khác ở mức bitrate trung bình (1/3 bitrate thường dùng trên Blu-ray) trở xuống. Tất nhiên, đúng rằng việc này thuận lợi cho việc trao đổi qua mạng và lưu trữ, nhưng cũng không vì thế mà phù hợp với luận điệu họ đưa ra.

---

* Lưu ý: Ở đây không nói đến các phần mềm authouring (như Blu-Code), bởi vì chúng không có bản bẻ khóa (do khâu licensing khắc khe) và có giá rất cao, mà muốn nói đến các phần mềm H.264 encoding thương mại thông thường (đa số dùng MainConcept) ví dụ Rovi TotalCode Studio, Harmonic ProMedia Carbon (tên cũ: Rhozet Carbon Coder), Elecard StreamEye series, Elecard Converter Studio, Ateme EAVC4...

Các chế độ ratecontrol của x264

Mục đích của bài viết là nhắc bản thân nhớ về các ratecontrol mode mà x264 hỗ trợ, không phân tích chi tiết kỹ thuật của từng mode.

Các mode được x264 hỗ trợ: CBR, ABR, CQ, CRF, lossless. (Thật ra lossless là trường hợp đặc biệt của CQ và CRF khi giá trị qp hoặc crf bằng 0 [đối với 8-bit]). Cả CBR và ABR đều có thể có hơn 1 pass (thường không ai dùng quá 3 pass, trong khuôn khổ bài viết sẽ chỉ nói đến 2-pass bởi vì người có đầu óc tỉnh táo sẽ không dùng hơn 2 pass). (Lưu ý: Một số người nhầm lẫn và cho rằng n-pass ABR là VBR; kỳ thật ngoại trừ hard-CBR mode như nêu dưới đây, tất cả mode đều là VBR).

Bàn về 10-bit H.264

Đây là bài viết tôi chép lại từ một post của mình trên VnSharing, có chỉnh sửa bổ sung.

Lược sử:

Từ khi chuẩn H.264 được mở rộng vào khoảng cuối năm 2004 (và đưa vào tài liệu đặc tả vào tháng 3/2005), sample bit depth precision đã được nâng lên đến 10 bits per sample (hiện tại cao nhất là 14-bit sau Bổ sung 2 tháng 11/2007), tuy nhiên tại sao gần đây nó mới được chú ý? Một phần là vì high bit depth không thực sự được các nhà sản xuất nội dung chú ý bởi khá nhiều người tiêu dùng đến nay vẫn đang dùng màn hình TN LCD 6-bit (per component). Tuy nhiên nội dung high bit depth không phải là điểm chính, mà quan trọng hơn là vì thiếu nhu cầu. Nguyên nhân: thứ nhất, về phía nhà sản xuất nội dung, BD quá dư dả dung lượng để có thể chứa bitrate cao nên high bit depth không thật sự tỏ rõ ưu thế, đối với broadcast thì các thiết bị thu [receiver] thế hệ hiện tại cần nâng cấp để giải mã được high bit depth H.264 do đó chưa khả thi về tính kinh tế; thứ hai, về phía người tiêu dùng, không có encoder và decoder miễn phí nào hỗ trợ (các encoder thương mại điển hình như MainConcept H.264/AVC Broadcast đã hỗ trợ từ khá sớm) nên ít ai biết được lợi ích mà high bit depth H.264 có thể mang lại, chưa kể là những nhận định sai lầm khiến cho người ta lờ nó đi. Điều này dẫn đến các nhà sản xuất phần cứng cũng chẳng quan tâm đến chuyện hỗ trợ high bit depth (vì họ chẳng dại gì bỏ tiền thêm vào tính năng người dùng không cần đến làm tăng giá thành không cần thiết). (Lưu ý: Những điều nêu ở đây chỉ áp dụng phía người tiêu dùng, bản thân high bit depth đã được sử dụng trong các khâu sản xuất [production chain] từ thời MPEG-2).