Видеокодирование 101: руководство для начинающих в 2026 году

Почему именно Фора Софт

Видео — самый быстрорастущий формат контента в интернете. Что бы вы ни строили — видео API, масштабируемую стриминговую платформу или интеграцию транскодирования в собственное приложение — кодирование находится в центре любой работы с видео. Фора Софт построила десятки критически важных видеоконвейеров для компаний из Fortune 500 и амбициозных стартапов. Мы понимаем технические компромиссы, операционную сложность и влияние правильного кодирования на бизнес. Это руководство собирает наш совокупный опыт в практические знания для всех, кто строит продукты на основе видео.

Что такое видеокодирование

Видеокодирование — это преобразование сырых видеоданных в сжатый формат, оптимизированный под хранение, стриминг или воспроизведение. Сырое видео занимает огромный объём: одна секунда несжатого 1080p при 30 fps весит около 750 МБ. Кодирование уменьшает этот объём до управляемых размеров (обычно 1–5 МБ в секунду для стримингового качества), сохраняя визуальное качество за счёт умных алгоритмов сжатия.

Кодирование состоит из трёх слоёв: контейнер (MP4, WebM, MOV), кодек (алгоритм сжатия) и настройки (битрейт, разрешение, частота кадров). Грамотный энкод балансирует размер файла, качество и время кодирования — вечный видеотреугольник.

Контейнер и кодек: в чём разница

Частая ошибка — путать контейнеры и кодеки. Это разные слои, которые работают вместе:

Контейнеры — это обёртка файла (.mp4, .webm, .mkv, .mov). Они упаковывают кодированный видеопоток, аудиопоток, метаданные и субтитры в один файл. Контейнер MP4 может содержать H.264, H.265 и даже AV1.

Кодеки — это алгоритмы сжатия. H.264 (MPEG-4 AVC), H.265 (HEVC), VP9 и AV1 — это кодеки. Они определяют, как пиксели сырого видео сжимаются и распаковываются. Один и тот же ролик, закодированный в H.264 и H.265, даст разные размеры файлов и кривые качества, даже внутри одного контейнера MP4.

Для веба и стриминга это различие принципиально, потому что поддержка в браузерах, аппаратное ускорение и лицензирование зависят от кодека, а не от контейнера.

Семейства современных кодеков: H.264, H.265, VP8/VP9, AV1 и VVC

H.264 (MPEG-4 AVC)

Выпущенный в 2003 году, H.264 остаётся индустриальным рабочим конём. На нём работают YouTube, Netflix, Zoom и практически любая стриминговая платформа. Почему? Универсальная аппаратная поддержка, понятное лицензирование (с явными периодами без роялти для интернет-видео) и зрелый инструментарий кодирования. Эффективность битрейта средняя — современные H.265 и AV1 сжимают примерно на 25–50% лучше при сопоставимом качестве.

Когда выбирать: поддержка устаревших устройств, real-time-приложения (WebRTC), а также когда нужна гарантированная совместимость с любым устройством.

H.265 (HEVC)

H.265 уменьшает битрейт вдвое по сравнению с H.264 при том же качестве. Это стандарт для 4K-стриминга, эфирного телевидения и ситуаций с ограниченной пропускной способностью. Лицензирование сложное: HEVC Licensing Administrator (LAC) и несколько патентообладателей собирают роялти. На 2026 год многие компании продолжают жить в условиях лицензионной неопределённости, поэтому H.265 чаще выбирают для корпоративного видео, чем для веба.

Когда выбирать: премиальные видеосервисы, архивы, где экономия битрейта оправдывает лицензионные расходы, и 4K.

VP8 и VP9

Кодеки VP от Google свободны от лицензионных отчислений. VP8 — уже наследие; VP9 даёт сжатие на уровне H.265 (примерно на 40% лучше H.264) и обслуживает резервные потоки YouTube. Однако аппаратная поддержка ограничена топовыми мобильниками и относительно свежими десктопами. Кодирование медленное.

Когда выбирать: требования без роялти и доставка через YouTube.

AV1

