Ẩn dấu dữ liệu bằng motion vector

1. Information Hiding, Digital Watermarking and Steganography
Đây là các khái niệm nói việc việc mã hóa, nhúng thông tin vào trong đối tượng (có thể là picture, audio, video …), có liên quan đến vấn đề bảo mật thông tin, hoặc bảo vệ bản quyền.
Đây là vấn đề rộng, chỉ đưa ra keyword chứ không dám lạm bàn, kẻo thành nói ngu, mà nói ngu thì cực kì nguy hiểm cho cả bản thân với ai đó chưa biết mà không may đọc phải.

2. Ẩn dấu dữ liệu bằng motion vector
Motion compensation (bù chuyển động) là thuộc loại công cụ nén quan trọng và mang về tỉ lệ nén rất cao trong việc nén video.
Với các ảnh liên tiếp nhau, về cơ bản là đối tượng trong ảnh phần lớn giống nhau (trừ tình huống chuyển cảnh), chỉ khác nhau do vị trí của nó bị xê dịch. Kỹ thuật bù chuyển động đưa ra nhằm tận dụng đặc trưng này của luồng video, thay vì lưu lại toàn bộ ảnh thì nó chỉ lưu lại phần chuyển động của bằng các vector, gọi là motion vector. Dĩ nhiên là cả điểm khác nhau sau khi đã bù chuyển động (DPCM), nhưng sự khác nhau này đã giảm đi đáng kể sau khi có tính đến bù chuyển động. Trong việc nén video, thì quá trình tìm kiếm vùng giống nhau giữa các ảnh sẽ quyết định motion vector tối ưu.
mv1

Vấn đề muốn đề cập ở đây, là ta có thể tận dụng chính bộ vector này để đồng thời mã hóa dữ liệu mong muốn trong quá trình nén video. Đầu tiên bộ encoder sẽ tìm motion vector tối ưu, trước khi đưa motion vector đó vào thực hiện nén video, thì chỉnh sửa nó một cách có chủ ý nhằm nhúng dữ liệu vào đấy, tất nhiên giá trị motion vector không còn tối ưu nữa, nên ảnh hưởng ít nhiều đến chất lượng video. Việc chỉnh sửa thế nào tuân theo 1 qui tắc nào đó mà chỉ có encoder, và tiết lộ cho bên decoder mà được phép nhận chia sẻ dữ liệu đó biết, bên phía decoder khi giải mã video đó thì dựa vào motion vector sẽ lấy được thông tin được ẩn dấu trong đó.
Để dễ hình dung có thể xem hình vẽ dưới.
hidedata1

3. Thử chơi với H.264
Áp dụng cho H.264, bằng cách chọn một codec có sẵn nào đó, sửa motion vector theo 1 qui luật nhất định.
Để dễ dàng thực hiện thì sử dụng codec hàn lâm nhất jvt codec[2], cái này là codec do JVT sử dụng trong quá trình xây dựng chuẩn nén H.264.
Nếu xem xét motion vector nhỏ hơn 1 giá trị ngưỡng nào đấy (threshold value) thì sẽ sửa nó về giá trị nhỏ hơn hoặc bằng sqrt(2), tức là motion vector nhỏ hơn giá trị ngưỡng luôn có giá trị trong tập (0,0); (0,1) ; (1,0) ; (0,-1);(1,1)… Bằng cách qui định dữ liệu ứng với với các giá trị này thì ta có thể mã hóa 1 chuỗi bit nhị phân bằng motion vector (tham khảo file insert_data.c trong source code[3]).
Sau khi chỉnh sửa jvt codec[2], bộ codec mới của H.264 ở [3] đã hỗ trợ việc sử dụng motion vector để nhúng dữ liệu vào ở bộ encoder, còn bộ decoder thì có thể giải mã nó và lưu thành 1 file có kết quả giống như dữ liệu đã nhúng.

h264_1
Thông tin và cách sử dụng có thể tham khảo readme.txt của source code[3], khi thay đổi data video đầu vào như frame size, số frame thực hiện mã hóa … thì cần sửa lại file cấu hình (config) của bộ encoder cho phù hợp.

