Apple codec & Sony codec

1. Vô đề.
Nghỉ hè dẫn vợ con đi chơi Fuji-Q, vùng dưới chân nói Phú Sỹ. Nhân dịp này mang con Handycam HDR-CX470 của Sony đi quay thằng ku chơi để về up lên cho các cụ ở nhà xem.
Vì không phải dân biết chơi Camcorder nên không có ý định review đánh giá con Handycam, chỉ là về xử lý thấy dung lượng file lớn quá, trong chừng mức có thể (về công cụ lẫn thời gian) thử xem qua xem các thánh Sony đang thiết kế bộ codec thế nào.
Vì đang dùng iphoneSE thần thánh, nên cũng tiện tay lướt qua xem Apple bí hiểm có gì khác không.

2. Công cụ sử dụng.
2.1. FFMPEG.
Trong thế giới multimedia processing, thì ffmpeg thì quá nổi tiểng nên không cần giới thiệu chi tiết. Đây là công cụ mã nguồn mở (opensource) mạnh mẽ, hỗ trợ đủ mọi video/audio đến multimedia file format (container).

FFMPEG được bắt đầu từ hồi “em mong ước đến năm 2000″(nhưng chiến tranh không tàn mà còn sống khỏe) bởi Fabrice Bellard (một trong những lập trình viên đẳng cấp nhất thế gian mà đang còn sống cho đến thời điểm hiện tại 07-2018) cho đến 2004. Sau đó được dẫn dắt bởi Michael Niedermayer Từ 2004 đến 2015.

Đến 13/03/2011, sau một thập kỉ phát triên, do không đồng quan điểm, một số thành viên nhóm phát triển (chắc ngộ Clean Code) muốn ưu tiên nâng cao chất lượng code & API. Các thanh niên đó đã tách thành dự án libav, vụ này gây ra bao nhiêu phiền hà cho cộng đồng :-(. Tuy nhiên các sửa đổi của libav vẫn được merger vào ffmpeg, có vẻ công việc này nhàm chán quá nên Michael Niedermayer đã từ chức leader vào 2015[4].

Ffmpeg được release theo package cho từng os riêng. Nếu không có mục đích tham gia phát triển ffmpeg hoặc cần sửa đổi source code thì strong recommend là lên trang chủ down về mà dùng luôn, vì nó đã enable rất nhiều lib phụ thuộc.

2.2. JM tool.
Trái ngược với ffmpeg, thì không nhiều người biết đến công cụ này, chắc chỉ sử dụng trong giới nghiên cứu về video coding, vốn dĩ đấy cũng là mục đích của nó chứ không phải hướng đến lĩnh vực ứng dụng. JM là viết tắt của Join Model (nghe tên hơi cà rốt), đây là h.264 codec (jvt codec),được nhóm JVT (nhóm hợp tác MPEG và VCEG) phát triển và dùng để xây dựng chuẩn nén h.264. Làm gì có codec nào có trước khi public chuẩn nén, nên dĩ nhiên nó dành quán quân về h.264 codec đầu tiên trên thế giới :-).

JM là full codec,  đầy đủ cả decoder lẫn encoder h.264. Sử dụng decoder của JM cho phép phân tích các thông tin chi tiết hơn về h.264.
JM có thể down trên trang chủ của ITU-T ở đây[3], theo README là có thể biên dịch ^^.

3. Thực hành.
3.1. Chuẩn bị video.
Đặt HDR-CX470 ở chế độ 1080P, 60fps, quay video nhiều cảnh động để đảm bảo bộ encoder làm việc tích cực nhất có thể. Sẽ phân tích tầm 1 phút, thời gian đủ dài để bộ encoder ổn định, do đó cần quay hơn 1 phút.

ffmpeg command cắt lấy 1 phút đầu tiên.

ffmpeg -ss 00:00:00 -to 00:01:00 -i 20180718125711.MTS -c copy sony.mts

3.2. Phân tích thông tin video cơ bản.
Cần tham khảo document của ffmpeg để hiểu các thông tin trong khi phân tích.
● Đầu tiên là xem thông tin cơ bản nhất về các stream video/audio, bằng command dưới.

ffprobe -show_streams sony.mts

