Ютуб hls или rtmp что выбрать

Примечания к исследованию технологии прямой трансляции (протокол прямой трансляции + сервер потокового мультимедиа + обработка аудио и видео + FFmpeg)

Живой протокол

RTMP（Real Time Messaging Protocol）

Вступление

Протокол обмена сообщениями времени, протокол обмена сообщениями в реальном времени

RTMP — это открытый протокол, разработанный Adobe для передачи аудио, видео и данных между Flash-плеерами и серверами.

Протокол: длинное соединение TCP

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

Задержка: 1 ~ 3 секунды

преимущество

• Высокий уровень реального времени: обычно можно сделать в течение 3 секунд.
• Поддержка шифрования: rtmpe и rtmps — это протоколы шифрования.
• Высокая стабильность: наиболее стабильным методом воспроизведения флэш-памяти на платформе ПК является rtmp. Если вы выполняете CDN или распределение больших и средних кластеров, необходимо выбрать протокол с высокой стабильностью.
• Обычно обычные кодеры поддерживают этот протокол.

Недостаток

• Протокол сложный: писать надоело, а эффективность невысока.
• Проблема с кешем: протокол потоковой передачи неудобно кешировать.

RTSP（Real Time Streaming Protocol）

Вступление

Протокол потоковой передачи в реальном времени（Real Time Streaming Protocol，RTSP) Это протокол сетевого приложения, предназначенный для использования в развлекательных и коммуникационных системах для управления серверами потокового мультимедиа. Этот протокол используется для создания мультимедийных сеансов между терминалами и управления ими. Клиент медиасервера выдает команды видеомагнитофона, такие как воспроизведение, запись и пауза, для управления медиапотоком от сервера к клиенту (видео по запросу) или от клиента к серверу (запись голоса) в реальном времени. .

Свой собственный рестриминговый RTMP сервер с конвертацией RTMP SRT UDP MPEG DASH HLS

Протокол потоковой передачи времени, протокол потоковой передачи в реальном времени)

преимущество

● Низкая задержка, обычно 500 мс.

● Хорошая пропускная способность и высокая временная эффективность.

● Двухскоростное воспроизведение — это в основном функция, обеспечиваемая во время воспроизведения.

● Точное управление, произвольный выбор точек воспроизведения.

Недостаток

● Сервер сложен в реализации.

● Слабые прокси-серверы: небольшое количество и меньшая оптимизация.

● Отсутствие проникновения межсетевого экрана маршрутизатора.

● Разделение потока в трубе: требуется 1-3 канала.

HLS（HTTP Live Streaming）

Вступление

HTTP Live Streaming(АббревиатураHLS) Является результатомяблокоНа основеHTTPизпотоковое мультимедиаПротокол сетевой передачи. ЯблокоQuickTime XсiPhoneЧасть программного обеспечения. Он работает, разделяя весь поток на небольшие файлы на основе HTTP и загружая каждый раз только несколько файлов. Когда медиапоток воспроизводится, клиент может выбрать загрузку одного и того же ресурса с разной скоростью из множества разных альтернативных источников, что позволяет сеансу потокового мультимедиа адаптироваться к разным скоростям передачи данных. При запуске сеанса потоковой передачи клиент загружаетextended M3U (m3u8) playlistФайл, используемый для поиска доступных медиапотоков.

YouTube HLS настройка стрима на Ютуб в 2023 для лучшего качества

Протокол: короткая ссылка HTTP

Принцип: сбор данных за определенный период времени, создание файла среза ts, обновление m3u8.

Задержка:> 10 секунд

преимущество

● Хорошая производительность: такая же, как у http.

● Через стену: то же, что и http.

● Встроенная поддержка очень хороша: поддержка на iOS идеальна, но поддержка на Android оставляет желать лучшего. Существуют также различные плагины для ПК / флэш-памяти, поддерживающие HLS.

Недостаток

● Плохая производительность в реальном времени: это связано с длиной ts-среза, задержкой примерно 3 длины среза, в основном задержка HLS составляет более 10 секунд.

● Фрагментация файла: если HLS распределен, поток кода низкий, а когда фрагмент маленький, это приведет к слишком большой фрагментации файла.

услуги потокового медиа

1. NGINX-rtmp
2. Node-media-server
3. livego
4. SRS

NGINX-rtmp

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

Протокол поддержки: RTMP / HLS / MPEG-DASH

Платформа поддержки: Linux / FreeBSD / MacOS / Windows

Если это платформа Windows, вы можете скачать скомпилированный файл напрямую.

Node-media-server

Введение: реализация медиа-сервера RTMP / HTTP-FLV / WS-FLV / HLS / DASH / MP4 в Node.js

Протокол поддержки: RTMP / HTTP-FLV / WS-FLV / HLS / DASH

