Низкая задержка - универсальное стремление медиа. Когда такая компания, как Wowza, создает идеальную диаграмму для объяснения технологий потоковой передачи с низкой задержкой, вы должны снять перед ними шляпу и использовать диаграмму с указанием авторства и некоторыми незначительными изменениями. Я представляю эту диаграмму как рисунок 1; давайте обсудим в порядке, обозначенном выделенными цифрами, которые я добавил.
1. Приложения с низкой задержкой
РУКОВОДСТВО ПО ПРОДУКТУ
Лучшие PTZ-камеры для потоковой передачи в реальном времени
Чтобы убедиться, что мы все на одной странице, задержка в контексте прямой трансляции означает межстекольную задержку. Первое стекло - это камера, на которой ведется прямая трансляция, а второе - экран, который вы смотрите. Задержка - это задержка между появлением на камере и на вашем телефоне. На задержку влияют такие факторы, как время кодирования (на мероприятии), время транспортировки в облако, время транскодирования в облаке (для создания лестницы кодирования), время доставки и, что особенно важно, сколько секунд буферизуется вашим плеером перед началом воспроизведения.
На верхнем уровне показаны типичные приложения и их требования к задержке. Популярными приложениями, которым не хватает из-за низкой задержки и задержки, близкой к реальному времени, являются сайты азартных игр и аукционов.
Прежде чем углубляться в обсуждение технологии, поймите, что чем меньше задержка прямой трансляции, тем менее устойчива она к перебоям в пропускной способности. Например, при использовании настроек по умолчанию поток HLS будет воспроизводиться через 15+ секунд прерванной полосы пропускания, и если он будет восстановлен в этот момент, зритель может никогда не узнать о проблеме. Напротив, поток с низкой задержкой прекращает воспроизведение почти сразу после прерывания. Таким образом, преимущество времени запуска с малой задержкой всегда должно быть сбалансировано с отрицательным эффектом остановок при воспроизведении. Если вам совершенно не нужна низкая задержка, возможно, не стоит жертвовать отказоустойчивостью, чтобы ее получить.
Тем не менее, полезно разделить задержку на три категории следующим образом.
ИНФОРМАЦИОННЫЙ БЮЛЛЕТЕНЬАудио + Видео + ИТ. Наши редакторы являются экспертами в области интеграции аудио / видео и информационных технологий. Получайте ежедневную аналитическую информацию, новости и профессиональные контакты. Подпишитесь на Pro AV сегодня.
- Хорошо бы иметь - Быстрее всегда лучше, но если вы ведете прямую трансляцию заседания Совета по образованию или школьного футбольного матча, вы можете решить, что надежность потоковой передачи более важна, чем низкая задержка, особенно если многие зрители смотрят через соединения с низким битрейтом.
- Конкурентное преимущество - В некоторых случаях низкая задержка дает конкурентное преимущество, а низкая задержка означает конкурентный недостаток. На диаграмме вы заметите, что типичная задержка для кабельного телевидения составляет около пяти секунд. Если ваш потоковый сервис конкурирует с кабельным, вы должны быть в этом диапазоне, при этом меньшая задержка обеспечивает скромное конкурентное преимущество.
- Связь в реальном времени - Если вы являетесь сайтом азартных игр или аукционов, или если ваше приложение требует обмена данными в реальном времени, вам абсолютно необходимо обеспечить низкую задержку.
- Руководство по сравнению прямых трансляций
- Как предсказать успех кодека
Теперь, когда мы знаем категории, давайте рассмотрим наиболее эффективный способ обеспечить необходимый уровень низкой задержки.
2/3 Приятно иметь низкую задержку
Число 2 показывает, что Apple HLS и MPEG-DASH, развернутые с использованием настроек по умолчанию, приводят к задержке примерно в 30 секунд. Цифры простые; Если вы используете десятисекундный размер сегмента и перед началом воспроизведения требуется, чтобы в буфере проигрывателя было три сегмента, у вас будет тридцать секунд. По правде говоря, Apple изменила свои требования с десяти секунд до шести несколько лет назад, и большинство производителей DASH используют 4-6-секундные сегменты, поэтому значение по умолчанию действительно ближе к 20 секундам.
Тем не менее, номер 3, HLS Tuned и DASH Tuned, показывает задержку около 6-8 секунд. По сути, настройка означает переход от 10-секундных сегментов к 2-секундным сегментам, что, применяя ту же математику, обеспечивает задержку в 6-8 секунд. Таким образом, когда задержка удобна, вы можете резко сократить ее без затрат времени и средств на разработку или значительного увеличения риска доставляемости.
4. Конкурентное преимущество - HTTP-технологии с малой задержкой.
Когда низкая задержка необходима в качестве конкурентного преимущества, простое сокращение размеров сегмента не поможет; вам нужно будет реализовать настоящую технологию с низкой задержкой. Здесь есть два класса; Технологии HTTP, такие как HLS с низкой задержкой и CMAF с низкой задержкой для DASH, а также решения, основанные на других технологиях, таких как WebSockets и WebRTC.
Для большинства производителей приложений этого класса технологии HTTP с малой задержкой предлагают наилучшее сочетание доступности, обратной совместимости, гибкости и набора функций. Итак, в этом разделе я расскажу о HLS с низкой задержкой и CMAF с низкой задержкой для DASH, а в следующем - о других технологиях.
Все системы с низкой задержкой на основе HLS / DASH / CMAF работают одинаково, как показано на рисунке 2. То есть вместо ожидания завершения кодирования всего сегмента, что обычно занимает от 6 до 10 секунд (верхняя часть рисунка 2). , кодировщик создает гораздо более короткие фрагменты, которые передаются в CDN, как только они будут завершены (нижняя часть рисунка 2).
Например, если ваш кодировщик создавал шестисекундные сегменты, у вас будет как минимум шесть секунд задержки; втрое больше, чем если бы зритель получил три обычных сегмента до начала воспроизведения. Однако, если ваш кодировщик выталкивает фрагменты каждые 200 миллисекунд, а проигрыватель настроен на немедленное начало воспроизведения, задержка должна быть намного, намного меньше. Одно из ключевых преимуществ этой схемы - обратная совместимость; поскольку сегменты все еще создаются, проигрыватели, несовместимые со схемой с низкой задержкой, по-прежнему должны иметь возможность воспроизводить сегменты, хотя и с большей задержкой. Эти сегменты также мгновенно доступны для VOD-презентаций из прямой трансляции.
Помимо этих преимуществ, технологии HTTP с низкой задержкой поддерживают большинство функций своих собратьев по обычным задержкам, включая шифрование, вставку рекламы и субтитры, которые не всегда поддерживаются технологиями на основе WebRTC и WebSockets. Скорее всего, вы сможете реализовать выбранную технологию с низкой задержкой, используя существующую инфраструктуру проигрывателя и доставки, минимизируя затраты на разработку и другие технологические затраты.
Выбор технологии HTTP с низкой задержкой
Существует два основных стандарта HTTP Adaptive Streaming, HLS и DASH, а также унифицированный контейнерный формат CMAF. После того, как Apple анонсировала свое решение HLS с низкой задержкой, оно мгновенно вытеснило ряд массовых усилий и стало предпочтительной технологией для обеспечения низкой задержки HLS. Хотя спецификация все еще относительно нова, она уже поддерживается такими поставщиками технологий, как Wowza и WMSPanel с их продуктом Nimble Streamer.
Существует стандарт DVB для DASH с низкой задержкой, и отраслевой форум DASH одобрил несколько режимов с низкой задержкой для DASH, которые будут включены в их следующие рекомендации по совместимости. В соответствии со всеми этими спецификациями разработчики кодировщиков и плееров, а также сети доставки контента в течение нескольких лет работали над обеспечением взаимодействия, чтобы все приложения DASH / CMAF с малой задержкой сразу же приступили к работе.
Например, Harmonic и Akamai вместе продемонстрировали CMAF с низкой задержкой еще в NAB и IBC 2017, показывая доставку OTT в реальном времени с задержкой менее пяти секунд. С тех пор Harmonic интегрировала функциональность DASH с низкой задержкой в свои продукты на базе устройств (Packager XOS и Electra XOS) и решения SaaS (VOS Cluster и VOS260). Многие другие производители кодировщиков и плееров сделали то же самое.
Независимо от того, решите ли вы реализовать HLS с низкой задержкой или низкую задержку для DASH, или и то, и другое, переход от существующей архитектуры доставки HLS и / или DASH должен быть относительно плавным и недорогим.
5. Связь в реальном времени
WebRTC обычно является движком для интегрированного пакета, который включает в себя кодировщик, проигрыватель и инфраструктуру доставки. Примеры крупномасштабных потоковых решений на основе WebRTC включают в себя Real Time от Phenix, Limelight Realtime Streaming и Millicast от CoSMo Software и Influxis (рисунок 3). Вы также можете получить доступ к технологии WebRTC в таких инструментах, как Wowza Streaming Engine, CoSMO Software и Red 5 Pro Server. Время задержки для технологий этого класса составляет от 0,5 секунды для 71% потоков (Phenix), менее 500 миллисекунд (Red5 Pro) до менее одной секунды (Limelight). Если вам нужна задержка менее двух секунд, вам следует рассмотреть вариант WebRTC.
Если вам нужна связь в реальном времени, вам, вероятно, потребуется внедрить решение на основе WebRTC или Websockets. WebRTC был разработан для связи между браузерами и поддерживается всеми основными настольными браузерами на Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 и BlackBerry 10, поэтому он должен работать без загрузки на любой из этих платформ. Как следует из названия, WebRTC - это протокол для доставки прямых трансляций каждому зрителю, одноранговому или серверному.
WebSockets - это протокол реального времени, который создает и поддерживает постоянное соединение между сервером и клиентом, которое любая сторона может использовать для передачи данных. Это соединение может использоваться для поддержки как доставки видео, так и других коммуникаций, поэтому оно удобно, если вашему приложению требуется интерактивность. Как и реализации WebRTC, службы, использующие WebSockets, обычно предлагаются как служба, включающая проигрыватель и CDN, и вы можете использовать любой кодировщик, который может передавать потоки на сервер через RTMP или WebRTC. Примеры включают nanoStream Cloud от Nanocosmos и Streaming Cloud со сверхнизкой задержкой Wowza. Wowza заявляет о задержке менее 3 секунд для своего решения, в то время как Nanocosmos утверждает, что около одной секунды, от стекла к стеклу.
Другие технологии с низкой задержкой
Существует четвертая категория продуктов, которые лучше всего назвать «прочие», в которых используются различные технологии для обеспечения низкой задержки. В эту категорию входят THEO Technologies High Efficiency Streaming Protocol (HESP), проприетарный протокол адаптивной потоковой передачи HTTP, который, согласно THEO, обеспечивает задержку менее 100 миллисекунд при одновременном сокращении полосы пропускания примерно на 10% по сравнению с другими технологиями с низкой задержкой. HESP использует стандартные кодировщики и CDN, но требует специальной поддержки в упаковщике и проигрывателе (рисунок 4). Вы можете узнать больше о HESP в официальном документе, доступном для загрузки здесь.
Вот список вопросов, которые следует учитывать при принятии решения, какую технологию с малой задержкой реализовать и как это сделать.
Строить или покупать?
Если вы внедряете технологию самостоятельно, обязательно ответьте на все вопросы, перечисленные ниже, прежде чем выбирать технологию. Если вы выбираете поставщика услуг, используйте его для сравнения различных поставщиков услуг.
Вы выбираете стандарт или партнера?
Выше мы описали различные технологии для достижения низкой задержки, но их реализация варьируется от поставщика услуг к поставщику услуг. Таким образом, не все реализации LL HLS будут включать доставку ABR, по крайней мере, сначала. Большинство традиционных широковещательных приложений, вероятно, перейдут на стандарты на основе HTTP, такие как HLS / DASH / CMAF с низкой задержкой, в то время как приложения, требующие сверхнизкой задержки, такие как ставки и аукционы, будут тяготеть к другим технологиям. В любом случае при выборе поставщика услуг важнее определить, могут ли они соответствовать вашим технологическим и бизнес-целям, чем какие технологии они фактически внедряют.
Можно ли его масштабировать и какой ценой?
Одним из преимуществ технологий на основе HTTP является то, что они масштабируются по стандартной цене с использованием большинства CDN. Напротив, для большинства технологий на основе WebRTC и WebSocket требуется выделенная инфраструктура доставки, реализуемая поставщиком услуг. По этой причине услуги, не основанные на HTTP, могут быть более дорогими в доставке, чем HLS / DASH / CMAF. Сравнивая поставщиков услуг, выясните, сколько стоит событие, включая вход, транскодирование, пропускную способность, создание файла VOD, одноразовые или индивидуальные конфигурации и т. Д.
Проблемы, связанные с реализацией?
Задайте следующие вопросы, связанные с внедрением и использованием технологии.
- Какая задержка достижима в масштабе, соответствующем размеру вашей аудитории и географическому распределению?
- Есть ли ограничения по качеству - некоторые технологии могут быть ограничены определенным максимальным разрешением или профилями H.264.
- Будут ли пакеты проходить через брандмауэр? Системы на основе HTTP используют протоколы HTTP, которые дружественны к брандмауэрам. Другие используют UDP, который может не проходить через брандмауэры автоматически. Если UDP, есть ли какие-либо обратные каналы для доставки заблокированным зрителям?
- Какие платформы поддерживаются? Предположительно компьютеры и мобильные устройства, но как насчет STB, ключей, устройств OTT и смарт-телевизоров?
- Может ли система масштабироваться, чтобы соответствовать вашему целевому количеству зрителей? Является ли инфраструктура CDN частной, и если да, может ли она доставлять контент всем релевантным зрителям на всех соответствующих рынках? Каковы ожидаемые затраты на масштабирование?
- Можете ли вы использовать свой собственный плеер или вам нужно использовать системный плеер? Если ваши собственные, какие изменения потребуются и сколько это будет стоить?
- Что нужно для воспроизведения на мобильных устройствах? Будут ли потоки воспроизводиться в браузере или требуется приложение? Если требуется (или желательно) приложение, доступны ли SDK?
- Какие кодеры может использовать система? Большинство из них должны использовать любой кодировщик, который может поддерживать RTMP-соединения с облачным транскодером, но проверьте, нужны ли другие протоколы.
- Можно ли повторно использовать контент для VOD или потребуется перекодирование? Ничего особенного, поскольку транскодирование видео до приемлемой ступени кодирования стоит около 20 долларов в час, но дорого для частых трансляций.
- Какие есть варианты резервирования и каковы затраты? Для критически важных трансляций вам нужно знать, как дублировать рабочий процесс кодирования / трансляции, если какой-либо компонент системы выйдет из строя во время события. Поддерживается ли эта избыточность и какова стоимость?
Какие функции доступны и в каком масштабе?
Будет широкий спектр предложений функций от разных поставщиков, которые могут включать или не включать:
- ABR потоковая передача - сколько потоков и есть ли соответствующие ограничения по битрейту или разрешению?
- Что насчет функций DVR? Могут ли зрители остановить и возобновить воспроизведение без потери контента.
- Синхронизация видео - Может ли система синхронизировать всех зрителей с одной и той же точкой в потоке? Потоки могут дрейфовать по местоположениям и устройствам, и без этой возможности пользователи некоторых подключений могут иметь преимущество для аукционов или азартных игр.
- Какая защита контента доступна? Если вы производитель премиального контента, вам может понадобиться настоящая DRM. Другие могут обойтись аутентификацией или другими подобными методами.
- Доступны ли субтитры? Субтитры необходимы по закону для некоторых трансляций, но в целом полезны для всех.
- А как насчет размещения рекламы или другой схемы монетизации? Поддерживает ли это поставщик технологий / услуг?
В общем, если вы стриминговый магазин, стремящийся соответствовать или превзойти время трансляции в диапазоне от 5 до 6 секунд, стандартная технология HTTP, вероятно, будет вашим лучшим выбором, поскольку она будет наиболее близка к поддержке того же набора функций, что и вы ». re в настоящее время используется, например, защита контента, субтитры и монетизация. Если у вас есть приложение, для которого требуется гораздо меньшая задержка, вам, вероятно, понадобится решение на основе WebRTC или Websockets или проприетарная технология HTTP. В любом случае ответы на перечисленные выше вопросы помогут вам определить поставщика технологий и / или услуг, который наилучшим образом соответствует вашим потребностям.