AV1: кодек, що важливий навіть якщо ви ніколи не стрімите

October 19, 2025 • February 3, 2026 • Читання: 5 хв • Views: 0

Було корисно?

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

Це проблема кодека — незалежно від того, чи ви керуєте стрімінговою платформою. AV1 — це не просто приємніший спосіб дивитися відео; це важіль, що змінює вихідні витрати,
слід від збереження, архітектуру конвеєра й шаблони інцидентів. Якщо ви керуєте production‑системами, AV1 вас зачепить. Можливо — під час святкового замороження.

Чому AV1 важливий поза стрімінгом

Більшість організацій не «стрімить». Вони «мають відео». Служба підтримки приймає записи екрана. Маркетинг викладає демо продукту. HR розсилає тренінги.
Безпека зберігає відеонагляд. DevRel публікує вебінари. Продажі надсилають персоналізовані кліпи. І будь‑який внутрішній інструмент, що приймає контент від користувачів,
стає відеоплатформою, коли хтось розуміє, що текстові поля необов’язкові.

Кодеки тихо вирішують форму цього безладу:

Зростання об’єктного сховища: відео домінує в байтах. Різниця 20–40% за розміром — це різниця між «нудним рахунком» і «чому цей бак як іпотека?»
Витрати на egress і CDN: навіть «не‑стрімінгові» додатки доставляють медіа в браузери, мобільні клієнти й партнерські API.
Бюджети на обчислення: час кодування, витяг ескізів, перевірки якості та «на всякий випадок» транскоди стоять на CPU/GPU як недоплачена оренда.
Затримка й UX: вибір кодека змінює час старту, переривання буферизації й розряд батареї — а потім змінюється і черга підтримки.
Безпека та відповідність: конвеєри транскодування створюють нові копії даних, нову складність зберігання й нові точки відмов (особливо в регульованих середовищах).

Заголовок AV1 — «краща компресія». Операційний підсумок: AV1 переміщує витрати з мережі/зберігання на обчислення й управління сумісністю.
Якщо ви плануєте цю зміну — ви виграєте. Якщо натрапите на неї випадково — отримаєте інцидент із першим у житті словом «кодек».

Цікаві факти та історичний контекст

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

AV1 створила Alliance for Open Media (AOMedia), консорціум, що утворився 2015 року задля просування екосистеми без роялті.
Корені AV1 включають VP9 від Google та елементи інших дослідницьких кодеків; це скоріше стратегічне злиття, ніж чисте нововведення.
Бітстріми AV1 завершилися в 2018 році, але широке апаратне декодування зайняло роки — програмне забезпечення може вийти швидко; кремній йде за календарем.
Netflix і YouTube були ранніми рушіями AV1, бо вони відчувають вигоди компресії як реальні гроші: менше переданих даних, менше пропусків кешу, менше заторів останньої милі.
AV1 використовується не тільки для відео, а й для реального часу (наприклад WebRTC), де ефективність бітрейту конкурує з затримкою й CPU.
AVIF (AV1 Image File Format) використовує внутрішнє кодування AV1 для зображень, тож «прийняття AV1» часто пробирається через пайплайни зображень першими.
Апаратне декодування прискорилося з новими GPU і мобільними SoC; довгий хвіст старих пристроїв все ще диктує стратегії відкату.
HEVC (H.265) і VVC (H.266) теж дають сильну компресію, але складність ліцензування й невизначеність сформували наратив AV1 як «за замовчуванням майбутнього».
Швидкість кодування значно покращилася завдяки енкодерам типу SVT-AV1 і rav1e; ранні твердження «AV1 непридатний через повільність» втратили силу, але не повсюдно.

Що таке AV1 (і чого він не є)

AV1 в одному реченні

AV1 — сучасний відеокодек, створений для зменшення бітрейту при заданій якості, особливо на низьких‑середніх бітрейтах, із сильним акцентом на безроялті‑прийняття.

Про що інженерам варто дбати

Ефективність бітрейту: часто можна доставити схожу суб’єктивну якість при нижчому бітрейті проти AVC (H.264), іноді й проти HEVC залежно від контенту й налаштувань.
Торговельний простір CPU/GPU: декодування AV1 програмно може бути дорогим; кодування AV1 може бути дуже витратним, якщо не обрати розумні пресети або апаратне прискорення.
Сумісність: «працює всюди» досі більшість випадків — це H.264, особливо для старого заліза й вбудованих платформ.
Контейнери: AV1 зазвичай доставляється в MP4 (ISO BMFF) або Matroska/WebM. Ви зустрінете всі ці варіанти в реалі.

