bzip2 & x265

Từ khi biết đến mấy chuẩn nén video gần đây (nói là gần đây nhưng thật ra từ H.264 đến giờ cũng 14 năm có lẻ rồi) như H.264, H.265 đều hỗ trợ nén không mất dữ liệu (lossless compression), bằng cách bỏ quá trình transform và quantization, xem ở mục Perceptual redundancy. Đôi lúc tôi thắc mắc xem thử so sánh sánh nó với mấy cái tool nén thường dùng nén các dữ liệu nói chung như Zip, Rar xem xem tỉ lệ nén nó cỡ bao nhiêu.

Kiểm tra bên nào nén mạnh hơn là một việc làm khá là phi khoa học, vì mục đích và đối tượng của 2 thằng khác hẳn nhau, nên việc so sánh kiểu này rất khập khiễng, không có ý nghĩa gì nhiều, cũng chả nói được lên điều chi nốt. Cơ mà mình thích thì mình thử thôi, thử qua 1 lần để từ giờ về sau đỡ “bứt rứt”.

Tôi chọn bzip2 để nén kiểu zip, lựa chọn kiểu zip là khá là ngẫu nhiên vì tôi không biết nhiều về các tool & thuật toán nén này để lựa chọn, đơn giản zip là thuật toán nén có lẽ được dùng nhiều nhất, còn chọn bzip2 là do dựa vào bài này cho thấy bzip2 nén cao so với các phần mềm nén khác như gzip, lzmash.

Về nén video, tôi chọn H.265 vì thời điểm hiện tại nó là chuẩn nén video cho phép tỉ lệ nén cao nhất. Để nén video theo chuẩn H.265 thì chọn x265, theo những gì tôi biết thì đây có vẻ là open source phổ biến và cung cấp độ nén tốt nhất so với các bộ encoder theo chuẩn H.265. Bản thân x265 được xây dựng dựa trên HM tool (HEVC model), là công cụ được nhóm JCT-VC xây dựng trong quá trình xây dựng đặc tả của H.265/HEVC.
Ngoài ra x265 thừa kế rất nhiều thuật toán nén từ x264 (nhìn cái tên chắc cũng đoán được). Mà x264 là open source tốt nhất thực hiện nén theo chuẩn H.264, nghe đâu facebook, youtube cũng dùng (nhưng tôi không tìm thấy thông tin tham khảo ngoài website chính của x264), do đó tôi nghĩ chắc x265 ngon :-), và tất nhiên cái quan trọng nhất để lựa chọn ở đây là cả nó hỗ trợ mode lossless.

Với bzip2 thì file kiểu gì cũng không thành vấn đề, nhưng với x265 vì bản chất nó nén video, nên file đó phải là số nguyên lần của frame size nào đó 🙂 ví dụ 1920×1080 hay chí ít cũng phải là 16×16, vì thế nếu dùng file bất kì thì phải thêm 1 đoạn dummy data vào cho nó đảm bảo việc alignment đấy, sau này khi cần giải nén file đã nén thì ta cắt bỏ đoán dummy data đấy ra là được.
Tuy nhiên để đơn giản thì tôi chọn luôn 1 file raw video, đây cũng là tạo điều kiện thuận lợi cho x265, coi như bzip2 cửa trên, chấp 1 quả trước.

Đầu tiên, người nông dân phải tạo file raw video, để tạo raw video ta kiếm 1 file video nào đó dạng .mp4 chẳng hạn, cái này rất dễ vì a/e thường hay phim ảnh.

$ffmpeg -i conchocon.mp4 -vframes 100 -c:v rawvideo -pix_fmt yuv420p out.yuv

File đang dùng có định dạng yuv420p, 1440×1080 → 1 frame size = 1440x1080x1.5 = 2332800 (byte), vậy 100 frame thì 233280000 byte.

Nén bằng bzip2 với option cho tỉ lệ nén cao nhất.

$bzip2 –best -z -k out.yuv

Kết quả file nén = 85802555 byte, như vậy tỉ lệ nén là 233280000/85802555 ~ 2.71 lần.

