Комментарии 10
Если не нужно непрерывное видео, а достаточно обновляемой раз в несколько секунд картинки, то можно периодически брать картинку с камеры и отсылать на сервер, а на вэб-странице обновлять картинку джаваскриптом.
Более высокая задержка воспроизведения в «прямом эфире».
Я когда-то пробовал делать очень маленький размер mp4-сегмента (около 100мс и меньше - сегменты даже без ключевых кадров, ага) и отсылать их в браузер через вебсокет - получал задержку около 300мс на стабильном соединении
Спасибо, мысль интересная. Но начать воспроизведение не получится без ключевого кадра. Значит, минимально возможное отставание времени всё же будет от нуля до 1 GOP в теории, если не двигать вперёд время воспроизведения элемента video.
Мы ведь говорим об отставании текущего кадра от реального времени, верно? Можете рассказать подробней?
Новые версии для приложения Камеры будут?
Я вижу вы сделали версию 2.0 и больше проект за 3 последних месяца увы не развивается.
Камеры поддерживаются, обновляются и находятся в актуальном состоянии, критичных багов нет. Времени на всё не хватает, но проект открыт, пулл реквесты принимаются;).
Какое именно развитие вы хотели бы видеть?
Вы писали про детекцию движения и API. Думаю это самое востребованное. Без этого функционала камеры мало пригодны для работы т.к. сидеть постоянно смотреть в них тяжело, нужно перебросить работу на саму камеру, пусть определяет движение сама и нам в приложение через API сообщяет это. Я насколько помню для API нужет отдельный TCP порт, кажется 8443 или 8000. И что-то странное что через API для для кодека h.265 нет оповещения. Попробуйте написать в официальную поддержку для помощи с API.
Да, есть такое в трекере задач.
API отключен только для плюсов, с обычными кодеками H.264/265 все работает.
Удаленный доступ к IP камерам. Часть 3. HEVC и web