Чого AV1 не є

Не магічна купон‑знижка на пропускну здатність: економія залежить від контенту. Розмовні голови стискаються інакше, ніж конфеті‑гранати.
Не «безкоштовний» операційно: якщо ви вмикаєте AV1 без вимірів CPU — ви добровільно підписуєтесь на інцидент із перевантаженням потужностей.
Не заміна для інженерії доставки: градуювання, пакування, кешування й поведінка плеєра все одно мають значення.

Перефразована думка від Вернера Фогельса (CTO Amazon): «Усе ламається, весь час». Кодеки не виняток; вони просто ламаються креативніше.

Де AV1 перемагає в продакшені

1) Тиск на egress і CDN: тихий вбивця бюджету

Якщо ви платите за вихідні дані, ефективність бітрейту стає статтею бюджету, а не теоретичною метрикою. Навіть скромна економія на титулі кумулюється через каталог,
користувачів і час. AV1 допомагає, бо може забезпечити порівнянну якість при нижчому бітрейті, ніж H.264, особливо там, де H.264 починає виглядати як акварель.

Операційний виграш не лише в рахунку. Нижчий бітрейт може зменшити буферизацію на слабких мережах і пом’якшити пікові навантаження. Ваші графіки мережі стають менш піковими.
Ваш on‑call мозок краще спить.

2) Слід від зберігання: менше байтів — менше проблем

Зберігати менше байтів — це не тільки дешевше; це механічно простіше. Менші об’єкти швидше реплікуються. Реставрації завершуються швидше. Перехід по життєвому циклу
коштує менше. Часи відновлення покращуються. Якщо ви керуєте власним сховищем, менші робочі набори означають кращу поведінку кешу й менше таємничих «чому кластер гарячий?».

3) Краще якість при обмежених бітрейтах для «корпоративного відео»

Корпоративне відео часто дивляться через поганий Wi‑Fi в готелі через VPN, поки хтось ділиться екраном і собака вирішує гавкнути.
Ефективність AV1 на низьких бітрейтах може зробити ці умови менш жорсткими. Бізнес назве це «досвід працівника».
SRE назве це «менше заявок у підтримку».

4) AVIF підтягує екосистему

Навіть якщо ви ніколи не відправляєте AV1‑відео, AVIF може з’явитися у вашому пайплайні оптимізації зображень, бо він може перевершити JPEG/PNG/WebP для певного контенту.
Це приносить декодування AV1 у браузери та пристрої, і ваша платформа раптово матиме думку про підтримку кодека.

5) Тиск на стандартизацію в довгостроковій перспективі

На практиці екосистема сходиться: сучасні браузери підтримують AV1, основні CDN це розуміють, і апаратне декодування стає нормою в нових пристроях.
Це не означає «включайте відразу». Це означає, що питання за замовчуванням змінюється з «чому AV1?» на «де не AV1?»

Жарт 1: Якщо ви думаєте, що «рішення про кодек» не ваша робота, зачекайте, поки буферизується відео CEO на ключовому виступі. Вітаємо — тепер це ваша робота.

Де AV1 шкодить (реальні режими відмов)

Вартість кодування: рахунок приходить у CPU‑годинах

Кодування AV1 може бути дорогим. Не завжди, не назавжди, але достатньо, щоб поводитися з ним як з важким пакетним навантаженням:
ставте в чергу, обмежуйте, вимірюйте і припускайте, що хтось завантажить 4K 60fps «швидкий кліп».

Ключове операційне рішення — де ви витрачаєте обчислення:

Офлайн/пакетно: краще для каталогів, VOD, архівів і «обробити один раз, віддати багато разів».
Just‑in‑time: заманливо, але небезпечно. Ви переплавите флот у найневідповідніший момент.
З Апаратною підтримкою: чудово, коли доступно, але вводить планування і гетерогенність.

Вартість декодування: батарея й старе залізо

Декодування AV1 широко підтримується в сучасних браузерах і багатьох нових пристроях, але «широко» — не «універсально», а програмний декод може бути енергоємним.
Операційний симптом підступний: це не аварія, а підвищена відтік користувачів, негативні відгуки додатка або «відео гріється телефон» у зворотному зв’язку.

Пакування й сумісність: гострі краї

Доставка AV1 часто вимагає схеми: AV1 для здатних клієнтів, H.264 (а іноді й HEVC) як відкат. Це означає більше рендішенів, більше маніфестів
і більше місць, де невідповідність конфігурації може створити помилку відтворення. Найпоширеніша помилка — не сам кодек, а логіка переговорів.

