Как работи видеокодек. Част 2. Какво, защо, как

Първа част: Основи на работа с видео и изображения

Какво? Видеокодекът е част от софтуера/хардуера, който компресира и/или разпакетира дигитално видео.

За какво? Несмотря на определени ограничения както по пропускна способност, така
така и по количеството място за съхранение, пазарът изисква все по-качествено видео. Спомняте ли си, как в миналото изчислихме необходимия минимум за 30 кадъра в секунда, 24 бита на пиксел, с резолюция 480×240? Получихме 82,944 Мбит/с без компресия. Компресията е засега единственият начин изобщо да предаваме HD/FullHD/4K на телевизионни екрани и в Интернет. Как се постига това? Сега накратко ще разгледаме основните методи.

Преводът е извършен с подкрепата на компанията EDISON Software.

Ние се занимаваме с интеграция на системи за видеонаблюдение, а също така разработваме микротомограф.

Кодек vs Контейнер

Честа грешка на начинаещите е да бъркат кодека на дигиталното видео с контейнера на дигиталното видео. Контейнерът е специфичен формат. Обвивка, съдържаща метаданни за видеото (и, евентуално, звука). Компресираното видео може да се разглежда като полезен товар на контейнера.

Обикновено разширението на видеофайла указва неговия вид контейнер. Например, файлът video.mp4 вероятно е контейнер MPEG-4 Part 14, а файл с име video.mkv е, най-вероятно, матрьошка. За да бъдете напълно сигурни в кодека и формата на контейнера, можете да използвате FFmpeg или MediaInfo.

Няколко факта от историята

Преди да преминем към Как?, нека се потопим малко в историята, за да разберем по-добре някои стари кодеци.

Видеокодек H.261 появява се през 1990 година (технически — през 1988) и е създаден за работа със скорост на предаване от 64 Кбит/с. В него вече се използваха идеи като цветова субдискретизация, макроблокове и т.н. През 1995 година беше публикуван стандартът за видеокодек H.263, който се развиваше до 2001 година.

През 2003 година беше завършена първата версия H.264/AVC. През същата година компанията „TrueMotion“ пусна своя безплатен видеокодек, компресиращ видео с загуби, наречен VP3. През 2008 година Google купи тази компания, като пусна VP8 също през същата година. През декември 2012 година Google пусна VP9, и той се поддържа от около ¾ от пазара на браузъри (включително мобилни устройства).

AV1 — това е нов безплатен видеокодек с отворен код, разработен от Алианса за отворени медии (AOMedia), чийто състав включва известни компании като: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel и Cisco. Първата версия на кодека 0.1.0 беше публикувана на 7 април 2016 г.

Раждането на AV1

В началото на 2015 г. Google работеше върху VP10, Xiph (който принадлежи на Mozilla) работеше върху Daala, а Cisco разработи безплатен видеокодек, наречен Thor.

След това MPEG LA първоначално обяви годишни лимити за HEVC (H.265) и такса, 8 пъти по-висока от тази за H.264, но скоро отново промениха условията:

без годишен лимит,
такса за съдържание (0,5% от приходите) и
такса за единица продукция, която е приблизително 10 пъти по-висока от тази за H.264.

Съюз за открити медии беше създаден от компании от различни области: производители на оборудване (Intel, AMD, ARM, Nvidia, Cisco), доставчици на съдържание (Google, Netflix, Amazon), създатели на браузъри (Google, Mozilla) и други.

Целта на компаниите беше обща — видеокодек без лицензионни такси. След това се появи AV1 с много по-прост патентен лиценз. Тимоти Б. Териберри направи впечатляваща презентация, която стана основа на текущата концепция за AV1 и модела на лицензирането.

Ще бъдете изненадани да научите, че можете да анализирате кодека AV1 през браузера (заинтересованите могат да посетят aomanalyzer.org).

Универсален кодек

Нека разгледаме основните механизми, стоящи зад универсалния видеокодек. Повечето от тези концепции са полезни и се използват в съвременни кодеци, като VP9, AV1 и HEVC. Предупреждавам, че много от нещата ще бъдат опростени. Понякога ще се използват реални примери (както в случая с H.264), за да се демонстрират технологиите.