Hạn chế: làm lâu rồi nên không nhớ, nhưng hình như khi nhúng data bằng cả motion vector trước và sau (backward & forward) thì có bug, ai đó fix hộ đi 😀 .

Tài liệu tham khảo
[1] https://en.wikipedia.org/wiki/Digital_watermarking
[2] http://iphome.hhi.de/suehring/tml
[3] https://github.com/truongpt/jm19.0_watermarking

 

Rate control in video coding

1. Rate control là gì.
Cụm từ này không biết nên dịch sang tiếng việt thế nào, nên thôi tạm để nguyên từ gốc của nó.
Rate control là một trong những phần quan trọng nhất trong bộ encoder để quyết định video sau khi nén có đạt được bitrate đúng yêu cầu hay không. Ngoài ra nó còn có ảnh hưởng rất lớn đến việc giữ cho chất lượng của các hình ảnh (picture) trong video sau khi nén, có được sự ổn định, chất lượng đồng đều nhau.
Đây thuộc phần tốn rất nhiều mồ hôi và cả “chửi tục” của các kỹ sư trong quá trình phát triển video encoder. Do việc có được một xử lý rate control tốt cần rất nhiều thời gian, cũng như cần người giàu kinh nghiệm để có thể hiệu chỉnh được các hệ số hợp lý, và rất nhiều trường hợp mong muốn ra con bò thì nó ra con dê.

Các bộ encoder gần như được tự do sử dụng các phương pháp, các chiến lược (strategy) cho rate control, vì vấn đề này xem như nằm ngoài phạm vi phủ sóng của đặc tả chuẩn nén.

2. Vai trò của rate control.
Một bộ encoder khi thực hiện nén video luôn xác định mức độ cần nén là bao nhiêu, việc này được bởi yêu cầu bitrate đầu vào. Dựa trên thông tin đó, rate control sẽ quyết định mức độ nén của video, mà mang tính chất quyết định nhất là giá trị QP (Quantilization Parameter: Thông số lượng tử), con số này càng cao thì độ nén video càng lớn, và tất nhiên được cái lọ thì phải bỏ cái chai, độ mất mát thông tin cũng lớn theo tức là chất lượng video sẽ kém đi.

Ngoài giá trị độ lớn thì mỗi mảng ứng dụng lại có một yêu cầu riêng về thuộc tính đối với bitrate, ví dụ broadcast video thì thường yêu cầu bitrate cố định (constant bitrate, dĩ nhiên cũng chỉ là tương đối thôi), với IP television thì lại cho phép bitrate có thể thay đổi trong một phạm vi giới hạn.

Quay lại về việc thực hiện nén video, một điều hiển nhiên là các ảnh trong một luồng video luôn có mức độ nén không giống nhau, ảnh I sẽ có size (dung lượng) lớn hơn ảnh P,B, do 2 ảnh này được phép sử dụng tham chiếu đến ảnh khác, nên độ nén tăng lên đáng kể. Trong khi đó frame rate (số hình ảnh được hiển thị trong 1 giây) thường là cố định, do đó nếu không có sự điều chỉnh hợp lý thì bitrate sẽ thay đổi không phù hợp với ứng dụng tương ứng. Đây là nhiệm vụ cơ bản của rate control.

Về vấn đề ổn định chất lượng, nếu xem video lúc thì hình ảnh rõ nét, lúc thì xấu như ma lem thì thà xấu toàn bộ chắc xem còn dễ chịu hơn. Rate control cũng là nhân tố quan trọng trong vấn đề này. Do rate control liên tục điều chỉnh độ nén của từng ảnh liên tiếp để thỏa mãn yêu cầu bitrate, nhưng nó cũng phải ràng buộc để các ảnh liên tiếp nhau chất lượng không quá khác nhau nhiều quá, tránh tạo ra video dek thằng nào muốn xem. Một video tốt cần có chất lượng đồng đều nếu có thay đổi cũng nhẹ nhàng như chứng khoán chứ không được đột biến như đồ thị bitcoin. Dĩ nhiên đến làm được điều này thì không chỉ mỗi rate control mà còn các xử lý khác, nhưng có thể nói rate control là con bài át chủ.