Зрілість інструментів варіюється по шляху

FFmpeg сильний. Але не кожен «пакетний продукт для корпоративних медіа» обробляє AV1 так само чисто, як H.264.
Ви знайдете кути, де втрачається метадані, неправильно трактуються колірні простори або пайплайн припускає «відео = AVC».

Жарт 2: Нічого так не змушує цінувати H.264, як AV1‑джоб кодування, що закінчується відразу після наради, для якої його й готували.

Три міні‑історії з корпоративного фронту

Міні‑історія 1: Інцидент через неправильне припущення

Середня SaaS‑компанія додала «відео‑відповіді» в тікети підтримки. Функція була проста: записати кліп у браузері, завантажити, транскодувати й відтворити в тікеті.
Команда обрала AV1 за економію сховища й майбутнє. Припущення було чистим і заспокійливим:
«Браузери вже підтримують AV1, тож відтворення буде ок.»

Роллаута пройшла гладко в внутрішньому тестуванні. Більшість співробітників користувалися сучасними ноутбуками з оновленим Chrome. Потім це вдарило в реальний світ:
корпоративні клієнти з заблокованими Windows‑збірками, старим залізом і Citrix‑сесіями, що вже були алергічні до відео.
Відтворення не падало красиво; воно переходило на програмний декод і підлагувало, як модем на татуському бездротовому зв’язку.

Запити в підтримку зросли. Функцію «відео‑відповідь» звинуватили у «гальмуванні» по всьому додатку, бо вона навантажувала CPU у клієнта.
Тим часом бекенд‑метрики були в нормі. SRE на виклику вивчив класичний урок: ви не можете дебагнути пожежу CPU на клієнті сервісними метриками.

Виправлення не було героїчним. Вони реалізували реальну перевірку можливостей (не вгадування по user‑agent), випустили H.264‑відкат і перестали авто‑програвати AV1 на обмежених клієнтах.
Постмортем інциденту мав єдиний дієвий рядок: ніколи не припускайте підтримку декоду лише на основі «статистики останніх браузерів»; вимірюйте її у вашій популяції.

Міні‑історія 2: Оптимізація, що відгукнулася боком

Внутрішня платформа обробки медіа запускала нічні джоби для транскоду записаних тренінгів. Хтось помітив, що CPU‑кластер простоює вдень.
Ідея: перенести транскодування в «just‑in‑time», коли користувач натискає play, щоб кодувати лише те, що дивляться. Менше даремних обчислень, ефективніше використання.
Звучало як плюс на слайді.

Насправді, перший тиждень нового кварталу включав онбординг. Тисячі співробітників натиснули «play» майже одночасно.
JIT‑пайплайн поставив у чергу AV1‑енкоди саме в той момент, коли система потребувала низької затримки. CPU підскочив, черги роздулися,
і плеєр чекав на кодування. Користувачі натискали оновити. Це створило більше запитів. Класичний thundering herd, тепер з відео.

Щоб погіршити ситуацію, пресети енкодера налаштували на компресію, а не на швидкість, бо «воно ж ночами працює».
AV1‑кодування радо з’їдало всі ядра і ще просило. Автоскейлер реагував як задумано, але потужності відставали від попиту. Результат не був повним відключенням;
це була повільна катастрофа: таймаути, часткове відтворення, гнівні відгуки під час онбордингу.

Відкатом стало попереднє кодування популярного контенту й збереження JIT лише для рідкісних випадків, з жорсткими лімітаціями та швидшими пресетами.
Урок: перенесення роботи в шлях запиту — це не оптимізація; це ставка. Якщо робите таку ставку — оцініть її як ставку: навантажувальні тести, admission control і ізоляція черг.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Команда безпеки зберігала відеоспостереження і час від часу потребувала «кліпи для інцидентів» для розслідувань. Вони мігрували рівні сховищ і хотіли кращої компресії.
AV1 виглядав привабливо. Менеджер інженерії зробив найменш захопливу річ: наполіг на маленькому пілоті,
матриці сумісності і строгій валідації після транскоду (тривалість, толерантність по кількості кадрів, наявність аудіо і тест декоду).

Під час пілоту підмножина камер виробляла відео з дивною поведінкою таймштампів. AV1‑файли були валідними, але метадані контейнера спричиняли баг у плеєрі інструменту для розслідувань.
Без валідації це дійшло б у продакшен як «випадкові кліпи не відтворюються», найгірший тип бага: переривчастий, невідтворюваний, що звинувачує користувачів.