Платформа поддержки: Windows / Linux / Unix

Официальный веб-сайт: https://github.com/illuspas/Node-Media-Server/

Разверните потоковую службу за одну минуту

livego

Введение: живой сервер, написанный на чистом Go

Протокол поддержки: RTMP / AMF / HLS / HTTP-FLV

Платформа поддержки: Windows / Linux / MacOS

SRS

Введение: SRS-позиционирование — это кластер серверов прямой трансляции в Интернете на рабочем уровне, обеспечивающий лучшую концептуальную целостность и простейшую реализацию кода.

Протокол поддержки: RTMP / RTSP / HSL / HTTP-FLV

Платформа поддержки: Linux / MacOS

Официальный сайт: https://github.com/ossrs/srs

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

Если вы хотите испытать в windows, вы можете скачать модифицированную версию пользователей сети.

Фактор задержки

Сетевая задержка

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

Предполагая, что по этой ссылке есть кеш и время равно Tmax_cache, тогда задержка от хоста до средства просмотра, Tdelay, составляет:

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

Итак, давайте просто оценим примерную задержку в сети. Как мы все знаем, скорость света в вакууме составляет около 300 000 км / с, в то время как скорость света в других средах будет значительно снижена, поэтому в обычном оптоволокне инженеры обычно считают, что скорость передачи составляет 200 000 км / с. На самом деле вы можете сослаться на следующее:

Задержка в оба конца (мс)

Пекин в Нью-Йорк

Следовательно, в случае меньшего количества узлов и лучшего состояния сети, сетевая задержка также будет наименьшей.С определенным буфером задержкой можно управлять на уровне примерно 1 ~ 2 с. Однако при большом количестве узлов и плохой сети задержка в сети соответственно увеличивается.Практика показывает, что задержка может достигать более 15 секунд.

Сетевой джиттер

Сетевой джиттер относится к несогласованности последовательности прибытия, интервала и времени пакетов данных. Например, если отправлено 100 пакетов данных, каждый пакет отправляется каждые 1 с. В результате 27-й пакет столкнулся с перегрузкой сети во время процесса передачи, в результате чего пакет 27 прибыл не сразу после 26, а задержался до момента после 87. В прямом эфире эффект джиттера фактически такой же, как и при потере пакетов. Потому что вы не можете воспроизводить контент в соответствии с порядком получения, иначе это вызовет искажение.

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

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

Потеря сетевых пакетов

RTMP, HLS, HTTP FLV и другие протоколы, используемые в прямом эфире CDN, основаны на TCP. Очень важной особенностью TCP является надежность, то есть потеря данных не произойдет. Для обеспечения надежности TCP использует трехстороннее квитирование во время передачи, как показано на рисунке ниже. Сначала клиент отправит серверу запрос на подключение, после чего клиент подтвердит подключение.

Это трехстороннее рукопожатие. Затем клиент начинает отправлять данные, каждый раз, когда он отправляет пакет данных, после получения «полученного» подтверждения от сервера он продолжает отправлять следующий пакет. Чтобы гарантировать передачу, TCP имеет механизм автоматической повторной передачи. Если во время передачи происходит потеря пакета, а «принятый» сигнал с противоположной стороны не получен, потерянный пакет будет автоматически повторно передан до истечения времени ожидания.

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

Накопленная задержка RTMP

Эта задержка возникает только в протоколе RTMP.

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

Следовательно, когда состояние сети плохое, сервер кэширует пакеты, вызывая накопленные задержки;

Когда состояние сети хорошее, отправьте их клиенту вместе.

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

GOP-Cache

Группа изображений（Group of pictures，GOP）

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

Фигура

Изображение с: https://www.processon.com/view/56ebb341e4b01c9aeb5f137f

Прочитав картинку выше, вы, вероятно, поймете, что задержка rtmp связана с gop.

Итак, почему задержка rtsp ниже, чем rtmp? Поскольку это точно контролируется, вы можете выпрыгнуть из этого контроля, основываясь на группе гопов.

Основные атрибуты видео

Частота кадров

Кадр относится к одному изображению в кодовом потоке, а частота кадров относится к количеству кадров кодового потока в единицу времени, единица измерения — fps (кадр в секунду). Видео, которое мы видим, состоит из одного кадра изображений, то есть одного изображения за другим; если за одну секунду выполняется 24 изображения, частота кадров составляет 24 кадра в секунду (кадров в секунду); есть только 8 изображений, и частота кадров составляет 24 кадра в секунду (кадров в секунду). Скорость составляет 8 кадров в секунду (кадров в секунду); чем выше частота кадров, тем более плавное изображение. Конечно, она в определенной степени велика, и в этом нет необходимости быть слишком большим. С одной стороны, нет никакой разницы между невооруженным глазом и компьютер не может этого вынести.!