1-ви етап — разделяне на изображението

Първата стъпка е разделяне на кадъра на няколко секции, подсекции и т.н.

Защо? Има много причини. Когато разделяме картината, можем по-точно да прогнозираме вектора на движение, използвайки малки секции за малки движещи се части. Докато за статичен фон можем да се ограничим до по-големи секции.

Обикновено кодеките организират тези секции в секции (или фрагменти), макроблокове (или кодиращи блокове) и множество подсеции. Максималният размер на тези секции варира, HEVC задава 64×64, докато AVC използва 16×16, а под секциите могат да се разделят до размери 4×4.

Спомняте си разновидностите кадри от предишната статия?! Може да ги приложим и към блоковете, така че да имаме I-фрагмент, B-блок, P-макроблок и т.н.

За желаещите да практикуват — вижте как изображението ще бъде разделено на секции и подсекции. За това можете да използвате вече споменатото в предишната статия. Intel Video Pro Analyzer (този, който е платен, но предлага безплатна пробна версия с ограничение до първите 10 кадри). Тук са анализирани секциите. VP9:

2-ра стъпка — прогнозирането

След като имаме секции, можем да съставяме астрологични прогнози за тях. За INTER-прогнозиране е необходимо да се предадат вектори на движение и остатъка, а за INTRA-прогнозиране се предава посоката на прогнозата и остатъка.

3-та стъпка — преобразуване

След като получим остатъчния блок (предсказаната секция → реалната секция), може да го преобразуваме по такъв начин, че да знаем кои пиксели могат да бъдат отхвърлени, като същевременно запазим общото качество. Има различни преобразувания, които осигуряват точно поведение.

Въпреки че има и други методи, да разгледаме по-подробно дискретното косинусно преобразуване (DCT — от дискретно косинусно преобразуване). Основни функции на DCT:

• Преобразува блокове пиксели в блокове на равен по размер частотен коефициент.
• Компактира мощността, помагайки да се елиминира пространствената излишност.
• Осигурява обратимост.

На 2 февруари 2017 г. Синттра Р. Дж. (Cintra, R.J.) и Баяр Ф. М. (Bayer F.M.) публикуваха статия относно DCT-подобно преобразуване за компресия на изображения, което изисква само 14 допълнения.

Не се притеснявайте, ако не сте разбрали предимствата на всеки пункт. Сега с конкретни примери ще се уверим в тяхната реална стойност.

Нека вземем следния блок пиксели 8×8:

Този блок се визуализира в следното изображение 8 на 8 пиксела:

Прилагаме DCT към този блок пиксели и получаваме блок коефиенти с размер 8×8:

И ако визуализираме този блок коефиенти, получаваме такова изображение:

Както виждаме, то не прилича на оригиналното изображение. Можем да забележим, че първият коефициент значително се отклонява от всички останали. Този първи коефициент е известен като DC-коефициент, представляващ всички проби в входния масив, нещо подобно на средната стойност.

Този блок на коефициенти има интересна характеристика: той отделя високочестотните компоненти от нискочестотните.

В изображението голяма част от мощността е концентрирана на по-ниски честоти, затова, ако преобразуваме изображението в неговите честотни компоненти и отхвърлим по-високите коефициенти, можем да намалим количеството данни, необходими за описание на изображението, без да пожертваме твърде много качество.

Честотата означава колко бързо се променя сигналът.

Нека да опитаме да приложим знанията, получени в тестовия пример, като преобразуваме оригиналното изображение в неговата честота (блок коефициенти), използвайки DCT, а след това отхвърлим част от най-маловажните коефициенти.

Първо, конвертираме изображението в честотна област.

След това отхвърляме част (67%) от коефициентите, главно долния десен ъгъл.

Накрая възстановяваме изображението от този отхвърлен блок на коефициенти (помнете, това трябва да е обратимо) и го сравняваме с оригинала.