3. Rate control làm việc như thế nào.
Trên thực tế cũng như lý thuyết đây là một phạm vi rất rộng, vì rate control thực ra là một mô hình dự đoán trước để quyết định tham số nén quan trọng là QP, do đó với mỗi chuẩn nén khác nhau lại cần một phương pháp khác nhau. Mỗi khi một chuẩn nén ra đời lại kéo theo một mớ chuyên gia mò ra chiến lược rate control phù hợp, âu cũng là tạo công ăn việc làm cho xã hội.

Trong ứng dụng thực tế, phải chấp nhận điểm cân bằng giữa chất lượng rate control đạt được và độ phức tạp của nó. Thậm chí có nhiều bộ encoder còn sử dụng luôn giá trị cố định QP cho từng loại picture.

Về cơ bản có thể hiểu một cách đơn giản thì rate control diễn ra như hình vẽ dưới. (Chú ý các khái niệm GOP, I,P,B picture đang hiểu theo định nghĩa của MPEG2-Video. Đây là khái niệm cơ bản cần nắm vững nên sẽ có bài ôn lại về cái mớ lộn xộn này sau).

rate1

GOP là 1 nhóm picture có tính lặp đi lặp lại trong một chuỗi video, do đó rate control thường đi theo đơn vị là GOP.

●Bước 1: Ở lớp GOP, từ bitrate và frame rate thì dễ dàng tính được cần nén 1 GOP đạt được size bao nhiêu. Nếu GOP này là xuất phát của video thì cứ theo giá trị đó sử dụng, nếu không thì cần cân nhắc bù trừ vớ sai lệnh của GOP trước đó.

●Bước 2: Mỗi GOP thông thường có 1 ảnh I và số lượng ảnh P,B cố định. Từ size của GOP sẽ ước lượng được size ảnh I,P,B mà bộ nén cần đạt được, tất nhiên có cân nhắc đến độ lớn của ảnh I,P,B bằng các hệ số, mà hệ số này liên tục được thay đổi sau mỗi lần thực hiện nén ảnh để đảm bảo dần dần có độ chính xác nhất.
Từ size của mỗi ảnh, ví dụ ảnh I thì rate control sẽ dựa vào mô hình ước lượng đển ước tính giá trị QP của ảnh I đó.

●Bước 3: Từ size của ảnh, tiếp tục ước lượng giá trị size của MB(macroblock) cần đạt được, kết hợp với giá trị QP ở bước 2 sẽ ước lượng ra được giá trị QP của MB đó.

Sau bước 3 thì MB đã đủ điều kiện và sang bước tiếp theo để thực hiện chính thức nén. Sau khi có kết quả size thực tế của MB đó sau khi nén thì rate control lại so sánh với size dự đoán, dựa vào độ sai lệch đó để bù vào MB tiếp theo và cập nhật lại thông số mô hình dự đoán. Quá trình này tiếp diễn lên đến lớp GOP.

Tuy nhiên đời không như mơ, thực tế thì có những bộ encoder mà GOP có thể thay đổi, số ảnh trong GOP không cố định. Hay là có những vị trí chuyển cảnh (scene change), hay mức độ sai khác với ảnh trước rất lớn (fade in/out) thì nếu điểm đó là ảnh P, thì ngay cả ảnh P cũng cần chọn giảm hệ số nén để giữ chấp lượng vì sẽ ảnh hưởng lớn đến các ảnh sau. Do đó tùy sự ưu tiên của từng bộ encoder mà chiến lược rate control khác nhau.

4. Tương thích với đặc tả.
Mặc dù rate control là phạm vi nằm ngoài đặc tả chuẩn nén video, nhưng chuẩn nén cũng có một số ràng buộc tương đối khi kiểm tra video đó có tương thích với bộ decoder hay không.
Ở các mục lục của đặc tả chuẩn nén, với H.264 thì ở Annex C Hypothetical reference decoder, đều đưa ra yêu cầu nhằm đảm bảo bộ decoder sẽ không bị mất data hay data không đến kịp đển thực hiện decode mặc dù nó đã thực hiện tuân theo đặc tả chuẩn nén.