Từ output log, lấy ra một số giá trị như dưới.

str1
str2

Từ đó có thể rút ra được vài thông tin sau.
– Birate 27 Mbps
– High profile, level 4.2. xem ý nghĩa profile/level ở [7].
– Khi encode, chỉ sử dụng 1 picture để tham chiếu đối với tham chiếu liên ảnh. (Với level 4.2 thì h.264 support tối đa có thể tham chiếu đồng thời 4 ảnh).

● Phân tích chi tiết hơn chút về thông tin từng ảnh.

ffprobe  -show_frames -select_streams v:0 sony.mts

Chỉ tập trung vào 2 thông tin khoanh đỏ.
str3
Thông tin này thay đổi theo từng picture, hình ở trên chỉ là picture đầu tiên.
Sau khi kiểm tra toàn bộ thông tin ở trên với tất cả các picture thì được như dưới.
Về pict_type thì thấy được cấu trúc I,P,P …I,P,P … Có 29 ảnh P giữa các ảnh I, không có ảnh B.
→ GOP có dạng I,P,P …P (30 ảnh). Việc không có ảnh B làm cho độ phức tạp khi thiết kế bộ codec giảm đi đáng kể.
→ Theo thông tin trên chỉ số ảnh dùng tham chiếu (refs=1), do đó chỉ là ảnh sau tham chiếu ảnh trước.

pts (Presentation Time Stamp) để chỉ thời điểm mà picture đó được hiện thị, xem giá trị này với tất cả các picture thì ta thấy giá trị này tăng đều.
→ Các ảnh không bị thay đổi thứ tự trong quá trình encode.  Từ thông tin chỉ có ảnh I,P (không có B) cũng dễ đoán được điều này.

● Và nhiều thông tin cực kì chi tiết
Dùng ffmpeg bằng các option của nó (ex: debug …) có thể phân tích thông tin rất chi tiết đến cả macroblock, nhưng nó ngoài phạm vi bài viết.

3.3. Phân tích QP của picture.
QP là của mỗi picture, sinh ra từ quá trình rate control xem ở [5]. Xem QP của mỗi picture cho ta hình dung qua được độ phức tạp của chiến lược rate control trong bộ codec.

Tìm mãi không thấy command cho phép ffmpeg log giá trị trung bình QP của từng picture nên đành dùng JM. JM chỉ làm việc với element stream, tức là raw h.264 chứ không chơi với container, như mts, mp4 … Do đó đầu tiên vẫn phải nhờ ffmpeg bóc cái h.264 element stream ra.

ffmpeg.exe -i sony.mts -c:v copy sony.264

Đưa vào JM, và thực hiện decode bằng command dưới.

ldecod.exe -d decoder -P InputFile=sony.264

qp
Ôi, than ơi, các thánh chơi QP cố định = 30 cho các picture cmnl. Vậy ở level picture thì giá trị QP chả điều chỉnh gì hết, tất nhiên xuống mức macroblock có thể điều chỉnh quanh giá trị này.

4. IphoneSE của Apple thì sao.
– Birate 23.7 Mbps
– High profile, level 4.2.
– Khi encode, chỉ sử dụng 1 picture để tham chiếu.
– GOP: I,P,P ..P (60 ảnh).
– Không có ảnh B, tức là không có sự thay đổi thứ tự để hiển thị.
– Rate control có vẻ tích cực hơn, QP thay đổi từ 20 ~ 31 . I picture là ảnh quan trọng ảnh hưởng nhiều đến chất lượng,  vì thế nên nên được encoder với QP thấp hơn.
– Cơ bản Apple dùng QP thấp hơn, độ mất mát thông tin ít hơn, nhưng vẫn nén được bitrate thấp hơn Sony? ( thật ra phải cùng 1 data đầu vào mới nói được vậy).