Оскільки валідація була обов’язковою, пайплайн одразу помітив неправильні виходи й карантинізував їх. Команда зберегла оригінальний H.264 як відкат
і прикріпила діагностичні артефакти. Коли вендор просив зразки — вони були. Коли аудитори питали про цілісність доказів — був документований слід.

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

Практичні завдання: команди, виводи та рішення

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

Завдання 1: Швидко визначити кодек і контейнер

cr0x@server:~$ ffprobe -hide_banner -i sample.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'sample.mp4':
  Metadata:
    major_brand     : isom
  Duration: 00:00:20.04, start: 0.000000, bitrate: 1850 kb/s
  Stream #0:0(und): Video: av1 (av01 / 0x31307661), yuv420p10le, 1920x1080, 29.97 fps, 1720 kb/s
  Stream #0:1(und): Audio: opus (Opus / 0x7375704F), 48000 Hz, stereo, 96 kb/s

Що це означає: Це AV1‑відео в MP4 з Opus‑аудіо. Зверніть увагу на 10‑біт (yuv420p10le).

Рішення: Перевірте, чи ваші цільові платформи вміють декодувати AV1 і працювати з 10‑бітним відео. Якщо ні — кодуйте 8‑бітний відкат (yuv420p) або забезпечте H.264.

Завдання 2: Перевірити апаратне декодування на Linux

cr0x@server:~$ vainfo
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
vainfo: VA-API version: 1.20 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver 23.4.1
vainfo: Supported profile and entrypoints
      VAProfileAV1Profile0            : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointVLD

Що це означає: GPU підтримує декодування AV1 (VLD) через VA‑API.

Рішення: На цьому хості кроки декодування/транскодування можна віддати на GPU. Розгляньте планування GPU для сервісів з великою вагою декодування.

Завдання 3: Підтвердити можливості NVIDIA (NVDEC/NVENC)

cr0x@server:~$ nvidia-smi --query-gpu=name,driver_version --format=csv
name, driver_version
NVIDIA L4, 550.54.14

Що це означає: Маєте NVIDIA GPU; модель важлива для підтримки AV1‑кодування.

Рішення: Якщо плануєте апаратне кодування AV1, підтвердьте, що NVENC підтримує AV1 на цій SKU до виділення потужностей.

Завдання 4: Виміряти, чи клієнт декодує програмно (симптом високого CPU)

cr0x@server:~$ mpv --hwdec=auto --vo=gpu sample.mp4
 (+) Video --vid=1 (*) (av1 1920x1080 29.970fps)
 (+) Audio --aid=1 (*) (opus 48000Hz stereo)
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p10le
Using hardware decoding (vaapi).

Що це означає: mpv повідомляє про апаратне декодування через VA‑API. Якби було «Using software decoding», вартість CPU різко зросла б.

Рішення: Якщо на цільових машинах використовують програмний декод, надсилайте відкат H.264 або знижуйте складність (8‑біт, нижча роздільна здатність) для цих клієнтів.

Завдання 5: Закодувати AV1 зі SVT‑AV1 (бенчмарк швидкості/якості)

cr0x@server:~$ ffmpeg -y -i input.mp4 -c:v libsvtav1 -preset 8 -crf 34 -g 240 -pix_fmt yuv420p -c:a copy output_av1.mkv
... 
frame=  600 fps= 52 q=34.0 Lsize=    10.8MiB time=00:00:20.01 bitrate=4422.3kbits/s speed=1.74x
video:10.1MiB audio:0.6MiB subtitle:0.0MiB other streams:0.0MiB global headers:0.0MiB muxing overhead: 1.6%

Що це означає: Кодування швидше за реальний час (1.74x) з помірним пресетом. Вихід — MKV, AV1‑відео, аудіо скопійовано.

Рішення: Якщо швидкість < 1.0x на продакшен‑контенті — підніміть номер пресету (швидше) або знизьте цілі складності. Якщо бітрейт надто високий — підкорегуйте CRF або обережно застосуйте налаштування для зерна фільму.

Завдання 6: Закодувати H.264‑відкат з передбачуваною сумісністю

cr0x@server:~$ ffmpeg -y -i input.mp4 -c:v libx264 -preset veryfast -crf 23 -pix_fmt yuv420p -movflags +faststart -c:a aac -b:a 128k output_h264.mp4
...
frame=  600 fps=220 q=-1.0 Lsize=    17.2MiB time=00:00:20.01 bitrate=7040.4kbits/s speed=7.33x

