Себестоимость мегабайта видео: от загрузки до просмотра

MAATRIX

Когда считают, во сколько обходится видеосервис, почти всегда берут только тариф за гигабайт на диске и на этом успокаиваются. Реальная себестоимость мегабайта видео складывается из четырёх разных статей — загрузки, транскодирования, хранения всех версий файла и раздачи при каждом просмотре, — и именно последняя, самая незаметная на старте, съедает бюджет при росте аудитории. Разберём весь путь от загрузки исходника до воспроизведения у зрителя и покажем, где на самом деле накапливаются расходы.

Почему «цена хранения» — это не себестоимость видео

Первая ошибка почти всех прикидок «на салфетке» — взять цену хранилища за терабайт в месяц, умножить на объём каталога и назвать это себестоимостью. Хранение — только одна из четырёх статей, причём часто не самая крупная.

Полный жизненный цикл одного видеофайла выглядит так:

1. Загрузка — исходник попадает на сервер, где-то временно лежит перед обработкой.
2. Транскодирование — из одного исходника нарезается набор версий под разные устройства, каналы и разрешения.
3. Хранение — на диске остаётся не один файл, а исходник плюс весь набор транскодированных копий.
4. Раздача — при каждом просмотре байты снова уходят по сети, и так столько раз, сколько у видео просмотров.

Если считать только пункт 3, ошибка будет тем больше, чем популярнее контент. Ролик, который никто не смотрит, действительно стоит примерно как место на диске. Ролик с миллионом просмотров стоит совсем другую сумму, и в ней хранение — почти незаметная строчка. Дальше разберём каждый этап отдельно, чтобы было видно, где именно и почему растут расходы.

Этап 1. Загрузка и хранение исходника

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

• Место на диске под приём. Загрузка обычно идёт во временный bucket или директорию — быстрый диск (NVMe) нужен не для длительного хранения, а чтобы принять поток без просадки записи. Держать весь входящий трафик на дорогом NVMe постоянно не нужно, но на момент приёма это требование к IOPS, а не к ёмкости.
• Сетевой трафик на приём. Если файлы принимаются не в том дата-центре, где идёт обработка, — это отдельный входящий трафик. У большинства провайдеров входящий (ingress) трафик бесплатен или дешевле исходящего, но не у всех — стоит свериться с тарифом конкретного провайдера.
• Валидация и защита. Проверка на битые файлы, вирусы, соответствие формату — это CPU-время ещё до очереди на транскодирование. Небольшая, но ненулевая статья на масштабе тысяч загрузок в день.
• Решение — хранить исходник или нет. Часть сервисов держит исходник вечно (на случай пересчёта в новый кодек через пару лет), часть удаляет его через фиксированный срок после успешного транскодирования. Исходник обычно самый тяжёлый файл в цепочке, и если он не нужен постоянно, это прямой рычаг экономии.

Уже на этом этапе видно: себестоимость начинается не с «мегабайта на диске», а с решений о том, где и как долго лежит необработанный файл.

Этап 2. Транскодирование — самый вычислительно затратный этап

Один и тот же ролик должен воспроизвестись на телефоне с медленным мобильным интернетом, на телевизоре 4K по Wi-Fi и в браузере на ноутбуке с посредственной видеокартой. Под это готовится не одна копия, а «лестница» рендиций (rendition ladder) — набор версий с разным разрешением и битрейтом, обычно от 240p до 1080p или 4K, часто в нескольких кодеках сразу (H.264 — для совместимости со старыми устройствами, H.265/HEVC или AV1 — для экономии трафика на новых).

Это самый ресурсоёмкий этап всей цепочки, и вот почему:

• Кодирование — это CPU/GPU-время, а не место на диске. Каждая рендиция — это полный проход кодировщика по всему видеоряду. Чем больше рендиций в лестнице, тем больше проходов.
• Кодеки сильно различаются по вычислительной цене. H.264 кодируется относительно быстро, но даёт больший размер файла при том же качестве. H.265 и AV1 сжимают плотнее (экономят на хранении и раздаче), но кодирование у них заметно тяжелее по CPU — AV1 в этом смысле самый прожорливый на энкодинге, хотя и самый экономный на выдаче. Точное соотношение процессорного времени зависит от настроек качества и версии энкодера — на своём железе и пресетах оно будет своим.
• GPU-кодирование ускоряет проход, но не бесплатно. Аппаратные энкодеры (NVENC у NVIDIA, QuickSync у Intel, VCE/VCN у AMD) кодируют быстрее чистого CPU-энкодинга, но обычно проигрывают программным кодировщикам в эффективности сжатия при равной нагрузке — либо скорость ценой чуть большего файла, либо время CPU ради лучшего сжатия. Выбор — компромисс между арендой GPU-сервера и стоимостью хранения плюс раздачи более тяжёлых файлов.
• Пересчёт при смене стандарта — скрытая будущая статья. Решение добавить AV1-рендиции ко всей библиотеке — это не инкрементальная работа, а повторное кодирование каталога с нуля. Чем больше библиотека, тем дороже такой пересчёт, и об этом стоит думать заранее.

Практический вывод: количество рендиций в лестнице — это прямой рычаг стоимости транскодирования. Разумная лестница даёт покрытие большинства устройств без избыточных промежуточных ступеней «на всякий случай».