AV1 — кодек следующего поколения, разработанный Alliance for Open Media (Netflix, Google, Amazon, Cisco). Он сжимает на 20–30% лучше H.265 и имеет явное лицензирование без роялти. Подвох: кодирование медленное (в 10–50 раз медленнее H.264). К 2026 году аппаратное ускорение (NVIDIA, Apple, Intel) расширяется, но всё ещё ограничено. Для архивов или премиального видео по запросу (где время кодирования не критично) AV1 непобедим.

Когда выбирать: безроялтийные сценарии, архивы и доставка в условиях ограниченной полосы, когда время кодирования допустимо.

VVC (Versatile Video Coding)

VVC — новейший стандарт ITU-T (финализирован в 2021), сжимает на 40% лучше H.265. Внедрение идёт медленно за пределами исследований и премиального корпоративного сегмента из-за неясности с лицензированием и почти отсутствующей программной поддержки. Следите за ним в перспективе 2027–2028 годов.

Когда выбирать: только как задел на будущее; для большинства команд в 2026 году к продакшену не готов.

Сравнительная матрица кодеков

Кодек	Эффективность битрейта	Аппаратная поддержка	Скорость кодирования	Лицензирование
H.264	Базовая	Универсальная	Быстрая	Понятное (для стриминга — без роялти)
H.265	~50% лучше	Ограниченная (мобильные/новые)	Медленная – средняя	Сложное (LAC + патентообладатели)
VP9	~40% лучше	Ограниченная (YouTube)	Очень медленная	Без роялти
AV1	~30% лучше	Растущая (аппаратное ускорение)	Очень медленная (без аппаратной)	Без роялти
VVC	~40% лучше	Минимальная	Неизвестно	Неясное (ITU-T)

Битрейт, разрешение и частота кадров: невозможный треугольник

У каждого видео есть три ручки: битрейт (Мбит/с), разрешение (пиксели) и частота кадров (fps). Увеличиваете одно — остальные начинают давить на качество. Вот ориентиры стриминга на 2026 год:

360p (SD, mobile-first): 0,5–1,0 Мбит/с при 24–30 fps. Приемлемо для речи и регионов со слабой полосой.

480p: 1,0–2,0 Мбит/с при 24–30 fps. Бюджетное стриминговое качество.

720p (HD): 2,5–4,0 Мбит/с при 24–30 fps. Индустриальный стандарт для стриминга, образования и веб-видео.

1080p (Full HD): 4,0–8,0 Мбит/с при 24–30 fps. Премиум-стриминг и видео по запросу.

4K: 15–25 Мбит/с при 24–30 fps (предпочтительно H.265; H.264 потребует 40+ Мбит/с).

Ключевая мысль: большинство зрителей перестают замечать улучшения выше 720p на экранах средней диагонали. Распределяйте битрейт между разрешением и частотой кадров исходя из контента и устройства, а не по привычке.

Управление битрейтом: CBR, VBR и CVBR

Постоянный битрейт (CBR): одинаковый битрейт на каждую секунду видео, независимо от сложности сцены. Просто, предсказуемо, но расточительно: статичный кадр получает тот же битрейт, что и быстрая экшн-сцена. Подходит для real-time-стриминга (WebRTC, RTMP) с фиксированной полосой.

Переменный битрейт (VBR): больше бит уходит на сложные сцены (движение, детализация) и меньше на статичные (говорящие головы, затемнения). Файлы получаются меньше при том же или лучшем качестве. Требует двухпроходного кодирования. Стандарт для видео по запросу (YouTube, резервные потоки Netflix).

Ограниченный VBR (CVBR): гибридный подход: битрейт меняется в пределах буферного ограничения. Используется стриминговыми сервисами для адаптивного битрейта (ABR), где у каждой ступени лестницы есть максимум, чтобы не уйти в недогрузку буфера. Рекомендуется для live-адаптивного стриминга.

На практике: VBR — для записанного контента; CBR — для live или чувствительных к буферу приложений; CVBR — для пакетов адаптивного битрейта.

I-, P- и B-кадры: скелет сжатия

Видеокодеки не сжимают каждый кадр независимо. Они эксплуатируют временную избыточность — то, что соседние кадры почти идентичны.

I-кадры (Intraframes): самодостаточные, сжаты как JPEG. Не ссылаются на другие кадры. Самый большой размер. Используются как точки монтажа и якоря случайного доступа.

P-кадры (Predicted frames): сжаты относительно предыдущих кадров. Хранят только различия («дельты»). Гораздо меньше I-кадров. Включают прямое предсказание.

