Задержка видео: Задержка в прямых трансляциях потокового видео – Amazon Web Services

Задержка в прямых трансляциях потокового видео – Amazon Web Services

Отставание видео, передаваемого по технологии OTT, от эфирного телевидения и социальных сетей – не единственная проблема для поставщиков контента. Вот несколько других факторов, которые необходимо учитывать при снижения задержки.

Платформа Flash и протокол RTMP: приложения на базе Flash, использующие потоковое вещание по протоколу RTMP, раньше с успехом обеспечивали низкие задержки, но теперь, когда технология Flash считается устаревшей, а разработчики браузеров сокращают поддержку или полностью блокируют компоненты Flash, сети доставки контента (CDN) стали сокращать поддержку протокола RTMP (который и раньше мало использовался для доставки). Поставщики контента вынуждены искать другие пути.

Масштабируемость, надежность и низкая задержка: одним из вариантов решения проблем масштабирования является переход на технологии потокового вещания, совместимые с HTML5.

К ним относятся HTTP Live Streaming (HLS), Dynamic Adaptive Streaming over HTTP (DASH или MPEG‑DASH) и Common Media Application Format (CMAF).

Эти технологии потоковой передачи данных используют протокол HTTP, а следовательно, при доставке возможно кэширование. Таким образом, сети CDN могут более эффективно доставлять большие объемы данных.

Однако несмотря на решение проблем масштабируемости и надежности, к общей длительности доставки прибавляются десятки секунд, что мешает достижению низкой задержки.

Интерактивные возможности: некоторые поставщики контента предпочитают развивать сервисы индивидуального вещания с интерактивными возможностями. Задержка видеосигнала в таких случаях, как правило, недопустима.

Если кадр видео отображается на экране на 30 секунд позже момента его съемки камерой, интерактивные действия, требующие обратной связи в режиме реального времени, становятся невозможными.

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

Ключевые причины для реализации низкой задержки потокового видео

Материал основан на техническом описании, разработанном компанией Harmonic, при участии Akamai, THEOplayer, Viaccess-Orca и NexStreaming.

Ранние форматы потоковой передачи, в основном разработанные для SVOD, были ориентированы на то, чтобы избежать двойной буферизации при обработке видео на проигрывателе. Но чтобы обеспечить гарантированное вещание на любом устройстве, в цепочке доставки и обработки видео и в первую очередь на плеере, приходилось использовать буферизацию памяти. Такой подход способствовал успешному распространению OTT, но в то же время приводил к существенной суммарной задержке в тракте доставки и обработки. Например, в протоколе HTTP Live Streaming (HLS) от Apple, выпущенном в 2009 году, рекомендовано было использовать 10-секундные сегменты, причем для начала воспроизведения проигрыватель должен буферизовать не менее трех сегментов.

По этой причине для многих OTT-сервисов характерна задержка в 40 секунд и более. Позже Apple пересмотрела свою рекомендацию в пользу шестисекундных сегментов, но это все равно дает 18-секундную задержку только на стороне абонента.

Задержка в 20 секунд и более не является проблемой для сервисов SVOD, но она становится таковой для живых трансляций и спортивных событий премиум-класса. Для видео такого рода задержка ОТТ-распространения должна быть сопоставимой с задержкой в вещательной сети, а именно составлять около 5 секунд. В противном случае неизбежна негативная реакция абонента, узнающего о голе из новостной ленты или по радостным крикам из соседнего окна за 20 секунд до того, как этот гол появится у него на экране. Кроме того, обеспечение одинаковой задержки в ОТТ и вещательных сетях позволяет использовать интерактивные приложения второго экрана, так как обеспечивает временную корреляцию событий на экране телевизора и в приложении на планшете.

На рисунке 1 показана степень важности низкой задержки для различных типов видеоуслуг и контента.

Рис. 1. Шкала чувствительности к задержке вещания

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

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

Факторы, определяющие задержку вещания

В этом материале мы рассматриваем совокупную задержку как суммарную задержку всех процессов обработки и доставки между системой производства видеосигнала (обычно это некомпрессированный сигнал с выхода центральной аппаратной) и до воспроизведения на экране конечного пользователя (см. рисунок 2).

Рис. 2. Суммарная задержка в цепочке рабочего процесса

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

Как CMAF решает вопросы задержки

MPEG Common Media Application Format (MPEG-CMAF) — это стандартизированный медиаконтейнер, недавно введенный для упрощения масштабного распространения OTT-услуг.

MPEG-CMAF основан на использовании контейнера fMP4 (ISOBMFF) и может применяться как в рамках MPEG-DASH, так и c HLS-протоколом c использованием общего шифрования. Действительно, режим шифрования CBC теперь поддерживают Apple, Microsoft, Google и Adobe, что позволяет абонентским устройствам, поддерживающим разные системы DRM, принимать и открывать один и тот же зашифрованный видеофрагмент. Сохранилась необходимость составлять в отдельном манифест-файле для MPEG DASH и плейлисте для HLS, но зашифрованные медиасегменты при использовании CMAF одинаковы для обоих форматов, что значительно упрощает распространение контента и снижает нагрузку на сети.

Другим важным преимуществом MPEG-CMAF является появление возможности организации низкой задержки LLC (Low Latency Chunk — чанки с низкой задержкой). MPEG-CMAF LLC предоставляет возможность доставки сегмента небольшими частями (чанками), длительностью, например, по 200 мс, до формирования полного двухсекундного или шестисекундного сегмента. В режиме CMAF LLC передача данных ускоряется по всей цепочке, в том числе в декодере, который может начать декодирование, не дожидаясь получения всего сегмента. MPEG CMAF LLC — очень эффективный инструмент, который при использовании кодера с низкой задержкой и плеера с поддержкой DASH (так как iOS 11 поддерживает CMAF, но не LLC) может обеспечить суммарную задержку в тракте в пределах трех секунд или меньше.

Конечно, проигрыватель HLS также может декодировать данный поток, но при этом будет вносить дополнительную задержку по сравнению с плеером MPEG DASH CMAF LLC (см. рисунки 3 и 4).

Чтобы в полной мере использовать преимущества CMAF LLC, необходимо обеспечить поддержку CMAF и передачи HTTP-чанков во всех звеньях цепи доставки, включая пакетизатор, вещающий сервер, CDN и плеер. Судя по тестам Harmonic и обсуждениям с партнерами, можно говорить о широкой поддержке CMAF LLC со стороны отраслевых игроков, включая операторов CDN и разработчиков плееров. Тем не менее отметим, что проигрыватели, которые поддерживают CMAF, но без LLC, по-прежнему могут декодировать видео только после приема полного медиасегмента.

Рис. 3. Старая схема распространения ОТТ-сегментов (например, в HLS)

Рис. 4. Передача HTTP чанков в рамках CMAF LLC

Результаты практического применения

Совместными усилиями компаний Harmonic и Akamai была реализована демонстрация работы комплексной системы CMAF LLC, для OTT-доставки видео в реальном времени с задержкой до пяти секунд. Но, как известно, условия реальной среды могут отличаться от демонстрационных. Поэтому, поскольку технология CMAF LLC уже интегрирована в продукты Harmonic, производитель совместно с партнерами и клиентами начал проводить ее испытания в экосистемах, включающих разные компоненты, от локальных устройств до облачных SaaS-решений. Передача видео велась с использованием общественных или частных CDN-сетей на телеприставки путем потоковой передачи через управляемые сети, а также на смартфоны по сетям LTE.

Условия испытаний

В следующих разделах представлена сводка первых результатов, собранных в реальных условиях. Предлагается подробный обзор того, чего можно добиться с помощью имеющихся решений CMAF LLC. Тестовая система включала два экрана: один воспроизводил видео, переданное по эталонному вещательному каналу, а другой экран (телевизора или смартфона) демонстрировал видео, доставленное с применением технологии OTT DASH CMAF LLC. Задача состояла в том, чтобы обеспечить одинаковую задержку в вещательной сети и на OTT-платформе.

Эталонная вещательная сеть

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

Для вещания необходимо высокое качество видеоизображения и низкая скорость, что требует предварительной фильтрации, предварительного анализа изображения, использования алгоритмов многопроходного кодирования и длинных групп кадров (GOP). Каждый из этих инструментов компрессии добавляет задержку, поэтому вклад кодера в суммарную задержку в вещательной сети составляет более 90%. Помимо вещательного кодера, задержка добавляется главным образом мультиплексорами/скремблерами, модуляторами, спутниковым трактом (~ 250 мс) и декодером в абонентском устройстве. Можно уменьшить задержку самого кодера за счет реализации кодера с более низкой или даже сверхнизкой задержкой, но это будет влиять на качество видео или битрейт кодера.

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

Внедрение DASH CMAF LLC на головной станции

Задержка в цепочке DASH CMAF LLC может сильно различаться в зависимости от метода реализации (на аппаратной или облачной платформе) и стабильности пропускной способности сети. Если OTT-платформа развернута на аппаратной платформе, то ABR-кодер обычно получает тот же сигнал, что и вещательный кодер. Поскольку качество видео и скорость битрейта являются общими задачами для операторов вещания и OTT-услуг, то кодеры в обоих случаях дают схожую задержку. Остальная часть цепочки DASH CMAF LLC (пакетизатор, сервер вещания, CDN и плеер) вносит незначительный вклад в общую задержку, особенно при использовании сетей доступа с хорошей пропускной способностью (например, проводные сети). В этом случае при использовании двухсекундных сегментов и фрагментов CMAF длительностью 100 мс средняя совокупная задержка видео от вещания до его отображения на абонентском устройстве составляла около 5,5 секунд, то есть примерно столько же, сколько и в вещательной сети (см. рисунок 5).