Виждаме, че то напомня на оригиналното изображение, но има много различия. Изхвърлихме 67,1875% и все пак получихме нещо, което наподобява оригинала. Можеше да отхвърлим коефициентите по-продумано, за да получим изображение с още по-добро качество, но това е тема за следваща дискусия.

Всеки коефициент се формира с използване на всички пиксели.

Важно: всеки коефициент не отговаря директно на един пиксел, а представлява претеглена сума на всички пиксели. Тази удивителна графика показва как се изчисляват първият и вторият коефициент, използвайки тежести, уникални за всеки индекс.

Можете също така да се опитате да визуализирате DCT, като се погледнем на простото образуване на изображение на неговата основа. Например, ето символ A, образуван с използване на всяко тегло на коефициента:

4-ти етап — квантоване.

След като на предишния етап отхвърлим някои коефициенти, на последния етап (трансформация), извършваме специална форма на квантоване. На този етап е допустимо да губим информация. Или, по-просто казано, ще квантоваме коефициентите с цел постигане на компресия.

Как можем да квантизираме блока на коефициентите? Един от най-простите методи е равномерната квантизация, при която взимаме блока, разделяме го на едно число (на 10) и закръгляме получения резултат.

Можем ли да обърнем този блок на коефициентите? Да, можем, като го умножим по същото число, на което сме делили.

Този подход не е най-добрият, тъй като не отчита важността на всеки коефициент. Можеше да се използва матрица на квантизация вместо едно число, а тази матрица може да се възползва от свойствата на DCT, квантизирайки повечето от долните десни и малко от горните леви.

5 стъпка — ентропийно кодиране

След като квантизирахме данните (блокове от изображения, фрагменти, кадри), все още можем да ги компресираме без загуби. Съществуват много алгоритмични методи за компресиране на данни. Ще се запознаем накратко с някои от тях; за по-дълбоко разбиране можете да прочетете книгата „Разбираме компресията: компресия на данни за съвременни разработчици“ (Understanding Compression: Data Compression for Modern Developers»).

Кодиране на видео с VLC

Да предположим, че имаме поток от символи: a, e, r и t. Вероятността (между 0 и 1), че всеки символ в потока се среща, е представена в тази таблица.

Можем да присвоим уникални двоични кодове (предпочитание за малки) на най-вероятните, а по-големи кодове на по-малко вероятните.

Компресираме потока, предполагаем, че в крайна сметка ще изразходваме 8 бита за всеки символ. Без компресия би било необходимо 24 бита за символ. Ако всеки символ се замени с кода си, то се получава икономия!

Първата стъпка е кодиране на символа e, който е равен на 10, а вторият символ — това е a, който се добавя (не по математически начин): [10] [0], и накрая, третият символ t, който прави нашия финален компресиран бит поток равен на [10] [0] [1110] или 1001110, за което са необходими само 7 бита (в 3.4 пъти по-малко място от оригинала).

Обърнете внимание, че всеки код трябва да е уникален с префикс. Алгоритъмът на Хаффман ще помогне да намерим тези числа. Въпреки че този метод не е без недостатъци, все още съществуват видеокодеци, които предлагат този алгоритмичен метод за компресия.

Как кодер, так и декодер трябва да имат достъп до таблица с символите и техните бинарни кодове. Затова е необходимо да изпратите и таблицата в входните данни.

Арифметично кодиране

Да предположим, че имаме поток от символи: a, e, r, s и t, а вероятността им е представена в тази таблица.

С тази таблица ще построим интервали, съдържащи всички възможни символи, подредени по най-голямо количество.

Сега нека кодиране на потока от три символа: eat.

Първо избираме първия символ e, който се намира в подинтервала от 0,3 до 0,6 (не включително). Вземаме този подинтервал и го разделяме отново в същите пропорции, както по-рано, но вече за този нов интервал.

Нека продължим с кодирането на нашия поток eat. Сега вземаме втория символ a, който е в новия подинтервал от 0,3 до 0,39, а след това взимаме последния ни символ t и, повтаряйки същия процес отново, получаваме последния подинтервал от 0,354 до 0,372.