B-кадры (Bidirectional frames): сжаты с использованием и прошлых, и будущих кадров. Самый маленький размер, но требуют двунаправленного просмотра вперёд и увеличивают задержку. В real-time (WebRTC) запрещены.

GOP (Group of Pictures): паттерн I-, P- и B-кадров. GOP вида «I, 3 B-кадра, P» означает один I-кадр, затем повторяющиеся группы из 3 B-кадров и одного P-кадра. Длинные GOP (30–300 кадров) лучше сжимают, но требуют больше буфера и снижают точность перемотки. Короткие GOP (6–12 кадров) дают быструю перемотку и обязательны на границах сегментов HLS/DASH.

Цветовая субдискретизация: почему можно отбросить детали цвета

Человеческий глаз чувствительнее к яркости (luminance), чем к цветности (chroma). Кодеки этим пользуются, снижая разрешение цвета.

4:4:4 (без субдискретизации): полный цвет в каждом пикселе. Профессиональные архивы. Тройной объём цветовых данных.

4:2:2 (горизонтальная субдискретизация): цвет в 50% горизонтального разрешения. Эфирный стандарт. Двойной объём цветовых данных.

4:2:0 (горизонтальная и вертикальная субдискретизация): цвет в 25% пространственного разрешения. Незаметно на типовых экранах. 50% цветовых данных. Используется в стриминге (H.264, H.265, VP9, AV1).

Большая часть стриминга использует 4:2:0 и экономит 30–40% битрейта без видимой потери качества на мобильных и десктопных экранах.

Адаптивный битрейт: нужное качество для каждого устройства

Live-телевидение и видео по запросу требуют одновременной выдачи нескольких уровней качества. Адаптивный битрейт (ABR) кодирует одно видео в 4–8 разных разрешений и битрейтов («рендиции» или «ступени»), упаковывает их в сегменты, а плеер переключает уровни в зависимости от полосы, наполнения буфера и возможностей устройства.

HLS (HTTP Live Streaming): протокол Apple. Сегменты TS (MPEG-2) или fMP4 (фрагментированный MP4), плейлист m3u8. Сегменты по 2–6 секунд. Универсален в iOS и macOS; нативная поддержка в Android ограниченная.

MPEG-DASH (Dynamic Adaptive Streaming over HTTP): открытый стандарт. Сегменты MP4, плейлист MPD (XML). Более гибкий, нативно поддерживается в десктопных браузерах. Сегменты от 2 до 10 секунд.

CMAF (Common Media Application Format): единый контейнер и для HLS, и для DASH. Сокращает объём хранения на 30–50% (общие сегменты) и упрощает мультиплатформенную доставку.

Лучшая практика в 2026 году: кодируйте один высококачественный мезонин (2160p, 50 Мбит/с), затем транскодируйте его в 4–6 ABR-рендиций (360p, 480p, 720p, 1080p, 2160p) в облачном транскодере. Упаковывайте через CMAF для одновременной доставки HLS + DASH.

Аппаратное ускорение и программное кодирование: скорость против контроля

Кодирование сильно нагружает CPU. Современные GPU дают огромный прирост скорости:

NVIDIA NVENC: H.264, H.265, AV1. В 10–100 раз быстрее libx264. Есть на GeForce, Tesla и датацентровых GPU. Лучшее в классе аппаратное ускорение AV1 на 2026 год.

Intel Quick Sync (QSV): H.264, H.265. Встроен в процессоры Intel. Ускорение в 5–50 раз. Управление битрейтом менее точное, чем у софтового кодирования.

Apple VideoToolbox: H.264, H.265 на Mac и iOS. Бесшовная интеграция. Возможности зависят от поколения SoC Apple.

Android MediaCodec: зависит от производителя устройства. H.264 поддерживается везде; H.265/VP9 — в зависимости от класса; AV1 встречается редко.

Программное кодирование (libx264, libx265, libaom-av1): самое медленное, но самое гибкое. Точный контроль битрейта, лучшая тонкая настройка качества, полное владение кодеком. Используйте, когда нужен хирургический контроль или аппаратное ускорение недоступно.

На практике: аппаратное ускорение — для скорости и экономии (облачные фермы кодирования). Программное — для критичных к качеству или малосерийных задач.

