> Видеокамеры находятся в одной сети, клиенты - в другой


Между этими подсетями есть "неподконтрольные" маршрутизаторы ?
Т.е. такие, на которых нет возможности организовать проксирование мультикаст-пакетов ?

> ABolnykh ©   (12.10.09 11:59) [19]


> Если видеокамер у нас - 16, к каждой может подключаться
> штук 8 (пока ориентировочно) клиентов, для каждого видеопотока
> нужно организовать отдельный буфер, выделять и складывать
> в него кадры, отправлять их каждому подключившемуся клиенту,
>  не забывая отделять кадры друг от друга разделителями и
> вставлять паузы, - какая мощность компьютера должна для
> этого быть? Обычный - не супер-пупер - потянет?

Пропускная способность 100 мбит сети в идеале до 300 кадров/сек при размере кадра 640*480 точек и среднем сжатии (40 кбайт кадр). Для гигабитной примерно в 10 раз больше соответственно. Главное чтобы потянула сеть. Компьютер потянет. Я у себя тестировал значительно больше - работает нормально. Фактически вся нагрузка на компьютер - это поиск разделителей в принимаемом HTTP потоке. Если в потоке заданы Content-Length то поиск мгновенный.
Компьютер лучше многоядерный (2-4 ядра), т.к. сервер инди он многопоточный и чем больше ядер тем ровнее будет загрузка процессора.

> ABolnykh ©   (12.10.09 11:59) [19]

Есть такая бесплатная софтина под Linux: ZoneMinder. Так вот, она умеет все что тебе надо и она с исходниками на си++. http://www.zoneminder.com/

> Сергей М. ©   (12.10.09 13:40) [20]
>
> Между этими подсетями есть "неподконтрольные" маршрутизаторы ?

Камеры находятся в Интернете.
Интернет есть Интернет. Там может быть, что угодно.

> ABolnykh ©   (12.10.09 14:34) [23]


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

> Сергей М. ©   (12.10.09 15:31) [24]


> А при таких скоростях производительность ретранслирующего
> хоста становится уже не критичной.

Да, но на один поток между камерой и ретранслятором может приходиться 100 потоков между ретранслятором и клиентами, если конечно ретранслятор не использует мультикаст.

> Сергей М. ©   (12.10.09 15:31) [24]

> Тогда мультакаст, конечно же, отпадает.

А во вторичную-то сеть можно сделать мультикаст? То есть, принять своим дивайсом из Интернета нужный видеопоток, разложить его на кадры, а потом смультикастить каждый кадр процедурой SendBuffer компонента TIdIpMCastServer на нужный групповой адрес? Во вторичной локальной сети никаких маршрутизаторов быть не должно, по крайней мере, можно заранее оговорить обязательность наличия их отсутствия.
Это было бы намного проще отслеживания подключения каждого клиента, формирования для него персональной задержки etc.

Задача, действительно, начинает очень мало напоминать равнобедренный треугольник. Честно сказать, к покадровому дроблению видеопотока я был изначально морально не готов, думал обойтись использованием готовых компонентов.  :-(

> ABolnykh ©   (12.10.09 16:08) [26]


> во вторичную-то сеть можно сделать мультикаст?


Да, конечно.

> DVM ©   (08.10.09 17:03) [16]
>
> Задача не так проста, как кажется. Просто тупо ретранслировать поток не выйдет, поток нужно принять, выделить кадры, затем собрать аналог потока. который транслировать клиенту.
>
> Работа ретранслятора грубо говоря выглядит следующим образом.
>
> 1) Ретранслятор подключается к камере по HTTP и начинает принимать видеопоток.
> 2) Выделяет очередной кадр (как разделены кадры в потоке см на сайте аксис HTTP API)
> 3) После того как кадр выделен, мы его откладываем в некий буфер, затирая предыдущий.
> 4) Продолжаем принимать входящий поток, обновляя наш буфер.
> 5) Тут к ретранслятору подключается очередной клиент.
> 6) Выдаем клиенту заголовок в соответствии с Axis HTTP API
> 7) Начинаем высылать клиенту кадры, отделяя их друг от друга разделителями. Кадры берем из буфера. Между кадрами делаем паузы чтобы поддерживать нужную частоту кадров, которую например клиент может передать нам в запросе. Кадровый буфер причем должен быть потокобезопасный.
> 8) Аналогично для второго третьего нн-ого клиентов.
> 9) Кроме этого следует наверное отключаться от камеры если клиентов нет.
>
> В двух словах не расскажешь, т.к. каждый шаг здесь отдельная длинная история.

[b]DVM[/b], ОГРОМНОЕ СПАСИБО ЗА ТАКОЙ ДЕТАЛЬНО ПРОРАБОТАННЫЙ "БИЗНЕС-ПЛАН"!