Просто трябва да изберем число в последния подинтервал от 0,354 до 0,372. Нека изберем 0,36 (но може и да изберем всяко друго число в този подинтервал). Само с това число можем да възстановим оригиналния си поток. Точно така, все едно рисуваме линия в рамките на интервалите, за да закодираме нашия поток.

Обратната операция (тоест декодиране) е също толкова проста: с нашето число 0,36 и нашия началния интервал можем да стартираме същия процес. Но сега, използвайки това число, идентифицираме потока, кодиран с помощта на това число.

С първия интервал забелязваме, че нашето число съответства на резката, следователно, това е нашият първи символ. Сега отново разделяме този подинтервал, извършвайки същия процес, както преди. Можем да забележим, че 0,36 съответства на символа a, и след повторение на процеса стигаме до последния символ t (формирование на нашия оригинален кодиран поток eat).

И за кодера, и за декодера би трябвало да има на разположение таблица с вероятностите на символите, затова е необходимо да изпратите и нея в входните данни.

Доста елегантно, нали? Някой, който е измислил това решение, е бил адски умен. Някои видео кодеци използват тази техника (или поне я предлагат като опция).

Идеята е да се компресира без загуби квантизиран битов поток. Сигурно в тази статия липсват тонове детайли, причини, компромиси и т.н. Но вие, ако сте разработчик, трябва да знаете повече. Новите кодеци се опитват да използват различни алгоритми за ентропийно кодиране, като ANS.

6 стъпка — формат на битовия поток

След като направим всичко това, остава да разпакуем компресираните кадри в контекста на направените стъпки. Трябва изрично да информираме декодера за решенията, взети от кодера. На декодера трябва да се предостави всяка необходима информация: битова дълбочина, цветово пространство, резолюция, информация за прогнозите (вектори на движение, насочени INTER-прогнозирания), профил, ниво, честота на кадрите, тип кадър, номер на кадър и много други.

Ние повърхностно ще се запознаем с битовия поток H.264. Първата ни стъпка е да създадем минимален битов поток H.264 (FFmpeg по подразбиране добавя всички параметри на кодиране, като SEI NAL — малко по-късно ще разберем какво е това). Можем да направим това, използвайки нашето собствено хранилище и FFmpeg.

.\/s\/ffmpeg -i \/files\/i\/minimal.png -pix_fmt yuv420p \/files\/v\/minimal_yuv420.h264

Тази команда ще генерира необработен битов поток H.264 с един кадър, резолюция 64×64, с цветово пространство YUV420. В този случай се използва следното изображение като кадър.

Битовият поток H.264

Стандарт AVC (H.264) определя, че информацията ще бъде изпратена в макрокадри (в контекста на мрежата), наричани NAL (това е един такъв абстракционен слой в мрежата). Основната цел на NAL е да предостави "приятелско за мрежата" представяне на видео. Този стандарт трябва да работи на телевизори (на базата на потоци), в Интернет (на базата на пакети).

Съществува маркер за синхронизация за определяне на границите на NAL елементите. Всеки маркер за синхронизация съдържа стойност 0x00 0x00 0x01, с изключение на самия първи, който е равен на 0x00 0x00 0x00 0x01. Ако стартираме hexdump за генерирания битов поток H.264, ще идентифицираме най-малко три NAL шаблона в началото на файла.

Както споменахме, декодерът трябва да знае не само данните за изображението, но и детайлите на видеото, кадъра, цвета, използваните параметри и много други. Първият байт на всеки NAL определя неговата категория и тип.

Обикновено първият NAL в битовия поток е SPS. Този тип NAL отговаря за информирането за общите кодиращи променливи като профил, ниво, резолюция и др.

Ако пропуснем първия маркер за синхронизация, можем да декодираме първия байт, за да разберем какъв тип NAL е първият.

Например, първият байт след маркера за синхронизация е равен на 01100111, където първият бит (0) е в полето forbidden_zero_bit. Следващите 2 бита (11) ни информират за полето nal_ref_idc, което указва дали този NAL е референтно поле или не. А останалите 5 бита (00111) ни информират за полето nal_unit_type, в този случай е блок SPS (7) NAL.