Облачные сервисы кодирования: современная альтернатива своей инфраструктуре

Построить свою ферму кодирования реально, но это требует закупки GPU, управления охлаждением и операционной экспертизы. Большинство команд отдают это на специализированные облачные транскодеры:

AWS Elemental MediaConvert: корпоративный уровень. H.264, H.265, VP9, AV1. Ценник на 2026 год: около 3,7–9 ₽ за минуту в зависимости от кодека и выходного разрешения. Предсказуемая стоимость при больших объёмах. Без инвестиций в железо.

Google Cloud Transcoder: H.264, H.265. Примерно 3 ₽ за минуту. Хорош для клиентов Google Workspace; функционально беднее AWS.

Mux (API-first): удобен для разработчиков. Стриминг и видео по запросу. Интегрируется в платформы вроде Webflow и Zapier. Прозрачные тарифы за минуту, дашборды мониторинга в реальном времени.

Bitmovin: полноценная видеоплатформа. Кодирование, плеер, аналитика. Сильные позиции на европейском рынке. Конкурентен по AV1 и метрикам качества.

Coconut: лёгкий и доступный (2,2–3,7 ₽ за минуту). Подходит для стартапов с ограниченным бюджетом и простых сценариев. Менее развитое QoS, чем у корпоративных сервисов.

Стратегия: сравните стоимость за минуту с вашими объёмами. При объёмах меньше 100 ТБ в месяц облако почти всегда дешевле собственной инфраструктуры.

Реальные команды FFmpeg: от теории к практике

FFmpeg — швейцарский нож кодирования. Вот несколько готовых рецептов на 2026 год:

Базовое кодирование в H.264 (720p, VBR, быстрый пресет):

ffmpeg -i input.mov -c:v libx264 -preset fast -crf 22 -s 1280x720 -c:a aac -b:a 128k output.mp4

H.265 с аппаратным ускорением NVIDIA (1080p, CVBR):

ffmpeg -i input.mov -c:v hevc_nvenc -rc vbr -cq 23 -s 1920x1080 -c:a aac -b:a 128k output.mp4

AV1 в два прохода для архивного качества (медленно, но эффективно):

ffmpeg -i input.mov -c:v libaom-av1 -crf 28 -b:v 0 -cpu-used 4 -row-mt 1 -c:a aac -b:a 128k -pass 1 -f null NUL && ffmpeg -i input.mov -c:v libaom-av1 -crf 28 -b:v 0 -cpu-used 4 -row-mt 1 -c:a aac -b:a 128k -pass 2 output.webm

HLS с адаптивными рендициями (4 ступени):

ffmpeg -i input.mov -filter_complex 'scale=640:360' -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 128k -hls_time 4 -hls_list_size 0 output_360.m3u8 -filter_complex 'scale=1280:720' -c:v libx264 -preset medium -crf 21 -c:a aac -b:a 192k output_720.m3u8

Запись экрана (мало движения, конференц-формат):

ffmpeg -i screencast.mov -c:v libx264 -preset slower -crf 18 -x264-params aq-mode=3:deblock=1,1 -c:a aac -b:a 96k screencast_final.mp4

Метрики качества видео: PSNR, SSIM и VMAF

Как понять, что энкод получился хорошим? Золотой стандарт — человеческое восприятие, но оценивать его дорого. Метрики качества автоматизируют сравнение:

PSNR (Peak Signal-to-Noise Ratio): простая математическая мера попиксельной разницы. Выше — лучше (>40 дБ — высокое качество, <20 дБ — плохое). Плохо согласуется с восприятием. Подходит для инженерных проверок, не для рекомендаций пользователям.

SSIM (Structural Similarity Index): сравнивает яркость, контраст и структуру. Шкала 0–1 (>0,9 — отлично). Согласуется с восприятием лучше, чем PSNR. Но всё равно ловит не все артефакты.

VMAF (Video Multimethod Assessment Fusion, Netflix, 2015): объединяет несколько метрик с помощью машинного обучения, обученного на человеческих оценках. Шкала 0–100. >78 — визуально без потерь; 70–75 — небольшие артефакты; <60 — явная деградация. Индустриальный стандарт в 2026 году для контроля качества. Используйте именно его при валидации энкода.