Що це означає: H.264‑відкат кодується швидко і відтворюється практично всюди.

Рішення: Тримайте це як «мінімальне» рендерування для сумісності, особливо для корпоративних десктопів, вбудованих браузерів і старих мобільних пристроїв.

Завдання 7: Порівняти об’єктивну якість (PSNR/SSIM) для перевірки

cr0x@server:~$ ffmpeg -i input.mp4 -i output_av1.mkv -lavfi "[0:v][1:v]ssim;[0:v][1:v]psnr" -f null -
...
[Parsed_ssim_0 @ 0x55c1c2c8d700] SSIM Y:0.963421 (14.35) U:0.987210 (18.92) V:0.989003 (19.59) All:0.971085 (15.41)
[Parsed_psnr_1 @ 0x55c1c2c8f100] PSNR y:39.12 u:43.88 v:44.01 average:40.24 min:35.66 max:44.90

Що це означає: Об’єктивні метрики вказують, що AV1‑енкод близький до джерела. Не ідеально, але пристойно.

Рішення: Використовуйте метрики для виявлення грубих регресій між пресетами, а не для оголошення перемоги. Якщо SSIM падає на рухливому контенті — підправте пресет/CRF або додайте вищу позицію у градуюванні.

Завдання 8: Виявити інтервал ключових кадрів і структуру GOP (стабільність стрімінгу)

cr0x@server:~$ ffprobe -select_streams v:0 -show_frames -show_entries frame=pict_type,key_frame,best_effort_timestamp_time -of csv=p=0 output_av1.mkv | head
1,I,0.000000
0,P,0.033367
0,P,0.066733
0,P,0.100100
0,P,0.133467

Що це означає: Перший кадр — ключовий (I). Наступні — передбачувані. Можна просканувати I‑кадри, щоб підтвердити проміжки.

Рішення: Якщо ви орієнтуєтесь на HLS/DASH — вирівняйте інтервали ключ‑фреймів під тривалість сегмента (наприклад, 2s або 4s). Невирівняння викликає неефективне сегментування і погане перемотування.

Завдання 9: Перевірити колірний простір та глибину для уникнення «чому воно блякло?»

cr0x@server:~$ ffprobe -v error -select_streams v:0 -show_entries stream=pix_fmt,color_space,color_transfer,color_primaries -of default=nw=1 output_av1.mkv
pix_fmt=yuv420p
color_space=bt709
color_transfer=bt709
color_primaries=bt709

Що це означає: Стандартне SDR BT.709. Якщо бачите bt2020/pq/hlg — ви в HDR‑території.

Рішення: Не конвертуйте HDR у SDR мовчки без тонмапінгу; виглядає погано і користувачі звинувачують «ваш плеєр». Якщо потрібно — робіть це явно і тестуйте.

Завдання 10: Перевірити бренд контейнера/сумісність (капризи MP4)

cr0x@server:~$ mp4info output_h264.mp4 | head
Track # 1 Info - Track ID 1 - Time Scale 90000
Media Duration: 20.020 secs
Track Duration: 20.020 secs
Media Info: Language "und" - Type "vide" - Codec "avc1"
Track # 2 Info - Track ID 2 - Time Scale 48000
Media Info: Language "und" - Type "soun" - Codec "mp4a"

Що це означає: MP4 вказує avc1/mp4a — безпечне поєднання.

Рішення: Коли доставляєте AV1 в MP4 — валідуйте плеєри у вашому середовищі. Деякі стеки все ще надійніші з AV1 у WebM/MKV, залежно від обмежень клієнта.

Завдання 11: Бенчмарк пропускної здатності енкодера, щоб розмірити пул воркерів

cr0x@server:~$ /usr/bin/time -v ffmpeg -y -i input.mp4 -c:v libsvtav1 -preset 10 -crf 36 -an /tmp/out.mkv
...
	Command being timed: "ffmpeg -y -i input.mp4 -c:v libsvtav1 -preset 10 -crf 36 -an /tmp/out.mkv"
	User time (seconds): 82.13
	System time (seconds): 3.44
	Percent of CPU this job got: 1580%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:05.41
	Maximum resident set size (kbytes): 4128440

Що це означає: AV1‑енкод використав ~16 ядер (1580% CPU) і пікову пам’ять ~4GB, завершившись за 5.4s для короткого кліпу.