Рис. 5. Рабочий процесс DASH CMAF LLC, реализованный на аппаратной платформе 

Внедрение DASH CMAF LLC при облачной реализации OTT

Поскольку все больше операторов рассматривают применение облачной инфраструктуры для развертывания OTT-сервисов, в Harmonic провели тестирование с использованием видео SaaS от Harmonic. Производительность кодера Harmonic, включая задержку, была одинаковой, независимо от того, работал он в составе локального или облачного решения (см. рисунок 6).

Рис. 6. Внедрение DASH CMAF LLC при облачной реализации

Основная трудность облачной реализации заключается в том, что сигнал из аппаратной должен быть доставлен до облачного сервиса транскодирования. Обычно для преобразования студийного сигнала в IP-поток, который может быть отправлен в облако, требуется кодер для межстудийного обмена. Такие кодеры обеспечивают видеопоток хорошего качества с задержкой в несколько сотен миллисекунд. Затем поток IP отправляется в облако через управляемую сеть с хорошим QoS или через открытый Интернет.

В зависимости от качества (QoS) используемой сети, может появиться необходимость защиты потока от ошибок с помощью помехоустойчивого кодирования (FEC) или за счет повторных передач. Эти методы защиты реализуются довольно легко, однако приводят к увеличению задержки. Ниже приведена таблица, в которой обобщенно показано, как уровень помехозащищенности влияет на задержку на этапе доставки потока в облако.

Таблица 1. Влияние режима помехозащищенности на задержку

Качество сети	Помехозащищенность в канале доставки в облако	Суммарная задержка в канале доставки в облако
Отличное	Не активирована	О,8 сек
Удовлетворительное	Работает в обычном режиме	1,4 сек
Плохое	Работает в усиленном режиме	2,5 сек

В ходе тестов компания Harmonic обнаружила, что все процессы, связанные с загрузкой потока в облако, в большинстве регионов добавляли дополнительные 1,4 секунды задержки. В результате общая задержка HD-потока с момента его выхода из аппаратной до начала воспроизведения плеером при использовании облачных систем компрессии и доставки составляла приблизительно семь секунд.

Влияние качества сети доступа на задержку в плеере

Приведенные результаты были получены в условиях распространения видео по качественным сетям доступа, как правило, по управляемым сетям, с хорошим Wi-Fi-покрытием. В таких случаях сетевой буфер DASH CMAF LLC плеера может быть уменьшен до минимума без риска его опустошения из-за перегрузки сети.

В сетях LTE, характеризующихся более длительными задержками и быстрым изменением пропускной способности, OTT-потоки сталкиваются с более сложными условиями доставки мультимедиа.

Тесты, проводившиеся в сетях LTE, подтвердили важность увеличения глубины сетевого буфера на 1-2 секунду для обеспечения непрерывности обработки и воспроизведения видео (см. таблицу 2).

Таблица 2. Результаты испытаний

DASH CMAF LLC доставка	Кодирование ОТТ-потока на головной станции	Кодирование ОТТ-потока в облаке
Управляемая проводная сеть	5,5 сек	7,0 сек
Сеть LTE	7,5 сек	9,5 сек

Таким образом, качество сети доступа является основным фактором, определяющим задержку, а следовательно, и качество восприятия услуги (QoE). С этой точки зрения возможность адаптироваться к изменяющимся условиям сети нужнее, чем доработка клиентской части.

Влияние UHD-разрешения на задержку в OTT-сети

Необходимость распространять спортивные события премиум-класса с задержкой не больше, чем в вещательных сетях, — один из основных факторов внедрения решений с низкой задержкой вещания. Эти премиум-события также должны доставляться на экраны телевизоров в UHD-формате. Самым простым способом охватить большую аудиторию UHD-вещанием часто оказывается OTT-доставка по оптоволоконному соединению. Поэтому стриминг UHD с низкой задержкой также становится важной задачей В большинстве испытаний систем с низкой задержкой, проведенных компанией Harmonic, включая тесты с облачным транскодированием, использовалось как раз видео формата UHD. Мы не обнаружили каких-либо существенных различий в задержке между HD и UHD, поэтому приведенные выше цифры применимы и к UHD.

Альтернативы DASH CMAF LLC

Как показано выше, DASH CMAF LLC — это проверенная на практике технология, снижающая суммарную задержку. Компания Harmonic и некоторые ее партнеры являются активными сторонниками этой технологии, однако существуют и другие варианты решения проблемы. Рассмотрим эти альтернативы.

Оптимизация потоковой передачи ABR с применением механизмов HLS и DASH

Сегодня подавляющее большинство OTT-проектов реализовано на базе адаптивной потоковой HTTP-передачи с использованием HLS или DASH. Поскольку плеерам необходимо буферизовать определенное количество сегментов, прежде чем они смогут начать декодировать видео (три в случае HLS), существует прямая зависимость между размером сегмента и суммарной задержкой. Одним из наиболее простых подходов к снижению суммарной задержки является простое сокращение длительности сегмента. Основное преимущество такого подхода в том, что он не требует никакого изменения компонентов экосистемы. Тем не менее эта опция имеет некоторые важные ограничения:

• Согласованность экосистемы. Cокращение длительности сегмента в технологии DASH и особенно в HLS возможно с определенными оговорками. Для пакетов формата HLS компания Apple изначально установила минимальную длительность сегмента в 10 секунд, которая затем была сокращена до шести секунд. И хотя опуститься ниже этого порога технически возможно, это потребует нестандартной реализации плеера. Кроме того, это означает, что вся экосистема (пакетизатор, сервер-источник, CDN, клиент, проигрыватель) должны согласовать возможность совместной работы в таком режиме.

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

• Качество видео. Как показано на рисунке 7, уменьшение длительности сегмента с 10 до 2 секунд не влияет на качество видео. Тем не менее снижение ниже двухсекундного порога приведет к использованию кодером более короткой последовательности кадров, что, в свою очередь, немедленно повлечет за собой снижение качества видео. А снижения длительности сегмента двухсекундного порога, к сожалению, недостаточно для обеспечения задержки, сопоставимой с вещательной.

Рис. 7. Влияние сокращения длительности сегмента

Таким образом, задержку в стандартных системах ABR-стриминга на базе HLS и DASH снизить можно, но до определенного уровня. Переход в режим с действительно низкой задержкой приводит к риску появления несогласованностей в экосистеме, дополнительным затратам на настройку и снижению качества восприятия услуги (QoE).

WebRTC

WebRTC — это протокол с открытым исходным кодом, изначально разработанный для взаимодействия между браузерами в одноранговых сетях. С точки зрения показателей задержки протоколы WebRTC и Web-socket актуальны в первую очередь для приложений со сверхнизкой задержкой. Типичные приложения, для которых предназначен WebRTC, — задачи близкие к вещанию в реальном времени (например, приложения для интерактивных социальных сетей, видеоконференции и т. д.). Следует признать, что с точки зрения задержки данная технология может работать даже лучше, чем это необходимо для соответствия параметрам задержки в вещательных сетях. Однако к ОТТ-платформам предъявляются и другие требования.

Конкурентоспособная система OTT-услуг должна удовлетворять значительно большему количеству требований, чем просто доставка живого контента с минимальной задержкой. Современные OTT-платформы должны обеспечивать защиту контента, масштабируемость услуг, поддерживать нелинейные сервисы и т. д. Технология WebRTC как таковая таких возможностей не дает. В момент начала сеанса WebRTC требует выделенных серверов, имеющихся не во всех CDN, поэтому масштабируемость технологии вызывает сомнения. Более того, для WebRTC требуется другая версия клиента, поэтому понадобится реинжиниринг всей базы HLS и DASH клиентов.

Комплексное сравнение различных решений

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

Таблица 3, сравнение потоковых технологий с низкой задержкой

Ключевые показатели	ABR (HLS/DASH)	ABR (HLS/DASH) c CMAF LLC*	WebRTC
Основная область применения	OTT-вещание	OTT-вещание	Обмен данными в режиме близком к реальному времени
Суммарная задержка	От 20 до 40 сек (обычная). Ниже 10 секунд (с ограничением по качеству видео)	5-9 сек (результаты тестов)	Может быть ниже 3 сек
Основные преимущества		Низкая стоимость доставки **
	Встроенная поддержка: Линейные и нелинейные рабочие процессы Монетизация контента (DAI) Стандартные DRM системы с общим шифрованием Вещательные кодеки (в том числе и HEVC) и UHD-разрешение
Ограничения	Ухудшение качества сжатого видео при выборе режима кодирования с низкой задержкой (короткие сегменты и GOP)	Проблемы интеграции компонентов экосистемы (сервера- источника, CDN, плеера).	Масштабируемость Ограниченная поддержка кодеков Собственная DRM-система, нет поддержки монетизации контента (DAI)
Этап внедрения	Широкое внедрение, (без оптимизации по задержке)	Готова к внедрению	Внедрена