Чтобы посчитать VMAF энкода относительно исходника:

ffmpeg -i source.mp4 -i encoded.mp4 -filter_complex "libvmaf=model=version=vmaf_v0.6.1:log_fmt=json:log_path=vmaf_out.json" -f null -

Кодирование для WebRTC и для VOD: тактические различия

У коммуникаций в реальном времени (видеозвонки, live-стриминг) и у видео по запросу (YouTube, Netflix) разные ограничения:

WebRTC (Janus, Pion, Kurento): задержка <500 мс end-to-end. Однопроходное кодирование. Без B-кадров (двунаправленный просмотр вперёд ломает низкую задержку). Адаптивный битрейт внутри сессии (REMB, GCC). Выбор кодеков ограничен: VP8, VP9 (экосистема Google), H.264 (устройства с аппаратной поддержкой в первую очередь). Частота кадров важнее разрешения (минимум 24–30 fps).

VOD (YouTube, Netflix, Vimeo): задержка не важна. Двухпроходное или многопроходное кодирование. B-кадры разрешены и приветствуются. Битрейт оптимизируется оффлайн. Выбор кодеков широкий: H.264, H.265, VP9, AV1. Приоритет за разрешением; частота кадров может опускаться до 24 fps и ниже для киноконтента.

Live-стриминг (HLS, DASH с live-контентом): гибрид: нужна низкая задержка (<10 секунд), но больше гибкости, чем в WebRTC. Интервал между ключевыми кадрами 1–2 секунды (против 30+ для VOD). Обычно H.264 или H.265 с CBR.

Надёжный конвейер кодирования: Agent Engineering

Продакшен-конвейер кодирования — это не просто «запустить FFmpeg». Нужны оркестрация, мониторинг, восстановление после ошибок и аудит-трейлы.

Очередь и диспетчеризация: входящие видео складываем в очередь сообщений (SQS, RabbitMQ, Kafka). Пул воркеров забирает задания, кодирует, выгружает результаты.

Упаковка нескольких рендиций: кодируем один вход в 4–6 разрешений параллельно или последовательно. Параллельно быстрее, но требует больше одновременных GPU/CPU. Последовательная схема позволяет переиспользовать промежуточный кэш.

Проверки здоровья: валидируем количество кадров, длительность, кодек, битрейт на выходе. Декодируем и выборочно проверяем кадры через VMAF. Алерт, если качество падает ниже порога.

Логика повторов: временные сбои GPU, переполнение диска, сетевые таймауты. Реализуйте экспоненциальный backoff. Логируйте ошибки в аналитику; алертируйте при повторяющихся сбоях.

Учёт стоимости: фиксируйте часы GPU, исходящий трафик и реальное время на задание. Агрегируйте по клиенту, типу контента, кодеку. Используйте это для прогноза и бюджета.

Кейс: реальное дерево решений по кодированию

Вашей команде нужно закодировать 500 часов лекций для видео по запросу. Вот логика принятия решений:

1. Оцените чувствительность к стоимости: 500 часов × 3,7 ₽/мин (облако) = 112 тыс. ₽. По карману большинству компаний.

2. Выберите кодек: H.264 (универсальная поддержка браузерами и устройствами) для основного уровня, H.265 в качестве запасного для второго уровня доставки (экономит 40% полосы).

3. Определите лестницу: 360p (0,8 Мбит/с), 720p (2,5 Мбит/с), 1080p (5 Мбит/с). Пропустите 4K (лекциям он не нужен).

4. Выберите сервис: AWS MediaConvert или Mux. Оба надёжные и сопоставимые по цене. AWS — если у вас уже есть экосистема EC2; Mux — если хотите более простую интеграцию с видеоплеером.

5. Кодируйте и упаковывайте: облачный транскодер отдаёт HLS + DASH, упакованные через CMAF. Манифест генерируется автоматически.

6. Выборочная проверка: скачайте 10 закодированных роликов. Проиграйте на десктопе и мобильных (iOS/Android). Прогоните VMAF на 3 роликах. Если все дают >78 — принимайте партию.

7. Архивируйте исходники: храните оригинальные .mov-файлы в холодном хранилище (Glacier, Archive tier). Через пару лет может понадобиться перекодировать с другими настройками.

Пять вопросов: фреймворк принятия решений