Рішення: Обмежуйте конкурентність згідно CPU й пам’яті. Якщо дозволити планувальнику запускати «стільки, скільки можливо», ви створите проблему шумного сусіда й хвости затримки в інших сервісах.

Завдання 12: Виявити, коли пайплайн прив’язаний до I/O (не до кодека)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          78.12    0.00    5.10    9.40    0.00    7.38

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz aqu-sz  %util
nvme0n1         520.0  68480.0     0.0   0.00    4.10   131.7    310.0  50240.0     0.0   0.00    6.90   162.1   4.20  98.0

Що це означає: Високий iowait і ~98% завантаження NVMe. Ваш енкодер може чекати читання/запису з диска.

Рішення: Перенесіть проміжні файли на швидше локальне сховище, стрімте через пайпи або зменшіть кількість паралельних джобів. Не «оптимізуйте кодек», поки ваш SSD кричить.

Завдання 13: Перевірити, чи маніфести/рендишен включають AV1, де очікується

cr0x@server:~$ grep -E "CODECS|av01|avc1" -n master.m3u8 | head
12:#EXT-X-STREAM-INF:BANDWIDTH=900000,RESOLUTION=854x480,CODECS="avc1.4d401f,mp4a.40.2"
18:#EXT-X-STREAM-INF:BANDWIDTH=650000,RESOLUTION=854x480,CODECS="av01.0.05M.08,mp4a.40.2"

Що це означає: У master‑плейлисті є варіанти і для H.264, і для AV1.

Рішення: Якщо рядків з AV1 немає — пакувальник або стадія пайплайна їх не виробили. Не дебажте плеєри, поки не підтвердите коректність пакування.

Завдання 14: Підтвердити, що воркери мають очікувані бібліотеки/підтримку AV1

cr0x@server:~$ ffmpeg -hide_banner -encoders | grep -E "svtav1|libaom-av1|rav1e"
 V....D libaom-av1           libaom AV1 (codec av1)
 V....D librav1e             librav1e AV1 (codec av1)
 V....D libsvtav1            SVT-AV1(Scalable Video Technology for AV1) encoder (codec av1)

Що це означає: Хост може кодувати AV1 з кількома енкодерами.

Рішення: Стандартизувати один енкодер на рівень (наприклад, SVT‑AV1 для загального CPU‑кодування), щоб уникнути «працює на одному воркері» дрейфу і непослідовної якості/бітрейту.

Швидкий план діагностики

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

Перше: це проблема кодування, декодування чи пакування?

Проблема кодування: черги ростуть, CPU воркерів насичені, тривалість завдань збільшується, користувачі чекають на «обробку».
Проблема декодування: високий CPU у клієнта, розряд батареї, пропущені кадри, підлагування на конкретних пристроях.
Проблема пакування/маніфесту: негайна помилка відтворення, «непідтримуваний формат», чорний відео, лише аудіо або проблеми лише на певних клієнтах.

Друге: доведіть кодек і профіль у артефакті

Запустіть ffprobe на фактичному доставленому артефакті, а не на джерелі або стадійному файлі.
Підтвердіть глибину біт, кольорове передавання і контейнер.

Третє: перевірте доступність апаратного прискорення там, де це важливо

На серверах: наявність VA‑API/NVDEC, стан драйверів, права контейнера.
На клієнтах: чи пристрій декодує апаратно чи програмно? (Падіння кадрів корелює з програмним декодом.)

Четверте: вирішіть, чи вузьке місце — CPU, пам’ять чи I/O

CPU‑bound: високий user CPU, низький iowait, передбачуване лінійне уповільнення з конкуренцією.
Memory‑bound: зростаючий RSS, свопінг, OOM‑вбивства контейнерів, довгі паузи GC у навколишніх сервісах.
I/O‑bound: високий iowait, насичені диски, повільні читання з об’єктного сховища, повтори.

П’яте: звузьте область, потім зменшіть складність

Протестуйте одиночний файл. Один воркер. Один пресет. Відоме джерело.
Переведіть пресет на швидший, обмежте роздільну здатність, примусьте 8‑біт SDR, вимкніть неважливі фільтри.
Якщо все ще не працює: підозрюйте середовище (драйвери, бібліотеки, дозволи), а не «AV1 не працює».

Поширені помилки (симптом → корінь → виправлення)

1) Симптом: Відтворення працює на вашому ноутбуку, у клієнтів підлаговує

Корінь: Клієнти декодують AV1 програмно (або 10‑бітний AV1) на обмеженому залізі/VDI.

