From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00, DNS_FROM_AHBL_RHSBL, FSL_HELO_BARE_IP_2, RCVD_IN_DNSWL_LOW, RCVD_NUMERIC_HELO, RP_MATCHES_RCVD, SPF_HELO_PASS,SPF_PASS,T_HEADER_FROM_DIFFERENT_DOMAINS autolearn=no autolearn_force=no version=3.4.0 X-Injected-Via-Gmane: http://gmane.org/ To: sisyphus@lists.altlinux.org From: Anton Farygin Date: Thu, 7 Apr 2016 10:07:22 +0300 Message-ID: References: <56FEB06A.3090204@gmail.com> <57040EC7.50300@complife.ru> <570532E0.50305@complife.ru> <57054A05.4060001@complife.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.112.110.22 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 In-Reply-To: <57054A05.4060001@complife.ru> Subject: Re: [sisyphus] =?utf-8?b?0JLQuNC00LjQvNC+LCDQvdCw0LHQu9GO0LTQtdC90Lg=?= =?utf-8?b?0LUu?= X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Sisyphus discussions List-Id: ALT Linux Sisyphus discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 07:07:37 -0000 Archived-At: List-Archive: List-Post: 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.