Hình vẽ dưới miêu tả tình trạng CPB (Coded picture buffer: vùng nhớ chứa dữ liệu đầu vào của bộ decoder). Dữ liệu vào vùng nhớ này tăng tuyến tính (giả sử với constant bitrate) vì đến thời điểm ảnh nào được decode thì bộ decoder sẽ lấy ảnh đó ra khỏi bộ đệm. Do đó nếu ảnh quá lớn thì sẽ gây CPB bị underflow như vùng màu xanh, ảnh tiếp theo không kịp đến là cho quá trình play video bị giật. Ngược lại nếu ảnh quá nhỏ thì sẽ gây CPB overflow dễ gây mất dữ liệu đầu vào.

hrd1

Để xử lý vấn đề này thì ở encoder luôn có mô hình giả lập để đảm bảo size các ảnh luôn ở phạm vi cho phép mà không xẩy ra tình trạng trên. Đây cũng là một việc của rate control.

5. TM5 (test model 5).
Về phương pháp rate control cho đến H.264 có thể tham khảo tài liệu [1], viết rất đầy đủ và chi tiết (tuy tác giả là của các chú Tàu khựa, nhưng mình nghĩ a/e nên đọc kỹ).
TM5 là chiến lược rate control cho MPEG2-Video, được giới thiệu vào 1993, tức là cách đây 25 năm. Đến hôm nay thì vẫn có công ty sừng sỏ về video của Nhật Bản vẫn dùng cho H.264, H.265 tất nhiên kèm sau sự chỉnh sửa đang kể.
Tham khảo [3] để biết chi tiết hơn về phương pháp này.

6.Tài liệu tham khảo.
[1]https://www.intechopen.com/books/recent-advances-on-video-coding/rate-control-in-video-coding
[2]THE H.264 ADVANCED VIDEO COMPRESSION STANDARD Second Edition, Iain E.Richardson
[3]http://www.mpeg.org/MPEG/MSSG/tm5/Ch10/Ch10.html

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

Kế hoạch chuẩn nén video sau MPEG-HEVC/H.265

1. Công tác chuẩn bị.

Đến hẹn lại lên, sau chu kỳ trên dưới 10 năm lại cần có một chuẩn nén video mới, với nguyên nhân quan trọng nhất là tốc độ truyền data trên internet chỉ tăng gấp 2 trong khi đó với thì màn hình độ phân giải tăng gấp 4. Ngoài ra còn do xuất hiện nhiều xu thế ứng dụng mới mà chuẩn nén video hiện tại chưa đáp ứng phù hợp, cũng có thể thêm một lý do nữa là giải quyết công ăn việc làm cho đám chuyên gia về nghiên cứu kỹ thuật nén video.

Năm 2004 đánh dấu ra đời MPEG-AVC/H.264, cho đến 2009 thì việc bổ sung thêm các công cụ mã hóa đã hoàn thành. MPEG-HEVC/H.265 được phiên bản đầu tiên được thông qua vào 2013, và đến đầu 2017 thì công bố profile SCC(Screen Content Coding Extension) hướng tới các ứng dụng nén hình ảnh không tự nhiên (tức là video các cảnh không phải thực tế, kiểu như phim hoạt hình, các ứng dụng chia sẻ màn hình …) đánh dấu về cơ bản hoàn thành việc phát triển các công cụ mã hóa trong HEVC.

ISO/IEC và ITU-T lại lên kế hoạch cho chuẩn nén video mới, dự định sẽ bản đầu tiên sẽ được công bố vào năm 2020.

Bước đầu tiên để đánh giá sự cần thiết làm ra chuẩn nén video mới bằng cách thực hiện các brainstorm (một kiểu thảo luận tự do nhằm đánh giá nhu cầu), để thu thập ý kiến từ các công ty, các tổ chức chuyên về mã hóa video[1].

2. Yêu cầu chính thức

Sau khi đi đến thống nhất cần một chuẩn nén video mới, thì ISO/IEC và ITU-T sẽ đưa ra tài liệu yêu cầu chính thức cho chuẩn nén video mới[2].

Tài liệu yêu cầu này sẽ miêu tả cụ thể những tiêu chí chuẩn nén video mới, để căn cứ vào đó sau này sẽ quyết định công cụ mã hóa (encoding tool) nào được thông qua để tích hợp vào đó.