Tiếp đến nén lostless bằng x265 với option “–preset placebo” tức tối ưu về tỉ lệ nén.

$x265.exe –input out.yuv –fps 30 –preset placebo –lossless –input-res 1440×1080 –frames 100 -o lossless.h265

Kết quả file sau khi nén có kích thước 32171670 byte, đạt tỉ lệ nén là 233280000/32171670 ~ 7.25. Dùng option nén này thì thời gian nén cực kì lâu, chỉ với 100 frame tức là khoảng 3 giây video nhưng nén hết hơn 30 phút với cấu hình máy Intel(R) Core(TM) i5-3470 CPU@3.20GHz 3.20GHz, 8.00GB.

Tuy nhiên ngay cả lúc tôi chấp nhận không chọn ưu tiên mức độ nén mà chọn việc tối ưu cho tốc độ ” –preset ultrafast” để rút ngắn thời gian nén, lúc đấy hết tầm 16 giây, thì file sau khi nén cũng đạt được 40435062 byte, tỉ lệ nén là 233280000/40435062 ~ 5.77. Kết quả ngoài dự đoán của tôi.

Để chắc ăn là x265 đã thực hiện nén lostless, ta có thể dùng ffmpeg giải nén (decode) và so sánh nó với file gốc lúc đầu.

$ffmpeg -i lossless.h265 dec.yuv
$diff dec.yuv out.yuv

Do việc nén video phải cân đo đong đếm nhiều thứ để thỏa mãn đặc trưng khi nén video, như về tốc độ, về sử dụng memory …, nên tôi nghĩ rằng cho dù ở top đầu nén video như x265 đi chăng nữa thì khó ăn được bzip2 khi so sánh ở mode lossless. Thành ra kết quả nhận được làm tôi khá bất ngờ. Có vẻ như việc lựa chọn file raw video, đồng thời ít có sự chuyển cảnh đã tạo nhiều điểm lợi thế cho x265, y hệt như đang đá bóng sân nhà của x265 công thêm việc trọng tài thiên vị cho nó nốt. Lúc đầu chỉ định chơi nhởi đến đây, nhưng có vẻ quá thiệt cho bzip2, để công bằng hơn chút, lúc nào rảnh thì thử xem với kiểu file văn bản, text, doc … thì điều gì xẩy ra.

Còn nữa …

Tham khảo
[1] https://hevc.hhi.fraunhofer.de
[2] https://tukaani.org/lzma/benchmarks.html
[3] https://www.itu.int/en/ITU-T/studygroups/2013-2016/16/Pages/video/jctvc.aspx
[4] https://github.com/videolan/x265

Creative Commons License

Tản mạn về lịch sử chuẩn nén video

Chuẩn mã hóa video được rất nhiều công ty, tổ chức phát triển, nó cũng gần tương tự như các sản phẩm thương mại, có những chuẩn nén chết yểu mà cũng có những chuẩn nén rất thành công. Ở thời điểm bài viết này (12/2017) thì chuẩn H.264 phổ biến nhất đã thêm level 6, 6.1, 6.2 cho phép hỗ trợ nén lên đến format 8K(8192×4320), chuẩn H.265 gần như đã phát triển xong và rất nhiều công ty đã hỗ trợ như Sony, Apple, hay open source như x265, nhưng nó cũng gặp trở ngại lớn ngoài sự phổ biến của H.264  (giống như do WindowXP phổ biến quá làm các version mới hơn khó phổ biển) thì phí bản quyền quá cao nên Google (Youtube) vẫn chưa thấy kế hoạch support, và một liên minh non trẻ mới thành lập tuyên bố phát triển một chuẩn video mở có tên là AOM AV1 với độ nén vượt quá H.265 [5] chắc do bất mãn với phí bản quyền H.265 đã đi ngược triết lí của ISO là “kỹ thuật đi trước tiền bạc tính sau”.

