From: Anton Farygin <rider@altlinux.com> To: sisyphus@lists.altlinux.org Subject: Re: [sisyphus] Видимо, наблюдение. Date: Thu, 7 Apr 2016 10:07:22 +0300 Message-ID: <ne50va$5rl$1@ger.gmane.org> (raw) In-Reply-To: <57054A05.4060001@complife.ru> 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.
next prev parent reply other threads:[~2016-04-07 7:07 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-01 17:31 Вадим Илларионов 2016-04-01 18:59 ` ruslandh 2016-04-02 5:44 ` В.А. Илларионов 2016-04-01 19:29 ` Michael Shigorin 2016-04-03 13:01 ` Anton Farygin 2016-04-04 7:05 ` Stas 2016-04-04 11:21 ` Anton Farygin 2016-04-05 19:15 ` Michael A. Kangin 2016-04-06 6:42 ` Anton Farygin 2016-04-06 16:01 ` Michael A. Kangin 2016-04-06 16:52 ` Anton Farygin 2016-04-06 17:40 ` Michael A. Kangin 2016-04-07 7:07 ` Anton Farygin [this message] 2016-04-07 14:48 ` Michael A. Kangin 2016-04-07 15:32 ` Anton Farygin 2016-04-06 10:27 ` В.А. Илларионов 2016-04-06 16:04 ` Michael A. Kangin 2016-04-06 16:53 ` Anton Farygin 2016-04-08 14:55 ` Вадим Илларионов 2016-04-08 14:54 ` Вадим Илларионов 2016-04-08 19:59 ` Michael A. Kangin 2016-04-09 0:38 ` Вадим Илларионов 2016-04-09 12:10 ` Michael A. Kangin 2016-04-09 17:12 ` Michael Shigorin 2016-04-10 0:00 ` Вадим Илларионов 2016-04-10 17:05 ` Michael Shigorin 2016-04-11 0:21 ` Вадим Илларионов
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='ne50va$5rl$1@ger.gmane.org' \ --to=rider@altlinux.com \ --cc=sisyphus@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 Sisyphus discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/sisyphus/0 sisyphus/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 sisyphus sisyphus/ http://lore.altlinux.org/sisyphus \ sisyphus@altlinux.ru sisyphus@altlinux.org sisyphus@lists.altlinux.org sisyphus@lists.altlinux.ru sisyphus@lists.altlinux.com sisyphus@linuxteam.iplabs.ru sisyphus@list.linux-os.ru public-inbox-index sisyphus Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.sisyphus AGPL code for this site: git clone https://public-inbox.org/public-inbox.git