Các yêu cầu bao gồm đặc trưng cụ thể của đối tượng mã hóa như kích cỡ khung hình (picture format), khả năng nén (compression performance)…, cũng như phạm vi ứng dụng.Ví dụ lần này đối tượng là 8K, khả năng nén gấp đôi HEVC, trong phần phạm vi ứng dụng đã có đề cập đến thực tế ảo, IoT, Automotive…

3. Thành lập dự án.

Để tiến hành nghiên cứu và thực hiện chuẩn nén mới, 2 bộ phận chuyên trách về mã hóa video, cụ thể là nhóm MPEG (Motion Picture Expert Group) của ISO/IEC và nhóm VCEG(Video Coding Experts Group) của ITU-T sẽ thành lập một nhóm liên kết giữa 2 bên, có tên là JVET(Join Video Explore Team) [3].

JVET được sự tham gia của hầu hết các chuyên gia về kỹ thuật nén video từ các công ty lớn về mảng video như Sony, Gopro, Samsung, Nikon, Qualcomm, Socionext …, và các trường đại học có chuyên môn về mã hóa video (chủ yếu là Hàn, Tàu và Đức).

JVET sẽ thực hiện thực hiện họp 4 lần trong 1 năm, cùng với chu kỳ họp hành của MPEG, để trao đổi các kết quả đạt được cũng như thống nhất nội dung cuộc họp tiếp theo. Toàn bộ tài liệu họp và nội dung các cuộc họp đều được phổ biến rộng rãi trên trang chính của JVET[6], [7].

4. Công cụ phát triển & qui trình làm việc.

Để phát triển chuẩn nén mới, JVET sử dụng công cụ có tên là JEM (Join Exploration Model) [5].

JEM được hiểu đơn giản là một phần mềm thực hiện mã hóa video dựa trên các kết quả đạt được hiện tại. Tức là JEM sẽ là codec đầu tiên cho chuẩn nén video mới, nó được xây dựng trên cơ sở thừa kế của công cụ HM (HEVC model)[12], vốn là công cụ để phát triển HEVC. JEM được sử dụng để kiểm tra các công cụ mã hóa trong quá trình phát triển chuẩn nén mới.

Đồng thời các công ty hay tổ chức khi đưa ra đề nghị công cụ mã hóa mong muốn tích hợp và chuẩn nén mới đều phải có bản sửa JEM có tích hợp công cụ mã hóa đó và kết quả kiểm tra đạt được đó trên JEM đi kèm.

Trong mỗi cuộc họp của JVET sẽ đánh giá kết quả đạt được trong 3 tháng từ cuộc họp lần trước, chủ yếu là xem xét các kết quả đề xuất về công cụ mã hóa lần trước, cùng nhau xem xét những đề xuất mới, ngoài ra cũng không kém phần quan trọng là cùng nhau xem xét lựa chọn ra tập hợp dữ liệu dùng để làm cơ sở đánh giá các các công cụ mã hóa đang được nghiên cứu.

Để phục vụ cho việc xây dựng chuẩn nén video mới, ISO/IEC & ITU-T phát hành thông báo chính thức đến các tổ chức chuyên về video để đề nghị đóng góp về kỹ thuật[4], đóng góp về kết quả kiểm tra[8],[9], cung cấp thêm về dữ liệu phục vụ cho việc đánh giá chuẩn nén mới[10].

Khi một công ty hay tổ chức đưa ra đề xuất công cụ mã hóa trong các cuộc họp của JVET, nếu công cụ mã hóa đó được đánh giá khả thi thì JVET sẽ tiến hành thực hiện việc đáng giá bằng cách kêu gọi 1 nhóm tình nguyện, độc lập đứng ra đánh giá, thông thường thì cũng là các công ty hoặc nhóm ở trong JVET, kết quả đánh giá sẽ được công bố vào cuộc họp kế tiếp, và từ kết quả đó để quyết định công cụ mã hóa này có được chấp nhận đưa vào chuẩn nén mới hay không.

Đến khi có đủ công cụ mã hóa tích hợp vào chuẩn nén mới để đạt được như yêu cầu thì JVET sẽ công bố tài liệu đặc tả chính thức.

5. Kết quả hiện tại.

Ở thời điểm hiện tại (04/2018), cuộc họp mới nhất là cuộc họp lần thứ 10 của JVET đang diễn ra vào 10/04/2018 ở San Diego, Mẽo.

