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

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

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

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

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

Ние сме сгодени интегриране на системи за видеонаблюдениеИ ние разработваме микротомограф.

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

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

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

Малко история

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

Видео кодек H.261 се появява през 1990 г. (технически - през 1988 г.) и е създаден да работи при скорост на трансфер на данни от 64 Kbps. Той вече използва идеи като субсемплиране на цветовете, макроблокове и др. Стандартът за видео кодек е публикуван през 1995 г H.263, която се развива до 2001г.

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

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

Раждане на AV1

В началото на 2015 г. Google работи върху VP10Xiph (който е собственост на 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 го задава на 64x64, докато AVC използва 16x16, а подразделенията могат да бъдат разделени до размери 4x4.

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

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

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

След като имаме раздели, можем да правим астрологични прогнози за тях. За ИНТЕР прогнози трябва да се прехвърли вектори на движение и остатъка, а за INTRA прогнозиране се предава прогнозна посока и остатъка.

3-та стъпка - трансформация

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

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

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

2 февруари 2017 г. Синтра R.J. (Cintra, RJ) и Bayer F.M. (Bayer FM) публикува статия за подобна на DCT трансформация за компресиране на изображения, която изисква само 14 добавяния.

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

Нека вземем този 8x8 блок от пиксели:

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

Приложете DCT към този блок от пиксели и получете блок от коефициенти 8x8:

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

Както можете да видите, не изглежда като оригиналното изображение. Виждате, че първият коефициент е много различен от всички останали. Този първи коефициент е известен като 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) колко често всеки знак се появява в поток е представена в тази таблица.

	a	e	r	t
вероятност	0,3	0,3	0,2	0,2

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

	a	e	r	t
вероятност	0,3	0,3	0,2	0,2
Двоичен код	0	10	110	1110

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

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

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

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

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

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

	a	e	r	s	t
вероятност	0,3	0,3	0,15	0,05	0,2

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

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

Първо изберете първия знак 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 тип идентификатор	описание
0	Неизвестен тип
1	Фрагмент от кодирано изображение без IDR
2	Секция с данни за кодиран срез A
3	Секция с данни за кодиран срез B
4	Секция с данни за кодиран срез C
5	Кодиран IDR фрагмент от IDR изображение
6	Повече информация за разширението SEI
7	Набор от параметри на SPS последователност
8	Набор от PPS параметри на изображението
9	Разделител за достъп
10	Край на последователността
11	Край на нишката
...	...

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

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

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

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

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

Име на параметър	Категория	описание
pic_width_in_mbs_minus_1	0	ue(v)
pic_height_in_map_units_minus_1	0	ue(v)

Ако извършим някои математически операции със стойностите на тези полета, ще получим резолюция. Човек може да представи 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) и след това можете да го изследвате допълнително:

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

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

значение тип_срез и 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 GB дисково пространство за съхраняване на видео файл с продължителност един час при качество 720p и 30 fps. Ако използвате методите, обсъдени в тази статия (междукадрови и вътрешни прогнози, трансформация, квантуване, ентропийно кодиране и т.н.), тогава можете да постигнете (въз основа на факта, че изразходваме 0,031 бита на пиксел), видео на доста задоволително качество, заемайки само 367,82 MB, а не 139 GB памет.

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

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

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

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

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

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