Этап 3. Хранение всех версий, а не одного файла

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

Здесь работают привычные механизмы экономии на хранении, но применительно именно к видео они выглядят так:

• Уровни хранения (storage tiers). Свежий и популярный контент — на быстром диске или в «горячем» object storage с низкой задержкой отдачи. Контент старше нескольких месяцев с падающей популярностью — в более дешёвом холодном хранилище, откуда отдача чуть медленнее, но это не критично для архива.
• Не все рендиции равноценны по востребованности. Аналитика просмотров часто показывает, что часть верхних по качеству рендиций (например, 4K) запрашивается заметно реже расчётной доли — не у всех зрителей канал и устройство это тянут. Повод пересчитать лестницу под реальный профиль аудитории, а не под теоретический набор устройств.
• Дедупликация и удаление неудачных проходов. В автоматизированном пайплайне транскодирования иногда остаются черновые или повторные прогоны кодирования, которые никуда не выкатили, но и не удалили — классический источник «фонового» роста хранилища без видимой причины.
• Object storage vs файловая система. Для большого каталога видео S3-совместимое объектное хранилище обычно удобнее и предсказуемее по цене за терабайт, чем файловая система на блочном диске — подробнее в разборе объектное хранилище против файловой системы.

Хранение всех версий — это статья, которая растёт линейно с размером каталога и с числом рендиций на файл. Она предсказуема и её легко бюджетировать заранее, в отличие от следующего этапа.

Этап 4. Раздача — трафик умножается на число просмотров

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

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

Несколько нюансов, которые часто упускают при прикидке бюджета на раздачу:

• Исходящий (egress) трафик почти всегда самая дорогая единица в счёте провайдера. Входящий трафик и хранение обычно стоят дешевле в пересчёте на гигабайт — у нас есть отдельный разбор этой асимметрии в статье egress-трафик: статья счёта, о которой узнают поздно.
• CDN не убирает стоимость раздачи, а перераспределяет её. Кеширующая сеть снижает нагрузку на источник и ускоряет доставку, но трафик через CDN тоже тарифицируется — иногда выгоднее прямой раздачи с сервера, иногда нет, зависит от объёма и провайдера. Сравнение разобрано в статье CDN против раздачи со своего сервера: когда окупается.
• Adaptive bitrate снижает трафик за счёт качества под слабый канал. HLS и DASH позволяют плееру на лету переключаться на менее тяжёлую рендицию при просадке скорости — это одновременно улучшает опыт зрителя и снижает счёт за раздачу.
• Досмотры и перемотки считаются заново. Каждая перемотка — это дополнительные сегменты, которые плеер запросит повторно. Реальный объём переданных данных за один «просмотр» в сегментированной доставке обычно выше номинального размера рендиции.

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

Как посчитать себестоимость мегабайта для своего каталога

Универсальной формулы с одним числом не существует — слишком много зависит от профиля аудитории и выбранной лестницы рендиций. Но структуру расчёта можно выстроить так, чтобы не упустить ни одну статью:

Себестоимость_ролика = 
    Стоимость_загрузки (ingress + временное хранение + валидация)
  + Стоимость_транскодирования (CPU/GPU-часы × число рендиций × длительность ролика)
  + Стоимость_хранения (Σ размер каждой версии × тариф хранения × срок хранения)
  + Стоимость_раздачи (Σ размер отданной рендиции × число просмотров этой рендиции × тариф egress)

Практический порядок действий:

1. Возьмите фактическую статистику за последний период — сколько загружено роликов, сколько минут суммарно оттранскодировано, сколько терабайт отдано наружу. Это данные из логов пайплайна и биллинга провайдера, а не из документации на кодек.
2. Разделите раздачу по рендициям. Если аналитика плеера умеет логировать, какая рендиция была отдана, вы увидите реальное распределение — часто окажется, что основная масса трафика приходится на две-три средние рендиции, а не на топовое качество.
3. Сопоставьте затраты с числом просмотров, а не с числом роликов. Себестоимость минуты видео с 10 просмотрами и с 10 миллионами просмотров различается на порядки именно из-за раздачи — при одинаковых затратах на загрузку, транскодирование и хранение.
4. Пересчитывайте регулярно, а не один раз при запуске. Профиль устройств аудитории и стоимость трафика у провайдеров меняются, лестница рендиций со временем тоже может устареть — то, что было оптимально год назад, может быть избыточным или недостаточным сейчас.

Такой расчёт удобно вести хотя бы раз в квартал по выборке из топ-100 самых просматриваемых роликов и топ-100 наименее просматриваемых — разница в структуре затрат между ними наглядно покажет, где на самом деле накапливается счёт.

Где реально экономят на масштабе

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

Отдельно стоит сказать про последний пункт: для проектов с предсказуемым и уже немаленьким объёмом трафика аренда собственного сервера под транскодирование и раздачу часто оказывается дешевле облачных видеосервисов с тарификацией по минутам обработки и гигабайтам раздачи — но это требует, чтобы кто-то в команде умел настраивать и поддерживать пайплайн самостоятельно. У нас есть отдельный разбор именно этого выбора — сколько обходится свой видеохостинг: там разложены реальные статьи расходов при переносе с готового SaaS-видеохостинга на собственную инфраструктуру.

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

Частые вопросы