Мультимедиа поверх IP. RTSP

Материал из Викиконспекты
Перейти к: навигация, поиск
НЕТ ВОЙНЕ

24 февраля 2022 года российское руководство во главе с Владимиром Путиным развязало агрессивную войну против Украины. В глазах всего мира это военное преступление совершено от лица всей страны, всех россиян.

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

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

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

Антивоенный комитет России

Распространяйте правду о текущих событиях, оберегайте от пропаганды своих друзей и близких. Изменение общественного восприятия войны - ключ к её завершению.
meduza.io, Популярная политика, Новая газета, zona.media, Майкл Наки.

RTSP

Потоковый протокол реального времени (Real Time Streaming Protocol, RTSP), прикладной протокол, предназначенным для использования в системах, работающих с мультимедиа данными, и позволяющий клиенту удалённо управлять потоком данных с сервера, предоставляя возможность выполнения команд, таких как «Старт», «Стоп», а также доступа по времени к файлам, расположенным на сервере.

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

Пример

Пример работы алгоритма показан на рисунке справа. По HTTP мы получаем не ссылку на ролик, а метафайл, который содержит информацию о ролике, в том числе и ссылку (чаще всего он содержит только её). Например: "rtsp://example.com/movie.mp4". Далее мы передаём этот метафайл медиаплееру, который делает запрос медиафайла. RTSP-сообщения посылаются отдельно от мультимедийного потока. Для них используется специальный порт с номером 554. RTSP.png

Формат RTSP запросов

Запрос на сервер посылается в текстовом виде в формате: "метод абсолютный_адрес контент версия_протокола". Вместе с запросом могут быть переданы дополнительные служебные поля (на новых строчках запроса).

Пример запроса: "rtsp://example.com/movie.mp4 RTSP/1.0"

Список команд

  • DESCRIBE - запрос описания контента
  • OPTIONS - запрос поддерживаемых методов
  • PLAY - запрос начала вещания контента
  • PAUSE - запрос временной остановки вещания
  • RECORD - запрос на записывание контента сервером
  • REDIRECT - перенаправление на другой контент
  • SETUP - запрос установки транспортного механизма для медиа-контента
  • ANNOUNCE - обновление данных описания контента
  • GET_PARAMETER - запрос указанных параметров у сервера
  • SET_PARAMETER - установка параметров сервера
  • TEARDOWN - остановка потока и освобождение ресурсов

RTP

Протокол RTP (англ. Real-time Transport Protocol) работает на прикладном уровне и используется при передаче трафика реального времени. Чаще всего данный протакол реализуется над UDP. Протокол TCP так же стандартизирован для передачи RTP, но как правило не используется, так как надежность передачи в TCP формирует временные задержки.

Структура пакета

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

+ Биты 0-1 2 3 4-7 8 9-15 16-31
0 Ver. P X CC M PT Порядковый номер
32 Метка времени
64 SSRC-идентификатор
96, если CC>0 [CSRC-идентификаторы]
96+(CC×32),
если X=1 		[Расширение заголовка - определенное профилем значение] [Расширение заголовка - количество блоков данных по 32 бита (EHL)]
96+(CC×32)+32 [Расширение заголовка - блоки данных]
96+(CC×32)
+X*(32+32×EHL) 		 
Данные
 
если P=1 Набивка (Padding data) L

0-1 — Ver. (2 бита) указывает версию протокола. Текущая версия — 2.
2 — P (один бит) используется в случаях, когда RTP-пакет дополняется пустыми байтами на конце.
3 — X (один бит) используется для указания расширений протокола, задействованных в пакете.
4-7 — CC (4 бита) содержит количество CSRC-идентификаторов, следующих за постоянным заголовком.
8 — M (один бит) используется на уровне приложения и определяется профилем. Если это поле установлено, то данные пакета имеют какое-то особое значение для приложения.
9-15 — PT (7 бит) указывает формат полезной нагрузки и определяет её интерпретацию приложением.
64-95 — SSRC указывает источник синхронизации.
EHL (Extension Header Length) — — количество 32-битных слов в блоке данных расширения заголовка.
L — последний байт в пакете, определяющий длину области набивки в байтах (используется для выравнивания в последнем пакете).

Восстановление потерянных пакетов

FEC

Прямая коррекция ошибок (англ. Forward Error Correction, FEC) — техника кодирования/декодирования, позволяющая исправлять ошибки методом упреждения. Применяется для исправления сбоев и ошибок при передаче данных, путём передачи избыточной служебной информации, на основе которой может быть восстановлена первоначальное содержание посылки. Например через каждые четыре пакета, можно передавать пакет контроля по четности, который содержит xor предыдущих четырёх. Таким образом можно восстановить поток при потере одного из пяти пакетов.

Интерливинг

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

Литература

Источник — «http://neerc.ifmo.ru/wiki/index.php?title=Мультимедиа_поверх_IP._RTSP&oldid=83248»