* Режим CMAF Low Latency Chunk с поддержкой передачи кодированных фрагментов по HTTP-протоколу.

** Низкая по сравнению с ABR, в связи с тем, что для доставки контента в HLS и DASH используются одни и те же сегменты мультимедиа и общая схема шифрования DRM (например, CBCS).

На рисунке 8 показано размещение этих технологий на комплексной шкале «конкурентоспособности».

Рисунок 8. Позиционирование технологии потоковой передачи с низкой задержкой

Каким будет следующий шаг в отношении CMAF?

Результаты тестов технологии CMAF показали ее работоспособность в рамках всей экосистемы и возможность ее коммерческой реализации. Следующие шаги предполагают оптимизацию. В 2017 году CMAF был стандартизирован, а в 2018 году обеспечена его совместимость с клиентскими приложениями и проведены первые комплексные испытания. В этом, 2019 году начнется коммерческое внедрение технологии при поддержке режима LLC (Low latency Chunk) в HLS со стороны Apple.

Теперь, когда технология CMAF с низкой задержкой выглядит достаточно зрелой для внедрения, следующим логическим шагом является более точная настройка всего рабочего процесса. И хотя каждый компонент может быть оптимизирован сам по себе, ее комплексное улучшение, оптимизирующее QoE придаст дополнительный импульс развитию экосистемы.

Заключение

Хотя эта статья посвящена режиму низкой задержки, применение CMAF сфере ОТТ набирает обороты безотносительно этой опции. Это связано с тем, что применение CMAF унифицирует уровни доставки и защиты контента. Это позволяет вещательным платформам, которые должны поддерживать и DASH, и HLS, минимизировать затраты на доставку и хранение трафика, что является ключевым для их бизнеса. Несмотря на существование альтернатив, CMAF LLC является единственным практическим вариантом решения проблемы задержки, сохраняющим при этом другие ключевые возможности, необходимые для запуска конкурентоспособной услуги OTT — масштабируемой, с единой системой шифрования, запущенной на существующей инфраструктуре CDN и с использованием имеющейся базы клиентов. Масштабируемость, реализация тергетированной рекламы и геоблокировок, защита контента с применением DRM и видео премиального уровня стали уже обязательным функционалом, отсутствие которого не компенсируется низкой задержкой. Вот почему в своих OTT-решениях Harmonic внедрил и CMAF LLC, и передачи кодированных фрагментов по HTTP-протоколу.

Компания Harmonic совместно с технологическими партнерами Akamai, THEOplayer, Viaccess-Orca и NexStreaming, работающими в области CDN и разработки плееров, уверена в возможности коммерческого развертывания CMAF и рекомендует вещателям и операторам начать внедрение DASH CMAF LLC уже сегодня.  

_________________________

Подпишитесь на канал «Телеcпутника» в Telegram: перейдите по инвайт-ссылке или в поисковой строке мессенджера введите @telesputnik, затем выберите канал «ТелеСпутник» и нажмите кнопку +Join внизу экрана.

Также читайте «Телеcпутник» во «ВКонтакте», Facebook , «Одноклассниках» и Twitter.

И подписывайтесь на канал «Телеспутника» в «Яндекс.Дзен».

Трансляция онлайн-видео с минимальной задержкой / Хабр

Не так давно к нам обратился клиент, который занимается видео-трансляциями аукционов и лошадиных скачек в прямом эфире. Сами мероприятия проходят в Австралии, а вот ставки на них делаются игроками в Макао — игровой столице Юго-Восточной Азии. Разумеется, он столкнулся с задержкой сигнала — как без неё. Задержка — это время между взятием кадра и его появлением на экране конечного устройства. И если обычному зрителю задержка в 5 или даже 10 секунд не критична, то тем, кто ставит на тотализаторе, подобная разница может стоить огромных денег. Отсюда возникла задача — свести к минимуму время прохождения видео от источника к зрителю.

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

Мы подумали, что некоторые техники, которые мы применили, будут интересны не только нам.

Итак, цепочку доставки видео схематично можно разделить на 6 этапов: съёмку, сжатие, передачу по локальной сети от энкодера к медиа-серверу, передача через интернет, декодирование и отображение на устройстве пользователя.

Посмотрим, чем определяются издержки на каждом из этапов и как их можно сократить.

1. Съёмка видео

Тут всё просто — всё зависит от камеры, которая используется в съёмке. Задержка здесь — меньше 1 мс, поэтому при выборе устройства можно сосредоточиться на потребительских качествах — кодеках и протоколах, качестве картинки, цене и т. п.

2. Сжатие (энкодинг)

Сжатие видео (encoding) — это обработка исходного видео с целью уменьшить размер передаваемых данных. Цель — пожать поток с помощью подходящего для задачи кодека. В настоящее время стандартом де-факто является видео в H.264 с аудио в AAC.

Работа на этом шаге влияет на всю цепочку в дальнейшем.

Предпочтение лучше отдать аппаратным решениям, т.к. программные добавляют время, нужное для работы с ресурсами, и накладные расходы операционной системы. Правильно настроенный энкодер не добавляет сколько-нибудь ощутимой задержки, но он задаёт битрейт результирующего потока и его тип. Различают переменный битрейт (variable bitrate, VBR) и постоянный (constant bitrate, CBR).

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

Однако с CBR тоже не всё так просто. На деле постоянный битрейт не является постоянным в каждый отдельный момент времени, т.к. поток H.264 содержит кадры разной величины. Поэтому в энкодере есть контроль усреднения битрейта на отдельных промежутках времени, чтобы объём данных был одинаковым на протяжении всей трансляции. Усреднение это делается, конечно же, в ущерб качеству. Чем меньше период усреднения, тем меньше буфер на этапе декодирования и тем хуже качество передаваемого видео.

Энкодеры промышленного уровня предоставляют разнообразные средства управления битрейтом, призванные давать CBR минимальным воздействием на качество. Их описание выходит за рамки нашей статьи, можно лишь упомянуть о таких параметрах как гранулярность контроля битрейта (Rate Control Granularity) и контентно-адаптивный контроль битрейта (Content-Adaptive Rate Control).

3. Передача от энкодера к медиа-серверу

Задержку на этом шаге определяет по бОльшей части работа сети между энкодером и медиа-сервером. Здесь играют свою роль настройки буфера при сжатии и накладные расходы используемого медиа-протокола. Поэтому для буфера энкодера стоит указать минимальное количество кадров и поставить его как можно ближе к медиа-серверу.

Протокол передачи данных нужно выбирать исходя из возможностей энкодера и медиа-сервера, который будет раздавать данные конечным пользователям. Для передачи видео в реальном времени наиболее подходят RTSP, RTMP или MPEG2-TS.

4. Передача через Интернет на устройство пользователя

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

Первый фактор в этой цепочке — буферизация внутри медиа-сервера при транзмаксинге (перепаковке) потока из одного протокола в другой.

Второй фактор связан со спецификой каждого протокола.
Если собираетесь использовать протоколы на базе HTTP, например HLS или MPEG-DASH, будьте готовы к существенному увеличению задержки. Дело здесь в самом принципе работы этих протоколов — они основаны на разбиении контента на сегменты, или чанки, которые выдаются последовательно. Размер сегментов зависит от протокола и параметров передачи, однако их не рекомендуется делать меньше 2 секунд. Apple рекомендует размет чанков в 10 секунд. Поэтому при использовании HLS надо или уменьшать размер, или смириться с потерями времени.
Можно предположить, что можно построить доставку на HLS или DASH, максимально уменьшив размер сегментов и сведя все остальные потери времени к минимуму. И для большинства кейсов это сработает. Однако для передачи в реальном масштабе времени (ведь в нашем примере — аукционы) нужно использовать протоколы RTMP или RTSP.

Кроме того, мы выпустили свой протокол живого вещания с малыми задержками, SLDP. Использует вебсокеты, поэтому работает в большинстве современных браузеров. Плюс есть SDK для мобильных платформ.

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

(полная версия карты кабелей — здесь)

Возможен вариант, когда между исходных медиа-сервером и зрителем вы решите поставить так называемый edge, то есть промежуточный кеширующий медиа-сервер для снижения нагрузки на систему при большом числе одновременных подключений. Если так, то не забудьте накинуть соответствующую задержку ещё и для эджа. Конечно, для максимальной оптимизации вы эджи будете ставить только для обычных зрителей, которым задержка не критична, однако помнить об этом тоже нужно.

5. Декодирование

Это шаг может сильно влиять на скорость передачи. Чтобы отыграть возможную недостачу данных при передаче (помним про предыдущие шаги), буфер проигрывания должен содержать данные одного полного усреднённого периода с учетом сетевых задержек. Поэтому буфер может содержать от нескольких GOP-ов (GOP = group of pictures) до нескольких кадров, в зависимости от параметров энкодера и состояния сети. Многие плееры принимают минимальное значение буфера проигрывания равным 1 секунде и меняют его по ходу работы. Минимально возможный буфер достигается при использовании аппаратных декодеров (плееров), например на базе Raspberry Pi.

6. Отображение

