Какой битрейт и кодек выбрать для монтажа и сдачи
Кодек и битрейт определяют размер файла и то, как клиент сможет его пересобрать сам. Разбираем выбор по задаче сдачи — с таблицей на 15 собственных замеров, а не по общим советам из интернета.
Битрейт и кодек выбирают не потому, что «H.264 лучше», а потому что от них зависит размер готового файла и то, сможет ли клиент пересобрать его сам. Если ролик идёт на площадку, важнее требования площадки; если клиенту в архив — важнее, чтобы файл открылся и не потерял качество. Ниже — таблица выбора с нашими замерами, формула расчёта размера и разница между CBR и VBR.
Кодек и битрейт для сдачи
Для сдачи по умолчанию берут H.264 в MP4: контейнер понимают все монтажные программы и телефоны, а файл получается лёгким. Второй по совместимости — H.265. В нашей лестнице на единственной паре с одинаковым CRF (28) файл у H.265 вышел больше, чем у H.264; качество мы не измеряли, поэтому сравнивать картинку по нашим данным нельзя. Если совместимость важнее, берите H.264.
| Задача | Контейнер | Кодек | Настройка | Что получится |
|---|---|---|---|---|
| Сдача на площадку, нужен лёгкий файл | MP4 | H.264 | CRF 23 | Универсально открывается, разумный вес |
| Сдача, когда нужен H.265 | MP4 | H.265 | CRF 24–28 | Файл больше, чем у H.264 на том же CRF; качество не измерялось |
| Ролик с большшим динамическим диапазоном | MOV | ProRes 4444, наш экспорт | Профиль ffmpeg: 4 | Альфа-канал до 16 бит; ProRes умеет хранить широкий цветовой охват и HDR |
| Архив, монтажная картинка с прозрачностью | MOV | ProRes 4444, наш экспорт | Профиль ffmpeg: 4 | Альфа-канал, максимальный вес |
| Быстрый черновой монтаж | MOV | ProRes 422 Proxy, наш экспорт | Профиль ffmpeg: 0 | Промежуточный файл для монтажа, а не для сдачи; ProRes кодирует каждый кадр независимо |
ProRes в MP4 не пишется: кодик завершается ошибкой и остаётся файл нулевого размера. Для него нужен контейнер MOV — это стоит знать до того, как проект заказчика уедет сдаваться.
Сколько весит файл: таблица замеров
Ниже — наши собственные замеры. Мы кодировали синтетический тестовый сигнал 1920×1080 при 25 fps длительностью 30 секунд в ffmpeg 9.0.2 и считали размер получившихся файлов. Все значения — для исходника в 1080p, если не указано иное. Строки с переменным битрейтом (VBR и настоящий CBR) зависят от работы кодика: при повторных прогонах их размер отличается на доли процента, поэтому в таблице приведены числа последнего прогона протокола.
| Кодек и настройка | Размер файла | Битрейт | Комментарий |
|---|---|---|---|
| H.264, CRF 18 | 31 758 807 Б | 8,47 Мбит/с | Самый высокий битрейт среди H.264 в нашей лестнице |
| H.264, CRF 23 | 20 558 332 Б | 5,48 Мбит/с | Рабочий компромисс для сдачи |
| H.264, CRF 28 | 10 773 733 Б | 2,87 Мбит/с | Компактный файл |
| H.265, CRF 20 | 34 934 738 Б | 9,32 Мбит/с | Самый высокий битрейт среди H.265 |
| H.265, CRF 24 | 26 079 918 Б | 6,95 Мбит/с | По битрейту между H.264 CRF 18 и CRF 23 |
| H.265, CRF 28 | 17 672 736 Б | 4,71 Мбит/с | По битрейту между H.264 CRF 23 и CRF 28 |
| H.264, VBR с целевым битрейтом 8 Мбит/с | 30 483 069 Б | 8,13 Мбит/с | Средний битрейт держится у цели; разброс внутри файла мы не измеряли |
| H.264, VBR с целевым битрейтом 12 Мбит/с | 45 215 148 Б | 12,06 Мбит/с | Для площадок с верхней границей битрейта |
| H.265, VBR с целевым битрейтом 8 Мбит/с | 30 854 839 Б | 8,23 Мбит/с | Тот же целевой битрейт, другой кодек |
| ProRes 422 Proxy, наш экспорт | 72 528 515 Б | 19,34 Мбит/с | Промежуточный файл, не для сдачи |
| ProRes 422 LT, наш экспорт | 148 521 236 Б | 39,61 Мбит/с | Промежуточный файл, не для сдачи |
| ProRes 422, наш экспорт | 193 226 105 Б | 51,53 Мбит/с | Рабочая база цветокоррекции |
| ProRes 4444, наш экспорт | 465 385 217 Б | 124,10 Мбит/с | С альфа-каналом, самый тяжёлый |
| Вертикаль 1080×1920, H.264 CRF 23 | 8 346 717 Б | 2,23 Мбит/с | Кадр увеличен до 3413×1920 и обрезан по центру — деталей после интерполяции меньше |
| 4K 3840×2160, H.264 CRF 23 | 44 092 600 Б | 11,76 Мбит/с | Апскейл: пикселей вчетверо больше, битрейт вырос в 2,1 раза — на пиксель бит в 1,86 раза меньше |
Оговорка к таблице: это нижняя граница
Исходник в наших замерах — тестовая таблица без деталей и движения. Реальная съёмка при том же CRF даст больший битрейт, поэтому таблицу нельзя читать как прогноз размера для конкретного проекта. Отдельно: ProRes в ffmpeg подбирает битрейт по сложности кадра, и на нашем исходнике результат заметно ниже целевых значений производителя. Порядок и соотношение сохраняются, абсолютные цифры — нет. Для планирования места на диске считайте по целевым битрейтам Apple для ProRes 422 Proxy — около 45 Мбит/с, ProRes 422 LT — около 102 Мбит/с, ProRes 422 — около 147 Мбит/с и ProRes 4444 — около 330 Мбит/с при 1920×1080 и 29,97 fps.
Размер файла выводится из битрейта и хронометража напрямую: берём сумму битрейта видео и битрейта аудио, умножаем на длительность в секундах и делим на 8 бит в байте — получаем байты. Проверка на наших же замерах: для VBR с целью 8 Мбит/с расчёт даёт 30 720 000 байт против измеренных 30 483 069, для цели 12 Мбит/с — 45 720 000 против 45 215 148.
- VBR с целью 8 Мбит/с (8 000 000 бит/с), звук 192 кбит/с (192 000 бит/с), 30 секунд → (8 000 000 + 192 000) × 30 ÷ 8 бит/Б = 30 720 000 байт, и мы получили 30 483 069 байта
- VBR с целью 12 Мбит/с (12 000 000 бит/с), звук 192 кбит/с, 30 секунд → 45 720 000 байт, измерено 45 215 148 байт
- Настоящий CBR 8 Мбит/с (nal-hrd=cbr) → 30 883 356 байт, 8,24 Мбит/с
Отсюда обратная задача: если известен лимит площадки на размер файла, а длительность неизвестна, делим лимит на суммарный битрейт и получаем максимальный хронометраж. Тот же расчёт в обратную сторону отвечает, сколько секунд влезет в файл заданного объёма.
Монтажный кодек и прокси
Для монтажа кодек выбирают по другому критерию — не по размеру, а по скорости работы. Работать с исходниками высокого разрешения тяжело: прокрутка и рендер отдают, машина встаёт. Решение — не пережимать исходник один раз, а делать прокси: уменьшенная копия с тем же таймлайном, по которой собирают черновик, и финальный рендер уже с полного исходника.
Когда прокси окупается
- Проект в 4K: прокси снимает основную нагрузку при прокрутке
- Материала много, а сроки сжатые — черновик собирается быстро, финал считается один раз
- Машина не тянет исходники — таймлайн подтормаживает на каждом переходе
- Монтаж ведётся по звуку, картинка проверяется на финальном рендере
- Проект собирают удалённо — оригиналы не нужно пересылать целиком
Прокси не нужен, если проект короткий, исходники уже лёгкие, а сдача идёт в том же низком разрешении — монтаж в исходнике тяжелее для машины, чем работа с лёгкими копиями. Отдельно: прокси годится для черновика, но не для финального рендера и не для сдачи клиенту.
CBR или VBR
CBR — постоянный битрейт: кодик выдаёт одинаковое количество бит в секунду, независимо от сложности кадра. Размер файла получается предсказуемым. VBR распределяет биты по сложности: битрейт растёт на детальных сценах и падает на статичных, и размер файла заранее неизвестен. Насколько разница видна глазом, мы не измеряли: качество изображения в наших замерах не считалось.
Если задача сдачи ограничена по битрейту или по размеру файла, надёжнее перекодировать с фиксированным битрейтом: при переменном битрейте размер получается непредсказуемым. Для финального качества на своём носителе разумнее VBR — он распределяет биты по сложности кадра. В наших замерах настоящий CBR 8 Мбит/с дал 8,24 Мбит/с, а VBR с целевым битрейтом 8 Мбит/с — 8,13 Мбит/с: средний уровень держится у цели, а разброс внутри файла мы не измеряли.
Частые вопросы
Какой битрейт выбрать для вертикального видео?
Для 1080×1920 того же материала, что мы кодировали в 1920×1080, хватит битрейта ниже, чем у горизонтальной версии: кадр увеличен и обрезан по центру, и после интерполяции деталей в нём меньше. В нашем замере H.264 CRF 23 на вертикали дал 2,23 Мбит/с против 5,48 Мбит/с у полного кадра. Но считать это можно только от материала: если в кадре мелкий текст или тонкие детали, битрейт стоит поднять.
4K или 1080p для сдачи?
Сдавайте в том разрешении, в котором клиент смотрит результат, а не в исходном. Если ролик идёт на телефонную площадку, 4K обычно не нужен: файл по нашим замерам получается примерно вдвое тяжелее — 44 092 600 байт против 20 558 332, а выигрыша в картинке апскейл не даёт. 4K имеет смысл, только если исходник снят в 4K: наш апскейл добавил веса, но не деталей. Апскейл с 1080p в 4K качества не добавляет: в нашем замере битрейт на пиксель у такого файла оказался ниже, чем у честного 1080p.
Нужен ли 10-бит?
Для сдачи — обычно нет: 8-бит хватает, а 10-бит добавляет к файлу объём, который в типовой сдаче никому не нужен. 10-бит имеет смысл, когда исходник снят в 10 бит: ProRes 422 — 10-битный кодек, а ProRes 4444 XQ держит до 12 бит на канал. Если исходник 8-битный, переводить в 10-бит на этапе сдачи бессмысленно: 10-битный файл не добавит деталей, которых нет в исходнике.
Что почитать дальше
Нужно сделать на заказ?
Мы делаем такие проекты на заказ — с теми же настройками, которые разбираем в материале.