ALT Linux Sisyphus discussions
 help / color / mirror / Atom feed
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.




  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