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

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

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

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

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

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

Кодек срещу контейнер

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

Обикновено разширението на видеофайла показва вида на неговия контейнер. Например, файлът video.mp4 най-вероятно е контейнер MPEG-4 Част 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) и такса, осем пъти по-висока от тази за H.264, но скоро те отново промениха правилата:

без годишен лимит,
такса за съдържание (0.5% от прихода) и
такса за единица продукция, която е приблизително десет пъти по-висока от тази за 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, и вероятността им е представена в тази таблица.

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

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

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

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

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

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

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

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

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

Идеята се състои в компресия на квантован битов поток без загуби. Сигурно в тази статия липсват много подробности, причини, компромиси и т.н. Но вие, ако сте разработчик, трябва да знаете повече. Новите кодеци се опитват да прилагат различни алгоритми за ентропийно кодиране, като 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