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

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

07.04.2016 09:07, Anton Farygin пишет:

> А как клиент справляется с живым отображением 18 потоков 720p в h264 ?
> Или превьюшки забираем в меньшем разрешении ? Но всё равно интересно,
> даже с меньшим разрешением.

Да, превьюшки как раз для этого и делались и прекрасно идут где-нибудь
320*240, больше от них и не надо.
Тяжелее всего было с браузерами. Файрфокс вообще начатый mjpeg стримить 
не прекращает, пока полностью со страницы не уйдёшь, у хром*ов гвоздями 
прибито ограничение где-то 8 документов с сервера...
vargus-viewer'у, как я помню, практически пофиг, он libvlc юзает, 
нагрузки приемлемые получаются. Тем более, mjpeg сыграть много ресурсов 
не надо.

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


>> Глубина архива получалась где-то месяц (без детектеров движения).
>
> На каком дисковом объёме ?

Где-то около 7тб суммарного объёма. Там 2 сервера, на каждом был 10 рейд 
из 4 дисков по 2 тб.
Могло бы быть и больше, если бы перекодировать всё видео, с ключевыми 
кадрами не каждые 2 секунды как у меня с камер приходило, а каждые 10-15 
секунд. Это значительно снижает объём видео. Ну и архивное разрешение 
можно было бы покрутить.


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

Ну не знаю, я htop'ом нагрузку от отдачи готовых видеопотоков вообще не 
замечал. Может они вносят лепту в LA тот же самый, может длинки с 
реалтеками недовольны будут.. В общем я не страдал.


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

mjpeg просто удобней всего.
А если для просмотра будет использоваться только vargus-viewer то можно 
гнать и h.264
А можно и не гнать, а направить клиента забирать этот поток прям с 
камеры (как и mjpeg) (если у клиента есть рутинг до камеры и она не 
загнётся 2-3 клиента одним потоком обслужить, некоторые китайсы 
ниасиливают).

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

Ну, если в архив готовеньким класть

> Но вообще конечно надо сесть подсчитать что дешевле - из h264 mjpeg или
> наоборот.

Однозначно mjpeg из h.264. Там примерно по половине времени уходит на 
раскодирование h.264 и кодирование mjpeg. Одно только может быть 
исключение - очень мерзкий h.264 или rtsp по которому он отдаётся.
Кроваво-Энтерпрайзный софт полон внутри костылей для борьбы с кривыми 
камерами. А у меня vlc юзается, он от такого страдает.

Ну а кодирование в h.264 крайне затратная операция. Для онлайна вообще 
нереальная, если речь идёт более чем о 2-4 потоках. И трудный поиск 
компромисса качество-размер-скорость.

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

это да...
Я щупал где-то 15 разных видов камер
Самые лучшие оказались Беварды BD-серии.