Когда стоит решение по кодированию, задайте себе эти пять вопросов по порядку:

В1. Какое основное устройство воспроизведения и какое подключение? Мобильный на 3G? Десктоп на широкополосной? Ответ задаст потолок битрейта и разрешения.

В2. Критична ли задержка? Если да (<500 мс) — используйте кодирование для WebRTC (VP8, H.264, один проход, без B-кадров). Если нет — оптимизируйте под качество (H.265, AV1, два прохода, B-кадры).

В3. Какой тип контента? Речь, говорящая голова? Берите более низкий битрейт (0,8–1,5 Мбит/с при 720p), выше QP. Экшн, быстрое движение? Выше битрейт (3–5 Мбит/с при 720p), ниже QP. Запись экрана? Высокий QP, низкий битрейт (1–2 Мбит/с), более медленный пресет.

В4. Важно ли лицензирование? Если роялти недопустимы — AV1 или VP9 (без роялти). Если лицензионные расходы вам по карману — H.265 даёт лучший баланс скорости и эффективности.

В5. Какая экспертиза у команды и насколько вы готовы к эксплуатационным сложностям? Самостоятельное кодирование (ffmpeg, парк GPU) требует операционной зрелости; облачные сервисы требуют интеграции, но снимают эксплуатацию. Выбирайте соответственно.

Пять типичных ошибок кодирования (и как их избежать)

1. Перекодирование (слишком высокий битрейт): излишний битрейт не улучшает качество выше определённого порога, а только тратит полосу. Проверяйте через VMAF. На 720p 5 Мбит/с в H.264 для веба часто избыточны. Начинайте с консервативных 2,5 Мбит/с и поднимайте, только если метрики качества проседают.

2. Однопроходный VBR без ограничителей качества: переменный битрейт соблазнителен («кодек сам решит»), но без ограничения битрейта отдельные сцены могут непредсказуемо скакать по качеству или скорости потока. В продакшене используйте CVBR с ограничениями maxrate и bufsize.

3. Игнорирование рассогласования цветовых пространств: источник в BT.709 (эфир), транскод в BT.601 (наследие), вывод в P3 (современные дисплеи). Если матрицы не тронуть — получите смещение цвета. Задавайте цветовые матрицы в FFmpeg явно: -color_primaries bt709 -color_trc bt709 -colorspace bt709.

4. Забытые интервалы ключевых кадров для ABR/HLS: длину GOP нужно совмещать с длительностью сегмента. Сегменты HLS/DASH должны начинаться с ключевого кадра ради точной перемотки. Если сегмент 4 секунды, а GOP — 30 кадров, перемотка станет рывковой.

5. Невалидированная аппаратная поддержка: кодируете передовым профилем (High 10, Main 10, Profile 0 у AV1), который не поддерживает 70% целевых устройств. Используйте FFmpeg с ограничениями профиля: -x264-params profile=main. Проверяйте воспроизведение на целевых устройствах до выкатки.

KPI кодирования: что измерять в продакшене

Когда конвейер уже работает, держите под наблюдением три блока метрик:

Качество: средний VMAF (держим >78), пропуски кадров (<0,1%), ошибки декодирования (<0,01%), разброс битрейта (коэффициент вариации <30%).

Операции: процент успешных заданий (>99%), среднее время кодирования на минуту видео, глубина очереди (алерт при >100), утилизация GPU (цель 70–85%), категории ошибок (переполнение диска, OOM на GPU, таймауты API).

Стоимость: стоимость одной минуты кодирования, стоимость одного ТБ исходящего трафика, стоимость на один просмотр пользователя (общая стоимость кодирования / общее число просмотров). Отслеживайте тренды месяц к месяцу; договаривайтесь о скидках за объём с облачными сервисами, если стоимость минуты растёт.

Когда НЕ нужно кодировать: ложная экономия

Кодирование добавляет стоимость, задержку и сложность. Иногда от него лучше отказаться:

Если ваш вход уже оптимизирован: 720p H.264 на 2,5 Мбит/с уже оптимизирован для стриминга. Перекодирование не улучшит качество, только потратит вычислительные ресурсы. Пропускайте без перекодирования (copy codec).

Если у вас меньше 1000 уникальных зрителей в месяц: стоимость облачного кодирования превысит стоимость хостинга самой платформы. Self-serve-инструменты (Cloudflare Stream, AWS SAM) могут оказаться и дешевле, и проще.