Общая частота кадров

фильм:23.976fps

ТВ (PAL）：25fps

ТВ (NTSC）：29.97fps

CRTмонитор:60Hz-85Hz

ЖК монитор:60Hz-75Hz

3Dмонитор： 120Hz

Разрешение

Разрешение относится к размеру экрана. Чем выше разрешение, тем больше изображение.

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

Существует два типа разрешения: разрешение изображения и разрешение дисплея.Разрешение изображения относится к размеру изображения, а разрешение экрана — к разрешению экрана.

Для видео существуют стандарты разрешения фиксированного размера, такие как D1 (720 × 576), 4CIF (704 × 576), VGA (640 × 480), SVGA (800 × 600), VXGA (1600 × 1200) и т. Д. . Позже, для изображения с фиксированным соотношением сторон (16: 9) метод разрешения — это вертикальная высота плюс сканирование, например 720P (1280 × 720, прогрессивная развертка), 1080P (1920 × 1080, прогрессивная развертка), 1080I (1920 × 1080, чересстрочная развертка), а затем назад используйте описание горизонтальных пикселей, например 2K (2048 × 1536 или 2560 × 1440 или 2560 × 1600), 4K (4096 × 2160 или 3840 × 2160), 8K (7680 × 4320 )).

Битрейт

Кодовая скорость — это скорость передачи данных, которая относится к битам данных, сгенерированным за единицу времени, в битах в секунду (бит в секунду), 1 Мбит / с = 1024 кбит / с = 1048576 бит / с. Как правило, при определенном разрешении чем выше скорость передачи данных, тем лучше качество видео.

(* Обратите внимание на разницу между битами в секунду и битами в секунду, 1 бит / с = 8 бит в секунду.)

Как правило, битрейт 720P составляет около 2 ~ 4 Мбит / с, а битрейт 1080P — около 4 ~ 8 Мбит / с. Для пользователей это требование широкополосного доступа. Видео 720P требует не менее 2M полосы пропускания, в зависимости от 1080P. Видео требует пропускной способности не менее 4 М. В текущем внутреннем сетевом окружении скорости восходящего и нисходящего потоков не равны. Если точка привязки хочет использовать видео высокой четкости, необходимо убедиться, что пропускная способность восходящей линии связи достаточна.

Кодирование

Обычно мы постоянно думаем, как сделать видеофайл меньше и четче? Ответ заключается в скорости передачи данных. Обработка скорости передачи данных называется методом кодирования. Как правило, существует три метода: CBR / ABR / VBR.

Полное название CBR — постоянный битрейт, что означает фиксированный битрейт, что означает, что битрейт фиксирован для всего видео;

ABR означает средний битрейт, что означает средний битрейт, что является компромиссом между CBR и VBR.

Кодек Метод кодирования видео

Среди них кодирование MPEG-1 используется для старых VCD, кодирование MPEG-2 используется для DVD, а позже MPEG-4 используется для все более обширных платформ, где MPEG-4 является легендарным MP4;

Кроме того, существует еще один набор методов кодирования под руководством Международного союза телексных видео (ITU), названный серией H.26X. Позже, в сотрудничестве с MPEG, был разработан метод кодирования H.264, который стал наиболее популярным. метод кодирования сегодня.

Формат контейнера

Список основных форматов упаковки

Источник: russianblogs.com

Ютуб hls или rtmp что выбрать

Плюсы и минусы HTTP Live Streaming

HLS (HTTP Live Streaming) — это протокол для передачи видео с адаптивным битрейтом. Первоначально разработанный Apple для яблочных систем, сегодня HLS стал самым используемым протоколом для передачи потокового медиа. В этой статье — всё про его особенности.

Как работает HTTP Live Streaming

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

HLS исторически поддерживает такие кодеки медиа, как h.264, AAC или MP3. Относительно недавно этот список дополнил и кодек видео h.265. Аналогичным образом работают протоколы MPEG-DASH, Microsoft Smooth Streaming и Adobe HTTP Dynamic Streaming (HDS).

Преимущества протокола HLS

Доставка на любые устройства

Microsoft Smooth Streaming и Adobe HTTP Dynamic Streaming (HDS) HLS поддерживают большинство браузеров и мобильных устройств. В перспективе MPEG-DASH тоже может получить широкую поддержку, но пока что он не поддерживается устройствами Apple. Остальные два протокола, Microsoft Smooth Streaming и Adobe HTTP Dynamic Streaming (HDS), сегодня совсем не распространены.

Запись и прямой эфир

Протокол HLS поддерживает как прямые трансляции, так и просмотр записей. Благодаря технологии манифеста и фрагментации, перемотка работает быстро и доступна одновременно с возможностью переключиться в прямой эфир. Это важное преимущество перед протоколами RTMP и WEBRTC, ориентированными только на прямой эфир.

Управление цифровыми правами

Протокол HLS поддерживает управление цифровыми правами (DRM). Технология позволяет отследить незаконное использование контента — как записей, так и прямого эфира. При этом инфраструктура управления цифровыми правами достаточно проста.

Неограниченная аудитория

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

Недостатки протокола HTTP Live Streaming

Любые технологии не идеальны, и HLS не исключение. Один из наиболее распространенных вопросов — латентность.

Задержки HLS

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

Но цель HLS — максимальная совместимость с клиентскими устройствами, а не минимизация абсолютной задержки. Поэтому типовое значение задержки — 10-25 секунд.

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

Можно ли решить вопрос с латентностью?

Протокол HLS продолжает развиваться. Летом 2019 года компания Apple разработала расширение LHLS — оно позволяет достичь задержки менее 2 секунд. В перспективе эта модификация будет поддерживаться практически всеми плеерами и мобильными устройствами.

В Facecast мы также разработали варианты потоковой передачи HLS с низкой задержкой. Наше решение уменьшит задержку до 10 секунд или меньше. Оно соответствует современным стандартам безопасности браузера посредством доставки HTTPS и позволит охватить все мобильные устройства.

Интеграционное решение StreamLabs и Haivision

Для передачи видео между разными локациями существует несколько способов:

1. Спутниковые и/или наземные выделенные линии. Но: их долго и очень дорого организовывать.
2. Проприетарные протоколы. Но: жесткая привязка к одному вендору и невозможность использовать один протокол во всей линии передачи влечет за собой дополнительные расходы и организационные проблемы.
3. RTMP, HLS и другие протоколы. Но: они изначально созданы для других задач и имеют существенные технические недостатки — плавающая задержка, привязка к кодекам, ограничения по количеству аудио пар и пр.

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

Решения VPlay/VRec от компании Stream Labs умеют работать с видео в протоколе SRT на прием и передачу, а компания Haivision предлагает энкодеры/декодеры и шлюзы вещательного класса для получения и доставки сигнала в любой точки мира с помощью надежного протокола SRT.

Области совместного применения:

ТВ-вещание

• вывести в прямой эфир репортаж с «полей» c качеством до 4K с помощью энкодера Haivision или мобильного телефона с установленным бесплатным ПО Haivision Play Pro;
• организовать включение внешних линий из удаленной студии;
• осуществить перегоны материала из корр. пунктов;
• организовать прием передачи материала от новостных агентств.

Видеопотоки приходят на вещательный сервер Stream Labs VPlay/VRec для включения в прямой эфир и/или для записи.

1. Нет необходимости использовать дополнительные аппаратные декодеры для введения видеопотоков;
2. ПО Stream Labs VPlay/VRec нативно поддерживает входящие видеопотоки SRT, обеспечивая аппаратное/программное декодирование;
3. Нет необходимости изменения настроек входящих SRT потоков — они настраиваются один раз для работы с Haivision SRT Gateway.

ТВ-производство

• осуществлять удаленное многокамерное видеопроизводство — сигналы с удаленных камер могут быть синхронно записаны сервером VRec.

1. Возможность автоматизированной тегированной разметки захватываемого видео с последующим экспортом монтажного решения в Adobe Premiere Pro, DaVinchi Resolve, Apple Final Cut X для многокамерного видеомонтажа;
2. Отсутствие необходимости использовать дополнительные аппаратные декодеры для введения видеопотоков в ПО многоканальной записи Stream Labs VRec;
3. ПО VRec нативно поддерживает входящие видеопотоки SRT, обеспечивая аппаратное/программное декодирование;
4. Не нужно изменять настройки входящих SRT потоков — они настраиваются один раз для работы с Haivision SRT Gateway.

О протоколе SRT

*Протокол потоковой передачи данных SRT (Secure Reliable Transport Protocol) – это адаптивный протокол с открытым исходным кодом, впервые разработанным компанией Haivision, который использует интеллектуальный механизм повторной передачи пакетов данных на основе UDP-протокола (User Datagram Protocol) совместно с AES-256 шифрованием.

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

Достоинства SRT протокола:

• поддержка любых видео кодеков, включая H.264 и H.265 HEVC, разрешений видео до 4K;
• более низкие задержки — в 2.5–3.2 в сравнении с протоколом RTMP;
• позволяет сохранять максимальную скорость передачи из конца в конец, при передаче с любым количеством промежуточных узлов;
• имеет настраиваемый видеобуфер для регулирования адаптивности, поддерживает шифрование AES-256 для видео потока.

Источник: haivision.ru