Tuy các cũng có những công ty đầu sỏ về xử lý video và có tiền bạc nên có thể tự đứng ra thiết kế chuẩn nén video như Google với VP8, VP9 hay Cisco System với Thor, nhưng nổi trội nhất vẫn là 2 tổ chức ISO/IEC và ITU-T. Tính từ năm 1984, 2 nhóm nghiên cứu về xử lý đa phương tiện của thuộc 2 tổ chức này cụ thể là VCEG thuộc ITU-T chuyên nghiên cứu về xử lý video tập trung vào các ứng dụng truyền thông, đàm thoại do đó thường ưu tiên những thuật toán để giảm độ trễ, birate thấp …, nhóm còn lại là MPEG thuộc ISO/IEC chuyên nghiên cứu về video cho các ứng dụng đa phương tiện, như truyền hình, hay phục vụ các trình xử lý play video nên ưu tiên các thuật toán liên quan đến hiệu năng nén.
Trong quá trình phát triển video codec được lãnh đạo bởi 2 tổ chức này, có những chuẩn video được mỗi tổ chức phát triển riêng, và cũng có chuẩn video được phát triển bởi sự hợp tác của 2 tổ chức này. Lược sử phát triển chuẩn video của 2 tổ chức tổng kết như hình dưới.

history_video
(Hình vẽ trích dẫn trong slide 5 ở tài liệu [9]).

Năm 1984, ITU-T ra mắt chuẩn nén video được coi là chuẩn nén video số đầu tiên với tên gọi H.120, nhưng theo wiki H.120 thì không có bất kì một codec nào dùng chuẩn nén này, tức là về mặt ứng dụng không thằng nào dùng cả, nghe đâu do hiệu năng thấp.

Đến tháng 11 năm 1988, ITU-T tiếp tục giới thiệu H.261, với tài liệu đặc tả chỉ vẻn vẹn 29 trang quá khiêm tốn với hơn 400 trang của những chuẩn nén hiện tại. Tuy thế H.261 đưa ra những khái niệm quan trọng như Macroblock vẫn còn được dùng đến tận 20 năm sau ở H.264, chỉ đến lúc H.265 (năm 2013) mới dẹp tên gọi này mà sử dụng tên gọi mỹ miều hơn CTU (Coding Tree Unit) tuy bản chất vẫn là mở rộng của Macroblock. Đặc biệt hơn, từ H.261 bắt đầu đưa ra kiến trúc của việc hoạt động video coding “Hybrid Coding Concept” như là hoạt động của bộ mã hoá video. Toàn bộ các chuẩn mã hoá về sau MPEG2-Video/H.262, H.263, AVC/H.264, HEVC/H265 và chuẩn đang được xây dựng cho đến thời điểm này (08/2018) VVC/H.26x, đều dựa vào cấu trúc trên.

Cũng cùng năm đó ISO/IEC giới thiệu chuẩn nén video đầu tiên của mình, mang tên MPEG1 Part2 tức là MPEG1 video nằm trong hệ thống MPEG1, nhưng cũng chẳng lấy gì làm thành công cho lắm.

Vào năm 1995, lần đầu tiên 2 tổ chức này cùng hợp tác giới thiệu chuẩn nén chung. ISO/IEC thì gọi là MPEG2 Part2 (MPEG2 video), còn ITU-T thì gọi là H.262 (thuộc dòng chuẩn H.26L). Do mục đích phát triển chuẩn nén video của 2 tổ chức khác nhau nên cũng là lần đầu tiên xuất hiện các khái niệm profile & level trong chuẩn video, nhằm giới hạn thành các tập con trong chuẩn nén phù hợp với từng ứng dụng khác nhau.

Sau đó ITU-T tiếp tục giới thiệu thêm một chuẩn video riêng của mình là H.263 vào 1995, đồng thời ISO/IEC cũng chẳng kém cạnh đã đưa ra MPEG4 Part2, nhưng có vẻ cả 2 thằng đều không được thành công nếu dựa vào mức độ phổ biến.