5. Kết luận.
A/e được học video coding, bao nhiêu thứ phức tạp như ảnh B tham chiếu 2 chiều cả quá khứ lẫn tương lai, h.264 cho phép 1 picture có thể đa tham chiếu (multi refer) lên đến 16 picture, cấu trúc GOP của h.264 rất tự do cho phép reorder, tham chiếu thoải mái …
Nhưng thực tế phũ phàng là để đạt được realtime (chắc là thế) các bộ encoder trong các thiết bị có vẻ phải hi sinh nhiều thứ để giảm độ phức tạp. Thậm chí cấu trúc GOP trên của h.264 còn đơn giản hơn cấu trúc của MPEG2-Video có ảnh B.
Mặc dù có vẻ codec trong IphoneSE chỉnh chu hơn HDR-CX470, nhưng để so sánh codec là vấn đề rất phức tạp mà cái quan trọng nhất là phải chung 1 dữ liệu đầu vào, trong khi đã đóng gói trong sản phẩm thì điều đó là không thể. Bài viết cũng chỉ là ngó qua một số thông tin từ kết quả video để phán đoán 1 chút về bộ encoder.

Tuy nhiên, một thiết bị quay video tốt, thì bộ encoder không phải là tất cả, ngoài ra còn ống kính, tính năng room, chống rung … tác động rất lớn đến chất lượng video và trải nghiệm.

Tham khảo.
[1]https://www.ffmpeg.org/
[2]https://en.wikipedia.org/wiki/FFmpeg
[3]https://www.itu.int/rec/T-REC-H.264.2-201602-I/en
[4]https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176489.html
[5]https://vcostudy.com/2018/04/21/rate-control-video-coding
[6]https://www.ffmpeg.org/documentation.html
[7]https://vcostudy.com/2018/04/14/profile-va-level-trong-ma-hoa-video

Profile và level trong mã hóa video

1. Profile và level trong mã hóa video.

Khái niệm về profile và level trong lĩnh vực nén video xuất hiện lần đầu tiên trong chuẩn nén MPEG2-Part2(video)/H.262, đây là chuẩn nén đầu tiên có sự hợp tác giữa ITU-T và ISO/IEC.

ITU-T phát triển và sử dụng các kỹ thuật nén video hướng đến ứng dụng về truyền thông, về đàm thoại, video hội nghị … do đó thường ưu tiên các tính năng như độ trễ thấp (low delay), bền vững và dễ dàng khôi phục với nhiễu, tính phức tạp các công cụ mã hóa thấp (do thường sử dụng trên các thiết bị có hiệu năng xử lý thấp).

Trong khi đó ISO/IEC lại thiên về các ứng dụng về truyền hình, broadcast television, lưu trữ nội dung video số. Thành ra ISO/IEC ưu tiên hơn về các kỹ thuật nén để có thể đạt mức độ nén cao, độ phân giải lớn, không ưu tiên nhiều tài nguyên hệ thống (toàn các thiết bị chuyên dụng trâu chó).

Vì lý do trên để MPEG2-Part.2/H.262 để có thể thỏa mãn yêu cầu của cả 2 tổ chức, thì khái niệm profile & level được đưa ra, nhằm phân chia toàn bộ công cụ mã hóa trong đặc tả kỹ thuật chung thành các tập hợp con phù hợp với từng ứng dụng, đồng thời cũng tránh việc lãng phí không cần thiết, kiểu như dùng búa tạ để đập ruồi.

Dễ hiểu nhất có thể hình dung nôm na giống như có rất nhiều loại dao, dao thái thịt, dao mổ gà, dao bổ củi …Profile sinh ra để phân loại ứng loại dao đó. Trong mỗi loại dao, ví dụ dao thái thịt thì có loại to, loại nhỏ và để sắp xếp kích cỡ thì khái niệm level được sinh ra. Tất nhiên nếu có thể thì tồn tại một số dao đa năng, cái gì cũng chiến, nhưng như thế không hiệu quả và còn gây lãng phí không cần thiết (đi mổ gà thì không cần thiết dùng đến cả loại dao có thể xử lý được trâu bò). 

2. Vấn đề tương thích

Với decoder, để có thể nói được bản thân nó hỗ trợ profile & level nào, thì bắt buộc bộ decoder đó phải hỗ trợ toàn bộ các công cụ mã hóa được giới hạn bởi profile & level đó. Về phía encoder trong giới hạn profile & level thì nó có thể lựa chọn công cụ mã hóa trong đó để thực hiện, không cần thiết (mà cũng hiếm khi) sử dụng hết toàn bộ.

