H.264 - це магія

H.264 - це стандарт кодека для стиснення відео. Це повсюдно - інтернет-відео, Blu-ray, телефони, камери безпеки, дрони, все. Зараз усі використовують H.264.

H.264 - чудова технологія. Це результат 30 + років роботи з однією єдиною метою: зменшити пропускну здатність, необхідну для передачі повноформатного відео.

Технічно це дуже цікаво. Ця публікація дасть змогу зрозуміти деякі деталі на високому рівні - я сподіваюся, не надто втомити вас із тонкощами. Також зауважте, що багато з описаних тут понять стосуються стиснення відео загалом, а не лише H.264.

Простий нестиснений відеофайл міститиме масив 2D-буферів, що містять піксельні дані для кожного кадру. Отже, це тривимірний (2 просторові розміри та 1 часовий) масив байтів. Для збереження кожного пікселя потрібно 3 байти - по одному байту для трьох основних кольорів (червоного, зеленого та синього).

1080p при 60 Гц = 1920x1080x60x3 =>

370 МБ/сек необроблених даних.

З цим практично неможливо боротися. Диск Blu-ray об'ємом 50 ГБ вміщує лише

2 хв. Ви не можете нікуди швидко перенести його. Навіть твердотільні накопичувачі мають проблеми зі скиданням цього прямо з оперативної пам'яті на диск [^ 1].

Так що так. Нам потрібна компресія.

Так, я відповім на це. Але спочатку дозвольте мені щось вам показати. Ось домашня сторінка Apple:

Я захопив екран цієї домашньої сторінки і створив два файли:

Ех Що? Ці розміри файлів виглядають зміненими.

Ні, вони мають рацію. Відео H.264 довжиною 300 кадрів - 175 КБ. Один кадр цього відео у форматі PNG становить 1015 КБ.

Схоже, ми зберігаємо у відео у 300 разів більше даних. Але розмір файлу становить п’яту частину. Отже, H.264 здається в 1500 разів ефективнішим, ніж PNG.

Як це взагалі можливо? Гаразд, у чому фокус?

Трюків дуже багато! H.264 використовує всі трюки, про які ви можете подумати (і тонни, про які ви не пам’ятаєте). Давайте розберемо важливі.

Проливна вага

Уявіть, що ви будуєте автомобіль для вуличних перегонів. Треба їхати швидше. Що перше, що ти робиш? Ви скинули трохи ваги. Ваша машина важить 3000 фунтів. Ви викидаєте непотрібні речі. Ті задні місця? pfft. Чак ті. Цей сабвуфер? Пропав. Для вас немає музики. Кондиціонер? Так, кинь. Спосіб передавання? Є. ні. Чекай! Нам це знадобиться.

Ви видаляєте все, крім важливих речей.

Ця концепція викидання бітів, що не потрібно для економії місця, називається з втратами стиснення. H.264 є кодеком з втратами - він викидає менш важливі біти і зберігає лише важливі біти.

PNG - це без втрат кодек. Це означає, що нічого не викидають. Біт за бітом, вихідне вихідне зображення можна відновити із зображення, кодованого PNG.

Важливі біти? Звідки алгоритм знає, які біти в моєму кадрі важливі?

Є кілька очевидних способів обрізати зображення. Можливо, верхній правий квадрант весь час марний. Тож, можливо, ми можемо обнулити ці пікселі та відкинути цей квадрант. Ми використали б лише 3/4 необхідного місця.

2200 фунтів зараз. Або, можливо, ми можемо вирізати товсту облямівку по краях кадру, важлива річ все одно посередині. Так, ви могли б це зробити. Але H.264 цього не робить.

H.264, як і інші алгоритми зображення із втратами, відкидає детальну інформацію. Ось крупним планом оригіналу в порівнянні із зображенням, що відкидається.

Подивіться, як на стиснутому не відображаються отвори в решітках динаміків у MacBook Pro? Якщо ви не збільшите масштаб, ви навіть помітите різницю. Зображення праворуч важить в 7% розмір оригіналу - і ми навіть не стискали зображення в традиційному розумінні. Уявіть, ваша машина важила всього 200 фунтів!