Sau khi định đánh quả lẻ không thành, 2 tổ chức tiếp tục bắt tay hợp tác để rồi vào năm 2003 đưa ra MPEG-4 Part10/H.264. Chuẩn nén này được thừa kế rất nhiều những thuật toán ưu việt của những chuẩn nén trước đó, đồng thời cũng có sự thay đổi rất mạnh mẽ về cấu trúc bit stream, đưa ra những khái niệm như NAL, và có vẻ xa rời các khái niệm liên quan đến hình ảnh (picture header, sequence header …) do đó làm cho những ai đã quen với MPEG-2 thì khi tiếp xúc với H.264 rất khó nắm bắt.
H.264 chuẩn nén được xem là thành công nhất cho đến thời điểm hiện tại, theo thống kê vào năm 2010 thì mức độ sử dụng H.264 trên internet hơn 60%. Mặc dù lúc đầu đối tượng của H.264 là video format FHD (1920×1080) tuy nhiên đến thời điểm hiện tại (2017) phiên bản mới nhất của H.264 cho phép hỗ trợ đến tận 8K(8192×4320) .

Thành công nối tiếp thành công, ISO/IEC và ITU-T tiếp tục thành lập nhóm JVCT để thiết kế và đưa ra MPEG H Part2/H.265 vào năm 2013, với đối tượng là video 4K và yêu cầu độ nén gấp đôi H.264 với cho phép mức độ phức tạp gấp 10 lần (đo ước lượng bằng thời gian mã hoá trên cũng một hệ thống). Đến thời điểm hiện nay 2017 thì chuẩn nén này về cơ bản đã hoàn thành tuy vẫn đang được tiếp tục bổ sung chỉnh sửa nên JVCT vẫn tiếp hành họp hằng năm (1 năm 4 lần).

Với tần suất 10 năm cần có một chuẩn nén mới, do độ phân giải màn hình tăng lên gấp 4 nhưng tốc độ internet chỉ tăng lên gấp đôi 🙂 do đó cần một chuẩn nén mới để tăng hiệu năng nén gấp đôi chuẩn nén hiện tại. Trong bối cảnh đó JEVT là nhóm chung của 2 tổ chức được thành lập với kế hoạch năm 2020 đưa ra chuẩn nén mới ( chắc ITU-T gọi là H.266?) với yêu cầu độ nén gấp đôi H.265, đối tượng là video format 8K, có thêm các thuật toán phù hợp mới các ứng dụng video mới nổi như video 360 độ, VR/AR …

Trong khi chưa biết tương lai nào cho H.265 vì phí bản quyền H.265 rất cao, có những trường hợp gấp trên dưới 10 lần H.264, do đó nhưng công ty sử dụng nhiều chuẩn nén video như google (youtube) rất lo sợ một khi H.265 trở nên phổ biến. Chắc cũng vì nguyên nhân đó mà liên minh chuẩn nén video mở được thành lập, theo kế hoạch là trong năm nay (2017) sẽ hoàn thành đặc tả kĩ thuật đồng thời có cả codec open đi kèm, với sự tham gia cả những công ty về phần cứng như AMD, ARM hay những công ty về dịch vụ như Amazon, Netflix … thì liên minh này rất hi vọng AOM AV1, tên của chuẩn nén mở này, sớm cất cánh và hạ gục H.265.

Tương lai nào chờ đợi H.265? Liệu ISO/IEC & ITU-T có tiếp tục thắng thế so với các chuẩn mở.

Update 14/04/2018: AV1 có vẻ đang hung hãn lên dần (đã công bố đặc tả pdf version, tuy vẫn là bản tạm thời), khoe rất nhiều ở NAB.

Update 01/08/2018: Chuẩn nén sau HEVC của ISO/IEC & ITU-T đã chính thức mang tên VVC.

Tài liệu tham khảo
[1]https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
[2]https://en.wikipedia.org/wiki/Video_coding_format
[3]https://en.wikipedia.org/wiki/H.261
[4]https://techcrunch.com/2010/05/01/h-264-66-percent-web-video/
[5]http://aomedia.org
[6]H.120: https://www.itu.int/rec/T-REC-H.120-199303-I/en
[7]H.262: http://www.itu.int/rec/T-REC-H.262-201202-I/en
[8]https://aomedia.org/news/aomedia-at-nab/
[9]https://www.slideshare.net/MathiasWien/trends-and-recent-developments-in-video-coding-standardization

Creative Commons License

Phân biệt “video codec” và “video coding format”