Do đó thông tin về decoder chỉ cần profile & level là đủ biết phạm vi nó hỗ trợ, còn encoder thì cần kèm theo chi tiết nó đã hỗ trợ những công cụ mã hóa nào, mới biết chính xác khả năng của nó.

3. Profile

Profile sẽ phân loại và giới hạn các công cụ mã hóa thành các tập con, tương ứng với từng ứng dụng khác nhau.

Tuy nhiên ở trong đặc tả chuẩn nén thì sẽ miêu tả cụ thể giá trị trong luông dữ liệu (bitstream) thông qua đó sẽ giới hạn các công cụ mã hóa của profile tương ứng. Do đó nếu từ đặc tả mà không có hiểu biết tương đối trước thì rất khó hiểu được với giá trị đó sẽ hạn chế công cụ mã hóa nào nếu không dành thời gian điều tra.

Xem xét kỹ với chuẩn H.264 [1] phiên bản (version) 12.0, ở mục A.2 miêu 15 profile khác nhau. Baseline Profile phù hợp với các ứng dụng cần độ phức tạp không cao, cần đảm bảo độ trễ thấp (không support slide B, nguồn gốc lớn nhất gây ra độ trễ do làm đảo thứ tự hiện thị) kiểu như các ứng dụng đàm thoại, truyền thông video trên mobile.

Sau phiên bản đầu tiên đưa ra sử dụng thì 2 công cụ mã hóa FMO, ASO rất ít được sử dụng, do hiệu quá không cao, mà cách thực thi thì phức tạp, loại bỏ 2 công cụ này đã tạo ra Constrained Baseline Profile.

Extended Profile được xây dựng dựa trên Constrained Baseline Profile bằng cách đưa thêm các công cụ mã hóa dành cho network streaming (truyền video qua mạng?). Main Profile dành cho các ứng dụng giải trí, như truyền hình kỹ thuật số, DVD player.

Hight Profile ưu tiên các công cụ mã hóa để có thể thực hiện nén video mức độ cao nhất, hỗ trợ nhiều không gian màu gồm cả YUV 444 (High 4:4:4 Profile) và mở rộng độ rộng bit lên 10 bit (High 10 Profile), do đó nó hướng đến các ứng dụng video cần độ phân giải cao.

Intra Profile chắc sẽ là profile buồn cười nhất nếu không hiểu về vấn đề ứng dụng, là profile chỉ hỗ trợ ảnh I, tức là không hỗ trợ công cụ đưa đến độ nén nhiều nhất là dự đoán liên khung (inter prediction), các kỹ thuật về bù trừ chuyển động xem như quảng đi hết. Tuy nhiên đây là profile hướng đến các ứng dụng chuyên nghiệp trong xử lý video ví dụ bên video editing, làm phim chuyên nghiệp, khi yêu cầu có thể dễ dàng chỉnh sử từng hình ảnh, mà chẳng cần ưu tiên cao về dung lượng lưu trữ.

4. Level
Level sẽ đưa ra giới hạn về kích thước khung hình, khả năng xử lý, bộ nhớ (memory), tốc độ truyền data phù hợp với ứng dụng đó. Ví dụ với mobile màn hình HD thì không cần thiết phải sử dụng bộ decoder có thể support lên tới FHD, lãng phí không cần thiết.

Có thể tham khảo thêm bảng “Table A-1 – Level limits” ở đặc tả của chuẩn H.264 có miêu tả kỹ càng giới hạn ứng với từng level như là giới hạn số Macroblock xử lý trong 1 giây, giới hạn kích thước khung hình, tốc độ bit tối đa, giới hạn buffer sử dụng tham chiếu …

Tài liệu tham khảo

[1]https://www.itu.int/rec/T-REC-H.264
[2]http://iphome.hhi.de/wiegand/assets/pdfs/h264-AVC-Standard.pdf
[3]http://blog.mediacoderhq.com/h264-profiles-and-levels/
[4]https://www.vocal.com/video/profiles-and-levels-in-h-264-avc/
[5]https://en.wikipedia.org/wiki/MPEG-2
[6]THE H.264 ADVANCED VIDEO COMPRESSION STANDARD Second Edition, Iain E.Richardson

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

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