Здесь, как и на первом шаге, время задержки пренебрежимо мало — всё покрывается возможностями железа.

Возвращаясь к примеру с нашим клиентом, цепочка доставки строилась из следующих частей. Видео снималось камерой и отдавалось на аппаратный энкодер Beneston VMI-EN001-HD. Далее от него поток по RTMP шёл на Nimble Streamer, который был настроен на максимальную производительность. В Макао данные шли также по RTMP, где в зале для приёма ставок стоит Raspberry Pi для декодировки и отображения на больших мониторах. Пинг от Австралии до Макао составил 140 мс. В RTMP-плеере на Raspberry Pi буфер был выставлен на 300 мс. Результирующая задержка сигнала для потока 1080p30 варьировалась между 500 и 600 миллисекундами, что вполне покрывает требования заказчика. Простые зрители по всему миру видят картинку с опозданием 3-4 секунды — не с последнюю очередь потому, что предпочитают смотреть через HLS на мобильных устройствах. В данном случае эта величина также приемлема.

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

О низкой задержке Low Latency и протоколах её реализации Video Compression Guru

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

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

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

Всё больше сервисов мигрируют в облако, чтобы сэкономить на арендуемых площадях, электроэнергии и покупке железа. Это повышает требования к низкой задержке с высоким RTT (Round Trip Time – время пересылки сообщения туда и обратно). Это особенно актуально при передаче больших битрейтов во время трансляции HD и UHD видео — например, если облачный сервер стоит в США, а потребитель контента находится в Европе.

В этом обзоре разберем, что сейчас предлагает рынок относительно вещания с низкой задержкой.

UDP

Наверное, первой технологией, которая активно применялась в современном телевещании и с которой связывают термин «низкая задержка», было вещание мультикаст трафика с MPEG Transport Stream содержимым по UDP. Обычно подобный формат выбирали в закрытых ненагруженных сетях, где вероятность потерянных пакетов сводилась к минимуму. К примеру, вещание с кодера на модулятор на головной станции (зачастую – в рамках одной серверной стойки), либо вещание IPTV по выделенной медной или оптоволоконной линии с усилителями и повторителями. Подобная технология используется повсеместно и показывает отличные показатели задержки. Отечественные компании достигали задержки на кодирование, передачу данных и декодирование с использованием сети Ethernet не более 80 мс при 25 кадрах в секунду. С более высокой частотой кадров – и того меньше.

Рис. 1. Измерение задержки при вещании в UDP в лаборатории

На первой картинке – сигнал с карты захвата SDI. На второй – сигнал, прошедший стадию кодирования, мультиплексирования, вещания, приёмки и декодирования. Как видно, второй сигнал приходит позже на одну единицу измерения (в данном случае – 1 кадр, который равен 40 мс, т. к. здесь 25 кадров в секунде). Подобное решение применялось на Кубке Конфедераций 2017 и Чемпионате Мира FIFA 2018, только ко всей архитектурной цепочке добавлялся модулятор, распределённая DVB-C сеть и телевизор в качестве конечного устройства. Общая задержка составила 220–240 мс.

А если сигнал проходит через внешнюю сеть? Там его ждут различные испытания: помехи, шейпирование, нагруженный трафиком канал, ошибки оборудования, повреждённые кабели, проблемы программного уровня. В таком случае требуется не только низкая задержка, но и переотправка потерянных пакетов. В случае с UDP с этим неплохо справляется технология Forward Error Correction с избыточностью (дополнительным проверочным трафиком или оверхедом). При этом неизбежно увеличиваются требования к пропускной способности сети, и, следовательно, задержка и объём избыточности в зависимости от ожидаемого процента потерянных пакетов. Процент восстановленных благодаря FEC пакетов всегда лимитирован, а при передаче по открытым сетям он может существенно изменяться. Таким образом, чтобы надёжно передавать большие объёмы данных на длительные расстояния, приходится добавлять к ним десятки процентов избыточного трафика.

TCP

Рассмотрим технологии, которые базируются на протоколе TCP (достоверной доставке). Если контрольная сумма полученного пакета не соответствует ожидаемому значению (выставленному в заголовке TCP пакета), то этот пакет отправляется повторно. А если на стороне клиента и сервера не поддерживается спецификация Selective acknowledgment (SACK), то происходит переотправка всей цепочки TCP пакетов с потерянного и до последнего полученного на сниженной скорости.

Ранее протокол TCP избегали, когда речь заходила про низкую задержку при вещании в прямом эфире, поскольку она вырастала из-за проверки на ошибки, пересылки пакетов, трехстороннего рукопожатия, «медленного старта» и предотвращения переполнения канала (TCP Slow Start и congestion avoidance phase). При этом задержка до начала передачи даже при широком канале может достигать пятикратной круговой задержки (RTT), а увеличение пропускной способности влияет на задержку крайне незначительно.

Также приложения, которые вещают по TCP, не получают полную обратную связь по состоянию соединения (таймауты, размеры окна для перевещания), т. к. передача TCP идёт единым сплошным потоком, и прежде, чем выдать ошибку, приложение может зависнуть на неопределённое время. А протоколы более верхнего уровня не имеют возможности тюнинга ТСP для минимизации проблем вещания.

При этом существуют протоколы, которые эффективно работают поверх UDP даже в открытых сетях и на длительные расстояния.

Рассмотрим и сравним различные реализации протоколов. Из протоколов и форматов передачи данных, которые базируются на TCP, отметим RTMP, HLS и CMAF, а из базирующихся на UDP — WebRTC и SRT.

RTMP

RTMP был проприетарным протоколом от Macromedia (теперь принадлежит Adobe) и был очень популярен, когда приложения на базе Flash пользовались успехом. Имеет несколько разновидностей с поддержкой шифрования TLS/SSL, и даже вариацией на базе UDP – RTFMP (Real Time Media Flow Protocol, использовался для соединений точка-точка). RTMP разбивает поток на фрагменты, размер которых может динамически меняться. Внутри канала пакеты, которые относятся к аудио и видео, могут чередоваться и мультиплексироваться.

Рис. 2. Пример реализации RTMP вещания

