[sisyphus] Видимо, наблюдение.
Michael A. Kangin
mak на complife.ru
Ср Апр 6 20:40:21 MSK 2016
On 04/06/2016 06:52 PM, Anton Farygin wrote:
> тестировалось по нагрузке в сравнении с zoneminder ?
zoneminder я вообще не рассматривал, после того как увидел его "архив"
из набора jpeg'ов.
Не знаю, научился ли он писать нормальные видеофайлы?
Ну и мне полюбому его функциональности не хватало.
> Теперь бы вот ещё собраться с духом и поставить потестировать. Но что-то
> мне кажется что перекодировок многовато, нет ?
Перекодировки можно оставлять только необходимые и в предельном случае
вообще отказаться от них.
При работе с аналоговыми камерами: мы кодируем всё "налету" в mjpeg (в
один поток, или два, если нужно меньшее качество для preview) и
сохраняем в таком виде на диск. После завершения записи одного файла по
нему проходится постпроцессор, который с idle-приоритетом перекодирует
этот кусок в h264 для длительного хранения (качество/размер/скорость
кодирования можно крутить в широких пределах).
При работе с цифровыми камерами с одним потоком (это могут быть
IP-камеры, или захват видео с mjpeg на выходе, или "хелперы" - у меня
трудились тощие клиенты на атомах на 4-8 аналоговых камер) мы получаем
от них (как правило) mjpeg, который готов для сохранения на диск для
последующего постпроцессинга, и показывается вживую безовсякого
перекодирования. Если нам не нужен отдельный preview-поток, то можно
обойтись без всякого перекодирования вживую.
Если камера выдаёт 2-3 потока, в т.ч. H264 пригодный для сохранения в
архив, нам вообще не надо ничего перекодировать. Постпроцессор только
переливает видео из потокового TS контейнера в индексированный MP4.
Если камера выдаёт только H264, нам надо из него перекодировать mjpeg
для показа вживую. Если вдруг просмотр вживую не требуется, или
используется просмотр в VargusViewer, который умеет h.264/rtsp
показывать (http://git.etersoft.ru/projects/other/vargus-viewer.git), а
не в браузере, то можно опять-же обойтись без перекодирования.
Иногда, в предельных случаях, приходится перекодировать из mjpeg в
mjpeg, если камера выдаёт крайне странный поток, не воспринимаемый
браузерами.
Постпроцессингу ничего не мешает заниматься нескольким машинам, образуя
кластер. Например, у меня помогали серверам компьютеры наблюдения
охранников, на которых они сидят и камеры смотрят.
>
> Т.е. - сейчас вот реально zoneminder отрабатывает 60 камер 720p, 30 -
> mjpeg, 30 - h264 китайские.
>
> При этом китайский h264 ещё и перекодируется на лету в mjpeg для хранения.
Хранить в mjpeg? не накладно ли?
Операция кодировки в mjpeg дешёвая, другое дело в h.264
У меня на самом большом объекте, где было где-то 63-65 камер, половина
выдавала mjpeg/h.264, половина только mjpeg.
Т.е. для всех 65 делалось онлайн-перекодирование mjpeg->preview_mjpeg, и
где-то для 30 оффлайновый mjpeg->h.264.
Занималось обработкой всего этого пара двухпроцессорных серверов, и им
немного помогали с постпроцессингом рабстанции охраны.
Глубина архива получалась где-то месяц (без детектеров движения).
на мощном компе класса i7 уживалось где-то 16 аналоговых камер, или 20 с
небольшим "однопоточных". Но тут просто подвинчивались параметры
перекодиварования, чтоб комп успевал справляться.
Да, для такой организации характерен LA под 30, и это нормально :)
> Ну и 5 клиентов одновременно забирают потоки в сумме примерно сотню.
Это процессоры не грузит, только сеть. Бондинга из двух гигабит хватало
на всё с большим запасом.
>
> Я так понимаю что в этом случае для воспроизведения клиенту генерится
> один поток h264 ?
в зависимости от того что такое "клиент" и что он там воспроизводит.
для онлайн просмотра браузером единственная альтернатива mjpeg.
и только mjpeg обеспечивает "мгновенную" скорость переключения с камеры
на камеру в просмотре. Когда сечёшь воришку это важно :)
А так можно и h264, если "клиент" его осилит увидеть.
Подробная информация о списке рассылки Sisyphus