Đâ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).
Ra đời vào khoảng giữa năm 2004, đến tháng 7-2010, x264 mới chính thức bắt đầu hỗ trợ encode ở chế độ high bit depth. Các revision tiếp theo liên tục cải tiến và tối ưu tính năng này nhưng người dùng vẫn thờ ơ. Lý do: encode được nhưng không xem được! Ngày 10 tháng 5 năm 2011 đánh dấu mốc quan trọng: patch cuối cùng của bộ patch giúp libavcodec có khả năng giải mã high bit depth H.264 đi vào master branch của Libav repo (và được merge vào master branch của FFmpeg repo ngay sau đó) (bộ patch này được đưa ra từ khoảng tháng 3 nhưng phải qua quá trình kiểm tra, sửa đổi khá kỹ mới được chấp nhận). Vậy nhưng ffdshow, một DirectShow wrapper nổi tiếng của libavcodec, mãi vẫn không thấy khả năng hỗ trợ high bit depth H.264. Bởi vì phần mã nguồn đó cần phải sửa để có thể bật tính năng này, trong khi đội ngũ phát triển của ffdshow hiện tại đều mất tăm cả, chỉ còn mỗi clsid lo việc maintain và sửa lỗi thôi (clsid cũng là một trong những người đứng đằng sau K-Lite codec pack và một số công cụ như Codec Tweak Tool, Windows7DSFilterTweaker). Vì thế những ai theo dõi quá trình này thật sự hụt hẫng. Nhóm maintainer của CCCP (Combined Community Codec Pack, không phải Сою́з Сове́тских Социалисти́ческих Респу́блик) thấy cần phải vào cuộc, vì high bit depth thể hiện lợi ích khá rõ rệt đối với nội dung anime. Họ thực hiện vài kỹ thuật hack giúp ffdshow giải mã được 10-bit H.264 (9-bit bị lỗi), mặc dù không biết độ ổn định đến đâu vì hack dù sao vẫn là hack chứ không phải một giải pháp thực sự. Tuy nhiên động thái này là một bước tiến lớn, thúc đẩy việc sử dụng high bit depth H.264 và hứa hẹn một giải pháp hoàn chỉnh sẽ đến trong nay mai (hy vọng là vậy). Đối với những player sử dụng trực tiếp libavcodec thông qua API/ABI như MPlayer, mplayer2... đến nay đã cập nhật để hỗ trợ tương đối ổn định. Riêng bản stable mới nhất của VLC (1.1.x series) vẫn chưa vì còn sử dụng phiên bản libavcodec cũ, tương tự đối với internal decoder của MPC-HC (và nhiều player khác như KMPlayer chẳng hạn). (*Ghi chú: bài viết gốc vốn được viết vào khoảng giữa tháng 7-2011, hiện tại tình hình đã thay đổi rất khác biệt so với lúc đó).
Đến thời điểm hiện tại (tháng 12-2011), trên Windows (XP SP2 về sau), có khá nhiều giải pháp để xem high bit depth H.264. Trên OS X và *nix, MPlayer và mplayer2 bản mới nhất đều đã hỗ trợ tốt high bit depth H.264, VLC 2.0 dự kiến phát hành vào đầu năm 2012 với nhiều cải tiến đáng kể cũng sẽ hỗ trợ (đội ngũ phát triển VLC quyết định bỏ qua 1.2 và tiến thẳng lên 2.0). Tuy nhiên, chưa có dấu hiệu nào cho thấy sẽ sớm có thiết bị phát (standalone player) hỗ trợ 10-bit H.264. Đối với các bộ giải mã tăng tốc dựa trên phần cứng (hardware acceleration) thì có phần khả quan hơn, tuy nhiên thế hệ chip sắp ra mắt của cả AMD, nVidia và Intel nhiều khả năng vẫn chưa có, người tiêu dùng có thể sẽ phải chờ thế hệ tiếp sau nữa (nghĩa là nếu có cũng phải đến năm 2013, giả sử chưa tận thế vào thời điểm đó).
(Bởi vì sẽ chẳng có mấy ai sử dụng 9-bit H.264 nên bây giờ chỉ nói đến 10-bit H.264 hoặc Hi10P theo tên profile).
Nhận xét:
10-bit H.264 sẽ có thể dần trở nên phổ biến trong giới fansub (vì đa số fan xem anime trên máy tính hoặc HTPC), nhưng sẽ không thể thực sự phổ biến nếu các nhà sản xuất thiết bị phần cứng không cập nhật firmware (việc này khó thực hiện) hoặc đưa vào hỗ trợ ở những thế hệ sản phẩm tiếp theo. Nhà sản xuất GPU cũng phải tham gia hỗ trợ khả năng giải mã high bit depth H.264 cho các chip tăng tốc phần cứng của họ.
Mặc dù được thiết kế cho nội dung 10-bit, nhưng nội dung 8-bit vẫn hưởng lợi rất lớn từ nó (vì 10-bit ở đây là độ chính xác trung gian dùng trong codec, chứ không hẳn chỉ là 10-bit output). Hiệu quả của 10-bit depth H.264 rõ rệt và ấn tượng nhất đối với anime, nhất là những anime được sản xuất gần đây. Đặc trưng những anime này là không có grain nhưng gradient được tận dụng triệt để. Khi encode ở chế độ 8-bit, với những cảnh sáng (hoặc sáng phần lớn), crf 19-21 và AQ strength thấp vẫn cho chất lượng rất cao nhưng những cảnh chứa nhiều gradient (cảnh nửa tối chẳng hạn) lại đầy banding. Để giải quyết hiện tượng này, các encoder thường giảm crf xuống khá thấp 15-16 và tăng AQ strength (cùng Psy) lên (hoặc thậm chí tắt MB-Tree đi). Khi dùng 10-bit, vì banding bị hạn chế đáng kể nên có thể dùng crf 18-20 và AQ strength vừa phải mà vẫn đạt chất lượng cao tương đương hoặc hơn. Theo đó dung lượng có thể giảm 20-35% tùy trường hợp so với bản 8-bit. Ngoài ra, do không cần tăng AQ và Psy để giảm banding nên bitrate thậm chí còn tiết kiệm được nhiều hơn. Tuy nhiên, đối với live action hoặc anime chứa nhiều grain nhưng ít gradient (thường là những anime movie sản xuất hồi thế kỷ trước), 10-bit không tỏ rõ sự vượt trội. Thật ra với những trường hợp này, encode chế độ 8-bit với crf 18-20 đã cho chất lượng cao. Lưu ý rằng, 10-bit vẫn gây ra compression artifact khi bitrate không đủ như 8-bit (tất nhiên là ở ngưỡng thấp hơn) nên việc tăng crf lên nữa sẽ có thể sinh artifact (mặc dù trong khoảng 21-23 vẫn khó phát hiện).
Cũng cần nói thêm rằng, đối với những anime hoặc live-action mà grain quá dày (và đặc biệt là digital noise, chúng thường "động" chứ không "tĩnh" như grain), 10-bit chẳng những không có hiệu quả đáng kể mà còn khiến cho việc decode trở nên nặng nề hơn rất nhiều. Những nội dung này thường khó encode và cần sử dụng một lượng bitrate trung bình khá lớn để đảm bảo chất lượng, chưa kể mức peak có thể rất cao nếu người encode không giới hạn nó. Điều này khiến cho việc decode với 8-bit vốn đã nặng, với 10-bit có khi sẽ nặng gần gấp rưỡi (trong khi đó 8-bit H.264 có thể dùng DXVA, CUVID hoặc QuickSync để hỗ trợ tăng tốc decode còn 10-bit H.264 hiện tại phải phụ thuộc hoàn toàn vào CPU).
Về tốc độ encode và decode: Với x264, theo kinh nghiệm cá nhân, tốc độ encode 10-bit còn khoảng 60-70% so với encode 8-bit ở cùng settings (70-80% nếu để đạt cùng chất lượng do dùng crf cao hơn), tuy nhiên vì tôi thường dùng settings tương đương preset slower hoặc veryslow nên kết quả có thể khác đi với những preset nhanh hơn. Về decoding, vì hiện tại chưa có bộ giải mã tăng tốc phần cứng nào hỗ trợ 10-bit H.264 nên việc decode hoàn toàn phụ thuộc vào software decoder (tức là chỉ sử dụng CPU). Trên lý thuyết, để decode 10-bit H.264 software decoder sẽ cần thêm lên đến khoảng 40% năng lực CPU so với 8-bit ở cùng bitrate. Trên thực tế, đa số trường hợp con số đó là thấp hơn nhưng vẫn là cao đối với những máy vốn đã yếu. Đối với thế hệ CPU hiện tại (sản xuất năm 2006 trở lại đây) và tương lai, việc phát nội dung 10-bit 1080p24 với 8 Mbps trở xuống thường không phải là chuyện khó khăn (tất nhiên không tính đến trường hợp có thêm animated softsub). Tuy nhiên, do việc sử dụng 10-bit H.264 với những anime "sạch" sẽ cần ít bitrate hơn nên mức sử dụng CPU thực sự không hẳn là tăng quá cao.
Một số nhầm lẫn thường gặp:
Nhầm lẫn: Encode ở chế độ high bit depth giúp nâng cao chất lượng source.
- Sai. Giống như tất cả encoder khác (bao gồm cả lossy lẫn lossless compression), phần encoder của x264 hoàn toàn không có khả năng nâng cao chất lượng source. (x264 sau này đã bổ sung thêm hệ thống filter, có một số bản patch bao gồm các filter dùng để denoise, deinterlace... nhưng cái đó không tính vào phần encoder).
Nhầm lẫn: Encode ở chế độ high bit depth không gây banding.
- Sai. Nhận định trên chỉ đúng khi thỏa hai điều kiện: source không có banding và bitrate dành cho output đủ lớn. Tất nhiên, như đã nêu, trong trường hợp source không có banding, 10-bit cần ít bitrate hơn 8-bit để cùng đạt hiệu quả như nhau, cho nên ở cùng một mức bitrate, 8-bit có thể gây banding còn 10-bit thì không. Lưu ý rằng: source ở đây tức muốn nói đến uncompressed raw được feed trực tiếp cho x264 (thông qua decoder hoặc frameserver) (nghĩa là không thể so sánh trường hợp encode từ nguồn qua filter với nguồn vanilla mà bảo rằng chúng được encode "cùng nguồn"; ý thứ hai là source có thể có banding, nhưng khi feed cho x264 thì không còn banding do đã deband chẳng hạn, nghĩa là "source không có banding" không thể hiểu là "source trên BD/DVD/phương-tiện-lưu-trữ-vật-lý-nào-đó không có banding").
Nhầm lẫn: Encode ở chế độ high bit depth sẽ khử banding (trong source). Như trên.
Nhầm lẫn: Encode ở chế độ 10-bit depth cho source 8-bit là vô nghĩa vì có thêm 2 bit thì chẳng được gì ngoài việc tốn thêm dung lượng, đặc biệt đa số người tiêu dùng vẫn đang dùng màn hình 6 hoặc 7-bit (per component) nên tăng bit depth lên rồi khi phát lại phải giảm xuống thì chẳng mang lại lợi lộc gì.
- Sai. Như đã được Dark Shikari (một developer của x264) giải thích nhiều lần, 10-bit là độ chính xác trung gian giữa các phép toán khi encoder và decoder hoạt động, việc tăng độ chính xác này từ 8-bit lên 10-bit làm giảm sai số đến 75% (do mỗi bit tăng thêm, sai số giảm đi thêm 50%), do đó source 8-bit vẫn hưởng lợi lớn từ việc này (sai số sinh ra hoặc khuếch đại hiện tượng banding với bitrate trung bình-thấp). Bởi 10-bit cần ít bitrate hơn khá nhiều để đạt chất lượng tương đương 8-bit nên việc encode bằng 10-bit không những không làm tăng dung lượng mà lại giảm đi. Tất nhiên nếu source lẫn output devide đều hỗ trợ 10-bit thì khỏi bàn. Giải thích chi tiết ở góc độ kỹ thuật có thể xem thêm 3 tài liệu pdf do Ateme (một công ty Pháp chuyên cung cấp các giải pháp video nén cho lĩnh vực truyền hình số) phát hành (đặc biệt tài liệu số 2) (3 tài liệu đó còn được lưu trữ trên trang http://x264.nl) hoặc theo cách hiểu "dân dã, gần gũi" hơn: https://gist.github.com/4459997
Có một nhận định mà tôi vẫn chưa xác nhận được tính đúng sai của nó: 10-bit giúp giữ grain và noise tốt hơn 8-bit. Các developer của x264 chỉ nói encode ở chế độ high bit depth giúp giữ dither và gradient tốt hơn 8-bit, nhờ đó làm hạn chế banding, chứ chưa nói đến grain và noise. Thực chất, đa số các thuật toán deband đều bằng cách tạo dither bù vào phần banding. Dither này thường là noise dạng tĩnh, và vì chúng lấp vào phần khuyết tạo nên gradient nên không còn mang đặc tính của noise. Digital noise thì ngược lại, chúng phục vụ mục đích nghệ thuật của nhà làm phim nên thường nổi rõ, rời rạc và "động" (nghĩa là thay đổi vị trí và số lượng qua mỗi khung hình) và dường như bit depth không ảnh hưởng nhiều đến chúng. (Dù sao thì 10-bit chứa nhiều thông tin hơn 8-bit nên vẫn cho chất lượng nhỉnh hơn).
Những vấn đề linh tinh:
- Một số encoder (chẳng hạn như Tenshi@Coalgirls) lấy lý do encode 10-bit bằng x264 vẫn còn nhiều vấn đề nên không/chưa dùng. Điều đó cho thấy hiểu biết của họ về encode cực kém. Trên thực tế, các encode của Tenshi đều dùng cùng một settings như nhau và có vẻ filter-chain cũng y như nhau, để bù lại trình độ encode kém cỏi của mình, encoder này sử dụng một mức bitrate thuộc hàng khủng để bù lại (và sử dụng tư duy logic ngược: dùng crf thấp hơn cho độ phân giải cao hơn! Mà đúng là với crf 13 cho 1080p, có dùng 10-bit hay không cũng không cần thiết. Nhân tiện: Nếu ai muốn dùng crf 12-13 cho độ phân giải 1080p thì cũng xin đừng dùng 10-bit). Vấn đề duy nhất mà 10-bit x264 còn vướng mắc là quá trình chuyển đổi bit (từ 8 sang 10 hoặc dither từ 16 xuống 10) còn chưa chính xác dẫn đến sự lệch màu (chroma) rất nhỏ và khó phát hiện trừ khi so sánh song song. Tuy nhiên có nhiều giải pháp để giải quyết vấn đề đó trong lúc chờ giải pháp chính thức từ x264 devs. (Từ revison 2155, đối với nội dung limited range lỗi này đã được sửa).
- Một số nhóm phân biệt release 10-bit và 8-bit của mình bằng các tag Hi10P và H.264 (ví dụ Doki), trong khi đó thực chất Hi10P là tên gọi tắt một profile của H.264 và do đó nó chính là H.264. Ngoài ra, Hi10P không có nghĩa là 10-bit, nội dung Hi10P cũng có thể là 9-bit (sample). Ngược lại, 10-bit YUV 4:2:2 H.264 chẳng hạn, không gọi là Hi10P (ví dụ sample 10-bit YUV 4:4:4 H.264). Việc đặt tên như thế chứng tỏ ít nhất người làm công tác release của nhóm đó không có khái niệm gì về H.264 (và có thể encoder cũng chẳng khá hơn).
(Ghi chú cho bản thân: Còn một số nhận định sai lầm khác chưa được nêu, phần lược sử có thể gây hiểu lầm do khó theo dõi, cần bố cục lại bài viết và cách trình bày)
10-bit H.264 sẽ có thể dần trở nên phổ biến trong giới fansub (vì đa số fan xem anime trên máy tính hoặc HTPC), nhưng sẽ không thể thực sự phổ biến nếu các nhà sản xuất thiết bị phần cứng không cập nhật firmware (việc này khó thực hiện) hoặc đưa vào hỗ trợ ở những thế hệ sản phẩm tiếp theo. Nhà sản xuất GPU cũng phải tham gia hỗ trợ khả năng giải mã high bit depth H.264 cho các chip tăng tốc phần cứng của họ.
Mặc dù được thiết kế cho nội dung 10-bit, nhưng nội dung 8-bit vẫn hưởng lợi rất lớn từ nó (vì 10-bit ở đây là độ chính xác trung gian dùng trong codec, chứ không hẳn chỉ là 10-bit output). Hiệu quả của 10-bit depth H.264 rõ rệt và ấn tượng nhất đối với anime, nhất là những anime được sản xuất gần đây. Đặc trưng những anime này là không có grain nhưng gradient được tận dụng triệt để. Khi encode ở chế độ 8-bit, với những cảnh sáng (hoặc sáng phần lớn), crf 19-21 và AQ strength thấp vẫn cho chất lượng rất cao nhưng những cảnh chứa nhiều gradient (cảnh nửa tối chẳng hạn) lại đầy banding. Để giải quyết hiện tượng này, các encoder thường giảm crf xuống khá thấp 15-16 và tăng AQ strength (cùng Psy) lên (hoặc thậm chí tắt MB-Tree đi). Khi dùng 10-bit, vì banding bị hạn chế đáng kể nên có thể dùng crf 18-20 và AQ strength vừa phải mà vẫn đạt chất lượng cao tương đương hoặc hơn. Theo đó dung lượng có thể giảm 20-35% tùy trường hợp so với bản 8-bit. Ngoài ra, do không cần tăng AQ và Psy để giảm banding nên bitrate thậm chí còn tiết kiệm được nhiều hơn. Tuy nhiên, đối với live action hoặc anime chứa nhiều grain nhưng ít gradient (thường là những anime movie sản xuất hồi thế kỷ trước), 10-bit không tỏ rõ sự vượt trội. Thật ra với những trường hợp này, encode chế độ 8-bit với crf 18-20 đã cho chất lượng cao. Lưu ý rằng, 10-bit vẫn gây ra compression artifact khi bitrate không đủ như 8-bit (tất nhiên là ở ngưỡng thấp hơn) nên việc tăng crf lên nữa sẽ có thể sinh artifact (mặc dù trong khoảng 21-23 vẫn khó phát hiện).
Cũng cần nói thêm rằng, đối với những anime hoặc live-action mà grain quá dày (và đặc biệt là digital noise, chúng thường "động" chứ không "tĩnh" như grain), 10-bit chẳng những không có hiệu quả đáng kể mà còn khiến cho việc decode trở nên nặng nề hơn rất nhiều. Những nội dung này thường khó encode và cần sử dụng một lượng bitrate trung bình khá lớn để đảm bảo chất lượng, chưa kể mức peak có thể rất cao nếu người encode không giới hạn nó. Điều này khiến cho việc decode với 8-bit vốn đã nặng, với 10-bit có khi sẽ nặng gần gấp rưỡi (trong khi đó 8-bit H.264 có thể dùng DXVA, CUVID hoặc QuickSync để hỗ trợ tăng tốc decode còn 10-bit H.264 hiện tại phải phụ thuộc hoàn toàn vào CPU).
Về tốc độ encode và decode: Với x264, theo kinh nghiệm cá nhân, tốc độ encode 10-bit còn khoảng 60-70% so với encode 8-bit ở cùng settings (70-80% nếu để đạt cùng chất lượng do dùng crf cao hơn), tuy nhiên vì tôi thường dùng settings tương đương preset slower hoặc veryslow nên kết quả có thể khác đi với những preset nhanh hơn. Về decoding, vì hiện tại chưa có bộ giải mã tăng tốc phần cứng nào hỗ trợ 10-bit H.264 nên việc decode hoàn toàn phụ thuộc vào software decoder (tức là chỉ sử dụng CPU). Trên lý thuyết, để decode 10-bit H.264 software decoder sẽ cần thêm lên đến khoảng 40% năng lực CPU so với 8-bit ở cùng bitrate. Trên thực tế, đa số trường hợp con số đó là thấp hơn nhưng vẫn là cao đối với những máy vốn đã yếu. Đối với thế hệ CPU hiện tại (sản xuất năm 2006 trở lại đây) và tương lai, việc phát nội dung 10-bit 1080p24 với 8 Mbps trở xuống thường không phải là chuyện khó khăn (tất nhiên không tính đến trường hợp có thêm animated softsub). Tuy nhiên, do việc sử dụng 10-bit H.264 với những anime "sạch" sẽ cần ít bitrate hơn nên mức sử dụng CPU thực sự không hẳn là tăng quá cao.
Một số nhầm lẫn thường gặp:
Nhầm lẫn: Encode ở chế độ high bit depth giúp nâng cao chất lượng source.
- Sai. Giống như tất cả encoder khác (bao gồm cả lossy lẫn lossless compression), phần encoder của x264 hoàn toàn không có khả năng nâng cao chất lượng source. (x264 sau này đã bổ sung thêm hệ thống filter, có một số bản patch bao gồm các filter dùng để denoise, deinterlace... nhưng cái đó không tính vào phần encoder).
Nhầm lẫn: Encode ở chế độ high bit depth không gây banding.
- Sai. Nhận định trên chỉ đúng khi thỏa hai điều kiện: source không có banding và bitrate dành cho output đủ lớn. Tất nhiên, như đã nêu, trong trường hợp source không có banding, 10-bit cần ít bitrate hơn 8-bit để cùng đạt hiệu quả như nhau, cho nên ở cùng một mức bitrate, 8-bit có thể gây banding còn 10-bit thì không. Lưu ý rằng: source ở đây tức muốn nói đến uncompressed raw được feed trực tiếp cho x264 (thông qua decoder hoặc frameserver) (nghĩa là không thể so sánh trường hợp encode từ nguồn qua filter với nguồn vanilla mà bảo rằng chúng được encode "cùng nguồn"; ý thứ hai là source có thể có banding, nhưng khi feed cho x264 thì không còn banding do đã deband chẳng hạn, nghĩa là "source không có banding" không thể hiểu là "source trên BD/DVD/phương-tiện-lưu-trữ-vật-lý-nào-đó không có banding").
Nhầm lẫn: Encode ở chế độ high bit depth sẽ khử banding (trong source). Như trên.
Nhầm lẫn: Encode ở chế độ 10-bit depth cho source 8-bit là vô nghĩa vì có thêm 2 bit thì chẳng được gì ngoài việc tốn thêm dung lượng, đặc biệt đa số người tiêu dùng vẫn đang dùng màn hình 6 hoặc 7-bit (per component) nên tăng bit depth lên rồi khi phát lại phải giảm xuống thì chẳng mang lại lợi lộc gì.
- Sai. Như đã được Dark Shikari (một developer của x264) giải thích nhiều lần, 10-bit là độ chính xác trung gian giữa các phép toán khi encoder và decoder hoạt động, việc tăng độ chính xác này từ 8-bit lên 10-bit làm giảm sai số đến 75% (do mỗi bit tăng thêm, sai số giảm đi thêm 50%), do đó source 8-bit vẫn hưởng lợi lớn từ việc này (sai số sinh ra hoặc khuếch đại hiện tượng banding với bitrate trung bình-thấp). Bởi 10-bit cần ít bitrate hơn khá nhiều để đạt chất lượng tương đương 8-bit nên việc encode bằng 10-bit không những không làm tăng dung lượng mà lại giảm đi. Tất nhiên nếu source lẫn output devide đều hỗ trợ 10-bit thì khỏi bàn. Giải thích chi tiết ở góc độ kỹ thuật có thể xem thêm 3 tài liệu pdf do Ateme (một công ty Pháp chuyên cung cấp các giải pháp video nén cho lĩnh vực truyền hình số) phát hành (đặc biệt tài liệu số 2) (3 tài liệu đó còn được lưu trữ trên trang http://x264.nl) hoặc theo cách hiểu "dân dã, gần gũi" hơn: https://gist.github.com/4459997
Có một nhận định mà tôi vẫn chưa xác nhận được tính đúng sai của nó: 10-bit giúp giữ grain và noise tốt hơn 8-bit. Các developer của x264 chỉ nói encode ở chế độ high bit depth giúp giữ dither và gradient tốt hơn 8-bit, nhờ đó làm hạn chế banding, chứ chưa nói đến grain và noise. Thực chất, đa số các thuật toán deband đều bằng cách tạo dither bù vào phần banding. Dither này thường là noise dạng tĩnh, và vì chúng lấp vào phần khuyết tạo nên gradient nên không còn mang đặc tính của noise. Digital noise thì ngược lại, chúng phục vụ mục đích nghệ thuật của nhà làm phim nên thường nổi rõ, rời rạc và "động" (nghĩa là thay đổi vị trí và số lượng qua mỗi khung hình) và dường như bit depth không ảnh hưởng nhiều đến chúng. (Dù sao thì 10-bit chứa nhiều thông tin hơn 8-bit nên vẫn cho chất lượng nhỉnh hơn).
Những vấn đề linh tinh:
- Một số encoder (chẳng hạn như Tenshi@Coalgirls) lấy lý do encode 10-bit bằng x264 vẫn còn nhiều vấn đề nên không/chưa dùng. Điều đó cho thấy hiểu biết của họ về encode cực kém. Trên thực tế, các encode của Tenshi đều dùng cùng một settings như nhau và có vẻ filter-chain cũng y như nhau, để bù lại trình độ encode kém cỏi của mình, encoder này sử dụng một mức bitrate thuộc hàng khủng để bù lại (và sử dụng tư duy logic ngược: dùng crf thấp hơn cho độ phân giải cao hơn! Mà đúng là với crf 13 cho 1080p, có dùng 10-bit hay không cũng không cần thiết. Nhân tiện: Nếu ai muốn dùng crf 12-13 cho độ phân giải 1080p thì cũng xin đừng dùng 10-bit). Vấn đề duy nhất mà 10-bit x264 còn vướng mắc là quá trình chuyển đổi bit (từ 8 sang 10 hoặc dither từ 16 xuống 10) còn chưa chính xác dẫn đến sự lệch màu (chroma) rất nhỏ và khó phát hiện trừ khi so sánh song song. Tuy nhiên có nhiều giải pháp để giải quyết vấn đề đó trong lúc chờ giải pháp chính thức từ x264 devs. (Từ revison 2155, đối với nội dung limited range lỗi này đã được sửa).
- Một số nhóm phân biệt release 10-bit và 8-bit của mình bằng các tag Hi10P và H.264 (ví dụ Doki), trong khi đó thực chất Hi10P là tên gọi tắt một profile của H.264 và do đó nó chính là H.264. Ngoài ra, Hi10P không có nghĩa là 10-bit, nội dung Hi10P cũng có thể là 9-bit (sample). Ngược lại, 10-bit YUV 4:2:2 H.264 chẳng hạn, không gọi là Hi10P (ví dụ sample 10-bit YUV 4:4:4 H.264). Việc đặt tên như thế chứng tỏ ít nhất người làm công tác release của nhóm đó không có khái niệm gì về H.264 (và có thể encoder cũng chẳng khá hơn).
(Ghi chú cho bản thân: Còn một số nhận định sai lầm khác chưa được nêu, phần lược sử có thể gây hiểu lầm do khó theo dõi, cần bố cục lại bài viết và cách trình bày)
