Перша частина:
Що? Відеокодек — це частина програмного/апаратного забезпечення, що стискає та/або розпаковує цифрове відео.
Для чого? Незважаючи на певні обмеження як за пропускною здатністю так
і за кількістю місця для зберігання даних, ринок вимагає все якіснішого відео. Пригадуєте, як у минулому пості ми підрахували необхідний мінімум для 30 кадрів за секунду, 24 біти на піксель, з роздільною здатністю 480×240? Отримали 82,944 Мбіт/с без стиску. Стиснення – це поки що єдиний спосіб взагалі передавати HD/FullHD/4K на телевізійні екрани та в Інтернет. Як це досягається? Нині коротко розглянемо основні методи.
Переклад зроблений за підтримки EDISON Software.Ми займаємось , а також .
Кодек vs Контейнер
Поширена помилка новачків – плутати кодек цифрового відео та контейнер цифрового відео. Контейнер це якийсь формат. Обертання, що містить метадані відео (і, можливо, аудіо). Стисне відео можна розглядати як корисне навантаження контейнера.
Зазвичай розширення відеофайлу свідчить про його різновид контейнера. Наприклад, файл video.mp4, ймовірно, є контейнером MPEG-4 Частина 14, а файл з ім'ям video.mkv - це, швидше за все, . Щоб бути повністю впевненим у кодеку та форматі контейнера, можна скористатися або .
Трохи історії
Перш ніж перейдемо до Як?, давайте злегка поринемо в історію, щоб трохи краще розуміти деякі старі кодеки.
Відеокодек 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) працював над Даала, а Cisco зробила свій безкоштовний відеокодек під назвою Тора.
Потім 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 через браузер (зацікавилися можуть перейти на адресу).
Універсальний кодек
Розберемо основні механізми, що у основі універсального відеокодека. Більшість цих концепцій корисні і використовуються в сучасних кодеках, таких як VP9, AV1 и HEVC. Попереджаю, що багато речей, що пояснюються, будуть спрощені. Іноді використовуватимуться реальні приклади (як у випадку з H.264) для демонстрації технологій.
1-й крок - розбиття зображення
Першим кроком є розділення кадру на кілька розділів, підрозділів і далі.
Для чого? Є багато причин. Коли дробимо картинку, можна точніше прогнозувати вектор руху, використовуючи невеликі розділи для маленьких частин, що рухаються. У той час як для статичного фону можна обмежитися і більшими розділами.
Зазвичай кодеки організують ці розділи у секції (або фрагменти), макроблоки (або блоки деревини кодування) та безліч підрозділів. Максимальний розмір цих розділів варіюється, HEVC встановлює 64х64, в той час як AVC використовує 16х16, а підрозділи можуть дробитися до розмірів 4х4.
Пригадуєте різновиди кадрів із минулої статті?! Це можна застосувати і до блоків, так що, у нас можуть бути I-фрагмент, B-блок, P-макроблок і т.п.
Для бажаючих попрактикуватися – подивіться як зображення розіб'ється на розділи та підрозділи. Для цього можна скористатися згадуваною в минулій статті (Той, що платний, але з безкоштовною пробною версією, що має обмеження на перші 10 кадрів). Тут проаналізовано розділи VP9:
2-й крок - прогнозування
Як тільки у нас з'явилися розділи, ми можемо складати астрологічні прогнози щодо них. Для INTER-прогнозування необхідно передати вектори руху та залишок, а для INTRA-прогнозування передається напрям прогнозу та залишок.
3-й крок - перетворення
Після того, як отримаємо залишковий блок (передбачений розділ → реальний розділ), можливо, перетворити його таким чином, щоб знати, які пікселі можна відкинути, зберігаючи при цьому загальну якість. Є деякі перетворення, які забезпечують точну поведінку.
Хоча є й інші методи, розглянемо докладніше дискретне косинусне перетворення (DCT - від дискретне косинусне перетворення). Основні функції DCT:
- Перетворює блоки пікселів на однакові за розміром блоки частотних коефіцієнтів.
- Ущільнює потужність, допомагаючи усувати просторову надмірність.
- Забезпечує оборотність.
2 лютого 2017 року Синттра Р.Дж. (Cintra, RJ) та Байєр Ф.М. (Bayer FM) опублікували статтю про DCT-подібне перетворення для стиснення зображень, що потребує лише 14 додатків.
Не переживайте, якщо не зрозуміли переваги кожного пункту. Зараз на конкретних прикладах переконаємось у їхній реальній цінності.
Давайте візьмемо такий блок пікселів 8×8:
Цей блок рендерується в наступне зображення 8 на 8 пискелів:
Застосуємо DCT до цього блоку пікселів та отримуємо блок коефіцієнтів розміром 8×8:
І якщо відрендеримо цей блок коефіцієнтів, отримаємо таке зображення:
Як бачимо, це не схоже на вихідне зображення. Можна помітити, перший коефіцієнт сильно відрізняється від решти. Цей перший коефіцієнт відомий як DC-коефіцієнт, що представляє всі вибірки у вхідному масиві, схоже на середнє значення.
Цей блок коефіцієнтів має цікаву властивість: він відокремлює високочастотні компоненти від низькочастотних.
У зображенні більша частина потужності сконцентрована на нижчих частотах, тому, якщо перетворити зображення на його частотні компоненти і відкинути вищі частотні коефіцієнти, можна зменшити кількість даних, необхідні опису зображення, не надто жертвуючи якістю картинки.
Частота означає, як швидко змінюється сигнал.
Спробуємо застосувати знання, отримані в тестовому прикладі, перетворивши вихідне зображення на його частоту (блок коефіцієнтів), використовуючи DCT, а потім відкинувши частину найменш важливих коефіцієнтів.
Спочатку конвертуємо їх у частотну область.
Далі відкидаємо частину (67%) коефіцієнтів, переважно нижню праву частину.
Зрештою, відновлюємо зображення з цього відкинутого блоку коефіцієнтів (пам'ятайте, воно має бути оборотним) і порівнюємо з оригіналом.
Бачимо, що воно нагадує вихідне зображення, але є багато відмінностей від оригіналу. Ми викинули 67,1875% і все ж таки отримали щось, що нагадує першоджерело. Можна було більш продумано відкинути коефіцієнти, щоб отримати зображення кращої якості, але це вже наступна тема.
Кожен коефіцієнт формується з використанням усіх пікселів
Важливо: кожен коефіцієнт безпосередньо не відображається на один піксель, а є зваженою сумою всіх пікселів. Цей дивовижний графік показує, як розраховується перший і другий коефіцієнт з використанням ваг, унікальних кожного індексу.
Ви також можете спробувати візуалізувати DCT, глянувши на просте формування зображення на його основі. Наприклад, ось символ A, що формується з використанням кожної ваги коефіцієнта:
4-й крок - квантування
Після того, як на попередньому кроці викидаємо деякі коефіцієнти, на останньому кроці (перетворення), робимо особливу форму квантування. На цьому етапі можна втрачати інформацію. Або, простіше кажучи, квантуватимемо коефіцієнти для досягнення стиснення.
Як можна квантувати блок коефіцієнтів? Одним із найпростіших методів буде рівномірне квантування, коли беремо блок, ділимо його на одне значення (на 10) і округляємо те, що вийшло.
Чи можемо звернути цей блок коефіцієнтів? Так, можемо, помноживши те саме значення, куди ділили.
Цей підхід не найкращий, оскільки він не враховує важливості кожного коефіцієнта. Можна було б використовувати матрицю квантувачів замість одного значення, а ця матриця може використовувати властивість DCT, квантуючи більшість нижніх правих та меншість верхніх лівих.
5 крок - ентропійне кодування
Після того, як квантували дані (блоки зображень, фрагменти, кадри), все ще можемо стискати їх без втрат. Існує багато алгоритмічних методів стиснення даних. Ми збираємося коротко познайомитися з деякими з них, для більш глибокого розуміння ви можете прочитати книгу «Розбираємося зі стиском: стиснення даних для сучасних розробників» («»).
Кодування відео за допомогою 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, з колірним простором ЮВ420. При цьому використовується як кадр наступне зображення.
Потік бітовий H.264
Cтандарт AVC (H.264) визначає, що інформація буде надсилатися в макрокадрах (в розумінні мережі), які називаються NAL (це такий рівень абстракції мережі). Основною метою NAL є надання "дружнього до мережі" подання відео. Цей стандарт має працювати на телевізорах (з урахуванням потоків), в Інтернеті (з урахуванням пакетів).
Існує маркер синхронізації визначення меж елементів NAL. Кожен маркер синхронізації містить значення 0x00 0x00 0x01, за винятком найпершого, який дорівнює 0x00 0x00 0x00 0x01. Якщо запустимо шестикутник для згенерованого бітового потоку 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 х 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) та номер кадру (номер_рами) Серед інших важливих полів.
Щоб отримати значення деяких полів (ue(v), me(v), se(v) Або te(v)), нам потрібно декодувати фрагмент, використовуючи спеціальний декодер, заснований на . Цей метод дуже ефективний для кодування змінних змін, особливо, якщо є багато значень за замовчуванням.
значення slice_type и номер_рами цього відео дорівнюють 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 кадрів?).
Огляд
Зазначимо, що багато сучасних кодеків використовують ту саму модель, яку щойно вивчили. Ось, погляньмо на блок-схему відеокодека Тора. Вона містить усі кроки, які ми пройшли. Весь зміст цієї замітки в тому, щоб ви принаймні краще розуміли інновації та документацію з цієї галузі.
Раніше розрахували, що потрібно 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