Theo kết quả cuộc họp trước đó, vào 20/1/2018 thì khả năng nén đã đạt được tầm 20~40% so với HEVC.

Ngoài ra có thể tham khảo thêm tổng kết bảo cáo[11] của Sullivan (làm việc ở Mirosoft, đại diện cho MPEG làm trùm trong đội JVET).

6.Tài liệu tham khảo.

[1]https://mpeg.chiariglione.org/standards/exploration/future-video-coding/presentations-brainstorming-session-future-video-coding
[2]https://mpeg.chiariglione.org/standards/exploration/future-video-coding/requirements-a-future-video-coding-standard-v3
[3]https://www.itu.int/en/ITU-T/studygroups/2017-2020/16/Documents/video/JVET-ToR-TD-PLEN-0155A1.pdf
[4]https://www.itu.int/en/ITU-T/studygroups/2017-2020/16/Documents/video/JVET-H1002-CFP-VCBHEVC-Final-v6.pdf
[5]https://jvet.hhi.fraunhofer.de/
[6]http://wftp3.itu.int/av-arch/jvet-site/
[7]http://phenix.it-sudparis.eu/jvet/
[8]https://www.itu.int/en/ITU-T/studygroups/2017-2020/16/Documents/201701/Video-CfE-Final.pdf
[9]https://mpeg.chiariglione.org/tags/call-evidence
[10]https://mpeg.chiariglione.org/tags/future-video-coding
[11]http://www.cs.brandeis.edu//~dcc/Programs/Program2016KeynoteSlides-Sullivan.pdf 
[12]https://hevc.hhi.fraunhofer.de

Liên minh chuẩn nén video mở (Alliance for Open Media)

1. Bối cảnh ra đời

Sau thành công của H.264 (AVC), ITU-T và ISO tiếp tục phát triển H.265 (HEVC), đặc tả kỹ thuật được hoàn thành 2013, và đến 2015 đã dần dần phổ biến khi nhiều công ty bắt đầu giới thiệu sản phẩm có hỗ trợ chuẩn nén này.
Lý do về chi phí bản quyền luôn là nguyên nhân để các công ty phải chi trả nhiều cho nó mong muốn phát triển một chuẩn nén free, tức là không tính tiền bản quyển, ví dụ như trước đây google giới thiệu dòng chuẩn nén VP8, VP9 song song với H.264, H.265 tuy nhiên nó không thực sự thành công, hay có thể vượt mặt được các các chuẩn nén có bản quyền, (riêng VP9 cũng đạt được ít nhiều thành công do nó là chuẩn nén của Google nên tất nhiên Youtube sẽ ưu tiên dùng nó nhất, cây nhà lá vườn mà).
Với H.265 thì chi phí bản quyền còn lớn hơn H.264 nhiều lần do rắc rối tùm lum vụ cãi cọ bằng sáng chế (patent) nên các vị không chơi chung quản lý bản quyền bằng một chỗ như H.264 phó mặc cho MPEG-LA nữa mà chia ra 3-4 chỗ, rồi còn chủ nghĩa địa phương tính xèng bản quyền theo vùng miền ( xem chi tiết ở [9]), chính vì vậy trước khi nó thực sự chiếm thị trường thì nhu cầu cần có 1 chuẩn nén free đối trọng với nó là rất cần thiết.

Trong bối cảnh đó, thì một liên minh chuẩn nén được thành lập với mục tiêu xây dựng được một chuẩn nén free lấn lướt được H.265, với tên là AOM/AV1 được gọi ngắn gọn là AV1. Nhiều công ty đã đưa công nghệ mà trước đó đánh quả lẻ nhằm tạo ra chuẩn nén riêng nhưng đã không gặt hái được nhiều thành công, mong góp phần xây dựng một chuẩn chung, như chuẩn nén Daala (Xiph/Mozilla), VP10(Google), Thor (Cisco).
Với sự tham gia đầu đủ từ các công ty phần mềm (Google, Mozilla …), phần cứng (ARM, AMD …) và cả các công ty cung cấp dịch vụ video( Netflix, Amazon …), có thể nói đây là liên mình video lớn nhất từ trước đến giờ. Đặc biệt có sự tham gia của Apple từ cuối năm 2017, hứa hẹn đây là một chuẩn nén có triển vọng trong tương lai.

