К сожалению, я все еще застрял с небольшой реализацией связи RTP / RTCP для правильного доступа к моей IP-камере.
Что я хочу сделать
В камере есть внутренний буфер, который я хочу прочитать. Поэтому я общаюсь с камерой через RTSP и приказываю ей передавать данные в потоковом режиме. Когда камера обойдется со всем буфером, потоковая передача остановится.
Что у меня есть
TCP-соединение, которое обменивается данными через RTSP для DESCRIBE
/ SETUP
/ PLAY
Запрос (RTSP) для получения трансляция началась. Это соединение должно оставаться открытым, пока Камера передает данные.
Порт, через который я получаю данные, отправляемые через RTP (на основе UDP) - меня это не касается, у меня даже нет к нему доступа, я просто хотел упомянуть об этом для полноты картины.
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 )
Остальную часть буфера я просто заполнил нулями. Да, я знаю, что это просто взлом, и вы не должны говорить своим детям, чтобы они программировали подобным образом.
Теперь мой вопрос немного меняется: это нормально с этим хаком? Кажется, это работает, но я все еще немного обеспокоен тем, что моя камера будет использовать эти фиктивные данные и изменить конфигурацию, потому что она вставляет в нее какие-то странные вещи?