«Live Sampling» (без потоковой передачи) с IP-видеокамеры - PullRequest
1 голос
/ 28 октября 2019

Я пишу приложение C ++ для компьютерного зрения с требуемым поведением выборки видео с IP-камеры, не воспроизводит их поток . Для пояснения, потоковая с IP-камеры доставляет сжатый во времени видеопоток, определяемый как начальный и конечный момент времени, часто выражаемый как h264. Напротив, выборка видеокамера запрашивает одно изображение "сейчас". Если запросы изображения происходят достаточно быстро, чтобы h264 или аналогичный был более эффективным, используйте это сжатие, но никогда не доставляйте «старое изображение» клиенту библиотеки раньше, чем текущий запрос изображения во времени.

По сути, библиотека видео должна обеспечивать интерфейс выборки видео, а не интерфейс потоковой передачи видео. Если время между двумя запросами образцов видео составляет 5 минут, возвращаемое видеоизображение является последним произведенным изображением.

Из моего понимания h264, потоков IP-видео и написания приложений с использованием libavcodec в течение нескольких лет наиболее эффективным способом удовлетворения этих требований является двухпоточная архитектура. Работа одного потока состоит в том, чтобы непрерывно потреблять кадры с IP-камеры, в то время как работа второго потока заключается в том, чтобы принимать кадры из первого потока и передавать только последний видеокадр клиенту библиотеки, когда они запрашивают изображение с камеры. Ключом к удовлетворению требований библиотеки является поток видео, работающий отдельно от клиентского приложения библиотеки. Первый поток должен вращать потребляющие кадры, чтобы поддерживать работоспособность связи камеры и поддерживать самый последний кадр для клиента библиотеки.

Если эти требования выполнялись с одним потоком, а время между выборками видео составляло 5 минут (или даже 5 секунд), возможно, видеопоток умер с IP-камеры, поскольку поток не использовался, ноесли бы поток был еще жив, принимающему программному обеспечению пришлось бы «пропускать и выбрасывать» любые кадры, которые, возможно, была заблокирована камерой.

По сути, такое поведение сэмплирования не является обычно ожидаемым поведением IP-камер или потоковой передачи видео в целом. Если не использовать интерфейс захвата изображения, для поддержки этого поведения ПО необходимо использовать кадры с «вращающейся нитью», поэтому последний созданный кадр доступен, когда клиент библиотеки запрашивает его. Не существует «режима» или «живого профиля» для потокового видео, поддерживающего интерфейс сэмплирования видео. Нужно создать это в программном обеспечении с «потоком видеокадров», который работает отдельно от основного приложения. Это правильное мышление, или я где-то ошибаюсь?

1 Ответ

0 голосов
/ 05 ноября 2019

Предполагая, что большинство IP-камер поддерживают RTP. Я бы использовал библиотеку, такую ​​как Live555, чтобы получить поток H.264 вашей камеры. Затем я бы слегка проанализировал поток H.264, чтобы определить типы кадров и границы кадров в потоке. Я бы буферизовал одну группу кадров (GOP) - начиная с I-кадра. Как только вы получите следующий кадр I - сначала очистите буфер. Если вы получаете запрос образца - отправьте буфер H.264 в декодер H.264, а затем отправьте последний кадр, выходящий из декодера, в качестве запроса образца в библиотеку видео. Я бы, вероятно, запустил приемник RTP и производителя буфера в одном потоке, а получатель запроса библиотеки - в другом потоке. Вы должны сделать какую-то блокировку буфера. Вы не можете очистить буфер во время декодирования.

...