7% нічого собі! Як ви таким чином відкидаєте детальну інформацію?

Для цього нам потрібен швидкий урок математики.

Інформаційна ентропія

Тепер ми дістаємося до соковитих шматочків! Ха каламбури! Якщо ви брали уроки теорії інформації, ви, можливо, пам’ятаєте ентропію інформації. Ентропія інформації - це кількість бітів, необхідна для представлення певної інформації. Зверніть увагу, що це не просто розмір деякого набору даних. Це мінімальна кількість бітів, яка повинна бути використана для представлення всієї інформації, що міститься в наборі даних.

Наприклад, якщо ваш набір даних є результатом одного підкидання монети, вам потрібен 1 біт ентропії. Якщо у вас є два підкидання монет, вам знадобляться 2 біти. Має сенс?

Припустимо, у вас є якась дивна монета - ви її підкидали 10 разів, і кожен раз вона потрапляє на голови. Як би ви описали цю інформацію комусь? Ви б не сказали HHHHHHHHH. Ви просто сказали б "10 жеребів, усі голови" - бац! Ви щойно стиснули деякі дані! Легко. Я врятував вам години лефтів. Очевидно, це надто спрощення, але ви перетворили деякі дані на інше коротше подання тієї самої інформації. Ви зменшили дані надмірність. Ентропія інформації в цьому наборі даних не змінилася - ви щойно перетворили між поданнями. Цей тип кодера називається кодер ентропії - це універсальний кодер без втрат, який працює для будь-якого типу даних.

Частотний домен

Тепер, коли ви розумієте ентропію інформації, перейдемо до перетворень даних. Ви можете представляти дані в деяких основних одиницях. Якщо ви використовуєте двійковий файл, у вас є 0 і 1. Якщо ви використовуєте шістнадцяткове значення, у вас 16 символів. Ви можете легко перетворюватися між двома системами. Вони по суті еквівалентні. Все йде нормально? Гаразд!

Тепер трохи фантазії! Уявіть, що ви можете перетворити будь-який набір даних, який змінюється залежно від простору (або часу) - щось на зразок значення яскравості зображення, в інший координатний простір. Отже, замість координат x-y, припустимо, у нас є координати частоти. freqX і freqY зараз є осями. Це називається a частотна область представництво. Існує ще одна химерна математична теорема [^ 2], яка стверджує, що ви можете зробити це для будь-яких даних, і ви можете досягти ідеального перетворення без втрат, поки freqX і freqY досить високі.

Гаразд, але які частоти - це freqX та freqY?

freqX і freqY - це якийсь інший набір базових одиниць. Так само, як коли ми переходимо з двійкового на шістнадцятковий, у нас є інша фундаментальна одиниця, ми переходимо зі звичного X-Y на freqX і freqY. Шістнадцяткове значення "А" виглядає інакше, ніж двійкове "1010". Обидва означають одне і те ж, але дивись інший. Отже, як виглядає наше зображення в частотній області:

Тонкий гриль на цьому MacBook pro має високий інформаційний вміст у високочастотних компонентах цього зображення. Дрібно різний вміст = високочастотні компоненти. Будь-які поступові зміни кольору та яскравості, такі як градієнти, є низькочастотними компонентами цього зображення. Все, що між ними, потрапляє між ними. Тож дрібні деталі = висока частота. Пологі градієнти = низька частота. Має сенс?

У поданні в частотній області низькочастотні компоненти знаходяться поблизу центру цього зображення. Вищі частотні компоненти спрямовані до країв зображення.

Добре. Звичайно, це має сенс. Але навіщо це все робити?

Оскільки зараз ви можете зробити це зображення в частотному домені, а потім замаскувати краї - відкинути інформацію, яка буде містити інформацію з високочастотними компонентами. Тепер, якщо перетворити назад на звичайні координати x-y, ви виявите, що отримане зображення схоже на оригінал, але втратило деякі дрібні деталі. Але зараз зображення займає лише частину простору. Контролюючи, наскільки велика ваша маска, тепер ви можете точно налаштувати, наскільки детально ви хочете, щоб були виведені вихідні зображення.