2. Kế hoạch phát triển
Các tính năng được chốt vào 10/2017, đặc tả được chốt vào 01/2018, phần thời gian này chắc đã kiểm tra để có được bản chính thức (đoán vậy).

Cả chuẩn đặc tả lẫn open codec sử dụng đển phát triển đặc tả được lưu giữ ở git store dưới.
https://aomedia.googlesource.com

●Cập nhật: 11/04/2018
Tài liệu đặc tả bản draft (bản tạm) được công bố dưới dạng file pdf theo [14].
Phong cách viêt đặc tả tương đối giống tài liệu của ISO & ITU-T, tức là giống cách viết H.264, H.265, miêu tả cấu trúc luồng data, cách phân tích để ra các thông tin, cách decode nhưng không miêu tả thuật toán đứng đằng sau đó. Do lý do đó nên đặc tả thường chỉ dùng tham khảo trong quá trình phát triển codec, chứ không phù hợp cho việc học tập.

3. So sánh với H.264, H.265
Hiện tại do đặc tả cả AV1 vẫn chưa được hoàn thành, có vẻ như thế nên chưa có một báo cáo so sánh nào chi tiết khi so sánh với H.264, H.265. Do một báo cáo chi tiết cần có đánh giá trên phương diện chủ quan (sử dụng 1 tập các tình nguyện viên để xem demo video) nhưng đến thời điểm hiện tại mới chỉ có đánh giá khách quan ( tức là thông qua đo đạc matrix như PNSR …).

Theo báo cáo số [10] cho ta thấy phần lớn các trường hợp thì AV1 chất lượng ngang ngửa với HEVC. Tuy nhiên trong báo cáo [12] và [13] thì cho thấy các codec theo chuẩn nén hiện tại đều xách dép cho AV1. Nhưng ngạc nhiên thay trong báo cáo [11], một báo cáo rất đáng tin cậỵ vì nó được sự chấp thuận của IEEE, lại cho thấy codec theo chuẩn AV1 chỉ ngang ngửa với codec theo chuẩn H.264.

Tóm lại ai hơn ai kém, chắc phải đợi thêm thời gian :).

● Cập nhật: 26/05/2018.
Báo cáo [11] có vẻ thực hiện khi codec AV1 đang ở giai đoạn phát triển. Nên mình có mail hỏi ông anh làm paper đó về kết quả mới nhất thì nhận đc như báo cáo[15].
So với HM (codec dùng phát triển H.265) thì mức độ nén của AV1 codec vẫn kém 30% đến 47%.
Có vẻ về mặt kỹ thuật thì AV1 khó mà qua mặt được H.265 chứ chưa nói đến codec theo chuẩn nén mới mà ISO-IEC/ITU-T đang phát triển, chuẩn nén VVC. Tuy nhiên dưới  sự bảo kê của 1 loạt công ty công nghệ thì vẫn chưa biết ai sẽ là kẻ thắng.

Tài liệu tham khảo
[1]http://aomedia.org
[2]https://en.wikipedia.org/wiki/AV1
[3]https://en.wikipedia.org/wiki/Daala
[4]https://en.wikipedia.org/wiki/Thor_(video_codec)
[5]https://medium.com/@voluntas/av1-の未来が開いた-38c5fd174630
[6]https://hacks.mozilla.org/2017/11/dash-playback-of-av1-video/
[7]https://www.telecompaper.com/news/apple-joins-alliance-for-open-media–1226820
[8]https://hothardware.com/news/apple-joins-alliance-shrink-online-videos-royalty-free-codecs
[9]https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
[10]https://www.elecard.com/page/aom_av1_vs_hevc
[11]http://ieeexplore.ieee.org/document/7906321/?reload=true
[12]http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Bitmovin-Pushes-AV1-Forward-Joins-Alliance-for-Open-Media-117634.aspx
[13]https://streaminglearningcenter.com/blogs/av1hevcvp9-comparison-streaming-media-east.html
[14]https://aomediacodec.github.io/av1-spec/av1-spec.pdf
[15]http://iphome.hhi.de/marpe/download/spie-2017.pdf

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