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

[Anton Farygin]

On 06.04.2016 20:40, Michael A. Kangin wrote:
> On 04/06/2016 06:52 PM, Anton Farygin wrote:
>
>  > тестировалось по нагрузке в сравнении с zoneminder ?
>
> zoneminder я вообще не рассматривал, после того как увидел его "архив"
> из набора jpeg'ов.
> Не знаю, научился ли он писать нормальные видеофайлы?
> Ну и мне полюбому его функциональности не хватало.

В апстриме есть архивация по расписанию/заполнению, которая как раз 
подразумевает перекодировку. А сбор h264 возможен,но только в отдельной 
ветке.

>
>> Теперь бы вот ещё собраться с духом и поставить потестировать. Но что-то
>> мне кажется что перекодировок многовато, нет ?
>
> Перекодировки можно оставлять только необходимые и в предельном случае
> вообще отказаться от них.
>
> При работе с аналоговыми камерами: мы кодируем всё "налету" в mjpeg (в
> один поток, или два, если нужно меньшее качество для preview) и
> сохраняем в таком виде на диск. После завершения записи одного файла по
> нему проходится постпроцессор, который с idle-приоритетом перекодирует
> этот кусок в h264 для длительного хранения (качество/размер/скорость
> кодирования можно крутить в широких пределах).
>
> При работе с цифровыми камерами с одним потоком (это могут быть
> IP-камеры, или захват видео с mjpeg на выходе, или "хелперы" - у меня
> трудились тощие клиенты на атомах на 4-8 аналоговых камер) мы получаем
> от них (как правило) mjpeg, который готов для сохранения на диск для
> последующего постпроцессинга, и показывается вживую безовсякого
> перекодирования. Если нам не нужен отдельный preview-поток, то можно
> обойтись без всякого перекодирования вживую.

А как клиент справляется с живым отображением 18 потоков 720p в h264 ?

Или превьюшки забираем в меньшем разрешении ? Но всё равно интересно, 
даже с меньшим разрешением.

>
> Если камера выдаёт 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, и это нормально :)

Да, у меня сейчас LA под 50 временами и никаких проблем не вижу.

>
>
>> Ну и 5 клиентов одновременно забирают потоки в сумме примерно сотню.
>
> Это процессоры не грузит, только сеть. Бондинга из двух гигабит хватало
> на всё с большим запасом.

В zoneminder это грузет процессор и IO. Процессор не очень много, но 
дополнительные сто потоков тоже создают нагрузку.

>
>>
>> Я так понимаю что в этом случае для воспроизведения клиенту генерится
>> один поток h264 ?
>
> в зависимости от того что такое "клиент" и что он там воспроизводит.
> для онлайн просмотра браузером единственная альтернатива mjpeg.
> и только mjpeg обеспечивает "мгновенную" скорость переключения с камеры
> на камеру в просмотре. Когда сечёшь воришку это важно :)
> А так можно и h264, если "клиент" его осилит увидеть.

Т.е. - для отображения клиенту в любом случае приходится гнать mjpeg ?

Тогда не вижу особого смысла забирать поток в h264, если его нужно в 
любом случае для воспроизведения перекодировать в mjpeg - а это в моём 
случае сотня процессов.
Но вообще конечно надо сесть подсчитать что дешевле - из h264 mjpeg или 
наоборот.

Особенно с учётом того, что бюджетные камеры не умеют отдавать mjpeg.