From: "Michael A. Kangin" <mak@complife.ru> To: ALT Linux sysadmins' discussion <sysadmins@lists.altlinux.org> Subject: Re: [Sysadmins] I: zoneminder is back Date: Thu, 24 Apr 2014 13:16:09 +0300 Message-ID: <5358E469.3080500@complife.ru> (raw) In-Reply-To: <lj3b2b$v1v$1@ger.gmane.org> 21.04.2014 17:47, Anton Farygin пишет: >> Этого нет, хотя есть механизм внешних тревог - при каком то внешнем >> событии (например детектер движения в IP камере. Для разных событий >> можно написать хелперов) создаётся тревога с временем и текстовым >> описанием, кусок видео с настраиваевым количеством секунд до и после >> может быть сохранено с другим качеством, чем остальное видео, и ему >> может быть присвоен другой коэффициент выживания - когда место на диске >> заканчивается, старое видео стирается, но особо-важное может оставаться >> очень надолго > > Я только по тревогам пишу - у меня камер слишком много, что бы писать > всё в качестве 720p, а ресурсов на СХД мало ;) Ну mjpeg да. Я видео перекодирую в весьма компактный x264, с индивидуальными настроечками для каждой камеры. т.е. какой-нибудь серверочек с 16-20 аналоговых камер с разрешением где-нибудь 512*384 (больше по оцифровке не вытягивается) с 2тб спейса архив вполне вмещается на пару месяцев. Сплошной записи. >> Этого сколько угодно, потоки могут многократно дуплицироваться и >> кодироваться с разными форматами/качествами. Правда, в интерфейсе есть >> только full/preview. Надо будет знать непосредственные ЮРЛы видеопотоков. > > А ресурсы при кодировании и отдаче на просмотр как потребляет ? ну, у > меня например больше 30 камер при десятке одновременных сеансов с > разными конфигурациями просмотра. Мне сдаётся, что VLC при отдаче говотого потока вообще ничего не потребляет. Я не заметил по крайней мере. Кодирование потребляет, но всё зависит от :) Скажем, с бевардами я поступаю так - у них почти замечательное h264, но rtsp не годится для длительного просмотра - через несколько дней vlc от него виснет. Поэтому я беру с них видео (1280x720) в два потока - rtsp/h264 режу на файлики и кладу на диск, а mjpeg жму до 640/480 и отдаю как превью. Это пережатие занимает где-то 9-11% от ядра современного ксеона. с аналоговыми камерами сначала всё кодируется в mjpeg (иногда двух потоков - для превью и полное видео для просмотра и сохранения на диск), сбрасывается на диск и перекодируется в h264 требуемого качества. С выдающими только mjpeg перекодируем только preview поток, на диск кидаем готовое видео (впоследствии пережимаемое) С выдающими только очень корявый для сохранения h264 приходится няньчиться больше всего - сначала перекодируем в mjpeg (что при условии начального h264 гораздо хуже по ресурсам), и потом уже его сохраняем на диск и опять перекодируем в h264. перекодирование сохранённого mjpeg'а в финальный h264 происходит с идловым приоритетом, и в этом серверу могут помогать другие компьютеры. Например, что зря мониторинговые компьютеры охранников простаивают. На этом этапе можно пережать видео с поддержкой тревог - разные фрагменты с разным качеством, наложить какой нибудь текст с изображением. Всё что ffmpeg (или как там он по новому называется) позволит. Я обычно пережимаю на veryfast профиле, с фильтрами против гребёнки (для аналоговых камер), шумов и несколько пониженным (8-16) fpsом. Там где много резких движений, с -trellis=1. >> Вот мне эта "масса проблем" оказалась роковой. В большом круглосуточном >> супермаркете детектор движения нафиг не сдался, а вот поддержка >> пяти-шести десятков камер с постоянной записью... хм. > > Да, с постоянной записью у Zoneminder кривулька. > > А камеры в каком качестве поток отдают ? С бевардов я беру 1280x720, h264 vb и mjpeg где-то на 50-60q. C всяких старлайнов получается 720*576. Дешёвые уличные гонят 640*480 15fps. C аналогов - на что ресурсов хватит, до d1. Самое весёлое с платами оцифровки на PCI - они больше 4 камер в нормальном разрешении не прокачивают. Приходится к одному серверу ставить несколько тощеклиентиков только на оцифровку. А сервер принимает с них MJPEGи.
prev parent reply other threads:[~2014-04-24 10:16 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-04-19 6:14 Anton Farygin 2014-04-19 6:27 ` alexei 2014-04-19 12:39 ` Anton Farygin 2014-04-19 21:28 ` Michael A. Kangin 2014-04-20 9:27 ` Anton Farygin 2014-04-21 8:40 ` Michael A. Kangin 2014-04-21 14:47 ` Anton Farygin 2014-04-21 16:17 ` Maks Re 2014-04-21 17:53 ` Anton Farygin 2014-04-24 10:16 ` Michael A. Kangin [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5358E469.3080500@complife.ru \ --to=mak@complife.ru \ --cc=sysadmins@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux sysadmins discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/sysadmins/0 sysadmins/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 sysadmins sysadmins/ http://lore.altlinux.org/sysadmins \ sysadmins@lists.altlinux.org sysadmins@lists.altlinux.ru sysadmins@lists.altlinux.com public-inbox-index sysadmins Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.sysadmins AGPL code for this site: git clone https://public-inbox.org/public-inbox.git