И ещё парочка вопросов.
Какое количество кадров можно считать оптимальным при приёме потока (чтобы, с одной стороны, не было эффекта "дёрганья" от частого переподключения к камере, а с другой стороны - не слишком раздувать буфер потока), и чем (как) формировать задержку между отправкой кадров?

В идеале, конечно, было бы задать количество кадров = 0 (unlimited), тогда бы и все вопросы отпали. Как только получил и выделил очередной кадр - сразу смультикастил его во вторичную сеть, и не надо формировать никаких задержек. Но сразу встаёт вопрос переполнения потока при круглосуточном видеонаблюдении, и потом - куда воткнуть процедуру нахождения "--myboundary" в

Очень интересная тема, особенно в предчувствии того, что мне тоже предстоит делать нечто подобное. Возник вопрос: зачем влезать внутрь потока, разве нельзя просто его ретранслировать всем подключившимся клиентам?

> разве нельзя просто его ретранслировать всем подключившимся
> клиентам?
>


Ретрансляция по TCP может быть неприемлемой

Почему?

Потому что TCP подразумевает гарантию доставки (квитирование) , что делает его ощутимо медленнее протоколов без квитирования, что, в свою очередь, может быть не приемлемым для доставки поточных данных клиентам с оч узким каналом доступа.

> ABolnykh ©   (19.10.09 14:06) [28]


> Какое количество кадров можно считать оптимальным при приёме
> потока

Я считаю оптимальной 7 кадров в секунду. Это же все таки наблюдение за ситуацией а не кинофильм. Есть конечно маньяки которые с пеной у рта доказывают что надо 25, но сами не могут отличить 15 от 25 когда им показываешь.


> а с другой стороны - не слишком раздувать буфер потока

А у меня лично буфер всего на один кадр. Один буфер в один кадр на одну камеру. Камера обновляет буфер, клиенты получают обновления буфера.


> и чем (как) формировать задержку между отправкой кадров?

Формировать то ее можно банальным Sleep() но с расчетом ее мне пришлось повозиться.


> Как только получил и выделил очередной кадр - сразу смультикастил
> его во вторичную сеть, и не надо формировать никаких задержек.
>

Еще раз повторю, не надо копить кадры. Достаточно всегда иметь один кадр последний, его и шлем клиентам.


> и потом - куда воткнуть процедуру нахождения "--myboundary"
> в
> try http.get (url, stream);

С пом TIdHTTP можно получить только отдельный кадр (камеры аксис кстати могут отдавать и покадрово а не потоком). Отдельными кадрами тоже выход, правда несколько более грузит ПК и камеру. Для принятия потока лучше брать TidTCPClient (или как он там называется). Я вообще на чистых сокетах делал без обертки (пример разбора потока есть в коде ZoneMinder в файле remote_camera.c ).

> Fr0sT   (20.10.09 15:10) [29]

Дело в том что скорость на участке камера - ретранслятор может быть выше чем скорость на участке ретранслятор - клиент и куда девать тогда лишние кадры. Их из потока не выкинешь просто так. А если пытаться в таких условиях отдать все что прислала камера то получится отставание изображения которое все более будет нарастать и занимать память (куда кадры то девать).

Кроме этого отдельные клиенты могут захотеть принимать с меньшей частотой кадров изображение или другого размера и т.д. тут вариантов масса поэтому лучше ретранслировать собирая поток самому.

Еще разные модели камер могут транслировать по разному устроенный поток а для клиента лучше чтобы он был единообразным, так лучше если ретранслятор будет адаптирован под разного вида потоки чем клиент.

> [32] Сергей М. ©   (20.10.09 15:42)
Ок, точку зрения понял

> [34] DVM ©   (20.10.09 15:49)
Ага, вот оно что, на ретранслятор уже накладываются дополнительные функции! Тогда действительно, придётся разбирать.

Кстати, раз уж речь зашла о функциях ретранслятора. Ретранслятор должен уметь работать в обе стороны. Т.е. не только передавать видеопоток от камер клиентам, но и передавать команды клиентов камерам (например PTZ команды ил управление выходами DIO и т.д.)

Несколько проясню подробности нашего текущего техзадания.

Пока мы не волшебники, а только учимся, и потому решили сами несколько упростить себе ситуацию. А именно:
- камеры используем ТОЛЬКО Axis 207, потому возможная чехарда с несовпадением возможностей различных камер отпадает сама собой;
- все операторы смотрят картинку в одинаковом разрешении;
- аналогично - никакого волюнтаризма со стороны клиентов в вопросе самостоятельного выбора частоты кадров изображения (что тебе дали - то и смотри; чай, не у себя дома сидишь :-)  );
- никаких дополнительных функций на ретранслятор, в целях упрощения задачи, не возлагаем;
- никакого прямого обращения операторов к видеокамерам не допускается. Если диспетчер (человек) захочет зачем-то напрямую обратиться к видеокамере (посмотреть лог, установить часы, прописать юзера etc.), для этих целей предусматриваем прямой доступ к камерам через TIdMappedPortTCP. Через них же будем посылать камере и все дополнительные команды, не связанные с трансляцией видеопотока.

