Видео-CDN: как на самом деле работает доставка HLS

Почему видео отличается от всего остального, что вы отдаёте

Веб-страница весит пару мегабайт. Десять минут видео в 1080p весят порядка гигабайта на одного зрителя. Этот разрыв в три порядка — причина, по которой видео, которое как просмотр страницы было бы погрешностью округления, может насытить origin-сервер в день, когда станет популярным: сто одновременных зрителей одного файла — это сто непрерывных высокоскоростных потоков с одной машины.

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

HLS без мистики: это плейлист и папка файлов

HLS (HTTP Live Streaming) выглядит экзотикой, пока вы не откроете файлы. Кодировщик режет видео на короткие сегменты — по несколько секунд каждый — и пишет текстовый плейлист (.m3u8), который перечисляет их по порядку. Плеер скачивает плейлист, затем забирает сегменты один за другим по обычному HTTP, на несколько секунд опережая то, что показывает. Адаптивное качество — тот же приём дважды: мастер-плейлист указывает на несколько вариантных плейлистов (1080p, 720p, 480p), и плеер переключается между ними по мере изменения пропускной способности.

Следствие стоит проговорить прямо: в пути доставки нет никакого специального видеопротокола. Ни сокетов, ни стримингового сервера, ни экзотической инфраструктуры. Каждый запрос плеера — это GET небольшого статического файла, а небольшие статические файлы, отдаваемые миллионы раз, — это ровно та нагрузка, ради которой существует edge CDN.

Вариантный плейлист — обычный текст, указывающий на обычные файлы

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:6.000,
segment_000.ts
#EXTINF:6.000,
segment_001.ts
#EXTINF:6.000,
segment_002.ts
#EXT-X-ENDLIST

Конвейер VOD: закодировать один раз, сохранить один раз, раздавать с edge

Для видео по запросу конвейер состоит из трёх станций. Закодировать один раз — на вашей машине или в сборке: ffmpeg превращает исходное видео в папку «плейлист плюс сегменты» одной командой. Сохранить один раз — в S3-совместимом объектном хранилище, которое существует именно для файлов «записал один раз, читаешь много раз». Раздавать с edge: когда бакет стоит за CDN, первый зритель каждого сегмента наполняет кеш, а все после него получают ответ рядом с собой, пока ваше хранилище отвечает на каждый уникальный файл примерно один раз.

На cdn.com.tr хранилище и edge — одна платформа, так что это не интеграционный проект: создайте бакет, загрузите папку, и edge того же аккаунта — вместе с WAF и защитой от DDoS — встанет перед ним.

От исходного файла до потока, раздаваемого через CDN

# 1) encode into HLS (6-second segments, one quality for brevity)
ffmpeg -i talk.mp4 -c:v h264 -c:a aac \
  -hls_time 6 -hls_playlist_type vod \
  -hls_segment_filename 'talk/segment_%03d.ts' talk/playlist.m3u8

# 2) create the bucket and an access key (panel works too)
cdnctl object-storage buckets create --account <uuid> --name videos
cdnctl object-storage access-keys create --account <uuid> --bucket <bucket_uuid>

# 3) upload the folder with the standard AWS CLI
aws --endpoint-url https://s3.cdn.com.tr s3 sync ./talk s3://videos/talk

# the player now points at the playlist behind your CDN hostname:
#   https://video.example.com/talk/playlist.m3u8

Правила кеширования, которые решают судьбу доставки видео

Видео вознаграждает ту дисциплину заголовков кеширования, которую остальной контент лишь ценит, потому что два типа файлов в HLS-потоке требуют противоположного обращения.

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

Плейлисты — подвижная часть. Для готового VOD они меняются, только когда вы заменяете видео, так что час — нормально. Как только плейлист начинает дописываться — а именно так работает почти-live, — его нужно кешировать секундами, потому что плеер перечитывает его, чтобы узнать о новых сегментах. Ошибка в этом одном заголовке — классический видеобаг: зрители застыли на старых сегментах, пока плейлист говорит им, что ничего нового не существует.

На cdn.com.tr вы задаёте именно это разделение правилами доставки в панели: одно правило на путь сегментов с долгим временем, другое на *.m3u8 с коротким.

Детали, которые кусаются: диапазоны, CORS и сжатие

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

Второе — CORS: если плеер работает на другом хосте, чем видеофайлы, браузер потребует заголовки Access-Control-Allow-Origin на сегментах и плейлистах, и симптом забывчивости — плеер, который работает в отдельной вкладке, но не встроенный в вашу страницу.

Третье — сжатие: для медиа выключите его. Видео и аудио уже сжаты кодеком; gzip для сегмента .ts тратит CPU, не экономя ничего. Плейлисты можете сжимать — это текст, — но выигрыш микроскопический. Edge уже знает, что медиатипы пересжимать не нужно; заметка важна для конфигурации вашего собственного origin.

А live-стриминг? Честный ответ

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

Что live добавляет — это всё, что происходит до появления файлов: ingest (приём сигнала камеры по RTMP или SRT), транскодирование в реальном времени в лестницу качеств и упаковка — работающий конвейер со своими режимами отказа, а не папка, которую загружают один раз. Такой конвейер не собирают между делом, и это не то, что делает self-serve продукт этой платформы: cdn.com.tr — это половина истории, отвечающая за хранение и доставку. Если вашему проекту нужна полная live-цепочка, обсудите это с нами напрямую, вместо того чтобы втискивать её в рабочий процесс формы VOD, — и остерегайтесь любого провайдера, который продаёт «live-стриминг», не говоря, кто управляет кодировщиком.