Ось крупний план ноутбука на домашній сторінці знову. За винятком зараз, застосовується кругова маска з межею.

Цифри представляють інформаційну ентропію цього зображення як частку оригіналу. Навіть на рівні 2% ви не помітите різниці, якщо не перебуваєте на такому рівні масштабування. 2%! - ваша машина зараз важить 60 фунтів!

Отож, як ти скинув вагу. Цей процес при стисненні з втратами називається квантування[^ 3].

Добре. Вражаю, мабуть. Що ще у вас є?

Підвибірка кольоровості.

Система мозку людини/ока не дуже добре вирішує тонкі деталі в кольорі. Він може дуже легко виявити незначні зміни яскравості, але не кольору. Тож повинен бути якийсь спосіб відкинути кольорову інформацію, щоб скинути ще більше ваги.

У телевізійному сигналі дані кольорів R + G + B трансформуються у Y + Cb + Cr. Y - це яскравість (по суті чорно-біла яскравість), а Cb і Cr - кольоровість (колір). RGB та YCbCr еквівалентні з точки зору інформаційної ентропії.

Чому без потреби ускладнювати? RGB недостатньо хороший для вас?

Ще до того, як ми мали кольоровий телевізор, у нас був лише сигнал Y. І коли кольорові телевізори тільки почали з’являтися, інженерам довелося з’ясувати спосіб передачі кольорів RGB разом з Y. Замість того, щоб використовувати два окремі потоки даних, вони розумно вирішили закодувати кольорову інформацію в Cb та Cr і передати її разом із Y інформація. Таким чином, телевізори BW дивляться лише на Y-компонент. Окрім того, кольорові телевізори розглядатимуть компоненти кольоровості та внутрішньо перетворюватимуть на RGB.

Але перевірте фокус: компонент Y кодується з повною роздільною здатністю. Компоненти С лише з роздільною здатністю чверті. Оскільки око/мозок жахливо виявляє кольорові варіації, ви можете з цим уникнути. Роблячи це, ви зменшуєте загальну пропускну здатність на половину, з дуже малою візуальною різницею. Половину! Ваша машина зараз важить 30 фунтів!

Цей процес відкидання частини інформації про колір називається Підвибірка кольоровості[^ 4]. Хоча він не є специфічним для H.264 і існує вже десятки років, він використовується майже універсально.

Це великі вагові проливники для стиснення з втратами. Наші рамки тепер крихітні - оскільки ми відкинули більшість детальної інформації та половину кольорової інформації.

Чекай. Це воно? Чи можемо ми зробити щось більше?

Так. Зниження ваги - це лише перший крок. Поки ми розглядаємо просторові домени в межах одного кадру. Тепер настав час дослідити часове стиснення - де ми розглядаємо групу кадрів у часі.

Компенсація руху

H.264 - це стандарт стиснення з компенсацією руху.

Уявіть, що ви дивитесь тенісний матч. Камера закріплена під певним кутом. Єдине, що рухається, - м’яч вперед-назад. Як би ви закодували цю інформацію? Ти робиш те, що робиш завжди, правда? У вас є тривимірний масив пікселів, два виміри в просторі та один у часі. Правильно?

Ні Чому б ви? Більшість зображень і так однакові. Суд, мережа, натовп - все статично. Єдина реальна дія - це рух м’яча. Що, якби у вас було просто одне статичне зображення всього, що знаходиться у фоновому режимі, а потім одне рухоме зображення просто кулі? Чи не заощадить це багато місця? Розумієш, куди я з цим іду? Зрозумів? Бачите, куди я йду? Оцінка руху?

