Re: [sisyphus] Видимо, наблюдение.

["Michael A. Kangin" <mak@complife.ru>]

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, если "клиент" его осилит увидеть.