Вторият байт (binary=01100100, hex=0x64, dec=100) в SPS NAL е полето profile_idc, което показва профила, използван от кодера. В този случай е използван ограничен висок профил (т.е. висок профил без поддръжка на двуразмерен B-сегмент).

Ако разгледаме спецификацията на битовия поток H.264 за SPS NAL, ще открием много стойности за името на параметъра, категорията и описанието. Например, нека погледнем полетата pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.

Ако извършим някои математически операции със стойностите на тези полета, ще получим резолюцията. Можем да представим 1920 x 1080, използвайки pic_width_in_mbs_minus_1 с стойност 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920). Отново, за да спестим пространство, вместо да кодиране 1920, направихме това със 119.

Ако продължим да проверяваме нашето създадено видео в двоичен вид (например: xxd -b -c 11 v/minimal_yuv420.h264), можем да преминем към последния NAL, който е самият кадър.

Тук виждаме неговите първите 6 байтови стойности: 01100101 10001000 10000100 00000000 00100001 11111111. Тъй като е известно, че първият байт указва типа на NAL, в този случай (00101) е IDR фрагмент (5), и можем да изследваме допълнително:

Използвайки информация от спецификацията, можем да декодираме типа на фрагмента (slice_type) и номера на кадъра (frame_num) сред другите важни полета.

За да получим стойности на някои полета (ue(v), me(v), se(v) или te(v)), трябва да декодираме фрагмента, използвайки специален декодер, основан на експоненциален код Голомба.. Този метод е много ефективен за кодирането на стойности на променливи, особено когато има много стойности по подразбиране.

Стойности slice_type и frame_num това видео е равно на 7 (I-фрагмент) и 0 (първа ключова кадър).

Битовият поток може да се разглежда като протокол. Ако искате да научите повече за битовия поток, е добре да се обърнете към спецификацията ITU H.264. Ето макросхема, показваща къде се намират данните на изображението (YUV в компресиран вид).

Може да проучите и други битови потоци, като VP9, H.265 (HEVC) или дори нашия нов най-добър битов поток AV1. Всички ли те си приличат? Не, но след като разберете поне един — ще бъде много по-лесно да разберете останалите.

Искате ли да практикувате? Проучете битовия поток H.264

Може да генерирате еднокадрово видео и да използвате MediaInfo за проучване на битовия поток H.264. Всъщност, нищо не пречи дори да погледнете изходния код, който анализира битовия поток H.264 (AVC).

Предлагам да използвате Intel Video Pro Analyzer (казах, че програмата е платена, но има безплатна пробна версия с ограничение на 10 кадъра?).

Преглед

Струва си да се отбележи, че много съвременни кодеци използват същия модел, който току-що разгледахме. Ето, нека погледнем блок-схемата на видеокодека Thor. Тя съдържа всичките стъпки, които преминахме. Целта на тази бележка е да разберете поне малко по-добре иновациите и документацията в тази област.

Преди това изчислихме, че ще са необходими 139 Гб дисково пространство за съхраняване на видеофайл с продължителност един час при качество 720p и 30 fps. Ако използвате методите, разгледани в тази статия (междукодови и вътрешни предсказания, преобразуване, квантоване, ентропийно кодиране и т.н.), можете да постигнете (при условие, че харчите 0,031 бита на пиксел), видео с напълно задоволително качество, заемащо само 367,82 Мб, а не 139 Гб памет.

Как H.265 постига по-добра степен на компресия от H.264?

Сега, когато знаете повече за начина на работа на кодеците, е по-лесно да разберете как новите кодеци могат да осигурят по-висока резолюция с по-малко битове.

Когато сравняваме AVC и HEVC, не трябва да забравяме, че почти винаги става въпрос за избор между по-голямо натоварване на CPU и степен на компресия.

HEVC има повече опции за раздели (и подраздели), отколкото AVC, повече направления на вътрешно прогнозиране, подобрено ентропийно кодиране и много други. Всички тези подобрения направиха H.265 възможен компресия с 50% по-голяма от H.264.

Първа част: Основи на работа с видео и изображения

Източник: habr.com