RTMP формирует несколько виртуальных каналов, по которым передаются аудио, видео, метаданные и др. Большинство CDN`ов уже не поддерживают RTMP как протокол для раздачи трафика конечным клиентам. Однако у Nginx есть собственный RTMP модуль с поддержкой простого (plain) RTMP протокола, который работает поверх TCP и использует 1935 порт по умолчанию. Nginx может выступать в качестве RTMP сервера и раздавать контент, который он получает от RTMP-стримеров. Кроме того, RTMP по-прежнему пользуется популярностью для доставки трафика на CDN, а в дальнейшем трафик передаётся по другим протоколам.

Сегодня технология Flash устарела и практически не поддерживается: браузеры либо сокращают её поддержку, либо полностью блокируют. RTMP не поддерживает HTML5 и не работает в браузерах (воспроизведение возможно с помощью Adobe Flash плагина). Для обхода брандмауэров используют RTMPT (инкапсуляцию в HTTP запросы и использование стандартного 80/443 вместо 1935), но это значительно влияет на задержку и избыточность (по разным оценкам, RTT и общая задержка увеличиваются на 30%). RTMP по-прежнему популярен, например, для вещания на Youtube или в социальных сетях (RTMPS для Facebook).

Ключевые минусы RTMP — отсутствие поддержки HEVC/VP9/AV1 и ограничение на две аудиодорожки. Также RTMP не содержит временных меток в заголовках пакетов. RTMP содержит лишь метки, рассчитанные исходя из фреймрейта, поэтому декодер не знает, когда именно декодировать этот поток. Это обязывает принимающий компонент ровно выдавать самплы на декодирование, поэтому приходится увеличивать буфер на величину джиттера пакетов.

Другой проблемой RTMP является пересылка потерянных пакетов TCP, которая описана выше. Подтверждения получения (ACKs) не уходят сразу к отправителю, чтобы поддерживать низкий уровень обратного трафика. Только после получения цепочки пакетов отправляется позитивное (ACKs) или негативное (NACKs) подтверждение вещающей стороне.

По разным оценкам задержка при вещании с помощью RTMP составляет минимум две секунды при полном тракте кодирования (RTMP кодер → RTMP сервер → RTMP клиент).

CMAF

Common Media Application Format (CMAF) — протокол, разработанный экспертной группой по движущимся изображениям по заказу Apple и Microsoft для адаптивного вещания (с адаптивным битрейтом, который меняется исходя из изменения пропускной способности всего сетевого тракта) поверх HTTP. Обычно HTTP Live Streaming (HLS) от Apple использовал MPEG Transport Stream, а MPEG DASH — фрагментированный MP4. В июле 2017-го спецификация CMAF увидела свет. В CMAF фрагментированные MP4 сегменты (ISOBMFF) передаются по HTTP с двумя разными плейлистами для одного контента для соответствующего плеера: iOS (HLS) или Android/Microsoft (MPEG DASH).

По умолчанию CMAF (как HLS и MPEG DASH) не предназначен для вещания с низкой задержкой. Но внимание и интерес к низкой задержке постоянно растет, так что некоторые производители предлагают расширение стандарта, например Low Latency CMAF. Это расширение предполагает, что и вещательная, и приёмная стороны поддерживают два метода:

1. Chunk encoding: разделение сегментов на подсегменты (маленькие фрагменты с moof+mdat mp4 боксами, которые в итоге составляют целый сегмент, пригодный для проигрывания) и их пересылка до того, как весь сегмент собран воедино;
2. Chunked Transfer Encoding: использование HTTP 1.1 для отправки подсегментов на CDN (origin): отправляется только 1 HTTP POST запрос для всего сегмента в 4 секунды (25 кадров в секунду), а в дальнейшем внутри этой сессии могут быть отправлены 100 маленьких фрагментов (в каждом по одному кадру). Плеер также может пытаться скачивать не полностью готовые сегменты, CDN в свою очередь при помощи Chunked transfer encoding отдаёт уже готовую часть и далее держит соединение до добавления новых фрагментов в скачиваемом сегменте. Передача сегмента плееру завершится, как только весь сегмент будет сформирован (запушен) на стороне CDN-а.

Рис. 3. Стандартный и фрагментированный CMAF

Чтобы переключаться между профилями, необходима буферизация (минимум 2 секунды). Учитывая это, а также потенциальные проблемы в доставке, разработчики стандарта заявляют о потенциальной задержке менее трех секунд. При этом сохраняются такие киллер-фичи, как масштабирование через CDN с тысячами одновременных клиентов, шифрование (вместе с поддержкой Common Encryption), поддержка HEVC и WebVTT (субтитров), гарантированная доставка и совместимость с разными плеерами (Apple/Microsoft). Из минусов можно выделить обязательную поддержку LL CMAF на стороне плеера (поддержка фрагментированных сегментов и продвинутая работа с внутренними буферками). При этом в случае несовместимости плеер по-прежнему может работать с контентом в рамках спецификации CMAF со стандартной задержкой, типичной для HLS или DASH.

Low Latency HLS

В июне 2019 года Apple опубликовала спецификацию для Low Latency HLS.

Она состоит из следующих составляющих:

1. Генерация частичных сегментов (fragmented MP4 или TS) с минимальной длительностью вплоть до 200 мс, которые доступны ещё до формирования полного сегмента (чанка), состоящего из таких частей (x part). Устаревшие частичные сегменты регулярно удаляются из плейлиста.
2. Серверная сторона может использовать HTTP/2 Push режим, чтобы отправлять обновлённый плейлист вместе с новым сегментом (или фрагментом). Однако в последней правке спецификации в январе 2020 года эту рекомендацию исключили.
3. Обновлённые плейлисты отправляются после их появления/обновления, а не после непосредственного запроса.
4. Вместо полного плейлиста отправляется разница в плейлистах (сохраняется дефолтный плейлист, и далее отправляется только добавочная разница/дельта — x skip — при её появлении вместо отправки полного плейлиста).
5. Сервер объявляет о предстоящей доступности новых частичных сегментов (preload hint).
6. Информация о плейлистах загружается параллельно в соседних профилях (rendition report) для более быстрого переключения.

Рис. 4. Принцип работы LL HLS

Ожидаемая задержка при полной поддержке этой спецификации CDN`ом и плеером – менее трех секунд. HLS очень широко используется для вещания в открытых сетях благодаря отличной масштабируемости, поддержки шифрования и адаптивного битрейта, кросс-платформенности и обладает обратной совместимостью, что полезно, если плеер не поддерживает LL HLS.

WebRTC

Web Real Time Communications (WebRTC) — опенсорсный протокол, разработанный Google в 2011 году. Используется в Google Hangout, Slack, BigClueButton и Youtube Live. WebRTC — это набор стандартов, протоколов и JavaScript программных интерфейсов, который реализует сквозное шифрованное благодаря DTLS-SRTP в рамках peer-to-peer соединения. При этом технология не использует сторонние плагины или ПО, проходя через брандмауэры без потери качества и задержки (например, при использовании видеоконференций в браузерах). При вещании видео обычно используется реализация WebRTC поверх UDP.

Протокол работает следующим образом: хост отправляет запрос на соединение к пиру, с которым хочет соединиться. Пока соединение между пирами не установлено, они общаются между собой через третье лицо — сигнальный сервер. Далее каждый из пиров обращается к STUN серверу с вопросом «Кто я?» (как ко мне попасть извне?). При этом существуют публичные гугловские STUN сервера (например, stun. l.google.com:19302). STUN сервер отдаёт список IP и портов, по которому можно достучаться до текущего хоста. Из этого списка формируются ICE кандидаты. Вторая сторона делает то же самое. Происходит обмен ICE кандидатами через сигнальный сервер, и уже на этом этапе устанавливается peer-to-peer соединение, т. е. формируется одноранговая сеть.

Если прямое соединение установить невозможно, то в качестве релей/прокси сервера выступает так называемый TURN сервер, который также заносится в список ICE-кандидатов.

За мультиплексирование, отправку, контроль перегрузок и надёжную доставку отвечают SCTP (данные приложения) и SRTP (аудио- и видеоданные) протоколы. Для обмена «рукопожатиями» и дальнейшего шифрования трафика используется DTLS.

Рис. 5. Стек протоколов WebRTC

В качестве кодеков используются Opus и VP8. Максимальное поддерживаемое разрешение: 720p, 30 кадров в секунду с битрейтом до 2 Мбит/с.

Минусом WebRTC технологии в плане безопасности считается определение реального IP даже за NAT`ом и при использовании сети Tor или прокси сервера. WebRTC не предназначен для большого количества одновременных пиров для просмотра (тяжело масштабируется) в силу архитектуры соединений, а также практически не поддерживается CDN`ами на текущий момент. Наконец, WebRTC уступает своим коллегам по качеству кодирования и максимальному объёму передаваемых данных.

WebRTC недоступен в Safari и частично недоступен в Bowser и Edge. Задержка, заявляемая компанией Google, – меньше секунды. При этом данный протокол может использоваться не только для видеоконференций, а, например, для передачи файлов.

SRT

Secure Reliable Transport (SRT) — протокол, разработанный компанией Haivision в 2012 году. Протокол работает на базе UDT (UDP-based Data Transfer Protocol) и технологии восстановления пакетов ARQ. Поддерживает шифрование AES-128 и AES-256. Помимо режима listener (server) поддерживает режимы caller (client) и rendezvous (когда обе стороны инициируют соединение), которые позволяют устанавливать соединения через брандмауэры и NAT. Процесс «рукопожатия» в SRT работает в рамках существующих политик безопасности, поэтому разрешаются внешние соединения без открытия постоянных внешних портов в брандмауэре.

SRT содержит временные метки внутри каждого пакета, что позволяет проигрывать ровно с той скоростью, с которой поток закодирован без необходимости большой буферизации, выравнивая джиттер (постоянно меняющуюся скорость прихода пакетов) и входящий битрейт. В отличие от TCP, где при потере одного пакета может пересылаться вся цепочка пакетов, начиная с потерянного, SRT идентифицирует конкретный пакет по его номеру и пересылает только его. Это положительно влияет на задержку и избыточность. Пересылка пакета происходит с более высоким приоритетом, чем стандартное вещание. В отличие от стандартного UDT, в SRT полностью переписана архитектура переотправки пакетов, чтобы реагировать сразу же, как только пакет потерян. Такая технология является вариацией selective repeat/reject ARQ. Стоит отметить, что конкретный потерянный пакет можно переслать только фиксированное количество раз. Скип пакета отправителем происходит, когда время на пакете составляет более 125 % от общей задержки. SRT поддерживает FEC, и пользователь сам определяет, какую из этих двух технологий использовать (либо использовать обе), чтобы балансировать между самой низкой задержкой или самой высокой надёжностью доставки.

Рис. 6. Принцип работы SRT в открытых сетях

Передача данных в SRT может быть двунаправленной: обе точки могут посылать данные одновременно, а также могут выступать как слушателем (listener), так и стороной, инициирующей соединение (caller). Может использоваться режим «рандеву» (rendezvous), когда обе стороны пытаются установить соединение. Протокол имеет механизм внутреннего мультиплексирования, который позволяет мультиплексировать несколько потоков одной сессии в одно соединение, используя один UDP порт. Также SRT подходит для быстрой передачи файлов, которая впервые была представлена в UDT.

В SRT существует механизм контроля сетевой перегрузки (congestion control). Каждые 10 мс отправитель получает последние данные об RTT (круговой задержке) и его изменениях, доступном размере буфера, скорости получения пакетов и примерный размер текущего линка. Есть ограничения на минимальную дельту между двумя пакетами, посылаемыми подряд. Если их невозможно доставить вовремя, они удаляются из очереди.

Разработчики утверждают, что минимальная задержка, которую можно достигнуть при использовании SRT, — 120 мс с минимальным буфером при передаче на маленькие расстояния в закрытых сетях. Общая задержка, рекомендуемая для стабильного вещания, равна 3–4 RTT. Кроме того, SRT лучше справляется с доставкой при больших расстояниях (несколько тысяч километров) и высоком битрейте (10 и выше Мбит/с), чем его конкурент RTMP.

Рис. 7. Измерение задержки при вещании в SRT в лаборатории

