Спутник или земной интернет? Почему даже крупные бродкастеры спускаются с небес на землю

10.08.2024

6мин. чтения

Спутник или земной интернет

В 2022 году произошло знаковое событие для медиаиндустрии. Компания Olympic Broadcasting Services, которая ведет трансляцию Олимпийских игр, запустила доставку контента правообладателям через обычный интернет — в дополнение к спутниковой трансляции. Видео всех событий из Пекина впервые транслировалось в 4K качестве.

Для олимпийского вещания это был настоящий переворот. Начиная с 1964 года Игры транслировались через спутник. Сегодня самым современным решением для профессионального продакшена и бродкастинга стала доставка контента через интернет.

В этой статье попробуем разобраться, почему только к 2020-м годам профессионалы перестали бояться интернета для передачи данных. И расскажем, какую роль в этом сыграл SRT-протокол.

Спутниковые тарелки не сдавали позиции до последнего

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

Однако долгое время интернет использовали только для доставки услуг конечным пользователям, а не для передачи видео между студиями, везателями и ТВ-операторами. В начале 2010-х годов запустилась стриминговая платформа Twitch, которая быстро завоевала популярность. А после и YouTube открыл видеотрансляции для своих пользователей.

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

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

Против использования интернета для трансляций в то время говорили несколько факторов:

1. Ненадежность соединения. Не всегда и не везде была достижима передача по сети без задержек и потерь информации. Протокол RTMP, который использовали YouTube и Twitch, имел проблему Head of line blocking: из-за одного потерянного пакета данных можно было лишиться многих секунд видео. Протокол HLS от Apple обеспечивал более стабильное вещание, но для этого трансляция задерживалась на полминуты и дольше. Для спортивных мероприятий и прямых включений на ТВ это было недопустимо.

2. Особенности ТВ-стандартов. ТВ требовало определенных кодеков, не все из которых были совместимы с существующими протоколами передачи данных. Каждый производитель софта и оборудования считал своим долгом выпустить проприетарное решение, что создавало дополнительные сложности для передачи видео и постпродакшена.

3. Несовместимость оборудования. Для того, чтобы отправить видео из точки трансляции в студию по интернету, нужна была дополнительная техника. Приходилось закупать недешевое оборудование, лицензированное создателями кодеков и протоколов передачи данных.

Но уже через несколько лет ситуация начала меняться.

Надежный и недорогой интернет стал нормой. Спутниковые каналы не могли конкурировать с ним по цене и доступности. Бродкастеры и дистрибьюторы контента поняли, что смогут снизить расходы и улучшить свои позиции на рынке, если освоят интернет.

Вопрос был только в подходящих технологиях.

Появление SRT-протокола в открытом доступе

К 2013 году самыми популярными решениями для передачи видео были RTMP- и HLS-протоколы.

RTMP (Real Time Messaging Protocol) — проприетарная разработка Adobe на основе TCP, которую используют YouTube Live, Facebook Live, Twitch. Разработанный в 1996 году и завоевавший популярность благодаря Flash Player, этот протокол до сих пор широко используется для загрузки видео в соцсети. RTMP не умеет передавать аудиодорожки на нескольких языках и требует очень качественного интернет-соединения, чтобы исключить потерю данных. Эти сложности, а также ограничения, связанные с поддержкой кодеков, делали его непривлекательным для ТВ.

HLS (HTTP Live Streaming) — детище Apple родом из 2000-х. Некоторое время он поддерживался только на устройствах с iOS и MacOS. Особенностью протокола была функция адаптивной скорости передачи данных: она обеспечивала наилучшее качество воспроизведения вне зависимости от скорости интернета, ПО или устройства. Но из-за фокуса на качестве HLS работал с большой задержкой: трансляция могла отставать на полминуты и больше. Для прямых включений и спортивных трансляций на телевидении непредсказуемая задержка была главным препятствием.

Техническое решение, которое изменило рынок, предложила американская компания Haivision. В 2013 году она создала протокол Secure Reliable Transport (SRT) для передачи видео на основе UDP, который изначально был встроен в кодеры и декодеры ее собственного производства. В 2017 году компания выложила протокол в опенсорс и основала «Альянс SRT», благодаря которому протокол быстро стал индустриальным стандартом. Многие крупные компании поддержали SRT и вошли в «Альянс»: YouTube, Sony, Microsoft, Alibaba Cloud и другие.

В чем же особенность SRT и почему именно его сегодня выбирают компании для передачи ТВ-контента?

Низкие требования к скорости соединения

Для передачи видео в самом высоком разрешении SRT достаточно скромной скорости интернета: около 15-20 Мбит/с. При ошибках соединения протокол запрашивает и повторно передает только недополученные данные, не перегружая сеть.

