Проблема связи RTCP / RTP

К сожалению, я все еще застрял с небольшой реализацией связи RTP / RTCP для правильного доступа к моей IP-камере.

Что я хочу сделать

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

Что у меня есть

  1. TCP-соединение, которое обменивается данными через RTSP для DESCRIBE / SETUP / PLAY Запрос (RTSP) для получения трансляция началась. Это соединение должно оставаться открытым, пока Камера передает данные.

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

  3. UDP-сокет, который получает RTCP отчеты отправителя / описания источников . Это важно, поскольку я не знаю, когда поток останавливается (как упоминалось в пункте 2, я не могу просто посмотреть, когда поток остановился). Я читал об этом сокете до тех пор, пока не пришло сообщение RTCP Sender Report Goodbye , что означает, что потоковая передача завершена.Затем я могу закрыть TCP Socket (из RTSP коммуникация).

Что происходит не так

Он работает при небольших размерах буфера, например, 2 МБ или 4 МБ. Я получаю описания источников, а затем До свидания . Но в моем конкретном тестовом случае я хотел использовать 16 МБ (что все еще меньше половины того, на что способна камера). Я получаю отчеты об отправителях, но в какой-то момент (всегда около 8 МБ +/- 300 КБ) камера просто перестает отправлять.

Примечателен тот факт, что я могу получить доступ к буферу через VLC без проблем. Я даже посмотрел на связь (RTSP и RTCP), которая почти полностью такая же, как и в моем приложении ... единственное, чего не хватает, я упомяну ниже:

Возможные причины

Это та часть, где мне нужно ваш совет.

Возможность: Отсутствие отчетов о получателе

При потоковой передаче через VLC я заметил, что были некоторые RTCP отчеты получателя , отправленные из VLC на камеру (циклически, как отчеты отправителя ) . Так может ли быть, что камера ожидает хотя бы один отчет о приемнике в определенное время (или после определенного количества отправленных байтов)? На данный момент я не могу придумать другой причины.

Решение?

  • Если мы предположим, что камера прекращает потоковую передачу из-за отсутствия отчетов приемника , я хотел бы знать, есть ли способ реализовать их без передачи большого количества информации. Я уже читал некоторые из RFC 3550 и полагаю, что за сообщениями Report все еще скрывается некоторая логика.Сейчас мне на самом деле не нужен , и поэтому я также не хочу, чтобы реализовывал здесь полный протокол RTCP. Достаточно ли отправить несколько Отчет о приемнике фиктивных кадров, чтобы камера просто продолжала передавать поток? Если да, то как они выглядят?

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

Редактировать:

Хорошо, мне только что удалось создать какой-то фиктивный Отчет о приемнике , и он, кажется, работает (я просто мог получить 12 МБ, а затем получил желаемое «До свидания»)

Я только что заполнил буфер размером 28 байт и просто использовал некоторые значения в полях заголовка, что означает:

buffer[0] = 0x80;   // Version 2 , Padding = false, Reception Count = 0
buffer[1] = 0xC9;   // Packet Type 201 Receiver Report
buffer[2] = 0x00;   // Higher byte for total length
buffer[3] = 0x06;   // Lower byte for total length ( in 32 Bit words -> 28 Byte )

Остальную часть буфера я просто заполнил нулями. Да, я знаю, что это просто взлом, и вы не должны говорить своим детям, чтобы они программировали подобным образом.

Теперь мой вопрос немного меняется: это нормально с этим хаком? Кажется, это работает, но я все еще немного обеспокоен тем, что моя камера будет использовать эти фиктивные данные и изменить конфигурацию, потому что она вставляет в нее какие-то странные вещи?

9
задан Toby 23 February 2012 в 17:38
поделиться