На примере выше — измеренная в лаборатории задержка при вещании SRT в 3 фрейма при 25 кадрах в секунду. Т. е. 40 мс * 3 = 120 мс. Отсюда можно сделать вывод, что ultra low latency на уровне 0,1 секунды, которая может достигаться при вещании в UDP, доступна и при вещании в SRT. Способность к масштабированию в SRT не на таком уровне, как в HLS или DASH/CMAF, однако SRT активно поддерживается разными CDN`ами и перевещателями (рестримерами), а также поддерживает вещание напрямую конечным клиентам через медиа-сервер в режиме слушателя (listener mode).

В 2017 году Haivision открыла исходный код SRT библиотек и создала SRT Alliance, который насчитывает уже более 350 членов.

 

Резюме

В качестве резюме приведу сравнительную таблицу по протоколам:

Протокол	RTMP	WebRTC	LL CMAF	LL HLS	SRT
Функционал
Задержка	≥ 2 с	< 1 с	≥ 2,5 с	≥ 2,5 с	≥ 120 мс
Пропускная способность	Cредняя	Низкая	Высокая	Высокая	Высокая
Масштабируемость	Низкая1	Низкая	Высокая	Высокая	Cредняя
Кросс-платформенность и поддержка производителями	Низкая2	Cредняя3	Высокая	Высокая	Высокая
Адаптивный битрейт	Нет	Нет	Да	Да	Нет
Поддержка шифрования	Да	Да	Да	Да	Да
Способность проходить через брандмауэры и NAT	Низкая	Cредняя	Высокая	Высокая	Cредняя
Избыточность	Cредняя	Низкая	Cредняя	Cредняя	Низкая
Поддержка широкого набора кодеков	Нет	Нет	Да	Да	Да

¹ Не поддерживается CDN`ами для доставки конечным пользователям. Доступен для передачи контента до последней мили, например на CDN или рестример.
² Не поддерживается в браузерах
³ Недоступен в Safari

 

Сегодня всё опенсорсное и хорошо документированное довольно быстро приобретает популярность. Можно предположить, что такие форматы, как WebRTC и SRT, ждёт перспективное будущее в своих отраслях применения. По минимальной величине задержки эти протоколы уже опережают адаптивное вещание поверх HTTP, при этом сохраняют надёжность доставки, обладают низкой избыточностью и поддерживают шифрование (AES в SRT и DTLS/SRTP в WebRTC). Также в последнее время набирает популярность младший брат SRT (по возрасту протокола, но не по функционалу и возможностям) — протокол RIST, но это уже тема для отдельного обзора. RTMP же активно вытесняется с рынка новыми конкурентами, а из-за отсутствия нативной поддержки в браузерах, его вряд ли ожидает широкое применение в ближайшем будущем.

 

4 июня 2020

---

Автор

Виталий Сутурихин

Руководитель отдела интеграции и сопровождения Elecard с 2015 года. С 2006 года работает в сфере информационных технологий.

---

 

Профессиональный программный транскодер
с поддержкой RTMP, HLS, SRT — Elecard CodecWorks

Задержка сети и ее влияние на качество видеоконференции.

Posted on April 6th, 2021 by Игорь Снежко, Customer Support Regional Manager — Russia & Ukraine

В первой статье из этой серии мы обсудили профили качества видеоконференции, необходимую полосу пропускания и различные факторы, влияющие на качество. Мы узнали, что большинство этих факторов несложно устранить: приобрести более мощный ПК, расширить канал Интернет или просто настроить параметры видеоконференции. В этой статье мы поговорим о задержке (latency), которая дает измеримую оценку качеству видеоконференции. Мы также объясним, почему задержка сети может отрицательно влиять на работу пользователей.

Определение – задержка сети

Задержка показывает, как долго ваше видео / аудио доставляется от вас на сервер видеоконференций, и как долго видео / аудио от других доставляется к вам. Принятое нормальное значение – до 80-120 мсек. Разумеется, чем меньше задержка, тем лучше, поскольку это снижает вероятность эффекта, когда разговоры участников начнут накладываться один на другой.

Как уменьшить задержку?

Большое влияние на задержку имеет расстояние между вами и нашими облачными серверами видеоконференций. Поэтому при настройке АТС выбирайте правильный регион для пользователей. Тогда они смогут использовать самый близкий к ним сервер (MCU) 3CX.

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

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

В нижней части окна статистики WebMeeting показан сервер 3CX, к которому вы подключены, включая его расположение. Убедитесь, что используется ближайший сервер для региона участников конференции. Если выбран неподходящий сервер, измените его интерфейсе управления 3CX, в разделе Параметры → Конференции → вкладка Видеоконференции.

В следующей статье из этой серии мы расскажем, какие технологии 3CX использует для улучшения качества видеоконференций.

Как избежать задержки звука на Galaxy Buds+

Следующее поколение Galaxy Buds уже в продаже, поднимая качество звука и контроль над ним на новые высоты. От автоматического устранения нежелательного шума до батареи, которой хватит на весь день, — с помощью Galaxy Buds+ звук воспринимается совсем другим образом. Однако время от времени могут возникать звуковые задержки. Вот несколько дополнительных советов о том, как минимизировать звуковые задержки, особенно когда вы играете в игры или смотрите видео.

Прежде чем попробовать функции, предложенные ниже, обязательно проверьте, обновлено ли программное обеспечение вашего устройства до последней версии. Вы можете найти больше информации о том «Как подключить и обновить Galaxy Buds+ с помощью смартфона Galaxy» с поддержкой Samsung.

Как устранить звуковые задержки

Задержка звука — это когда звук в наушниках не совпадает с тем, что происходит на экране подключенного устройства. Существует несколько причин, по которым вы можете испытывать задержки звука на ваших Galaxy Buds и Galaxy Buds + при воспроизведении видео или игр. Однако это обычно легко исправить, например, улучшить соединение Bluetooth.

• Задержки звука могут возникать на любом аудиоустройстве Bluetooth. Вы можете минимизировать задержку, ограничивая помехи. Переместите устройства ближе друг к другу, чтобы улучшить связь. Убедитесь, что между наушниками и другими устройствами Bluetooth нет предметов, металлов, стен или людей.
• Кроме того, избегайте использования устройств, которые могут создавать помехи, таких как другие устройства Bluetooth, микроволновые печи и беспроводные маршрутизаторы.
• При использовании Galaxy Buds + вы можете активировать игровой режим, чтобы минимизировать задержки.

Шаг 1. Запустите приложение Galaxy Wearable и нажмите на Labs.

Шаг 2. Активируйте переключатель рядом с Игровой режим .

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

Что вызывает задержки вылетов зимой?

Метели накрыли Русскую равнину на этой неделе. 3 февраля непогода внесла коррективы в работу многих аэропортов. К примеру, из Волгограда не могли вылететь самолеты в Москву и Сочи. Задержки рейсов колебались от 50 минут до четырех часов. В этот же день из-за ветра и снега в Пскове не смог сесть самолёт из столицы. Решение о посадке или вылете всегда принимает командир воздушного судна, а вот всю информацию о погодных условиях он получает у метеорологической службы аэропорта.

«Буквально в один-два клика экипаж может нажать либо номер рейса, либо направление и получить всю полетную документацию. Таким образом ознакомиться с погодными условиями по пункту вылета, пункту посадки и по маршруту», – пояснила Лариса Булгак, главный синоптик-начальник Службы прогнозирования и брифинга.

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

«У нас очень хорошее оборудование на самолетах. Такое же хорошее оборудование в аэропортах. Полосы достаточно хорошо подсвечиваются. Есть инструментальная система посадки, которая работает совместно с оборудованием в самолете. Ммы проходим регулярные тренировки для посадки в подобных условиях», – рассказал Алексей Матвеев, командир воздушного судна.

Наиболее серьезная проблема для пилотов – это сильный боковой ветер, он часто становится причиной задержек авиарейсов, хотя есть экипажи, которые умудрялись заходить на посадку и в таких сложных условиях. Вылеты откладываются также из-за плохой видимости во время ливня или метели. Зимой самолеты обязательно должны проходить обработку против обледенения, что тоже может вызвать задержки.

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

Video Delay Instant Replay в App Store

Мгновенное воспроизведение! Спортивная камера с регулируемой задержкой при воспроизведении. Самостоятельно анализируйте свои действия во время фитнес-тренировки или тренировок. Получите мгновенную обратную связь и развивайте правильную мышечную память. Воспроизведите свои действия в замедленном режиме! Ускорьте спортивные тренировки с помощью режима обнаружения движения!

Это приложение — ваш личный тренер! Отправляйтесь в спортзал со своей фитнес-камерой!

Чтобы быстрее получать результаты, тренируйтесь с умом и убедитесь, что вы соответствуете форме.Используйте Instant Replay, чтобы улучшить свое выступление. Выберите время задержки, выполняйте упражнение и смотрите автоматический повтор! Не нужно перематывать или прикасаться к устройству, видео будет воспроизводиться мгновенно. Вы также можете выбрать время задержки, нажав на экран при начале и завершении задачи.

Для более быстрых действий (продолжительностью около 3 секунд), таких как стрельба в баскетбол, удары в гольф, акробатика или боевые искусства, используйте режим замедленной съемки. Нажмите SLO, выполняйте свое действие и смотрите мгновенный повтор в замедленном режиме.Будьте готовы к следующему повторению, когда появится обратный отсчет. Вы можете настроить скорость замедленного воспроизведения с помощью ползунка.

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

