Rtsp в роутере что это
Что такое протокол RTSP и как его использовать для IP-камеры?
Что представляет собой протокол RTSP?
RTSP или сетевой протокол потоковой передачи в реальном времени включен во все IP-камеры, NVR и DVR видеорегистраторы, обеспечивая гибкость для интеграции видео с продуктов, произведенных одной компанией, в продукты сторонних производителей.
RTSP протокол для систем ip видеонаблюдения
RTSP-поток от системы наблюдения или IP-камеры видеонаблюдения напрямую связан с настройками кодирования, установленными на самом устройстве. Это означает, что любой, кто хочет транслировать на телевизор или монитор 4K, должен приобрести видеокамеру 4K или систему 4K NVR.
Когда и зачем используется поток RTSP?
Альтернативный поток для повышения совместимости с ONVIF
Запись или резервное копирование в другое место
Потоковая передача RTSP также предоставляет возможность перезаписать и сохранить поток на другом сервере или записывающем устройстве. Поскольку RTSP существует уже давно, имеется множество серверов, которые его поддерживают. Большинство систем видеонаблюдения не только предоставляют потоки RTSP для отправки видео, они также могут принимать потоки RTSP для записи! Это полезно для клиентов, которые предпочитают иметь вторичную или резервную копию своих отснятых материалов, или если это требуется установленными правилами.
Системная интеграция умного дома
Системы «умный дом» совместимы с потоками RTSP для отображения камер или рекордеров на оборудовании домашней автоматизации. Технология RTSP предоставляет простой способ передачи видеопоток на несколько устройств в доме одновременно. Например, если у человека есть несколько планшетов или станций управления домом, он может получать поток с камеры или сетевого видеорегистратора независимо от того, где он находится в своем доме или офисе.
Программа VLC Media Player для использования потоков RTSP
Ретрансляция потока на сервисы потокового вещания
После установки и настройки программного обеспечения будет осуществляться потоковая передача видео в реальном времени на Youtube, Facebook Live или Twitch, в зависимости от того, что пользователь выберет для потоковой передачи.
Что такое протокол RTSP для IP-камер
Протокол RTSP можно использовать для передачи изображений в системах видеонаблюдения, и благодаря его совместимости с несколькими устройствами он является отличным вариантом для гибридных проектов.
В этой статье вы узнаете, что такое протокол RTSP и как его использовать для IP-камеры, цифрового рекордера (DVR) или сетевого рекордера (NVR).
Что такое протокол RTSP?
Этот протокол не был создан исключительно для видеонаблюдения, он уже использовался в других секторах, где существует необходимость в передаче в реальном времени, был принят производителями устройств видеонаблюдения и стал стандартным протоколом.
Протокол RTSP для CCTV
Производители видеонаблюдения внедряют протокол RTSP на своих камерах, рекордерах и программном обеспечении, чтобы они были совместимы с другими устройствами, доступными на рынке.
Приобретая IP-камеру и сетевой видеомагнитофон от разных производителей, вы можете общаться с ними по этому универсальному протоколу.
Для настройки оборудования необходимо выяснить, какую команду RTSP следует использовать, и эту информацию можно найти в руководстве по продукту или в службе технической поддержки.
Как использовать протокол RTSP
Представьте, что вы приобрели IP-камеру у Dahua (китайского производителя) и хотите использовать ее с сетевым рекордером (NVR), который у вас уже есть, но он принадлежит другому производителю, например Samsung.
Вам следует поискать в руководстве по эксплуатации камеры Dahua команду RTSP, которая должна использоваться для потоковой передачи видео по сети.
Если вы не найдете эту информацию в руководстве по продукту, вам следует обратиться в службу технической поддержки производителя, поскольку очень важно, чтобы вы получили правильную команду, чтобы ваше оборудование могло взаимодействовать друг с другом.
После получения этой информации вы должны вставить ее в устройство записи, которое инициирует запрос на отправку видео по этому универсальному протоколу.
На практике просто откройте меню NVR и введите команду RTSP, а затем введите имя пользователя и пароль IP-камеры, и после получения этой информации камера отправит видеопоток в реальном времени.
Как использовать протокол RTSP для облачной записи
Принцип записи видео в облаке тот же, просто используйте правильную команду RTSP, чтобы запросить камеру отправить видео на сервер, который находится где-то в Интернете.
На приведенной ниже схеме показана IP-камера, которая установлена во внутренней сети и подключена к маршрутизатору. Вам просто нужно настроить сервер записи в облаке для отправки команды RTSP через Интернет, и как только она будет получена камерой, она начнет потоковую передачу видео.
В этом примере сервер просто отправляет команду RTSP через Интернет и, достигнув внешнего интерфейса маршрутизатора, направляет его во внутреннюю сеть, где расположена камера.
Следовательно, необходимо настроить маршрутизатор и ввести правила маршрутизации, основанные на сетевых интерфейсах и портах связи.
Как проверить IP-камеру с протоколом RTSP
Существует традиционное бесплатное программное обеспечение под названием VLC, которое можно использовать для таких тестов. Диаграмма ниже показывает пример того, как его использовать.
В этом примере IP-камера подключена к маршрутизатору, который, в свою очередь, подключен к ноутбуку, который использует программное обеспечение VLC для отправки команды RTSP на камеру. Все находится в локальной сети, и поэтому нет необходимости в правилах маршрутизации (устройства подключены к внутренним портам).
В программном обеспечении VLC просто откройте меню « Media> Open Network Stream » или введите CTRL + N и вставьте команду RTSP с IP-камеры.
Команда в этом случае:
После отправки команды вы можете увидеть изображение IP-камеры прямо на ноутбуке, что подтверждает правильность используемой команды, а также правильность сетевых подключений и IP-адресов.
После этого начального теста можно перейти к более сложным тестам и использовать удаленное соединение с устройствами записи IP-камер или системами облачной записи.
Практический пример использования протокола RTSP через облако
Давайте поговорим о практическом примере использования протокола RTSP для CCTV.
Представьте себе ситуацию, когда у вас есть несколько аналоговых камер видеонаблюдения, подключенных к цифровому рекордеру (DVR), и вы намерены иметь избыточные видеозаписи. Вам просто нужно выбрать сервис, который позволяет хранить все на сервере в облаке (где-то в Интернете).
На рынке доступно множество облачных сервисов и вы можете выбрать тот, который лучше всего соответствует вашим потребностям.
В этом примере я буду использовать службы Angelcam, которые работают с различными марками устройств, а также хорошо работают с протоколом RTSP.
Настройка роутера для работы с облаком
Перед выполнением тестов с помощью команды в облаке необходимо настроить маршрутизатор, эта процедура предельно проста, достаточно использовать информацию IP и порт IP-камеры.
По сути, вы должны сообщить маршрутизатору, что он должен направлять трафик, поступающий из Интернета, на IP-камеру всякий раз, когда запрос направлен на определенный логический порт, который в случае протокола RTSP по умолчанию равен 554.
Очевидно, вам придется искать другие меню в разных моделях маршрутизаторов, обычно вы находите это меню как переадресация портов, переадресация портов или NAT.
Как настроить облачный сервер
Видеорегистратор Dahua может беспрепятственно работать с этой службой, поскольку она позволяет использовать команду RTSP, а информация, необходимая для настройки, доступна в руководстве по продукту.
В этом конкретном случае устройство представляет собой 4-канальный цифровой видеорегистратор Dahua, который использует следующую команду RTSP
Просто используйте эту команду и замените информацию об IP, порте, пользователе и пароле, и все, все будет работать в соответствии с вашей сетью. Все должно быть настроено на стороне сервера облака, и правила маршрутизации должны быть готовы на маршрутизаторе, который находится в вашей локальной сети.
Посмотрите на следующем изображении пример того, как настроить облако Angelcam. После создания учетной записи платформы на сайте https://angelcam.com войдите под именем пользователя и паролем и выберите опцию DVR и NVR.
После этого просто введите или вставьте команду RTSP, как показано на следующем рисунке
Обратите внимание, что используемая команда включает внешний IP-адрес, используемый маршрутизатором, и порт 554, который использовался в конфигурации маршрутизатора и который является стандартом DVR.
Важно понимать концепцию: команда RTSP, отправляемая облачным сервером, поступает на маршрутизатор через внешний интерфейс перед маршрутизацией в соответствии с установленными правилами, и поэтому вы должны убедиться, какой внешний IP-адрес используется маршрутизатором.
На следующем рисунке показан конечный результат подключения камеры к серверу в облаке.
В некоторых случаях вы заметите, что качество изображения может ухудшаться из-за некоторых факторов, таких как отсутствие стабильности интернет-соединения, уменьшение доступной полосы пропускания или несовместимость команд между облачным сервером или камерой.
Обязательно обновите микропрограмму IP-камеры до последней доступной версии, это поможет поддерживать совместимость с системами, которые используют RTSP в качестве облачных сервисов и рекордеры других марок.
Если у вас нет статического IP-адреса в вашей интернет-ссылке
Если у вас нет статического IP-адреса в интернет-соединении, вы можете использовать службу DDNS, доступную в Интернете, поэтому облачная служба будет продолжать работать и записывать изображения с вашей камеры, даже если произошла автоматическая смена внешнего IP-адреса. вашего роутера.
Как найти команду RTSP вашей IP-камеры
Заключительные соображения
Теперь вы уже знаете, что такое протокол RTSP и как вы можете проводить тесты и использовать его в практических ситуациях.
Я рекомендую вам выполнить локальные тесты с программным обеспечением VLC и устройствами, имеющимися в вашей сети, чтобы ознакомиться с использованием этого протокола.
Если понравилась статья поделитесь в социальных сетях, кликнув по иконкам ниже
Русские Блоги
[RTSP / RTP / RTCP / SDP] Подробное объяснение протокола
1. Протокол RTSP
Разница и связь между RTSP и HTTP:
(1) Контакт: оба отправляют сообщения в виде простого текста, а синтаксис протокола rtsp аналогичен HTTP. Rtsp был разработан таким образом в начале, чтобы быть совместимым с кодом анализа протокола HTTP, написанным ранее.
Существует два типа сообщений RTSP: сообщения запроса и ответные сообщения. Сообщение запроса относится к сообщению запроса, отправляемому от клиента на сервер, а сообщение ответа относится к ответу от сервера клиенту.
Общие методы RTSP включают в себя: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER и SET_PARAMETER.
Краткое описание метода RTSP:
Получение описания объекта мультимедиа также позволяет использовать заголовок получения, чтобы указать формат описания, который понимает пользователь.
При отправке с клиента на сервер, ANNOUNCE отправляет описание медиа-объекта, идентифицированного URL-адресом запроса, на сервер;
При отправке с сервера клиенту, ANNOUNCE обновляет описание соединения в режиме реального времени. Если новый носитель добавлен или изменен, все описание презентации будет отправлено снова
Запрос GET_PARAMETER для проверки значения параметра носителя, указанного в URL. Когда сущности нет, GET_PARAMETER может использоваться для проверки соединения между пользователем и сервером.
Получать методы, поддерживаемые сервером, или выдавать запросы OPTIONS в любое время, чтобы подтвердить состояние сервера или клиента.
Запрос PAUSE вызвал временное прерывание потоковой передачи. Если URL запрашивается для присвоения имени потоку, останавливаются только воспроизведение и запись, а если URL запрашивается для присвоения имени презентации или группе потоков, все активные в данный момент потоки в презентации или группе останавливаются. После возобновления воспроизведения или записи необходимо сохранить синхронизацию.
PLAY указывает серверу начать отправку данных с использованием механизма, указанного в SETUP, клиент может отправить запрос PLAY только после того, как на запрос SETUP был успешно получен ответ. Запрос PLAY устанавливает нормальное время воспроизведения в начале указанного диапазона и отправляет потоковые данные до конца диапазона. Запросы PLAY могут быть поставлены в очередь, сервер ставит в очередь запросы PLAY и выполняет их последовательно
Этот метод инициализирует диапазон записи мультимедийных данных в соответствии с описанием презентации, а временная шкала отражает время начала и окончания, а если временной диапазон не задан, используются время начала и окончания, предоставленные описанием презентации. Если соединение было инициировано, запись начинается немедленно. URL-адрес запроса данных сервера или другой URL-адрес решает, сохранять ли записанные данные; если сервер не использует запрос URL-адреса, ответ должен быть 201 (создать) и включать в себя объект, описывающий состояние запроса и ссылающийся на новый ресурс. Поставь голову Медиа-сервер, поддерживающий живую демонстрационную запись, должен поддерживать формат диапазона часов, а формат smpte не имеет смысла
Запрос на перенаправление информирует клиента о подключении к другому адресу сервера. Он содержит обязательный адрес заголовка, который указывает клиенту на выдачу запроса URL, а также может включать диапазон параметров, указывающий, когда перенаправление вступает в силу. Если клиент хочет продолжить отправку или получение URL-адреса мультимедиа, он должен отправить запрос TEARDOWN для текущего соединения и запрос SETUP для указанного мастера для выполнения нового соединения.
Запрос SETUP к URL-адресу определяет механизм передачи для потокового мультимедиа. Вы также можете заставить клиента выполнить запрос SETUP для воспроизводимого потока, чтобы изменить параметры передачи, разрешенные сервером. Если это не разрешено, ответом будет ошибка 455 «Метод недопустим в этом состоянии». Чтобы пройти через брандмауэр, клиент должен указать параметры передачи, даже если они не влияют на эти параметры.
Этот метод запрашивает установку значения параметра демо или указанного URL потока. Запрос должен содержать только один параметр, позволяющий клиенту решить, почему конкретный запрос не удался. Если запрос содержит несколько параметров, все параметры могут быть установлены успешно, и сервер должен действовать только по запросу. Сервер должен разрешить многократное задание одинаковых значений параметров, но не изменять значения параметров. Примечание. Параметры потоковой передачи мультимедиа должны быть установлены с помощью команды SETUP. Ограничение настроек параметров передачи на SETUP выгодно для брандмауэра. Разделите параметры на регулярное расположение, результат имеет более значимые признаки ошибок
Запрос TEARDOWN прекратить отправку данного потока URL и освободить связанные ресурсы.
Сообщение RTSP состоит из трех частей, а именно: начальная строка, первая строка и тело объекта.
Простой интерактивный процесс RTSP
C означает клиент RTSP, S означает сервер RTSP
Вышеупомянутый процесс является стандартным и дружественным процессом RTSP, но фактический спрос не обязательно приходит шаг за шагом.
Шаги 3 и 4 обязательны! Пока клиент сервера соглашается с тем, какие методы доступны, запрос опции может не потребоваться. На втором этапе, если у нас есть другие способы получения информации описания инициализации носителя (например, HTTP-запрос и т. Д.), Нам не нужно завершать запрос описания в rtsp. На шаге 5 вы можете решить, нужно ли вам это, исходя из требований к системе.
2. Протокол RTP
RTP пакет:
Номер версии (V): 2 бита, используются для обозначения используемой версии RTP.
Бит заполнения (P): 1 бит. Если этот бит установлен, конец пакета RTP содержит дополнительные байты заполнения.
Бит расширения (X): 1 бит. Если этот бит установлен, за фиксированным заголовком RTP следует заголовок расширения.
Счетчик CSRC (CC): 4 бита, содержащие количество CSRC, за которыми следует фиксированный заголовок.
Бит метки (M): 1 бит, интерпретация этого бита принимается профилем.
Тип полезной нагрузки (PT): 7 бит, определяющий тип полезной нагрузки RTP.
Порядковый номер (SN): 16 бит. Отправитель увеличивает значение на 1 после отправки каждого RTP-пакета. Получатель может определить потерю пакета и восстановить последовательность пакетов из этого значения. Начальное значение серийного номера является случайным.
Отметка времени: 32 бита, записывающая время выборки первого байта данных в пакете. В начале сеанса метка времени инициализируется начальным значением. Даже если нет сигнала для отправки, значение метки времени должно продолжать увеличиваться со временем (время идет). Отметка времени необходима для устранения джиттера и синхронизации.
Идентификатор источника синхронизации (SSRC): 32 бита. Источник синхронизации относится к источнику потока пакетов RTP. В одном сеансе RTP не может быть двух одинаковых значений SSRC. Идентификатор выбирается случайным образом. RFC1889 рекомендует алгоритм случайных чисел MD5.
Список источников вклада (список CSRC): от 0 до 15 элементов, каждый по 32 бита, используется для маркировки источника всех пакетов RTP, которые вносят вклад в новый пакет, сгенерированный микшером RTP. Микшер вставляет эти идентификаторы SSRC в таблицу. Идентификаторы SSRC перечислены так, чтобы принимающая сторона могла правильно указывать идентификационные данные обеих сторон в разговоре.
Три, RTCP
RTCP(Real-time ControlProtocol, RTCP) Основными функциями протокола управления передачей в реальном времени являются: мониторинг качества обслуживания и обратная связь, синхронизация между носителями и идентификация участников в многоадресной группе.Во время сеанса RTP каждый участник сеанса периодически отправляет контрольные пакеты RTCP всем другим участникам.Каждый пакет RTCP не инкапсулирует звуковые данные или телевизионные данные, но инкапсулирует статистические отчеты на принимающей стороне (и / или) принимающей стороне. RTCP также передается с использованием UDP.
В соответствии с передаваемой управляющей информацией пакеты RTCP можно разделить на пять категорий: RR (пакет отчета о приемнике), SR (пакет отчета об источнике), SEDS (пакет описания источника), BYE (объявление о выходе) и APP (пакет специального приложения) учебный класс:
SDES（Source Description Items）
Отправка пакета конечного отчета, используемого для отправки и получения статистической информации об активных источниках;
Группа отчетов отправителя SR (Sender Report) используется для того, чтобы отправитель мог сообщать о статусе отправки всем получателям многоадресным способом. Основным содержимым пакета SR являются: SSRC (источник синхронизации определения) соответствующего потока RTP, отметка времени и NTP пакета RTP, вновь сгенерированного в потоке RTP, количество пакетов, включенных в поток RTP, и количество байтов, включенных в поток RTP. Пакет SR инкапсулирован, как показано ниже:
Версия (V): То же, что поле заголовка RTP.
Заполнение (P): То же, что поле заголовка RTP.
Счетчик отчета о приеме (RC): 5 битов, количество блоков отчета о приеме в этом пакете SR может быть нулевым.
Тип пакета (PT): 8 бит, пакет SR равен 200.
Длина: 16 бит, где общая длина пакета SR в единицах по 32 бита уменьшается на единицу.
Источник синхронизации (SSRC отправителя): идентификатор источника синхронизации отправителя пакета SR. То же, что SSRC в соответствующем RTP-пакете.
NTP Timestamp (Сетевой протокол времени) Абсолютное значение времени при отправке пакета SR. Роль NTP заключается в синхронизации различных потоков мультимедиа RTP.
Отметка времени RTP: соответствует отметке времени NTP и имеет ту же единицу и случайное начальное значение, что и отметка времени RTP в пакете данных RTP.
Количество пакетов отправителя: общее количество пакетов данных RTP, отправленных отправителем в течение периода от начала отправки пакета до генерации этого пакета SR. Это поле очищается при изменении SSRC.
Число октетов отправителя: общее количество байтов данных полезной нагрузки, отправленных отправителем (исключая заголовок и заполнение) с момента отправки пакета до формирования пакета SR. Когда отправитель меняет свой SSRC, это поле должно быть очищено.
SSRC-идентификатор источника синхронизации n: этот блок отчета содержит статистическую информацию о пакетах, полученных из этого источника.
Потерянная скорость (Fraction Lost): указывает потерю пакетов RTP из источника синхронизации n (SSRC_n) с момента отправки последнего пакета SR или RR.
Накопленная потеря пакетов: общее количество пакетов RTP, потерянных от SSRC_n с начала приема пакета SSRC_n до отправки SR.
Получен расширенный максимальный порядковый номер: максимальный порядковый номер в пакете RTP, полученном от SSRC_n,
Полученный джиттер (Interarrival jitter): статистическая оценка дисперсии времени приема пакета RTP
Отметка времени последнего SR (Last SR, LSR): возьмите средние 32 бита отметки времени NTP в пакете SR, недавно полученном от SSRC_n. Если пакет SR не был получен, поле очищается.
Задержка с момента последнего SR (Задержка с момента последнего SR, DLSR): задержка с момента последнего получения SSRC_n пакета SR для отправки этого отчета.
Пакет отчетов приемника, используемый для получения статистической информации о неактивных станциях;
Пакет отчета источника SR и пакет отчета приемника RR используются для обеспечения обратной связи по качеству приема,В дополнение к коду типа пакета единственное различие между SR и RR состоит в том, что исходный отчет содержит 20-байтовый раздел информации об отправителе.Для каждого источника RR предоставляет информацию, такую как количество потерянных пакетов, максимальное порядковое число принятых пакетов, дрожание времени прибытия, время для приема последнего SR и задержка для приема последнего SR. SR не только предоставляет информацию обратной связи о качестве приема (так же, как RR), но также предоставляет идентификатор SSRC, временную метку NTP, временную метку RTP, количество отправленных пакетов и количество отправленных байтов. В зависимости от того, является ли получатель отправителем, чтобы решить, использовать ли пакеты SR или RR, активный источник отправляет SR после отправки последнего пакета или в течение интервала между предыдущим пакетом и следующим пакетом, в противном случае он отправляет RR; пакеты как SR, так и RR Может быть несколько блоков отчета о приеме без блока отчета о приеме, и источник, указанный в его отчете о выпуске, не обязательно является действующим источником в списке CSRC, и каждый блок отчета о приеме предоставляет статистику данных, принятых из конкретного источника. Может быть не более 31 блока отчетов о приеме, встроенных в пакеты SR или RR. Разница в совокупном количестве потерянных пакетов дает количество пакетов, потерянных в течение интервала, а разница в серийных номерах дает количество пакетов, ожидаемых для отправки в течение интервала. Соотношение двух равно Процент потери пакетов в течение интервала. На основании информации об отправителе сторонний монитор может рассчитать среднюю скорость передачи данных нагрузки и среднюю скорость передачи пакетов за неполученный интервал данных. Соотношение между ними дает средний размер загрузки. Если предполагается, что потеря пакета не имеет никакого отношения к размеру пакета, количество пакетов, полученных конкретным приемником, дает видимый трафик, полученный этим приемником.
3、SDES：
Пакет описания источника для отчетов и информации, связанной с сайтом, включая CNAME;
Пакет описания источника SDES предоставляет интуитивно понятную текстовую информацию для описания участников сеанса, включая CNAME, NAME, EMAIL, PHONE, LOC и другие элементы описания источника, что позволяет получателю получить информацию об отправителе. Пакет SDES состоит из заголовка пакета и блока данных. Блок данных может отсутствовать или быть множественным. Заголовок пакета состоит из версии (V), заполнения (P), указания длины, типа пакета (PT) и количества источников (SC). PT занимает 8 битов и используется для идентификации пакетов RTES SDES. SC занимает 5 битов и указывает количество блоков SSRC / CSRC, содержащихся в пакете SDES. Нулевое значение является действительным, но не имеет значения. Блок данных состоит из элементов описания источника. Содержимое элементов описания источника выглядит следующим образом:
CNAME: стандартная идентификация терминала, элемент SDES
Подобно логотипу SSRC, RTCP назначает уникальный логотип CNAME каждому участнику подключения RTP. Когда возникает конфликт или программа перезапускается, поскольку случайно назначенный идентификатор SSRC может измениться, элемент CNAME может обеспечить привязку идентификатора SSRC к идентификатору источника, который все еще остается постоянным.
Чтобы облегчить сторонний мониторинг, CNAME должен подходить для программ или персонала, чтобы найти источник.
NAME: имя пользователя, элемент SDES
Это реальное имя, используемое для описания источника, например «Джон Доу, Бит Рециклер, Мегакорп», которое может быть любой формы, которую хочет пользователь. Поскольку текстовая информация используется для описания, для приложений, таких как конференции, участники могут быть непосредственно отображены в списке. Элемент NAME является наиболее часто отправляемым элементом, кроме элемента CNAME. Значение NAME должно оставаться постоянным во время сеанса RTP, но оно не должно быть единственной зависимостью среди всех подключенных участников.
EMAIL: адрес электронной почты SDES item
Формат адреса электронной почты определяется RFC822, например, «[email protected]». Во время сеанса RTP содержимое элемента EMAIL надеется остаться неизменным.
ТЕЛЕФОН: Номер телефона SDES пункт
LOC: пользовательский географический элемент SDES
В зависимости от приложения этот элемент имеет разные уровни детализации. Для приложений конференции достаточно такой строки, как «Мюррей Хилл, Нью-Джерси». Однако для активных систем маркировки могут применяться строки символов, такие как «Room 2A244, AT & T BL MH». Детали оставлены для реализации или пользователей, но формат и содержание могут быть установлены инструкциями. Ожидается, что во время сеанса RTP, за исключением мобильного хоста, значение LOC останется неизменным.
ИНСТРУМЕНТ: название приложения или инструмента
Элемент TOOL содержит строку, которая представляет имя и версию приложения, сгенерировавшего поток, например «videotool 1.2». Эта часть информации полезна для отладки, аналогично заголовку SMTP почты или версии почтовой системы. Значение TOOL остается неизменным во время сеанса RTP.
ПРИМЕЧАНИЕ: элемент SDES уведомления / статуса
Элемент NOTE предназначен для описания информации о переходе текущего состояния источника, например, «по телефону, не могу говорить», или темы, используемой для передачи разговора во время лекции, его синтаксис может быть явно определен в настройках. Элемент ПРИМЕЧАНИЕ, как правило, используется только для переноса информации об исключениях и не должен включаться во всех участников, поскольку это снизит скорость получения отчетов и отправки CNAME и повредит выполнению соглашения. Как правило, элемент NOTE не используется как элемент в файле настроек пользователя, и при этом он не создается автоматически.
Поскольку элемент NOTE очень важен для отображения, когда участники сеанса активны, скорость передачи других элементов, отличных от CNAME (таких как NAME), будет уменьшена, в результате чего элемент NOTE будет занимать часть полосы пропускания RTCP. Если информация перехода не активна, элемент NOTE продолжает отправляться несколько раз с той же скоростью, и получатель уведомляется строкой нулевой длины строки.
PRIV: специальный расширенный пункт SDES
Обратите внимание, что префикс должен быть максимально коротким. Префикс PRIS SDES не зарегистрирован в IANA. Если подтверждается, что некоторые формы элементов PRIV являются универсальными, IANA должна назначить ему формальный тип элемента SDES, чтобы префикс не требовался, что упрощает применение и повышает эффективность передачи.
Если микшер принимает пакет BYE, микшер пересылает пакет BYE без изменения логотипа SSRC / CSRC. Если микшер выключен, он должен выдать пакет BYE перед закрытием, перечисляя все источники, обработанные микшером, а не только его собственный идентификатор SSRC. Как вариант, пакет BYE может включать 8-значный восьмеричный счет, за которым следует текстовое сообщение с указанием причины ухода, например: «cameramalfunction» или «RTPloop обнаружено». Кодировка строки символов такая же, как описано в пункте SDES. Если строковая информация достигает конца 32-битной границы в пакете BYE, строка не заканчивается нулем, в противном случае пакет BYE заполняется пустым восьмеричным.
Пакет APP используется для разработки новых приложений и экспериментов с новыми функциями и не требует регистрации значений типа пакета. Пакеты APP с неузнаваемыми именами следует игнорировать. После проверки, если определено, что она широко используется, рекомендуется переопределить каждый пакет APP без регистрации сегмента подтипа и имени в IANA.
Примените определенные функции.
резюме:
RTSP отвечает за установление и контроль сеансов, RTP отвечает за передачу мультимедиа, RTCP сотрудничает с RTP для контроля и статистики трафика, и они находятся в кооперативных отношениях.
Четыре, протокол SDP
SDP обычно включает в себя следующие аспекты:
(1) Название и цель сеанса
(2) Время выживания сеанса
(3) Медиа-информация, включенная в сеанс, включая: тип медиа (видео, аудио и т. Д.), Протокол передачи (RTP / UDP / IP, H.320 и т. Д.), Медиа-формат (видео H.261, видео MPEG и т. Д.) ), Multicast или удаленный (unicast) адрес и порт
(4) Информация, необходимая для получения медиа (адреса, порты, форматы и т. Д.)
(5) Используемая информация о пропускной способности
(6) Надежная контактная информация (Контактная информация)
Описание каждого поля:
1.Версия (обязательно)
2. происхождение (обязательно)
Инициатор сеанса описан:
: это числовая строка. Он должен быть уникальным на протяжении всей сессии. Для обеспечения его уникальности рекомендуется использовать временную метку NTP (сетевой протокол времени).
: версия объявления сеанса, чтобы прокси-сервер объявлений мог определить, какие объявления того же сеанса являются последними. Основным требованием является увеличение значения версии после изменения данных сеанса. Рекомендуется использовать временную метку NTP.
: тип сети, обычно «IN», что означает «интернет»
: тип адреса, обычно IP4
3. Название сеанса (обязательно)
Имя сеанса, есть только один «s =» во всем сеансе.
4. Данные подключения (необязательно)
Он представляет информацию о соединении СМИ. Например: c = IN IP4 224.2.1.1/127
В операторе сеанса должен быть элемент «c =» в описании уровня сеанса или элемент «c =» в каждом описании уровня медиа. В описании уровня сеанса и каждом описании уровня мультимедиа может быть элемент «c =».
: тип сети, обычно «IN», что означает «интернет»
: тип адреса, обычно IP4.
: приложение должно иметь дело как с доменным именем, так и с IP-адресом. Для одноадресной передачи это имя домена или IP-адрес. Рекомендуется использовать имя домена. Многоадресная передача является IP-адресом, и за IP-адресом должен быть TTL (диапазон значений 0-255). Адрес и TTL определяют область распространения многоадресного пакета, подлежащего распространению. пример:
5. Пропускная способность (необязательно)
Информация о пропускной способности, единица измерения килобит в секунду.
: включает в себя два типа CT и AS. CT: ConferenceTotal, общая пропускная способность. AS: Application-SpecificMaximum, максимальное значение одной полосы пропускания мультимедиа.
6. Время (обязательно), время повтора и часовые пояса
Описывает время начала и время окончания сеанса.
7. Объявления для СМИ (обязательно)
Название СМИ и адрес передачи. Описание мультимедиа начинается с «m =» и заканчивается следующим «m =».
: указывает тип медиа. Существуют «аудио», «видео», «приложение» (например, информация на доске), «данные» (данные, не отображаемые пользователю) и «управление» (описывает дополнительные каналы управления).
: порт, где медиапоток отправляется на транспортный уровень. Зависит от типа сети, указанного в строке c = и следующего протокола транспортного уровня: 1024-65535 для UDP, даже для RTP. Когда многоуровневый кодированный поток отправляется на адрес одноадресной рассылки, необходимо указать несколько портов. Способ заключается в следующем:
Для RTP четные порты используются для передачи данных, а нечетные порты используются для передачи пакетов RTCP. пример:
: протокол передачи, связанный с типом адреса строки c =. Два типа: RTP / AVP, что означает транспортный протокол реального времени с использованием профиля аудио / видео, передаваемого по UDP;
m=audio49232 RTP/AVP 0
Пример динамического связывания: 16-разрядное линейное кодирование с частотой дискретизации 16 кГц. Если мы хотим, чтобы динамический RTP / AVP тип 98 представлял этот поток, он записывается следующим образом:
m=video49232 RTP/AVP 98 a=rtpmap:98 L16/16000/2
8. rtpmap (необязательно)
0 или более строк атрибутов сеанса: a = rtpmap: / [/ ]
9. Предлагаемые атрибуты (необязательно)
Для аудио a = частота кадров: 50 1 байт * 8000 Гц * 20 мс = 160 B
Тогда объем аудиоданных для каждого пакета rtp составляет 160 В. Приращение временной метки составляет 160
a = lang: // Язык описания сеанса по умолчанию или язык описания мультимедиа
Замечания:Если анализатор SDP не может распознать определенный тип, все описание теряется.
Если значение атрибута «a =» не понято, атрибут будет потерян.
Описание уровня сеанса является значением по умолчанию описания уровня мультимедиа (то есть описание уровня мультимедиа фактически является описанием уровня сеанса, но используются значения по умолчанию параметров описания уровня сеанса, которые не записаны).
Интеллектуальная рекомендация
Генерация аудио PCM-данных в файлы WAV и MP3 с использованием FFMpeg
Справочник статей 1. Получить кодировщик и создать контекст декодера 2. Создайте аудио поток и выведите контекст обертки 3. Записать необработанные данные в файл Формат упаковки аудио WAV может хранит.
3. Wu Weida Machine Учебное примечание Полные сухие товары (глава 3: Линейный регрессионный обзор)
1053 Путь равного веса (30 очков)
1053 Путь равного веса (30 очков) Given a non-empty tree with root R, and with weight Wi assigned to each tree node Ti. The weight of a path from R to L&n.
1020 Tree Traversals
Главная мысль: Укажите количество узлов двоичного дерева, а также пост-порядок, результат прохождения среднего порядка и результат прохождения уровня. Идеи решения проблем: Подзадача о бинарном древе.
[OpenStack] Neenron Добавить ICMP и SSH правила (веб-интерфейс)
Вам нужно подготовить правила группы безопасности перед конфигурацией. Поскольку группа безопасности по умолчанию не позволяет Ping ICMP-пакеты и SSH удаленного входа в систему. Вам необходимо вручную.