Если вам нужен результат через 10 минут: у облачных транскодеров есть глубина очереди. AV1 кодируется медленно. Жёсткие реал-таймовые требования могут вынудить отправлять H.264 в сеть без оптимизации.

Если вы не измеряете качество: вслепую кодировать «на максимум» без VMAF и пользовательской обратной связи — это потери. Сначала измерьте, потом оптимизируйте. Возможно, кодировать вообще не нужно.

Часто задаваемые вопросы о видеокодировании

Можно ли перекодировать уже закодированное видео без потери качества?

Нет. Каждое перекодирование вносит потери поколения. Если перекодировать всё же нужно — используйте качественный промежуточный формат (мезонин, 4:4:4, минимум H.264 baseline) и по возможности перекодируйте от исходника.

В чём разница между CRF и целевым битрейтом?

CRF (Constant Rate Factor) — это метрика качества (0–51 для H.264; 0–63 для H.265; ниже — выше качество). Битрейт меняется так, чтобы выдержать заданное качество. Целевой битрейт — это жёсткий потолок. CRF удобен для видео по запросу; целевой битрейт — для стриминга и live.

Как понять, что моё кодирование слишком медленное?

Профилируйте кодирование (время на минуту видео). Целевой темп — 5–30x реального времени (минутный ролик кодируется за 2–12 секунд). Если медленнее, посмотрите загрузку CPU/GPU: если ниже 80%, переключайтесь на более быстрые пресеты. Если упёрлись в потолок — нужно больше железа.

Влияет ли формат кодирования на задержку воспроизведения?

Сам кодек напрямую не влияет на задержку воспроизведения, а вот размер GOP — да. Длинные GOP задерживают перемотку и требуют буфера. Для низкой задержки используйте короткие интервалы ключевых кадров (1–2 секунды).

Всегда ли стоит использовать аппаратное ускорение, если оно доступно?

Не всегда. Аппаратное ускорение быстрое, но точность тонкой настройки качества у него ниже. Для архивов и критичных к качеству задач программное кодирование с медленными пресетами часто обыгрывает аппаратное. Для real-time или чувствительных к цене сценариев аппаратное ускорение выигрывает.

Как выбрать между HLS и DASH?

HLS проще и имеет нативную поддержку в iOS/macOS. DASH гибче и стандартизирован. В 2026 году используйте оба через CMAF (общие сегменты, единая генерация манифеста).

Как часто пересматривать настройки кодирования?

Делайте бенчмарк ежеквартально или после серьёзных изменений в библиотеке. Если меняется профиль устройств вашей аудитории (больше мобильных, больше 4K), пересматривайте выбор кодека и лестницу битрейтов. Не гонитесь за каждым новым алгоритмом — держите фокус на бизнес-метриках (стоимость, качество, пользовательский опыт).

Как Agent Engineering от Фора Софт сокращает стоимость конвейера кодирования?

Генерация кода с участием ИИ сокращает шаблонный обвес FFmpeg-конвейера на 25–35%: MVP-сервис кодирования, который обычно делают 6 недель, у нас выходит за 4. Кроме того, мы переиспользуем проверенные шаблоны ABR-лестниц и оснастку для измерения качества между проектами.

Что читать дальше: видеоинфраструктура в Фора Софт

Итог: мастерство кодирования начинается здесь

Видеокодирование — не магия и не тривиальность. Это ремесло: понимание кодеков, компромиссов и собственных ограничений ведёт к элегантным решениям. H.264 не уйдёт в ближайшее время, H.265 останется лицензионным лабиринтом, AV1 — долгосрочная ставка. Облачные сервисы делают профессиональную инфраструктуру доступной, но только если вы измеряете и итерируете. Выбирайте кодек, битрейт и конвейер исходя из ваших пользователей, а не хайпа. Меряйте VMAF. Валидируйте на реальных устройствах. Пересматривайте настройки ежеквартально. Фора Софт строила решения по кодированию для команд любого масштаба — от стартапов, оптимизирующих свою первую тысячу видео, до корпораций, обрабатывающих петабайты. Грамотное кодирование экономит полосу, деньги и нервы пользователей. Это стоит делать правильно.