Клиентскую часть (программу для операторов) тоже пишем самостоятельно, и поскольку тоже не волшебники, все основные приёмно-отображательные функции решили возложить на лицензионно-покупной компонент TVideoGrabber. (Кстати, вопрос ретрансляции потока мы тоже попробовали возложить на него. Как ни странно, но работает (!), правда ОБАЛДЕННО грузит процессор: ретрансляция подключения ОДНОГО клиента (127.0.0.1) к ОДНОЙ видеокамере, подключенной к своей же сетевой карте, занимает примерно 65-70% процессорного времени моего P4 Celeron 2400 MHz. Плюс ко всему - огромная, секунд в 15-20, задержка отображения происходящего.)

DVM, ещё раз: ОГРОМНОЕ ВАМ СПАСИБО ЗА ЦЕННЫЕ СОВЕТЫ И КОНСУЛЬТАЦИИ!!!

И очередная порция идиотских вопросов.
Как я понял, частоту обновления (frames per second) Вы рекомендуете выбирать = 7 - исходя из условия достаточности этого значения для наблюдения за происходящим. Я-то спрашивал, какой размер потока лучше задавать при подключении в команде
http://<servername>/axis-cgi/mjpg/video.cgi?nbrofframes=_____?
А если каждый раз запрашивать по одному кадру (nbrofframes=1), то, опять же, непонятно, зачем искать границу кадра? Камера и так прислала один кадр, , начинающейся с "--myboundary, Content-Type" и заканчивающегося какими-то хитрыми двоичными данными, - копируй его в буфер и мультикасть! И потом: где задавать частоту обновления? В команде
http://<servername>/axis-cgi/mjpg/video.cgi?nbrofframes=1&fps=7   ???

И опять же: если мы запрашиваем у камеры "в лоб" 7 кадров в секунду, получаем каждый раз по 1 кадру и тут же их мультикастим - зачем нам самим формировать Sleep? Сам TVideoGrabber разве не способен правильно (во времени) отобразить полученное?

Кстати, DVM, какой населённый пункт нашей необъятной планеты Вы осчастливили, избрав местом своего проживания и творения? Если ответ на этот вопрос каким-то образом нарушает правила этого форума, можно ответить мне в личном сообщении.

> ABolnykh ©   (21.10.09 11:05) [37]


> http://<servername>/axis-cgi/mjpg/video.cgi?nbrofframes=_____?
>
> А если каждый раз запрашивать по одному кадру (nbrofframes=1),
>  то, опять же, непонятно, зачем искать границу кадра?

Когда я все писал, параметра nbrofframes несуществовало и я им не пользуюсь.

Если брать по одному кадру то проще будет вообще так:

http://<servername>/axis-cgi/jpg/image.cgi
Камера пришлет один единственный JPEG кадр. И никакаих --myboundary !!!

Когда нужен будет еще один, надо обратиться еще раз к камере. Паузу между обращениями можете регулировать сами, тем самым получите желаемый фпс.


> и заканчивающегося какими-то хитрыми двоичными данными,
> - копируй его в буфер и мультикасть!

Это JPEG данные. Начинаются и заканчиваются маркерами FFD8 и FFD9 соответственно.


> И потом: где задавать частоту обновления? В команде
> http://<servername>/axis-cgi/mjpg/video.cgi?nbrofframes=1&fps=7
>   ???

fps и есть частота обновления. Частоту обновления лучше всего задавать в пути.


> И опять же: если мы запрашиваем у камеры "в лоб" 7 кадров
> в секунду, получаем каждый раз по 1 кадру и тут же их мультикастим
> - зачем нам самим формировать Sleep?

Потому что возможности клиентов/сети камеры часто расходятся с желаниями/потребностями. В идеальных условиях локальной сети может и можно так как ты описал, но в условиях Интернет вряд ли.
Начнутся затыки, расхождения, в результате все начнет отставать и т.д.


> DVM, какой населённый пункт нашей необъятной планеты

(с) рядом с моим ником нажми.

> > И потом: где задавать частоту обновления? В команде
> > http://<servername>/axis-cgi/mjpg/video.cgi?nbrofframes=1&fps=7
> >   ???
>
> fps и есть частота обновления. Частоту обновления лучше
> всего задавать в пути.

Только в данном случае (nbrofframes=1) задание fps=7 бессмысленно, т.к. кадр один. Если бы nbrofframes=10, тогда при fps=5 мы получили бы все кадры за 2 секунды, а так бессмсленно. Задание в пути fps имеет смысл только для потоков видео, а не для одиночных кадров. Для одиночных надо фпс задавать на принимающей стороне, т.е. выполнять запросы к камере через нужные промежутки времени.