Тренеры и учителя физкультуры — используйте мгновенное воспроизведение с задержкой видео на экране телевизора (дублирование экрана). Анализируйте движения своих учеников с помощью видео обратной связи.

Video Delay Instant Replay отлично подходит для:

Фитнес / Спортивные тренировки / Физкультура
Crossfit / TRX workout
Баскетбол / Волейбол / Футбол
Теннис / Гольф
Силовые тренировки / Тяжелая атлетика / Бодибилдинг
Боевые искусства / Бокс / Спортзал
Гимнастика / Танцы
Физиотерапия / Йога / Пилатес
Фехтование / Стрельба из лука
Прыжки в воду / Плавание
Волшебные трюки / Веселые фильмы

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

Если вы тренируетесь по боевым искусствам или боксу, установите короткое время задержки, чтобы увидеть, как вы пинаете или пинаете в замедленной съемке!

Video Delay Instant Replay поможет вам тренироваться безопаснее, выполнять правильные упражнения и поддерживать хорошую осанку во время бодибилдинга или кроссфиттинга.

С помощью этого приложения Video Coach вы сможете улучшить свою форму баскетбольной стрельбы, скопировав своих любимых баскетболистов НБА.Также во время тренировок по баскетболу вы сможете увидеть, достаточно ли вы стоите на ногах или ваши ложные движения эффективны.

Если вы увлекаетесь футболом, Instant Replay поможет вам сравнить свою форму с лучшими футболистами.

Как насчет твоего удара в гольф? Теперь вы можете изучить свою форму удара в гольф и мгновенно исправить свои движения! То же самое с бейсбольными или теннисными качелями.

Это приложение для спортивной камеры отлично подходит для занятий физиотерапией и пилатесом. Оно может защитить вас от травм.Проверьте свою позу йоги с помощью мобильного фитнес-зеркала.

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

Вы можете установить столько времени задержки камеры, сколько позволяет память вашего устройства (йога, TRX, тренажерный зал или физиотерапия). Уменьшите разрешение камеры в настройках, если вам нужно больше времени задержки. Не забудьте включить камеру или позволить этому приложению использовать камеру вашего устройства!

BaM Video Delay в App Store

Входит в ТОП-10 СПОРТИВНЫХ приложений в США
Первая настоящая задержка видео — непрерывное отображение того, что только что произошло, для быстрой визуальной обратной связи
Используется спортивными тренерами, учителями физкультуры, профессиональными спортсменами и танцорами… или если вы просто хотите посмотреть, как вы выглядите танцпол 🙂

ВНИМАНИЕ:

+ ОБРАЗОВАТЕЛЬНАЯ СКИДКА
Приложение доступно со скидкой за объем для образовательных учреждений

+ БЕЗОПАСНОСТЬ УСТРОЙСТВА
Это приложение специально разработано, чтобы не использовать флешку для задержки видео, как другие приложения .Длительная запись на флешку сокращает срок ее службы.

+ КОНФИДЕНЦИАЛЬНОСТЬ
Приложение никоим образом не собирает и не отправляет личные данные и не требует входа в систему. Приложение автономно работает на вашем устройстве без необходимости связываться с другими службами или использовать подключение к Интернету.

ЧТО ГОВОРИТ КРИТИКИ (С ВИДЕО):

[Профессиональный учитель физкультуры Джаррод Робинсон]

«За эти годы я поговорил с тысячами учителей физкультуры о приложении BaM Video Delay.Это кардинальное изменение правил игры, которое берет то, что раньше было возможно с дорогими и сложными системами, и делает это реальностью для всех »

Raising The Bar with BaM Video Delay

[australiancurriculumtfel.edublogs.org]

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

Formative Assessment using BaM Video Delay app in PE

ОТЗЫВЫ ПОЛЬЗОВАТЕЛЕЙ:

Автор Kbone2000
5/5 Отлично приложение!
Это приложение нужно каждому тренеру.Мгновенная обратная связь для игроков и отличный способ самоанализа.

Джеймс Макдермотт
5/5 Отличное приложение!
Работает для того, что мне нужно, приятно, что у вас может быть задержка, а не каждый раз просить кого-то записывать.

Автор: awholelottatry
5/5 Отличный инструмент для технических тренировок для спорта и фитнеса
Это именно то, что я искал! Это было необходимо для совершенствования техники кроссфит-олимпийского подъема. Этот ценный инструмент может использовать каждый технический вид спорта.

ОПИСАНИЕ:

Вы когда-нибудь хотели научиться новому ходу?
Будь то профессиональные танцы, гимнастика, гольф, баскетбол, теннис, боевые искусства, брейк-данс, поза или другое применение.

Зеркало — это хорошо, но его трудно двигаться и смотреть одновременно, иногда даже невозможно, если не смотреть вперед.

С видеокамерой все в порядке, но хлопот со всем запуском, остановкой, перемоткой, позиционированием и прочим.

Итак, в конце концов, вы не используете ни то, ни другое, откажитесь от изучения чего-то нового и продолжайте жить своей жизнью.

«Bust a Move Video Delay» решает эти проблемы.
Это простой в использовании инструмент с быстрой обратной связью. Вы видите, что вы только что сделали, и можете исправить это, попробовать еще раз, посмотреть еще раз, исправить… и так далее.

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

ЧТО ДЕЛАЕТ «ВИДЕО ЗАДЕРЖКА»?

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

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

Теперь есть всего два простых шага:
1. ДВИЖЕНИЕ
(делайте то, что вы хотите узнать)
2. СМОТРЕТЬ И УЗНАТЬ
(увидеть, что вы только что сделали, а что не так)

Таким образом вы получите мгновенную обратную связь чтобы вы могли быстро учиться на своих ошибках и быстро поправляться.

ОСОБЕННОСТИ:

— непрерывное воспроизведение в режиме «свободные руки», но с задержкой
— до Full HD при 30 кадрах в секунду и HD при 60 кадрах в секунду
— универсальное приложение для iPhone / iPod и iPad
— задержки от 1 секунды до 6 минут
— использует память устройства вместо флэш-накопителя
— до 4 независимых просмотров, чтобы вы могли видеть себя 4 раза подряд
— замедленное движение и пауза для анализа видео
— экспорт как видео
— AirPlay и HDMI TV держатель кабеля
— автоматическое скрытие элементов управления интерфейсом
— «Live View» для легкого позиционирования камеры и настройки
— переключатель камеры с передней на заднюю
— переворот по горизонтали
— зум x2 с панорамированием
— установка экспозиции и фокуса
— и руководство , на всякий случай

Задержка видео | Видеоинтерфейс Crystal Vision

Сколько секунд задержки видео вам нужно?

Никто не занимается такими задержками видео, как мы.Они идеально подходят для использования везде, где вам нужно согласовать задержки в вашей системе — графика виртуальной студии, кодеры / декодеры MPEG, спутниковые и HD-радиосвязи, обработка звука и задержки ненормативной лексики.

В системе кадров Vision есть четыре задержки видео IP / SDI, обеспечивающие до 16 секунд задержки 3 Гбит / с и 32 секунды задержки HD и SD. Эти программные приложения (которые работают на медиапроцессоре MARBLE-V1) могут работать с IP (видео ST 2022 и ST 2110), с SDI или одновременно с IP и SDI.Это дает вам самое простое возможное обновление SDI до IP, а также делает их идеальными для смешанных установок SDI и IP, а также сред полностью IP или полностью SDI.

В системе кадров Indigo имеется выбор из пяти переменных задержек видео, обеспечивающих задержку до десяти секунд 3 Гбит / с, 43 секунды задержки HD и четыре минуты задержки SD. А если вы хотите предотвратить трансляцию оскорбительных или нежелательных видео или аудиоматериалов, теперь мы можем предложить гибкий диапазон задержек с ненормативной лексикой.

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

Задержки видео IP / SDI

• M-VIVID100-3 IP / SDI трехканальная переменная задержка видео (100 кадров на канал) — программное приложение, которое работает на медиапроцессоре MARBLE-V1
• M-VIVID200-2 Двухканальная переменная задержка видео IP / SDI (200 кадров на канал) — программное приложение, работающее на медиапроцессоре MARBLE-V1
• M-VIVID400-2 Двухканальная переменная задержка видео IP / SDI (400 кадров на канал) — программное приложение, работающее на медиапроцессоре MARBLE-V1
• M-VIVID800 IP / SDI одноканальная переменная задержка видео (800 кадров) — программное приложение, работающее на медиапроцессоре MARBLE-V1

Аппаратное обеспечение медиапроцессора

• Медиапроцессор MARBLE-V1, на котором работают программные приложения Crystal Vision, с возможностью подключения до четырех 10GbE, шести входов / выходов SDI и восьми входов / выходов AES

Задержки видео

Задержка ненормативной лексики

• Система задержки ненормативной лексики Cleanit 3G / HD / SD

Аудио синхронизатор | Купить Синхронизатор задержки аудио и видео

Синхронизатор задержки аудио и видео:

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

Синхронизатор звука:

Аудиосинхронизатор — это устройство, которое автоматически регулирует задержку частоты передачи.Задержка может произойти по многим причинам, включая задержку источника, транспортную развязку, какую-то среду, и космос. BS Broadcast предлагает широкий выбор синхронизаторов аудио и видео. Теперь ваша очередь не нужно ждать нежелательной задержки передачи. Все без проблем справляется с оборудованием.

Синхронизатор задержки видео:

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

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

Синхронизатор задержки аудио и видео:

Bs Broadcast предлагает высококачественное оборудование для синхронизации аудио и видео для повседневной работы задачи.Наши продукты предназначены для обеспечения специализированной ресинхронизации и обеспечения бесперебойной передача между двумя или более средами. Каждый из продуктов совместим с современными технологический кодек, используемый как в обычном ТВ, так и в спутниковой передаче. Мы гарантируем, что ваш воздух непрерывность обвиняется любыми отказоустойчивыми реле байпаса.

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

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

Задержка видео

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

Настройка

Источник

: выберите выход или вход, например видеокамеру.
Разрешение: выберите качество задержки видео.Если вы выберете видеокамеру для задержки, этот параметр будет таким же, как разрешение камеры.
Сохранить кодек: выберите видеокодек для использования при сохранении клипов с задержкой видео в файл.

ПРИМЕЧАНИЕ: DV Video Encoder поддерживает максимальное разрешение 720×576, выберите другой кодек, если вы хотите сохранять видеоклипы в HD.

Seconds: Выберите размер буфера задержки в секундах. Это приблизительное значение, основанное на входной частоте 30 кадров в секунду.

Контроль

Запись: Включение или выключение обновления задержки видео.
Скорость (100%): Задержка может воспроизводиться на различных скоростях, включая полную скорость и замедленное воспроизведение, например, 50%.

Сохранить секунды (10): выберите количество секунд самого последнего отснятого материала с задержкой видео для сохранения в файл.
Место сохранения (список): выберите место для сохранения клипа с задержкой видео после нажатия кнопки «Сохранить». См. Раздел «Сохраненные клипы с задержкой» ниже.

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

Сохраненные клипы с задержкой

Видеоклипы с отсроченным кадром можно сохранить в любое время, нажав кнопку «Сохранить» (см. «Сохранить» в разделе «Управление» выше).

В vMix есть два места для сохранения клипов задержки:

Список

Каждый сохраненный клип будет автоматически добавлен в отдельный вход списка по завершении. Этот вход списка предназначен для хранения всех клипов с задержкой видео в сеансе vMix независимо от источника.

Категория

Каждый сохраненный клип будет добавлен как отдельный вход в выбранной цветовой категории. См. Категории.

Обучение навыкам с задержкой видео

Я твердо верю в то, что для того, чтобы что-то улучшить, вам на 100% нужно уметь это видеть. Возьмем, к примеру, среду в классе. Представьте, что я опытный учитель физкультуры и вижу, как мои ученики борются с тем, как правильно бить по футбольному мячу. Как лучше всего передать им это? Что ж, я мог бы начать с объяснения недостатков или перейти на следующий уровень, предоставив демонстрацию.Все это хорошо, но они заходят далеко и не помогают нарисовать полную картину выступления.

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

В этом заключается сила видеоанализа, и это именно то, что вы можете сделать за секунды с помощью БЕСПЛАТНЫХ инструментов анализа видео.Чтобы проверить это, мы подготовили задание, над которым вы можете поработать со своими учениками, чтобы помочь им освоить новый навык.

Деятельность

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

Напротив, обучение предполагает постоянное изменение или улучшение поведения.

Обучение требует практики и использования обратной связи для внесения изменений и уточнений в мыслительные процессы и движения мышц.Это позволит постоянно улучшать выполнение навыка.

Чтобы увидеть это в действии, вам нужно принять участие в простом практическом задании, описанном ниже, и сообщить о своих выводах.

Цель

Цель: Изучить процессы, участвующие в обучении, и то, как эти факторы влияют на обучение.

Снаряжение: Теннисный мяч или аналогичный предмет и ведро или ящик для ловли мяча

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

Например: Теннисный мяч отскакивает в ведро с другой рукой, как показано ниже:

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

Предварительный тест: После настройки испытуемые будут иметь начальные десять испытаний, результаты
которые будут записаны в таблице предварительного тестирования?
Практика: Затем испытуемые немедленно перейдут к 10-минутному периоду практики
.

Ресурсы, которые помогут в вашей практике

Следующие БЕСПЛАТНЫЕ приложения предназначены для мгновенного воспроизведения без помощи рук. Просто установите заданное значение задержки (например, 10 секунд) и направьте приложение на ваше выступление. Теперь вы можете выполнить, а затем вернуться к устройству для просмотра.

Мгновенное воспроизведение с задержкой видео (iOS / Android)

Загрузите или просмотрите краткое видео ниже

Replay It (браузер Chrome)

Загрузите или просмотрите краткое видео ниже

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

Обсуждение:

1.Указывают ли результаты на то, что обучение имело место?
2. Можете ли вы предложить возможные причины ваших выводов?
3. У кого-то не было улучшений? Почему это могло произойти?

4. Объясните физические процессы, через которые вы прошли за десять минут практики.
5. Объясните умственные процессы, через которые вы прошли за десять минут практики.
6. Перечислите как можно больше факторов, которые, по вашему мнению, повлияли на ваше обучение во время этого упражнения.
7. Что больше всего повлияло на ваше обучение и почему?

Video Delay Instant Rplay Pro, автор michal bojanowicz

Мгновенное воспроизведение! Спортивная камера с регулируемой задержкой при воспроизведении. Самостоятельно анализируйте свои действия во время фитнес-тренировки или тренировок. Получите мгновенную обратную связь и развивайте правильную мышечную память. Воспроизведите свои действия в замедленном режиме! Ускорьте спортивные тренировки с помощью режима обнаружения движения! При необходимости записывайте свои действия.

Это приложение — ваш личный тренер! Отправляйтесь в спортзал со своей фитнес-камерой!

Чтобы быстрее получать результаты, тренируйтесь с умом и убедитесь, что вы соответствуете форме.Используйте Instant Replay, чтобы улучшить свое выступление. Выберите время задержки, делайте упражнение и смотрите автоматический повтор! Не нужно перематывать или прикасаться к устройству, видео будет воспроизводиться мгновенно. Вы также можете выбрать время задержки, нажав на экран при начале и завершении задачи.

Для более быстрых действий (продолжительностью около 3 секунд), таких как баскетбольная стрельба, удар в гольф, акробатика или боевые искусства, используйте режим замедленной съемки. Нажмите SLO, выполняйте свои действия и смотрите мгновенный повтор в замедленном режиме.Будьте готовы к следующему повторению, когда появится обратный отсчет. Вы можете настроить скорость замедленного воспроизведения с помощью ползунка.

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

Выберите один из 4 различных режимов записи видео, доступных в настройках:
* Непрерывный режим — когда вы нажимаете «REC», он начинает запись и будет продолжаться, пока вы не нажмете «STOP».
* Short Clips Mode (работает только в режиме SLO) — когда вы нажимаете «REC», он записывает каждый дубль с замедленным воспроизведением как новое видео.
* Buffered — записывает кадры камеры, которые уже находятся в буфере. Никогда не пропустите действие!
* Buffered Live — то же, что «Буферизованный», но показывает изображение с камеры в реальном времени вместо изображения с задержкой.

Тренеры и учителя физкультуры — используйте мгновенное воспроизведение с задержкой видео на экране телевизора (дублирование экрана). Анализируйте движения своих учеников с помощью видео обратной связи.

Video Delay Instant Replay отлично подходит для:

Фитнес / Спортивные тренировки / Физкультура
Crossfit / TRX workout
Баскетбол / Волейбол / Футбол
Теннис / Гольф
Силовые тренировки / Тяжелая атлетика / Бодибилдинг
Боевые искусства / Бокс / Спортзал
Гимнастика / Танцы
Физиотерапия / Йога / Пилатес
Фехтование / Стрельба из лука
Прыжки в воду / Плавание
Волшебные трюки / Веселые фильмы

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

Если вы тренируетесь по боевым искусствам или боксу, установите короткое время задержки, чтобы увидеть, как вы пинаете или пинаете в замедленной съемке!

Video Delay Instant Replay поможет вам тренироваться безопаснее, выполнять правильные упражнения и поддерживать хорошую осанку во время бодибилдинга или кроссфиттинга.

С помощью этого приложения Video Coach вы сможете улучшить свою форму баскетбольной стрельбы, скопировав своих любимых баскетболистов НБА.Также во время тренировок по баскетболу вы сможете увидеть, достаточно ли вы стоите на ногах или ваши ложные движения эффективны.

Если вы увлекаетесь футболом, Instant Replay поможет вам сравнить свою форму с лучшими футболистами.

Как насчет твоего удара в гольф? Теперь вы можете изучить свою форму удара в гольф и мгновенно исправить свои движения! То же самое с бейсбольными или теннисными качелями.

Это приложение для спортивной камеры отлично подходит для занятий физиотерапией и пилатесом. Оно может защитить вас от травм.Проверьте свою позу йоги с помощью мобильного фитнес-зеркала.

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

Вы можете установить столько времени задержки камеры, сколько позволяет память вашего устройства (йога, TRX, тренажерный зал или физиотерапия).