К сожалению, я все еще застрял с небольшой реализацией связи RTP / RTCP для правильного доступа к моей IP-камере.
Что я хочу сделать
Камера имеет внутренний буфер, который я хочу прочитать.Поэтому я общаюсь с камерой через RTSP и сообщаю ей о потоке данных.Когда камера прошла через весь буфер, потоковая передача остановится.
Что у меня есть до сих пор
ATCP-соединение, которое связывается по протоколу RTSP для запроса DESCRIBE / SETUP / PLAY (RTSP) для запуска потока.Это соединение должно оставаться открытым, пока камера передает данные.
Порт, на который я получаю данные, отправленные через RTP (на основе UDP) - обработка этого не является моей проблемой, у меня даже нет абсолютно никакого доступа к нему, я просто хотелупомяните это для полноты.
Сокет UDP, который получает RTCP Sender Reports / Source Descriptions.Это важно, так как я не знаю, когда поток останавливается (как упомянуто в пункте 2, я не могу просто посмотреть, когда поток прекратился).На этом сокете я читаю, пока не придет RTCP Sender Report Goodbye, что означает, что потоковая передача завершена.Затем я могу закрыть сокет TCP (из RTSP-связи).
Что идет не так
Работаетдля небольших размеров буфера, таких как 2 МБ или 4 МБ.Я получаю некоторые описания источников, а затем Goodbye.Но в моем конкретном тестовом примере я хотел использовать 16 МБ (что по-прежнему меньше половины того, на что способна камера).Я получаю отчеты об отправителях, но в какой-то момент (всегда около 8 МБ +/- 300 КБ) камера просто перестает отправлять.
Примечательно, что я могу без проблем получить доступ к буферу через VLC.Я даже посмотрел на связь (RTSP и RTCP), которая почти полностью совпадает с моей заявкой ... единственное, чего не хватает, я упомяну ниже:
Возможные причины
Это та часть, где мне нужен ваш совет.
Возможность: отсутствие отчетов о приемнике
При потоковой передаче через VLC я заметил, что было некоторое количество RTCP Receiver Reports, отправленное с VLC на камеру (циклически, как Sender Reports)Может ли быть так, что камера ожидает по крайней мере один Receiver Report в определенное время (или после определенного количества отправленных байтов)?На данный момент я не могу думать ни о какой другой причине.
Решение?
Если предположить, чтокамера прекращает потоковую передачу из-за отсутствия Receiver Reports Я хотел бы знать, есть ли способ реализовать их, не передавая много информации.Я уже прочитал некоторые из RFC 3550 , и я полагаю, что за этими сообщениями Отчета все еще есть логика.Теперь мне на самом деле не нужно , поэтому я также не хочу реализовать здесь полный протокол RTCP.Было бы достаточно отправить несколько Receiver Report фиктивных кадров, чтобы камера просто продолжала потоковую передачу?Если да, то как они выглядят?
Если это не связано с отсутствием Receiver Reports и они мне просто не нужны, в чем может быть причина для камерыостановить потоковую передачу?Какие-либо предложения?
Редактировать:
Хорошо, мне только что удалось создать своего рода Dummy Receiver Report, и это, кажется, работает (я просто мог получить 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 )
Остальную часть буфера я просто заполнил нулями,Да, я знаю, что это просто взлом, и вы не должны говорить своим детям, чтобы они программировали так.
Теперь мой вопрос немного меняется: все ли в порядке с этим взломом?Кажется, это работает, но я все еще немного обеспокоен тем, что моя камера будет использовать эти фиктивные данные и изменит конфигурацию, потому что она мешает некоторым странным вещам в ней?