Совместимость оборудования

SRT не зависит от конкретных видеокодеков и отвечает только за передачу данных. Для его использования не нужно специальных знаний и обученных специалистов. Достаточно иметь кодер, декодер или комплексное оборудование, которое включает возможность конвертировать NDI и SDI-потоки, используемые в ТВ-производстве. Благодаря открытому коду на рынке достаточно много качественных и доступных решений для этих задач.

Поддержка CBR и VBR

В спутниковых сетях, эфирном или кабельном телевидении используют MPEG-TS с постоянным битрейтом (CBR - Constant bitrate). Тогда как для OTT и других интернет-сервисов предпочтительнее видео с переменным битрейт (VBR - Variable bitrate), который меняется в зависимости от контента и загруженности сети.

Надежность

SRT минимизирует влияние джиттера и меняющейся пропускной способности. Протокол использует ARQ (Automatic Repeat reQuest) — интеллектуальный процесс повторной передачи пакетов. Благодаря этому механизму коррекции ошибок риск потери пакетов сведен к минимуму.

Безопасность

Протокол поддерживает шифрование AES-128 бит и AES-256 бит. Это стандарт для систем высокой безопасности: перехватить и расшифровать такие ключи достаточно сложно. Кроме этого, запустить еще одну резервную линию с SRT проще и дешевле, чем спутниковую.

Непрерывность вещания

SRT лучше справляется с потоковым видео, чем его конкурент RTMP. При потере соединения в RTMP поток останавливается, а реконнект может занять до минуты. В случае потери пакета в SRT будут потеряны только несколько кадров, при этом сама трансляция продолжится.

Сколько это стоит

Выполним простое упражнение: посчитаем, во сколько обойдется прямая трансляция мероприятия через SRT-протокол. Чтобы не быть голословными, возьмем реальную стоимость решений Flussonic, которые сейчас решают все связанные задачи.

Предположим, что у себя на сайте вы хотите сделать прямой репортаж с запуска космического корабля на Марс. На удаленном космодроме будут установлены 2 видеокамеры для съемок с разных ракурсов, и еще одна камера будет снимать ведущего неподалеку от места взлета.

Чтобы организовать репортаж через спутник, пришлось бы отправить на космодром ТВ-фургон с антенной, водителем, инженером и оплатить канал связи. По одному каналу можно передать только один сигнал с камеры. Переключать их пришлось бы на пульте в фургоне. Репортаж из фургона отправился бы через спутник в студию, а оттуда уже трансляцию отправили бы на сайт.

Для трансляции через интернет не нужно привозить ТВ-фургон. Достаточно подключить к интернету на космодроме сервер с установленным Flussonic Media Server и подключить к нему камеры. Все видео с камер можно отправлять отдельными потоками — до 20-30 штук. То есть одного медиасервера хватит на трансляцию даже с крупного мероприятия.

scheme

Для приема SRT-сигнала на студии тоже нужен Flussonic Media Server — или любое другое оборудование, которое принимает сигнал по этому протоколу и стримит его на сайт в нужном формате.

Две лицензии на Flussonic Media Server — для передачи сигнала с места трансляции и для его приема в студии — обойдутся всего в 23 800 рублей. А годовая подписка - в 238 000 рублей. При этом для подключения сервера не нужен отдельный инженер и особые настройки: справится даже непрофессионал.

Как начать использовать SRT для передачи видео

Сегодня SRT из технологии только для прямых трансляций превращается в стандарт для доставки ТВ-контента. Это удобный способ избавиться от недостатков, которые имеет спутник: высокой стоимости и ограниченной пропускной способности.

SRT не зависит от конкретного вендора благодаря открытому исходному коду и поддерживается множеством бесплатных инструментов. И хотя применение SRT сегодня ограничено передачей контента point-to-point и не подходит для дистрибуции конечным пользователям, он уже стал простым и дешевым аналогом спутника и оптоволокна.

Попробуйте платформу Flussonic Media Server, которая поддерживает множество форматов на входе и выходе и профессионально решает любые связанные с видео задачи. Свяжитесь с нами, чтобы рассказать о своем кейсе и попробовать бесплатную версию.

Ключевые слова:
Media Server SRT Protocols

Бесплатный триал Flussonic Media Server

Отправляя заявку, вы соглашаетесь с правилами и условиями

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

Если вы не получите от нас письмо в течение 30 мин, проверьте в спаме и добавьте наш адрес в избранные контакты.

Email: support@flussonic.com Phone: +7 (717) 272-78-21 +7 (495) 481-37-63