LINUX.ORG.RU

Механизм трансляции медиаданных по RTP + RTSP

 , , ,


0

1

Добрый день!


Не так давно решил разобраться с тонкостями передачи медиаданных по протоколам RTSP + RTP. К этой мысли подтолкнуло повсеместное «гибкое» использование RTSP протокола для получения потоков с любых IP-камер. Так как мой основной род деятельности связан с электроникой и программированием микропроцессоров на «низком» уровне, в этой теме захотелось тоже покопаться в низах, а именно в фундаментальном устройстве этой хорошо отлаженной системы. Собственно, цель данной темы - изложить то, к чему я пришел в результате чтения всевозможной информации (форумы, википедия, частичное изучение RFC) о трансляции медиа средствами RTSP (RFC 2326) с сопутствующими вопросами о корректности понятого мной материала.
В результате думаю написать программку по трансляции mp4 файла (только видео, без аудио) на RTSP-сервер.


Итак:
1.1) Активация порта на прослушивание входящих RTSP команд;
2.1) Пришел запрос с заголовком OPTIONS -> передаем опции, которые поддерживает сервер
2.2) DESCRIBE - ответом отдаём SDP файл, где говорим, что можем передать видео
2.3) В запросе SETUP получаем информацию об RTP и RTCP портах передачи данных Вопрос - эти порты запрашиваются со стороны клиента, а значит есть механизм отслеживания занятых/не занятых???
2.4) PLAY - говорим ОК и начинаем передачу данных через RTP/RTCP.
2.5) Если мы предусматриваем перемотку видео при получении RTSP потока (случай передачи файла серверу), то иногда нам может приходить PLAY с временной меткой Range: npt= / clock= / utc= . . . В этом случае, мы «переносим» метку отдаваемого в RTP видео на запрашиваемое значение. Тут хотелось бы очень услышать советы из вашего личного опыта по данной части, ибо информации по работе с Range крайне мало в сети.
2.6) При получении TEARDOWN - тормозим RTP поток и закрываем соединение с сокетом.
3.1) Так как мы собираемся отправлять mp4 файл, то логичен вопрос в распаковке и подготовке файла к отправке по RTP. Как известно, mp4 контейнер состоит из набора «чанков», размечаемых флагами ftyp, mdat, moov и тд. RTP же естественно имеет свой формат отправки видеоданных, описанный в RFC 3550 и RFC 3016 конкретно для mp4. Отдельный вопрос про механизм перепаковки - я правильно понимаю, что мы очищаем от служебных наборов байт mp4 контейнера передаваемый файл, и оставшийся набор байт порциями передаём в RTP-Payload части пакета? Или механизм перепаковки несколько другой? Буду признателен, если поделитесь информацией, примерами по данному вопросу.
4.1) Также, я ничего не написал про организацию RTCP прокола, передаваемого по нечетному порту, следующему за RTP, т.к. сейчас в процессе его изучения.


Буду благодарен любым комментариям, исправлениям и ответам по теме!


Ответ на: комментарий от Harald

С готовыми реализациями хорошо знаком - gstreamer и vlc отлично организуют RTSP трансляцию - идеальное поле для изучения Wireshark'ом.


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

Art_em
() автор топика
Ответ на: комментарий от Art_em

берите и копайте исходники реализаций, гитхаб засран ими по самое не хочу
реализации такие что даже олигофрен поймет

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.