Khi bàn về việc nén video thường có sự nhầm lẫn giữa video codec và video coding format (chuẩn nén video). Sự nhầm lẫn này thường thấy trong bộ phận kỹ sư liên quan đến phát triển sản phẩm mã hóa video, chứ không phải trong lĩnh vực nghiên cứu (đã đi nghiên cứu thì chắc chả thằng nào nhầm) . Hầu hết đều mặc định video codec chính là video coding format, do đó nhiều lúc sinh ra những nhầm lẫn về mặt kiến thức cơ bản, không đáng để xẩy ra do đó cũng nên phân biệt rõ ràng.

1. Video coding format.
“Video coding format” hay còn gọi là “video compression format” tạm dịch tiếng Việt là chuẩn mã hoá video ( riêng chữ video không biết dịch tiếng Việt là gì luôn :D), là tài liệu miêu tả cách biểu diễn dữ liệu dùng để mã hoá video. Nói một cách dễ hiểu hơn là dựa vào tài liệu đặc tả thì có thể giải mã một tệp (hoặc 1 luồng dữ liệu) video để tạo ra một chuỗi hình ảnh, sẽ phục vụ cho việc hiển thị.

Một chú ý quan trọng là dựa vào tài liệu đặc tả video chỉ chắc chắn có thể thực hiện được quá trình giải mã, còn chiều thực hiện mã hoá thành dữ liệu nén video, ngoài đặc tả chuẩn video thì một số quá trình cho phép mỗi cách thực hiện cho thể tự tối ưu bằng những thuật toán khác nhau, ví dụ như quá trình xử lý dự đoán chuyển động giữa các hình ảnh, quá trình chọn mức độ nén để đảm bảo đầu ra được tối ưu nhất (đạt được chất lượng tối ưu với ràng buộc của bitrate)…

Ví dụ về chuẩn H.264 và H.265 là các tài liệu đặc tả lần lượt theo đường dẫn dưới.
H.264(MPEG4-Part10): https://www.itu.int/rec/T-REC-H.264-201610-P/en
H.265(MPEG H Part2): https://www.itu.int/rec/T-REC-H.265-201504-I/en

2. Video codec.
Chữ CODEC là kết hợp viết tắt của 2 chữ enCOder và DEcoder, từ đó có thể hiểu đơn giản video codec bao gồm video encoder và video decoder (trên thực tế thì chỉ cần Decoder hoặc Encoder đã có thể gọi là codec), tức là một chương trình  thực hiện quá trình mã hóa và giải mã hóa, việc thực hiện như thế nào thì phụ thuộc vào chương trình đó thực hiện dựa trên video coding format nào.

Nói cách khác thì video codec là cách thức thực thi mã hoá hoặc giải mã video theo tài liệu đặc tả, ví dụ với đặc tả H.264 thì có rất nhiều video codec như x264 được phát triển với Videolan hay openh264 được phát triển bởi cisco, hay kiểu tên gọi codec của Sony trong các thiết bị sản xuất bởi Sony, codec của Apple trong Iphone, Ipad …

Do đặc tả chuẩn video ràng buộc chi tiết về quá trình giải mã, do đó phần giải mã trong video codec cho dù được thực hiện bởi chương trình nào thì cũng phải cho ra một kết quả giải mã giống nhau, nhưng quá trình mã hoá, ngoài phần bắt buộc tuân theo chuẩn mã hoá thì còn có phần cho phép mỗi chương trình tự tối ưu theo nhu cầu riêng để đạt được bộ mã hoá (encoder) tối ưu, thường là đạt chất lượng tốt theo hạn chế của hiệu năng hệ thống và yêu cầu bitrate.

Ví dụ về video codec theo chuẩn H.264 & H265..
x264: http://www.videolan.org/developers/x264.html
x265: http://x265.org/

3.Tài liệu tham khảo.
[1]https://en.wikipedia.org/wiki/Video_coding_format
[2]https://en.wikipedia.org/wiki/Video_codec
[3]THE H.264 ADVANCED VIDEO COMPRESSION STANDARD – Iain E. Richardson

 
Creative Commons License