transport srt что такое
Transport srt что такое
Протокол SRT: особенности и перспективы
SRT (Secure Reliable Transport) — относительно молодой протокол передачи данных, разработанный на основе UDP. Данный протокол обеспечивает два вида гарантий в разных режимах работы — гарантию доставки данных или гарантию задержки доставки. Давайте посмотрим, чем он интересен.
История технологии
Впервые SRT был продемонстрирован в 2013 году. Изначально он разрабатывался Haivision для собственных решений. Новый протокол был нужен, чтобы использовать «публичный» интернет для передачи контента. Это сильно сокращало затраты на передачу данных по сравнению с протоколами, использующими спутниковый интернет или частные сети.
Сейчас SRT — это универсальный протокол и open-source решение. С 2017 года исходный код размещен на GitHub. Решение распространяется бесплатно по лицензии MPL-2.0.
В 2017 году Haivision совместно с WOWZA основали альянс SRT Alliance. Его цель — поддержка и развитие протокола. Сейчас членами Альянса являются более 300 компаний.
Почему SRT — особенный
Кроме открытого кода у протокола есть еще несколько преимуществ.
Высокая скорость передачи видео
Она достигается благодаря использованию протокола UDP. На скорость влияет и использование временных меток для каждого отдельного пакета данных, которые размещаются в начале. Благодаря этому объемы буфера данных при использовании SRT в разы меньше, чем при применении RTMP.
Но UDP не гарантирует доставку пакетов адресату: его даже прозвали «протокол ненадёжных датаграмм». При разработке SRT эта особенность UDP была учтена и исправлена.
Интеллектуальный механизм повторной передачи данных быстрый и эффективный
SRT идентифицирует каждый пакет по его порядковому номеру. Если на стороне получателя образуется разница больше чем в 1 порядковый номер, отправителю незамедлительно посылается отрицательное подтверждение получения пакета NACK, и он передается заново — только один пакет, а не группа, как при использовании TCP
Поддержка стандарта сжатия видео H.265 (HEVC)
Использование алгоритма шифрования AES
Протокол поддерживает шифрование AES 128/256 для защиты потокового видео. Алгоритм одобрен АНБ США и структурами, отвечающими за безопасность в других странах. К примеру, чтобы расшифровать ключ такого алгоритма шифрования, суперкомпьютеру, который расшифрует ключ DES за 1 секунду, потребуется более 149 000 000 000 000 лет.
SRT против RTMP. В чем разница?
В RMPT целостность проверяется к определенной последовательности данных. Если потеряется какой-то из пакетов, снова отправится только «потерянный» пакет, а не вся последовательность. А это снижает потребности в буферизации.
В зависимости от условий и типа передаваемого контента, SRT, в основе которого UDP, может обеспечить скорость в 3-5 раз больше, чем RTMP с TCP.
Немалую роль играет и открытость исходного кода протокола, в то время, как RTMP проприетарный и полностью принадлежит Adobe.
Еще одна особенность SRT — поддержка любых кодеков. RTMP этим похвастаться не может.
Перспективы развития протокола SRT
Учитывая количество членов Альянса, перспектив у него немало. Например, сейчас Haivision совместно с Microsoft ведет разработку облачного сервиса маршрутизации SRT Hub на базе платформы Azure. Фактически это говорит о создании мирового облачного сервиса, который позволит повысить скорость передачи потокового видео и снизить временную задержку.
Количество российских компаний, внедряющих в свои решения SRT, тоже увеличивается. Протокол используют такие компании, как Softvelum (в медиасервере Nimble Streamer), BirdDog (NDI-решение c поддержкой SRT). В Facecast тоже завершена разработка собственного SRT-приемника. Благодаря открытости исходного кода протокола, решение максимально адаптированно под наши особенности. Мы считаем, что SRT — это не только перспективная технология, но и большой, интересный инструмент для того, чтобы делать свои продукты ещё лучше. И этот инструмент будет становиться всё более продвинутым. Так зачем ждать, если можно использовать?
Особенности SRT-технологии: потоковое вещание с открытым исходным кодом и низкой задержкой времени
Видеотрансляции по общедоступным сетям
Коммерческие решения, предоставляемые для проведения видеотрансляций в режиме онлайн через публичный интернет — дороги, а также работают только с совместимыми устройствами одного производителя, что ограничивает использование.
Протокол SRT, имеющий открытый исходный код, а также гибкую спецификацию, работает подобно другим запатентованным решениям, однако дополнительно обеспечивает взаимодействие между устройствами разных производителей.
Развитие рынка вещательных технологий
До появления технологии SRT на рынке телекоммуникаций было мало экономически выгодных решений для передачи качественного видео. Резервирование спутниковых линий связи, использование PoP-интерфейсов и дорогих терминальных устройств — все это значительно усложняло проведение трансляций.
Современные устройства имеют ряд преимуществ, упрощающих эксплуатацию, например, возможность быстрой организации экстренного вещания с места событий, а ранее можно было передавать только предварительно записанные трансляции. Также это достоинство позволяет снизить затраты путем отказа от транспортировки дорогостоящего оборудования в удаленные локации, откуда осуществляется прямое включение, а также повысить оперативность, гибкость, сэкономить время, необходимое для организации трансляции.
Другое преимущество инновационных телекоммуникационных решений — способность к восстановлению потерянных при передаче пакетов данных, что позволяет сделать передаваемое видео максимально качественным.
Главный недостаток закрытых запатентованных решений — невозможность получать или отправлять видеопотоки с устройств сторонних фирм-производителей. Если два пользователя не владеют оборудованием одной и той же марки, они не смогут передавать друг другу видеоданные. Этот минус подвергает запатентованные решения риску исчезновения с рынка в недалеком будущем.
Инновационная SRT–технология
SRT — протокол, обладающий открытым исходным кодом, без оплаты за использование и лицензию (при внедрении в любое устройство или услугу), разработанный для устранения недостатков существующих решений по передаче видео через интернет. Протокол поддерживается множеством бесплатных инструментов, отличается простотой использования, экономичностью, а также совместимостью с мобильными приложениями.
Технология SRT позволяет использовать порт Ethernet, а также различные беспроводные сети для приема и передачи видеоконтента практически через любое доступное IP- соединение, обладающее высокой пропускной способностью. Встроенная функция исправления ошибок позволяет восстанавливать утерянные пакеты данных, а также отправлять их повторно с минимальной временной задержкой.
Протокол SRT использует прямое соединение от источника вещания к месту назначения, что уменьшает задержку по времени, устраняет потенциально уязвимую точку отказа на центральном сервере, сокращает время сквозного прохождения данных через сеть, тем самым снижая затраты на передачу данных.
Технологию SRT для организации потокового вещания используют крупнейшие корпорации Microsoft и MediaKind, спортивный медиа-конгломерат ESPN, а также Евровидение под управлением Европейского союза телевещания.
Технические аспекты SRT‑технологии
Для решения этой проблемы применяются два метода: метод прямой коррекции ошибок (FEC) и автоматический запрос повторной передачи (ARQ).
Алгоритм FEC сообщает специальные данные, представляющие собой информацию для восстановления поврежденных или утерянных пакетов, передаваемому цифровому потоку. Однако метод работает только в системах, обладающих повышенной пропускной способностью, которая может выдержать дополнительный трафик данных, возникающий при работе FEC или прерывании видеопотоков из-за высокого уровня ошибок.
Алгоритм ARQ устанавливает двустороннюю связь между источником видео и местом назначения. Исходящие пакеты снабжены порядковыми номерами для определения корректности их прохождения. При потере пакетов получатель может создать список отсутствующих данных и передать его отправителю для повторной сессии, которая может повторяться несколько раз. Работа алгоритмов ARQ требует использования кэш-памяти (для хранения пакетов с их последующей повторной передачей), а также присутствия буфера на месте приема для упорядочивания пакетов перед отправкой.
На каждом пакете данных протокол SRT проставляет метки времени, имеющие высокое разрешение, что способствует точному воспроизведению видеопотоков на выходе приемного устройства. Пакеты отправляются в формате UDP, который обеспечивает передачу данных с низкой временной задержкой, а также незначительными издержками трафика.
Значительно уступает SRT популярный HTTP протокол, используемый современными медиасервисами для передачи видео в режиме онлайн. Его отличают сквозная задержка до 30 секунд, большая задержка по времени при потоковой передаче видео, что затрудняет или делает невозможной коммуникацию между сотрудниками, находящимися на разных точках линии связи.
Основа HTTP — протокол TCP. Он не фиксирует величину задержки, не способен пропускать некачественные байты, отправляя их повторно неограниченное количество раз, перегружая сеть, что приводит к «замораживанию» кадров и может стать причиной автоматически выполняемого сброса скорости передачи данных.
Соединение по протоколу SRT между двумя устройствами начинается с установления контакта для обмена информацией в трех возможных режимах:
● Режим вызывающего абонента (Caller mode) — попытки подключения конечной точки SRT- соединения к удаленному устройству при помощи известного адреса или номера порта UDP;
● Режим прослушивания (Listener mode) — непрерывный мониторинг входящего трафика на предмет наличия конкретного адреса, а также номера порта в ожидании соединения с вызывающим устройством;
● Режим встречи (Rendezvous mode) — одновременное взаимодействие обеих конечных точек SRT- соединения в вышеописанных режимах для упрощения соединения через определенные виды межсетевых экранов.
Каждый режим требует паролей, а также двустороннего подтверждения идентичности конечной точки перед началом передачи данных.
После установления контакта устройства обмениваются информацией о текущих возможностях, производительности линии связи, ключах шифрования.
SRT-Технология для потоковой передачи видео с низкой временной задержкой и открытым исходным кодом
Опубликовано в журнале ТКТ #05 (721) 2020
Передача видео через общедоступные сети
Современные технологии позволяют передавать высококачественное видео в режиме реального времени через публичный интернет. На сегодняшний день доступно множество запатентованных коммерческих решений, но эти отдельные системы подразумевают значительную ежемесячную плату за использование и ограничены в работе только с совместимыми устройствами – как правило от одного поставщика. SRT-протокол (Secure Reliable Transport) – это протокол передачи данных с открытым исходным кодом и гибкой спецификацией, находящийся в свободном доступе, который работает так же или даже лучше, чем другие аналогичные запатентованные решения, но в то же время обеспечивает возможность работы между устройствами разных производителей. Пользователи SRT-протокола могут выбирать наилучшие продукты для своих конкретных потребностей, в то же время они могут обмениваться видеопотоками с другими организациями и избегать «привязки» к конкретным поставщикам услуг и производителям оборудования.
Описание технологии SRT
Рисунок 1.
Всякий раз, когда видеотрансляция передается из одного места в другое, она подвержена битовым ошибкам и потере пакетов данных. Для видео профессионального качества эти ошибки могут привести к значительному ухудшению итогового качества, даже при уровне потерь, который обычно встречается при передаче через сеть интернет. На рисунке 1 показано, насколько сильно ухудшается качество передаваемого изображения даже при относительно небольшом уровне потери пакетов данных. Для исправления ошибок при передаче данных через сеть обычно используются два метода: метод прямой коррекции ошибок FEC (Forward Error Correction) и автоматический запрос повторной передачи ARQ (Automatic Repeat reQuest). Они оба используются в современных системах передачи видео. На рисунке 2 показано, как оба метода влияют на передачу пакетов данных через сеть.
Рисунок 2.
Алгоритм FEC добавляет специальные данные к передаваемому цифровому потоку, представляющие собой информацию, которую приемник впоследствии может использовать для восстановления поврежденных или отсутствующих пакетов. Одним из недостатков систем на основе алгоритма FEC является то, что дополнительные пакеты данных отправляются всегда – независимо от того, нужны ли они получателю или нет. Поэтому если линия связи работает безошибочно, дополнительный трафик, используемый для передачи пакетов FEC, используется напрасно. Второй недостаток заключается в том, что максимальная потеря пакетов данных, которая может быть допущена, связана с пропускной способностью сети, выделенной дополнительно для передачи данных восстановления FEC, и ограничена этим значением.
Алгоритм ARQ работает путем установления двусторонней связи между источником передачи видео и местом назначения. Каждому исходящему пакету данных присваивается уникальный порядковый номер, и получатель использует его, чтобы определить, все ли входящие пакеты были приняты корректно и в правильном порядке. Если пакеты потеряны при передаче, получатель создает список порядковых номеров отсутствующих пакетов и автоматически передает запрос отправителю для повторной передачи. В случае передачи через сети с высоким уровнем ошибок (как это может произойти в интернете в определенное время суток или при возникновении сбоев) этот процесс может повторяться несколько раз. Для работы ARQ-алгоритма требуется кэширование данных в месте отправки (для временного хранения пакетов в случае их повторной передачи) и наличие буфера данных в месте приема, чтобы упорядочить пакеты в правильном порядке перед их отправкой в декодер.
SRT-технология использует ARQ-алгоритм прежде всего потому, что он хорошо справляется с типами ошибок, которые наиболее часто возникают при передаче данных через интернет. Там преобладают случайные потери пакетов данных. С помощью ARQ-алгоритма эти ошибки могут быть легко исправлены посредством простой повторной передачи пакетов данных, которые не поступили к получателю. Если пакеты, содержащие битовые ошибки, поступают в приемник, они распознаются как отсутствующие пакеты и отправителю предлагается повторно передать их. В качестве дополнительного преимущества, SRT-протокол проставляет метки времени с высоким разрешением в каждом пакете, что позволяет точно воспроизводить видеопотоки на выходе приемника. Это гарантирует, что последующие устройства и программы смогут правильно декодировать видео- и аудиопотоки. Каждый пакет, отправляемый SRT, использует UDP-формат пакетов данных, который обеспечивает передачу пакетов с малыми задержками по времени. Большинство сетей передачи видео в режиме реального времени, разработанных для профессиональных приложений, используют UDP формат, поскольку он предлагает стабильную и легко воспроизводимую систему передачи пакетов данных с постоянной пропускной способностью. Это противоположно непредсказуемым TCP-соединениям, например HTTP-протоколу.
Что не так с потоковой передачей по HTTP-протоколу?
Многие современные медиа-сервисы, обеспечивающие в том числе передачу видео в режиме реального времени, транслируют данные через публичный интернет с использованием технологии потоковой передачи видео по HTTP протоколу. Примерами могут служить сервисы Netflix, YouTube и другие медиасети.
Может показаться, что потоковая передача видео по HTTP протоколу является жизнеспособным решением для всех типов приложений, но у него есть несколько недостатков. Прежде всего, это значительная задержка по времени при реализации потоковой передачи видео. Сквозная задержка длительностью до 30 секунд – не редкость в подобных решениях из-за большого количества этапов обработки данных и множества промежуточных буферов на пути прохождения данных. При таких временных запаздываниях часть профессиональных применений автоматически отпадает.
Кроме того, величина задержки не фиксирована: при хороших условиях работы сети задержки могут уменьшаться, но, когда условия плохие – они могут резко возрасти. Это связано с основой протокола, используемого для HTTP передачи видео и известного как TCP-протокол. TCP требует, чтобы все байты потока были полностью доставлены в их первоначальном порядке. Теоретически, при передаче видео несколько потерянных байтов могут быть исправлены или в худшем случае проигнорированы. С TCP-протоколом это сделать невозможно; вместо этого протокол будет продолжать повторять попытку отправки отсутствующих данных столько времени, сколько на это потребуется. Это и приводит к частому появлению замороженных кадров и надписи «буферизация».
Третья особенность TCP-протокола может быть не всегда заметна, но при этом очень важна для видеоприложений. Она заключается в автоматическом сбросе скорости передачи пакетов данных, когда происходит перегрузка сети. Такое поведение уместно с целью снижения общей нагрузки на сеть, но оно не подходит для передачи видеотрансляций, которые не способны выдержать снижение ниже своей номинальной скорости.
В целом, TCP-протокол играет важную роль в доставке видео пользователям, но описанные особенности делают его непригодным для передачи видеотрансляций в режиме реального времени для многих профессиональных задач.
Как происходит соединение по протоколу SRT?
Каждое SRT-соединение между двумя устройствами начинается с процедуры установления контакта и обмена важной информацией о текущих возможностях.
Три различных режима установления контакта предоставляются устройствам для установки связи друг с другом и передачи сведений, необходимых для отправки и получения пакетов. Первый – это режим вызывающего абонента (Caller), когда конечная точка SRT-соединения пытается подключиться к удаленному устройству по известному адресу и номеру UDP-порта. Второй – это режим прослушивания (Listener), в котором SRT-устройство непрерывно мониторит входящий трафик на наличие определенного адреса и номера порта, ожидая соединения с вызывающим устройством. Третий – это режим «встречи» (Rendezvous), где оба участника SRT-соединения одновременно действуют как в вызывающем (Caller), так и в прослушивающем (Listener) режиме, чтобы упростить установление соединения через определенные типы межсетевых экранов. После завершения процедуры установления контакта вызывающее и ожидающее устройство обмениваются информацией о своих возможностях и конфигурации. Оба устройства должны знать об общей временной задержке прохождения данных по линии связи, чтобы установить корректные размеры буфера данных для компенсации задержки при повторной передаче пакетов. Пропускная способность линии связи также может быть оценена и сообщена, чтобы определить требуемую степень сжатия видео для комфортного прохождения потока через сеть в пределах ее пропускной способности. При желании поток может быть закрыт паролем с использованием технологии 128/256-битного AES-шифрования.
SRT справляется с сетевыми задержками
Благодаря гибкой, адаптивной системе управления буфером данных, SRT-протокол может хорошо работать в сети с диапазоном задержек от нескольких миллисекунд до нескольких секунд, таким образом справляясь с передачей любого контента в частной сети или в глобальном интернете.
Легкое прохождение сетевых экранов
Ни одна современная организация, связанная со средствами массовой информации, не позволяет корпоративным системам иметь неограниченный доступ к интернету или из него. Сетевые экраны защищают сетевые устройства, такие как ПК и серверы, от нежелательных внешних подключений и атак. Процедура установления контакта, используемая SRT-протоколом, поддерживает исходящие соединения без необходимости открытия постоянных и опасных внешних портов в брандмауэре, тем самым поддерживая корпоративную политику безопасности.
Точная синхронизация видеопотоков
Многие сжатые форматы видео чувствительны к сбоям, вызванным изменениями синхронизации между различными частями потоков данных. В SRT-протоколе в каждом пакете данных есть временная метка высокого разрешения, назначенная отправителем, которая может быть использована получателем для точного воссоздания временных соотношений видеопотоков независимо от изменений и задержек в сети. Кроме того, во время процедуры установления контакта конечные устройства SRT-потока устанавливают стабильный профиль сквозной задержки, устраняя необходимость наличия собственных буферов данных у промежуточных устройств, чтобы справляться с изменяющимися задержками при передаче потоков данных.
Центральный сервер не требуется
Некоторые запатентованные системы по передаче медиаданных требуют использования централизованного сервера между отправителем и получателем, что увеличивает стоимость системы и временную задержку. SRT-соединения могут быть установлены непосредственно между двумя устройствами – в этом случае центральный сервер не нужен. Но при желании SRT-протокол может быть реализован и с использованием централизованных серверов и точек ретрансляции, например в таких приложениях как облачные системы сбора данных.
Принят ведущими поставщиками услуг
SRT – это открытый стандарт, в настоящее время поддерживаемый сообществом большого количества активных поставщиков технологий, обеспечивающий разнообразие продуктов и позволяющий избежать рисков и затрат, связанных с привязкой только к одному поставщику. В этом сообществе энтузиастов многие решения, предназначенные для самого широкого спектра профессиональных приложений, теперь поддерживают SRT стандарт, включая IP-камеры, кодеры, декодеры, шлюзы, OTT- и CDN- платформы.
Как первоначальный разработчик протокола SRT, компания Haivision также является одним из основателей SRT Alliance и проекта SRT Open Source для потоковой передачи видео с низкой задержкой по времени. Компания Haivision предлагает ряд различных технологических решений, предназначенных для многих типов приложений для передачи медиаданных.
Статьи
SRT, HLS и MPEG-DASH – будущее потокового вещания
Компании и провайдеры сетей доставки контента (CDN) готовятся к будущему, где потоковое вещание получит ещё более широкое распространение. Поэтому потребность в более эффективных протоколах такого вещания становится как никогда актуальной. Встречайте будущее живых трансляций – SRT, HLS и MPEG DASH. Давайте посмотрим, что представляет собой каждый из этих протоколов прямой трансляции, их преимущества и применение. А чтобы помочь вам выбрать тот, который подходит именно вам, в конце этой статьи приведено краткое сравнение.
Secure Reliable Transport (SRT)
SRT – восходящая звезда потоковой передачи. Протокол обеспечивает высокое качество видео и аудио с низкой задержкой по ненадёжному общедоступному Интернету. Фактически вы можете контролировать величину задержки и устранять такие проблемы, как дрожание из-за потери пакетов в плохих сетях. SRT также упрощает обход файерволов без помощи IT-специалиста, а также экономичен при развёртывании в существующей сетевой инфраструктуре. Кроме того, SRT предлагает безопасную потоковую передачу с 256-битным шифрованием AES.
SRT – это потоковый протокол с открытым исходным кодом, который набирает популярность благодаря «Альянсу SRT», объединяющему усилия многих лидеров отрасли и разработчиков с целью его продвижения и внедрения. Epiphan Video является сертифицированным членом «Альянса SRT» наряду с YouTube, Akamai, Wowza и другими. SRT включает в себя популярное программное обеспечение, в которое уже встроены OBS Studio, gstreamer и VLC.
Это фактически «технология замены спутника» – низкая стоимость и способность SRT доставлять высококачественный контент через Интернет в режиме, близком к реальному времени, дают вещателям жизнеспособную альтернативу дорогостоящей спутниковой технологии.
Преимущества
Как работает SRT
Между источником SRT (кодер) и получателем SRT (декодер) устанавливается выделенная линия связи для управления и восстановления пакетов. Получателем может быть сервер, CDN или другое устройство SRT. SRT использует свой собственный метод восстановления после потери пакетов, используя UDP-пакеты по сети, которые можно настроить для адаптации к изменяющимся условиям сети. Когда сетевые условия плохие, можно добавить больше буферизации пакетов для улучшения качества видео. По мере улучшения условий в сети величина задержки может быть уменьшена для потоковой передачи практически в реальном времени.
SRT обеспечивает прохождение через любые файерволы между источником и получателем. Для этого протокол имеет три режима: рандеву и вызов/слушатель.
Режим рандеву является самым простым и обычно не требует участия IT-специалистов для настройки прохождения файрволов между источником и получателем SRT. Если вы не можете пройти через сетевой экран, то следует использовать режим вызов/слушатель. Однако для настройки пересылки трафика потребуется определённое участие IT-специалистов, чтобы трафик, полученный на общедоступный IP-адрес и порт устройства-получателя SRT, переадресовывался на устройство в локальной сети.
Применение SRT
SRT идеально подходит для отправки нескольких удалённых каналов новостей по непредсказуемым сетям в центральный пункт назначения для производства и распространения, например, в модели вещания, когда удалённые журналисты сообщают в прямом эфире о местонахождении. Он также отлично подходит для привлечения удалённых гостей с низкой задержкой для интервью или двусторонней беседы. Всякий раз, когда требуется высококачественное видео и аудио по сетям с непредсказуемым качеством, SRT намного превосходит качество любого вызова по Zoom, потока WebEx или WebRTC.
HTTP Live Streaming (HLS)
HLS – это адаптивный протокол потоковой передачи на основе HTTP, который отправляет видео- и аудиоконтент по сети в небольшие сегменты потокового мультимедиа на основе TCP, которые повторно собираются в месте назначения. Стоимость развёртывания HLS является низкой, поскольку она использует существующую сетевую технологию на основе TCP, что является привлекательным для CDN, желающих заменить старые (и дорогие) RTMP-серверы. Но поскольку HLS использует TCP, то он работает по принципу «качество важней задержки», поэтому время задержки может быть высоким (например, в секундах, а не в миллисекундах).
HLS был первоначально разработан Apple Inc. в качестве протокола для потоковой передачи мультимедиа на устройства Apple. С тех пор Apple разработала HLS (push), который является потоковым протоколом открытого стандарта, доступным для всех устройств. В настоящее время HLS поддерживает видео, кодированное с использованием кодеков H.264 или HEVC.
Преимущество HLS заключается в том, что он предназначен для адаптации к различным условиям сети. Разные версии потока отправляются с разными разрешениями и битрейтами. Зрители могут выбрать то качество потока, что они хотят. HLS также поддерживает несколько звуковых дорожек, что означает, что ваш поток может иметь несколько языковых дорожек, из которых пользователи могут выбирать нужную. Другие преимущества включают поддержку скрытых титров, метаданных, управления цифровыми правами (DRM) и даже встроенных рекламных объявлений (в не слишком отдалённом будущем).
Поддерживается безопасная потоковая передача по HTTP, а также алгоритмы хеширования MD5 и SHA для аутентификации имени пользователя и пароля.
Преимущества
Как работает HLS
Подход очень похож на передачу файлов. Сегменты потокового мультимедиа через порт HTTP 80 (или порт 443 для HTTPS), который обычно уже открыт для сетевого трафика. Таким образом, контент может легко проходить через файерволы практически без участия IT-специалистов.
HLS использует контейнер транспортного потока MPEG2-TS с полуконфигурируемой продолжительностью сегмента, а также с настраиваемым размером списка воспроизведения для повторной сборки принятых сегментов на центральном сервере. Также поддерживается фрагментированный MP4.
Поскольку HLS использует технологию, основанную на TCP, метод потери и восстановления сетевых пакетов является интенсивным. Это одна из причин увеличения задержки. Хотя имеется некоторый контроль над размером сегмента мультимедиа, возможность уменьшить задержку ограничена – особенно если сервер требует загрузки среднего сегмента определённого размера.
Применение HLS
HLS по-прежнему является стандартом для потоковой передачи на мобильные устройства и планшеты. Вы также можете использовать HLS для потоковой передачи на CDN, который не поддерживает RTMP, когда низкая задержка не является обязательным требованием. Важно отметить, что RTMP уже считается устаревшим во всё более увеличивающемся количестве CDN. HLS также хорошо подходит для безопасной потоковой передачи корпоративного обучения и трансляций через локальные сети (LAN), когда низкая задержка не является обязательным требованием, а условия сети плохие (при условии, что сеть поддерживает HLS).
MPEG-DASH (Dynamic Adaptive Streaming over HTTP)
MPEG-DASH – это открытый стандарт адаптивного протокола потоковой передачи на основе HTTP, который отправляет видео и аудиоконтент по сети в виде небольших сегментов потокового мультимедиа на основе TCP, которые повторно собираются в месте назначения. Международная организация по стандартизации (ISO) и команда MPEG и MPEG-DASH спроектировали кодирование и разрешение независимо от других, что означает, что MPEG-DASH может передавать потоковое видео (и аудио) любого формата (H.264, H.265 и т. д.) и поддерживает разрешения до 4K. В остальном, MPEG-DASH функционирует почти так же, как и HLS.
Стоимость развёртывания MPEG-DASH низкая, поскольку в нём используется существующая сетевая технология на основе TCP, что является привлекательным для CDN. Но поскольку HLS использует TCP, то он работает по принципу «качество важней задержки», поэтому время задержки может быть высоким
MPEG-DASH также предназначен для адаптации к различным условиям сети. Разные версии потока отправляются с разными разрешениями и битрейтами. Зрители могут выбрать качество потока, который они хотят. Также поддерживаются несколько звуковых дорожек, а также расширенные функции, такие как скрытые титры, метаданные и управление цифровыми правами (DRM). Инфраструктура предназначена для будущих разработок, например, встроенной рекламу.
Поддерживается безопасная потоковая передача по HTTP, а также алгоритмы хеширования MD5 и SHA для аутентификации имени пользователя и пароля.
Преимущества
Как работает MPEG-DASH и его применение
MPEG-DASH работает так же, как HLS – отправляет короткие средние сегменты по HTTP (порт 80) или HTTPS (порт 443) для облегчения обхода файервола. Он использует контейнер транспортного потока MPEG2-TS с половиной настраиваемой длительности сегмента, а также настраиваемый размер списка воспроизведения для повторной сборки принятых сегментов на центральном сервере. Также поддерживается фрагментированный MP4.
Высокая задержка MPEG-DASH обусловлена главным образом потерей сетевых пакетов и методом восстановления, используемым во всех сетях на основе TCP. И хотя MPEG-DASH предлагает некоторый контроль над размером сегмента мультимедиа, возможность уменьшить задержку ограничена – особенно, если сервер требует загрузки среднего сегмента определённого размера.
MPEG-DASH лучше всего подходит для потоковой передачи на CDN, которые не поддерживают RTMP, в случаях, когда низкая задержка не является обязательным требованием. MPEG-DASH также хорошо подходит для безопасной потоковой передачи корпоративного обучения и трансляций через локальные сети (LAN), когда низкая задержка не является обязательным требованием, а условия сети плохие
Какой потоковый протокол подходит вам?
Хотя RTMP, безусловно, всё ещё является самым популярным потоковым протоколом, такие протоколы, как SRT, HLS и MPEG-DASH, бросают ему вызов. Так что они умеют такого, чего не умеет RTMP?
HLS и MPEG-DASH обеспечивают гораздо более простую и дешёвую масштабируемость, чем RTMP. Так как RTMP и обычно требует, чтобы порты были открыты вручную для прохождения через файерволы.
Если задержка или плохие условия сети не являются проблемой, то HLS или MPEG-DASH превосходит SRT. Протоколы адаптивной потоковой передачи на основе HTTP обеспечивают наилучшее возможное качество видео для зрителей с различными условиями сети и более просты в настройке, чем SRT.
Если требуется низкая задержка и вы используете потоковую передачу по сетям с непредсказуемым качеством, тогда SRT является предпочтительным протоколом потоковой передачи. SRT устанавливает свое собственное соединение для восстановления пакетов, которое намного эффективнее, чем TCP. Это позволяет SRT обеспечивать двустороннюю связь между хостом и удалёнными гостями в режиме практически реального времени. Вы также можете сами настроить задержку, чтобы приспособиться к условиям сети.
Заверните!
Многие CDN, такие, например, как Akamai, уже объявили о прекращении поддержки RTMP, как устаревшего и дорогого для развёртывания. С ростом популярности новых протоколов SRT, HLS и MPEG-DASH, RTMP вскоре уйдёт в прошлое. Вот почему мы в Epiphan Video, добавили поддержку SRT, HLS и MPEG-DASH в наше семейство систем видеопроизводства «все-в-одном» Pearl.
Теперь вы можете быть уверены, что Pearl Nano и Pearl Mini готовы к будущему потокового вещания. Семейство кодеров Pearl является одним из немногих устройств в своём ценовом диапазоне, которые сертифицированы для потоковой передачи HLS и MPEG-DASH на Akamai.