Кумедні жарти в сторону, це саме те, що робить H.264. H.264 розбиває зображення на макроблоки - зазвичай блоки розміром 16x16 пікселів, які він буде використовувати для оцінки руху. Він кодує одне статичне зображення - зазвичай називається I-обрамлення(Внутрішній кадр). Це повний кадр - містить усі біти, необхідні для побудови цього кадру. І тоді наступні кадри є або Р-кадри(передбачуваний) або B-кадри(двонаправлений прогноз). P-кадри - це кадри, які кодуватимуть вектор руху для кожного з макроблоків з попереднього кадру. Отже, P-кадр повинен бути побудований декодером на основі попередніх кадрів. Він починається з останнього I-кадру у відеопотоці, а потім проходить через кожний наступний кадр - додаючи дельти вектора руху, коли він рухається, поки не дійде до поточного кадру.

B-кадри ще цікавіші, коли передбачення відбувається двонаправлено, як з минулих кадрів, так і з майбутніх кадрів. Тож ви можете собі уявити, чому це домашнє відео від Apple так добре стискається. Тому що це насправді лише три I-кадри, в яких макроблоки переміщуються навколо.

Скажімо, ви відтворювали відео на YouTube. Ви пропустили останні кілька секунд діалогового вікна, тому перегляньте кілька секунд назад. Ви помічали, що він не миттєво починає відтворюватися за тим тимчасовим кодом, який ви щойно вибрали. Він робить паузу на кілька хвилин, а потім відтворюється. Ці кадри вже буферизовано з мережі, оскільки ви щойно його відтворювали, то чому ця пауза?

Так, це мене дратує. Чому це робить це?

Оскільки ви попросили декодер перейти до якогось довільного кадру, декодер повинен повторити всі обчислення - починаючи з найближчих I-кадрів і додаючи дельти вектора руху до кадру, на якому ви знаходитесь, - і це обчислювально дорого, а отже, і коротка пауза. Сподіваємось, вас зараз менше дратуватимуть, знаючи, що насправді ви робите важку роботу, а не просто сидите, щоб просто дратувати вас.

Оскільки ви кодуєте лише дельти векторів руху, цей прийом надзвичайно економічний для будь-якого відео з рухом, за рахунок деяких обчислень.

Тепер ми розглянули як просторове, так і часове стиснення! Поки що ми маємо шито місця, збереженого в квантуванні. Підвибірка кольоровості ще наполовину зменшила необхідний простір. Крім того, у нас є компенсація руху, яка зберігає лише 3 фактичні кадри для

300, що ми мали у цьому відео.

Мені це виглядає досить добре. Тепер що?

Тепер ми завершуємо та запечатуємо угоду. Ми використовуємо традиційний ентропійний кодер без втрат. Бо чому ні? Давайте просто ляпаємо це на добру міру.

Кодер ентропії

I-кадри після кроків з втратами містять надлишкову інформацію. Вектори руху для кожного з макроблоків у P та B-кадрах - це цілі групи з однаковими значеннями, оскільки кілька макроблоків рухаються на однакову величину, коли зображення прокручується у нашому тестовому відео.

Ентропійний кодер подбає про цю надмірність. І оскільки це кодер без втрат загального призначення, нам не потрібно турбуватися про те, які компроміси він робить. Ми можемо відновити всі дані, що надходять.

І ми закінчили! В основі цього - ось як працюють кодеки стиснення відео, такі як H.264. Це його фокуси.

ОК здорово! Але мені цікаво дізнатись, скільки зараз важить наш автомобіль.

Оригінальне відео було знято з непарною роздільною здатністю 1232x1154. Якщо ми застосуємо тут математику, то отримаємо:

5 секунд при 60 кадрів в секунду = 1232x1154x60x3x5 => 1,2 ГБ
Стиснене відео => 175 КБ

Якщо ми застосуємо те саме співвідношення до нашого автомобіля вагою 3000 фунтів, ми отримаємо 0,4 фунта як кінцева вага. 6,5 унцій!

Ага. Це магія!

Очевидно, що я масово спрощую кілька десятиліть напружених досліджень у цій галузі. Якщо ви хочете дізнатись більше, Сторінка Вікіпедії є досить описовою.

Є коментарі? Я щось помилився? Не любитель кульгавих жартів? Ображений на лайку? Використовуйте HackerNews або Reddit за озвучення вашої думки!