Виправлення: Надайте H.264‑відкат, уникайте авто‑плею на слабких клієнтах і віддавайте перевагу 8‑бітам для широкої сумісності, якщо HDR не потрібен.

2) Симптом: Черга кодування безмежно росте в пікові навантаження

Корінь: AV1‑кодування поміщено в шлях запиту або пул воркерів недофінансований; пресети оптимізовано під компресію, а не продуктивність.

Виправлення: Перенесіть роботу в пакет, попередньо кодуйте популярний контент, вводьте admission control і вибирайте швидші пресети для інтерактивних робочих процесів.

3) Симптом: «Непідтримуваний кодек» лише в деяких браузерах/пристроях

Корінь: Підтримка AV1 є, але не для цього профілю/рівня/глибини біт, або парування контейнера несумісне.

Виправлення: Обмежте виходи (8‑біт Profile 0 для найширшої сумісності AV1), валідуйте контейнер/бренд і реалізуйте вибір на основі можливостей клієнта.

4) Симптом: Кольори виглядають блякло або надто темно

Корінь: Втрачені або неправильно інтерпретовані колірні метадані; HDR доставлено в SDR‑пайплайн без тонмапінгу.

Виправлення: Зберігайте колірні теги, явний тонмапінг HDR→SDR і тестування на репрезентативних дисплеях/плеєрах.

5) Симптом: AV1‑файли менші, але «час до першого кадру» гірший

Корінь: Надто довгі інтервали GOP/ключ‑кадрів, погане вирівнювання сегментів або плеєр бореться зі складністю декоду на старті.

Виправлення: Вирівняйте ключ‑фрейми за межами сегментів (HLS/DASH), налагодьте стартові ранги і розгляньте трохи вищий бітрейт для першого сегмента.

6) Симптом: Воркерів вбиває OOM під навантаженням

Корінь: Пам’ять енкодера плюс конкурентність перевищують ліміти; великі проміжні кадри; фільтри (скейл, денойз) збільшують пам’ять.

Виправлення: Встановіть обмеження конкурентності, підвищте ліміти пам’яті там, де виправдано, знизьте складність фільтрів і уникайте зайвих проміжних файлів.

7) Симптом: «Повільно», але CPU не завеликий

Корінь: Пайплайн прив’язаний до I/O: читання з об’єктного сховища, мережеве уповільнення, насичення диска, накладка на малі файли.

Виправлення: Стадіруйте вхідні дані локально, скачайте пакетно, використовуйте більші multipart‑налаштування де можливо і моніторьте iowait/%util.

8) Симптом: Маніфест показує AV1, але клієнти завжди обирають H.264

Корінь: Неправильні рядки CODECS, відсутні init‑сегменти або логіка визначення можливостей плеєра відхиляє AV1‑шлях.

Виправлення: Валідуйте маніфести, підтвердіть рядки кодеків, тестуйте з відомим AV1‑плеєром і логируйте рішення про можливості на клієнті.

Контрольні списки / покроковий план

Покроковий план розгортання (що я робив би в реальній організації)

Визначте метрики успіху: зменшення egress, зменшення обсягу зберігання, відсоток успішного відтворення, вартість кодування за хвилину і p95‑латентність обробки.
Виберіть сферу AV1: тільки VOD? Завантаження користувачів? Записи екрану? Реальні дзвінки? Не починайте з «усе».
Оберіть шлях енкодера: SVT‑AV1 для CPU‑кодування загального призначення, або апаратне кодування там, де можна гарантувати доступність і якість.
Встановіть консервативні вихідні обмеження: 8‑біт SDR (yuv420p), розумний GOP (наприклад, 2–4s ключ‑фрейми для стрімінгу) і перевірений контейнер.
Майте відкат: H.264 baseline/high, AAC‑аудіо, MP4 faststart. Обов’язково, поки не виміряли свою клієнтську популяцію.
Побудуйте валідаційні шлюзи: перевірки ffprobe, тест декоду, перевірка тривалості/кадрів, наявність аудіо і карантин при помилках.
Інструментуйте: час кодування, глибина черги, CPU на джоб, пікова пам’ять, розмір виходу і помилки відтворення за кодеком.
Розгортайте по когортах: внутрішні користувачі → невеликий відсоток зовнішніх → нарощування. Слідкуйте за класами пристроїв, а не лише за загальною успішністю.
Підготуйте операційні контролі: feature‑flags, політика кодеків по орендарю, ліміти швидкості і перемикач, що примусово включає H.264.
Документуйте «чому» і «як»: щоб наступна команда не «оптимізувала» шлях, видаливши відкат.

