Коли ми натискаємо «Play» на YouTube, відкриваємо серіал на Netflix чи запускаємо випадковий відеофайл у себе на ноутбуці, за лаштунками розгортається складна інженерна операція. Значну частину цієї роботи виконують два проєкти з відкритим кодом, які більшість користувачів ніколи не бачила й не встановлювала свідомо: FFmpeg та VLC.
У розмові на подкасті Lex Fridman Podcast участь беруть Жан-Батіст Кемпф, лід-розробник VLC і президент організації VideoLAN, та Кіран Кунья, багаторічний контриб’ютор FFmpeg і людина, яка веде офіційний акаунт FFmpeg в X. Їхній досвід дозволяє поглянути на сучасну відеоекосистему зсередини — від сирих байтів до пікселів на екрані — і зрозуміти, чому саме відкритий код фактично тримає на собі більшість відеоінтернету.
FFmpeg: невидима інфраструктура YouTube, Netflix, Chrome і Firefox
У технічних колах FFmpeg часто називають «швейцарським ножем» для роботи з відео та аудіо. Але це визначення навіть применшує його роль. Сьогодні FFmpeg лежить в основі більшості відеопроцесів як онлайн, так і офлайн.
Оцінки свідчать: понад 90% усіх відеопроцесинг‑воркфлоу у світі так чи інакше використовують FFmpeg. Йдеться не лише про ентузіастів, які конвертують файли в терміналі. FFmpeg працює в бекендах гігантів на кшталт YouTube і Netflix, вбудований у браузери Chrome та Firefox, використовується в численних відеоплатформах, редакторах, стримінгових сервісах, системах відеоспостереження й корпоративних медіасерверах.
Ключова причина — універсальність і гнучкість. FFmpeg вміє:
- читати потоки байтів із найрізноманітніших джерел — від локальних файлів і HTTP‑стримів до DVD;
- розбирати контейнери (MP4, MKV, MOV, AVI та десятки інших);
- декодувати й кодувати величезну кількість відео‑ та аудіокодеків;
- працювати як у режимі командного рядка, так і як бібліотека, вбудована в інші застосунки.
У типовому сценарії платформа отримує відео від користувача, проганяє його через FFmpeg, щоб:
- розпакувати вихідний контейнер;
- декодувати відео та аудіо;
- перекодувати в потрібні формати й бітрейти;
- зібрати все назад у стандартизований контейнер для стримінгу.
Ці операції повторюються мільярди разів щодня, і майже завжди в ланцюжку присутній FFmpeg — навіть якщо кінцевий користувач ніколи про нього не чув.
VLC: універсальний програвач, який є майже всюди
Якщо FFmpeg — це «двигун» відеоінфраструктури, то VLC — її наймасовіший «інтерфейс» до користувача. VLC Media Player, флагманський проєкт VideoLAN, став де-факто універсальним медіапрогравачем.
За роки існування VLC було завантажено щонайменше 6,5 мільярда разів. Реальна цифра, ймовірно, значно вища: VLC постачається в складі дистрибутивів, репаків, корпоративних збірок, і відстежити всі канали розповсюдження неможливо. Але вже самі 6,5 мільярда завантажень роблять його одним із найширше розгорнутих медіапрогравачів в історії.
Його статус «універсального» не випадковий. VLC підтримує практично будь-який медіаформат на практично будь-якій операційній системі. Користувачеві не потрібно думати, що таке контейнер, який саме кодек усередині, чи є потрібні системні кодеки в ОС. VLC просто відкриває файл — чи це MP4, MKV, старий AVI, MOV, чи щось екзотичніше — і намагається відтворити його, покладаючись на власний стек декодерів.
Ця незалежність від системних компонентів і широка підтримка форматів зробили VLC стандартним «рятівником» у ситуаціях, коли інші плеєри безпорадно виводять помилку «формат не підтримується». Для мільярдів користувачів VLC став синонімом надійного відтворення будь-якого відео.
Що насправді відбувається, коли ви натискаєте «Play»
За простим жестом — натиснути «Play» — ховається багатоступеневий конвеєр, у якому FFmpeg і VLC часто працюють у тандемі. Цей шлях можна описати як послідовність перетворень від «адреси» до «пікселів і звуку».
Спочатку програвач отримує доступ до джерела даних. Це може бути локальний файл, HTTP‑посилання, DVD чи інший носій. Операційна система повертає потік байтів — суцільний масив даних без розуміння, де в ньому відео, де аудіо, де субтитри.
Далі в гру вступає контейнерний рівень. Контейнер — це те, що більшість користувачів називає «форматом файлу»: MP4, MKV, AVI, MOV. Усередині контейнера зберігаються окремі «доріжки» — відео, аудіо, субтитри, метадані. Завдання демультиплексора (demuxer) — розрізати суцільний потік байтів на ці доріжки й виділити окремі стиснені кадри відео та аудіофрейми.
На цьому етапі важливо не плутати контейнер і кодек. MP4 — це контейнер, H.264 — кодек. Той самий H.264 може бути всередині MP4, MKV чи MOV, а MP4 може містити різні відеокодеки й аудіокодеки. У реальному світі ситуація ще хаотичніша: файли часто мають «неправильні» розширення, а вміст не відповідає очікуванням. Тому VLC та FFmpeg не довіряють самому розширенню файлу — вони аналізують вміст, щоб зрозуміти, що саме всередині.
Після демультиплексування програвач має окремі потоки стисненого відео й аудіо. Наступне питання: хто буде декодувати відео — GPU чи CPU? Сучасні користувачі звикли до думки, що графічний процесор «прискорює» відео, але реальність складніша. Близько 45% відеофайлів не можуть бути декодовані на GPU й змушені повертатися до програмного декодування на CPU.
Причин кілька: варіанти кодека, які не підтримуються апаратно; відмінності між виробниками GPU; специфічні профілі чи параметри кодування. Тому плеєр спочатку аналізує стиснені кадри, щоб визначити, чи сумісні вони з апаратним декодером. Якщо так — дані передаються в «чорну скриньку» GPU. Якщо ні — увесь тягар лягає на програмний декодер, де й починається справжня математика.
Від стиснених бітів до зображення: як працює декодування
Програмне декодування — це процес, у якому складні теоретичні ідеї з теорії інформації, обробки сигналів і психофізіології зору перетворюються на практичний код, написаний переважно на C та асемблері.
Перший крок — зняти «математичну обгортку» з бітового потоку. Стиснені відеодані проходять через ентропійне кодування — методи на кшталт кодування Гаффмана чи арифметичного кодування. Вони не втрачають інформацію, а лише представляють її компактніше, використовуючи коротші коди для частіших символів і довші — для рідкісних. На етапі декодування це потрібно розгорнути назад, щоб отримати набір синтаксичних елементів — чисел і прапорців, які описують, як відновити кадр.
Далі вступає в дію просторове передбачення. У відео є так звані внутрішньокадрові (intra) кадри, або I‑фрейми. Їх можна уявити як окремі зображення, закодовані без посилань на інші кадри. Кодек намагається передбачити вміст кожного блоку зображення, використовуючи сусідні пікселі, а різницю між передбаченням і реальністю зберігає як «залишок» (residual).
Цей залишок зберігається не в піксельному (просторовому) вигляді, а в частотному. Для цього застосовуються блокові перетворення — найчастіше дискретне косинусне перетворення (DCT) або його варіанти. Зображення ділиться на блоки, кожен блок переводиться в частотну область, де високочастотні компоненти (дрібні деталі, шум) можна агресивніше «обрізати» через квантування.
Саме квантування — свідоме грубе округлення коефіцієнтів — робить відеокодек «втратним» на відміну від ZIP‑архівів. ZIP прагне відновити дані біт‑у‑біт, відеокодек навмисно викидає частину інформації, спираючись на те, що людське око її майже не помітить.
Після декодування ентропійного шару, зчитування синтаксису, відновлення залишків у частотній області й зворотного перетворення назад у просторову область, кодек додає ці залишки до передбаченого зображення. Результат — відновлений кадр, максимально наближений до оригіналу, але вже після сильного стиснення.
Те, що користувач іноді бачить як «квадратики» чи «блоки» на зіпсованому відео, — прямий наслідок блокової природи перетворень. Якщо бітовий потік пошкоджений або квантування надто агресивне, артефакти проявляються саме на межах блоків.
Інша ключова складова — часовий вимір. Сучасні відеокодеки максимально використовують тимчасову надлишковість: між сусідніми кадрами часто змінюється лише невелика частина зображення. Тому більшість кадрів у потоці — не I‑фрейми, а передбачувані кадри, які посилаються на попередні (і іноді наступні) кадри, зберігаючи лише різницю. Це ще один рівень складності, але й головне джерело економії бітрейту.
Як людське око диктує правила гри
Щоб зрозуміти, чому відео стискається настільки сильно, потрібно подивитися на масштаби. Перехід від сирого відео до стисненого потоку зазвичай дає виграш у 100–200 разів за розміром. Для аудіо перехід від сирого сигналу до MP3 — приблизно 10‑разове зменшення. Відео вимагає набагато агресивнішого стиснення, інакше зберігати й передавати сучасні роздільні здатності та частоти кадрів було б просто нереально.
Це можливо лише тому, що всі сучасні кодеки — і відео, і аудіо — побудовані навколо людського сприйняття. Вони не намагаються зберегти «математичну» точність сигналу, а оптимізують якість для очей і вух.
У відео це починається з переходу від RGB до YUV. Звичний для розробників і дизайнерів простір RGB (червоний, зелений, синій) зручний для відображення, але не оптимальний для стиснення. YUV розділяє зображення на яскравість (Y, лума) і два канали кольору (U та V, хрома). Це відповідає будові ока: одні рецептори (палички) чутливіші до яскравості, інші (колбочки) — до кольору.
Цим можна скористатися. У більшості відеоформатів роздільна здатність кольорових каналів зменшується відносно яскравості — так звана субдискретизація хроми (наприклад, 4:2:0). Фактично це означає, що інформації про колір у кадрі вдвічі менше, ніж про яскравість, але для більшості глядачів різниця майже непомітна. Уже тільки це дає економію близько 50% даних без видимого погіршення якості.
Далі вступають у гру складніші моделі: які частоти зображення око помічає гірше, як воно реагує на шум, які деталі важливіші для сприйняття. На основі цих знань кодеки вирішують, які коефіцієнти в частотній області можна обрізати сильніше, а які потрібно зберегти точніше.
Тут важливо розуміти принципову відмінність від архіваторів на кшталт ZIP. У ZIP дані на вході й виході мають бути ідентичними. У відеокодеках мета інша: отримати сигнал, який для людини виглядає «таким самим» або майже таким самим, навіть якщо математично він суттєво відрізняється. Це завжди баланс між ступенем деградації й тим, наскільки ця деградація помітна.
Ціна ефективності: чому нові кодеки такі «важкі» для процесора
Індустрія відеокодеків розвивається еволюційно. Кожне нове покоління — від MPEG‑2 до H.264, від H.264 до H.265/HEVC, від HEVC до AV1 та далі — зазвичай приносить приблизно 30% економії бітрейту для тієї самої візуальної якості.
Ці 30% здаються скромною цифрою, але в масштабах глобального відеотрафіку це колосальна економія пропускної здатності, дискового простору й грошей. Проте за цю економію доводиться платити обчислювальною складністю.
Щоб досягти додаткових 30% ефективності, кодувальник має перебрати набагато більше варіантів передбачення, блокових розбиттів, векторів руху, параметрів квантування. На практиці це означає, що потрібна потужність CPU для кодування зростає на порядок, а іноді й на два порядки.
Відеокомпресія за своєю природою асиметрична. Кодування — надзвичайно важкий процес, який може тривати в десятки чи сотні разів довше, ніж тривалість самого відео, особливо якщо йдеться про офлайн‑енкодинг для VoD‑бібліотек. Декодування ж має бути відносно легким: пристрій користувача повинен встигати відтворювати потік у реальному часі, часто на мобільному чипі з обмеженим енергоспоживанням.
Ця асиметрія визначає архітектуру всієї екосистеми. У датацентрах можна дозволити собі величезні обчислювальні кластери для кодування, але на боці клієнта потрібні максимально оптимізовані декодери. Саме тому низькорівнева оптимізація — ручний асемблер, SIMD‑інструкції, тонке налаштування кешу — залишається критично важливою. І саме тут відкриті проєкти на кшталт FFmpeg і VLC відіграють ключову роль, акумулюючи роки роботи тисяч інженерів у спільному коді.
Контейнери проти кодеків: чому реальний світ завжди брудніший за специфікації
Ще одна зона, де FFmpeg і VLC фактично стандартизують хаос, — це взаємодія з контейнерами. Формально все виглядає просто: є контейнер (MP4, MKV, AVI, MOV), є кодеки всередині (H.264, AAC тощо), є чіткі специфікації. На практиці ж реальний світ медіафайлів — це суміш історичних артефактів, напівправильних реалізацій і креативних інтерпретацій стандартів.
MP4, наприклад, часто сприймається як синонім H.264‑відео з AAC‑аудіо. І справді, у 99% випадків саме так і є. Але MP4 як специфікація набагато ширша: вона може містити різні відеокодеки, кілька аудіодоріжок, субтитри, метадані. Те саме стосується MKV (Matroska), який спочатку створювався як більш гнучкий і «фічерний» контейнер для спільноти.
До цього додаються історичні формати на кшталт AVI від Microsoft чи MOV від Apple, які еволюціонували разом із кодеками. У результаті користувачі, а часто й розробники, плутають «MP4» як контейнер із «MPEG‑4» як сім’єю стандартів, де є й аудіокодеки, і кілька відеокодеків, один із яких відомий як H.264 або AVC.
Для VLC та FFmpeg це означає одне: не можна довіряти ні розширенню файлу, ні навіть задекларованому формату. Потрібно аналізувати вміст, «продивлятися» структуру контейнера, виявляти, які саме кодеки всередині, і вже потім підбирати відповідні декодери. Саме ця здатність працювати з «брудними» реальними файлами, а не лише з ідеальними прикладами зі специфікацій, і робить відкриті інструменти незамінними.
Відкритий код як фундамент відеоекосистеми
І VLC, і FFmpeg — проєкти з відкритим кодом, які розвиваються десятиліттями завдяки внеску тисяч розробників. Жан-Батіст Кемпф як лід-розробник VLC і президент VideoLAN координує розвиток одного з наймасовіших медіапрогравачів у світі. Кіран Кунья як давній контриб’ютор FFmpeg і публічне обличчя проєкту в X допомагає формувати технічний і суспільний дискурс навколо відеокодеків.
Їхня робота — і робота спільнот навколо цих проєктів — рідко потрапляє в заголовки новин, але без неї сучасний відеоінтернет виглядав би зовсім інакше. Від того, як саме реалізовано ентропійне декодування, до того, як плеєр поводиться з «кривими» файлами, залежить, чи зможе користувач без проблем подивитися відео, чи зіткнеться з помилками й артефактами.
У кожному реченні технічного опису — «демультиплексор відокремлює доріжки», «декодер виконує зворотне перетворення», «GPU бере на себе частину навантаження» — ховаються роки досліджень, тисячі рядків коду й безліч компромісів між якістю, швидкістю, сумісністю та ліцензійними обмеженнями. Відкритий код дозволяє цю складність розділити між багатьма гравцями, замість того щоб кожна компанія будувала власний закритий стек із нуля.
Висновок: відеоінтернет тримається на невидимих «двигунах»
Сучасний користувач звик до того, що відео «просто працює» — у браузері, у застосунку, на телевізорі, у плеєрі на ноутбуці. Але за цією видимою простотою стоїть складна екосистема, де відкриті проєкти на кшталт FFmpeg і VLC виконують роль фундаменту.
FFmpeg забезпечує більшу частину відеопроцесингу в інтернеті й поза ним, від YouTube і Netflix до Chrome та Firefox. VLC, із щонайменше 6,5 мільярдами завантажень і підтримкою практично будь-якого формату на будь-якій ОС, став універсальним інструментом відтворення для мільярдів людей.
Разом вони демонструють, як глибоко відкритий код вкорінений у повсякденні технології — навіть тоді, коли користувачі ніколи не бачать його напряму. І щоразу, коли ми натискаємо «Play», саме ці невидимі «двигуни» запускають складний ланцюг перетворень, який перетворює сирі байти на знайоме зображення й звук.
Джерело
How video compression works – VLC lead developer explains | Lex Fridman Podcast