Контрольний список політики кодування (нудно, повторювано, ефективно)

Чи є визначена градація (renditions, бітрейти, роздільності) і вирівнювання ключ‑фреймів?
Чи обмежуємо конкурентність AV1‑кодування на хості й кластері?
Чи валідуємо виходи і автоматично карантинізуємо збої?
Чи логируємо рішення про вибір кодека на клієнті (перевірки можливостей)?
Чи зберігаємо оригінальні завантаження достатньо довго для повторної обробки?
Чи є документований відкат і протестований перемикач?

Операційний чекліст для передачі на чергування

Дашборди: глибина черги кодування, p95 тривалості джобів, CPU/пам’ять воркерів, I/O wait, лічильники помилок по етапах (завантаження/кодування/пакування/завантаження).
Ранбуки: «примусово H.264», «відключити AV1‑ранг», «злити AV1‑воркери», «переключити пресети на швидкий режим».
Зразки: зберігайте невеликий корпус «складних» відео (великий рух, захоплення екрана, HDR) для швидкого відтворення проблем.

Питання та відповіді

1) Якщо я ніколи не стрімлю, навіщо мені перейматися AV1?

Бо ви все одно зберігаєте й доставляєте відео. AV1 змінює зростання зберігання, egress та обчислення. Це питання продакшену, а не хобі для медіа.

2) Чи AV1 завжди менший за H.264?

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

3) Чи варто заміняти H.264 на AV1 всюди?

Ні. Використовуйте AV1 там, де є повторні перегляди і важливі витрати на трафік, і зберігайте H.264 для максимальної сумісності. «Скрізь» — це шлях до підтримки музею пристроїв.

4) Яка найпростіша безпечна стратегія розгортання?

Додайте AV1 як додатковий рендер, а не заміну. Обмежте доступ на основі можливостей і тримайте H.264 як дефолтний відкат, поки дані відтворення не доведуть інше.

5) Який енкодер AV1 варто використовувати?

Для CPU‑кодування в масштабі SVT‑AV1 — практичний вибір через компроміс швидкість/якість. libaom може бути відмінним, але іноді повільнішим на певних налаштуваннях.
Оберіть один, стандартизуйте і бенчмаркніть.

6) А що з апаратним кодуванням AV1?

Це може бути відмінно для пропускної спроможності і вартості за хвилину кодування, але треба валідувати якість виходу, впровадити планування (GPU — спільний ресурс) і керувати гетерогенними вузлами.
Апаратне прискорення вирішує одні проблеми і вводить інші.

7) AV1 «без роялті» і тому без ризику?

«Без роялті» — це намір і велика мотивація, але бізнес‑ризик — не лише ліцензування. Операційний ризик — сумісність, продуктивність, інструментарій — те, що не дасть вам спокою вночі.

8) AV1 допомагає для дзвінків у реальному часі (WebRTC)?

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

9) Чому деякі AV1‑файли відтворюються, але перемотування жахливе?

Зазвичай через інтервали GOP/ключ‑фреймів, вирівнювання сегментів або проблеми пакування. AV1 сам по собі не поганий у перемотуванні; це ваші налаштування кодування і сегментації вирішують.

10) Що одне забувають команди при прийнятті AV1?

Наблююваність на боці клієнта. Якщо ви не бачите, який кодек вибраний і чи декодується апаратно — ви дебажите сліпо.

Висновок: що робити далі

AV1 важливий, бо переміщує тиск у вашій системі. Менше трафіку і зберігання — це реальні гроші. Більше обчислень і управління сумісністю — теж реальні гроші, просто виставлені іншим рахунком.
Команди, що перемагають, ставляться до кодеків як до інфраструктури: вимірюють, поетапно впроваджують, спостерігають і роблять відкат можливим.

Практичні наступні кроки:

Протестуйте топ‑20 типів відео: (записи екрана, розмовні голови, високий рух) з одним пресетом AV1 і одним пресетом H.264. Зафіксуйте розмір, час кодування і суб’єктивну якість.
Додайте AV1 як опційний рендер: з відбором на основі можливостей і збережіть H.264 відкат.
Інструментуйте шляхи кодування й відтворення: щоб мати відповіді: який кодек було віддано, який декодовано і чи було апаратне прискорення.
Побудуйте перемикач‑вбивцю: що примусово змушує використовувати відкат без деплоймента. Колись ви ним скористаєтесь. Того дня буде незручно.