Здравствуйте, уважаемые Мастера!
Кто-нибудь может подсказать направление решения следующей задачи?

Имеется сетевая видеокамера со встроенным web-сервером.
Когда к видеокамере подключается клиент, она начинает транслировать на его IP свой видеопоток.
Когда к камере подключается второй клиент, она начинает транслировать свой видеопоток (тот же самый) и на его IP тоже.
Когда к камере подключается десятый клиент, суммарное количество идентичных видеопотоков становится равно десяти.
А если таких камер в сети - десятка полтора... Затык сети очевиден.

Стоит задача: разработать некоторый дивайс (компьютер с программой с неким компонентом), в котором между видеокамерой и этим компонентом существовал бы один видеопоток, а уже этот компонент рассылал бы этот видеопоток всем подключившимся клиентам.
Видеокамеры находятся в одной сети, клиенты - в другой.

Прочитав "Глубины Indy", я, по простоте душевной, в качестве искомого компонента выбрал TIdMappedPort, посчитав, что на каждое подключение он, по умолчанию, самостоятельно создаст отдельный поток (Thread), что и требуется.

Каково же было моё удивление, когда, написав пробный кусок программы и подключив через TIdMappedPort к камере трёх клиентов, а потом запросив лог видеокамеры, я обнаружил, что к камере подключены ТРИ клиента, а не один, как я ожидал. То есть, TIdMappedPort просто смаппировал обращённые к нему запросы к адресу камеры, а потоки же (Threads) если и создал для каждого подключения, то потоки обработки кода, а не видеопотоки. То есть, выбранный мною подход оказался неверным.

Полазав как следует по Интернету в поисках ответа на вопрос, как же всё-таки люди решают подобную проблему, ничего не нашёл. :-( А судя по тому, что "видеонаблюдательные" программы сейчас плодятся, как грибы, проблема должна иметь простое или несложное решение.

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

Пишу на Delphi 7, Indy 9.

По видимому вы плохо прочитали "Глубины Indy".
А вообще для таких случаев обычно используют Mutlicast пакеты. В инди соответсвующие компоненты имеются.
Дерзайте

За слово "Multicast" спасибо. И хотя в "Глубинах Indy" оно упоминается всего пару раз, благодаря Интернету, я ознакомился с этой стороной жизни.

А ещё что-нибудь наводящее, "поближе к телу"?

TIdIPMCastClient
TIdIPMCastServer
больше даже не знаю чего вам добавить.

Вот это и нужно было добавить. :-)
И хотя я сам уже почти вышел на эти компоненты, перелопатив кучу форумов, за подсказку СПАСИБО.

Нелёгкое это дело - ходить в гости...

> ABolnykh ©   (06.10.09 15:25)  

У меня есть программа которая тебе требуется, но она платная.

Из компонентов интди тебе скорее понадобятся TIdTCPClient (или TIdHTTPClient) и TidHTTPServer.

> У меня есть программа которая тебе требуется, но она платная.

Спасибо за предложение, но мне дано задание написать программу, а не купить готовую. :-) :-) :-)
К тому же, вряд ли Вам известны все подробности техзадания, так что, вполне вероятно, что это окажется и не совсем то, что мне требуется.

В дальнейшем, на подобные предложения реагировать не буду, уж не обессудьте.

> ABolnykh ©   (08.10.09 09:06) [6]


> К тому же, вряд ли Вам известны все подробности техзадания

Пока из того, что ты написал, все 1 в 1. Я просто специализируюсь на IP камерах и сетевом видео, поэтому могу предположить, что тебе может понадобится.


> В дальнейшем, на подобные предложения реагировать не буду,
>  уж не обессудьте.

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

> ABolnykh ©   (08.10.09 09:06) [6]

Кстати, что за камеры используешь?

Использую Axis 207.

Сразу оговариваюсь, что платить за советы могу только благодарностью, которую, как известно, в карман не положишь. Зато благодарность может иметь размерность Tiny, Small, Large, Huge - в зависимости от ценности совета.
(Шучу, конечно. Это так, для разрядки.)

Исходные тексты мне тоже не нужны, нужна ИДЕЯ, которая, хоть я и сижу уже второй день в прострации, самостоятельно приходить в голову почему-то никак не хочет. Если и понадобится исходник, то 5-10 строк, реализующих наиболее тонкий момент.

Поставленная передо мной задача проста, как равнобедренный треугольник.
В Интернете находятся несколько видеокамер. В локальной сети сидят несколько (N) наблюдателей-операторов и диспетчер, задающий, какому оператору что следует смотреть.
Моя задача - написать буферное устройство, соединяющее эти две сети, плюс выполняющее некоторые сетевые команды диспетчера.

Задачу уже можно было бы считать выполненной (всё работает!!!) и идти брать с полки пирожок, но тут неожиданно выяснилось, что... (см. первое сообщение этого топика.) И это явилось ударом под дых.
Теперь непонятно: если делать Multicast-рассылку в локальной сети с помощью TIdIpMCastServer, то как смаппировать две сети? Если две сети уже смаппированы, то как сделать multicast-рассылку? То есть, как соединить MappedPort с MCast-сервером?

В нашей организации это первая тема, связанная с сетевым программированием, так что спросить совета совершенно не у кого. Приходится изобретать очередной велосипед. Я же в сетевом программировании если уже не абсолютный ноль, но пока ещё не далеко от него ушедший, и потому задавать идиотские вопросы считаю своим прямым долгом и неотъемлемым правом. :)))

> Теперь непонятно: если делать Multicast-рассылку в локальной
> сети с помощью TIdIpMCastServer, то как смаппировать две
> сети? Если две сети уже смаппированы, то как сделать multicast-
> рассылку? То есть, как соединить MappedPort с MCast-сервером?

что то перепуталось все... откуда то мультикаст вылез. я так понял, к камерам по TCP нужно соединяться?

> что то перепуталось все... откуда то мультикаст вылез. я
> так понял, к камерам по TCP нужно соединяться?

Multicast вылез из сообщения [1].
К камерам подсоединяюсь по TCP. Камеры и клиенты - в разных сетях.
Проблема в том, что сколько подсоединений, столько и копий одного видеопотока в разные IP-адреса клиентов. А хотелось бы иметь ОДИН видеопоток и чтобы его принимали все, кому он нужен (т.е. кому положено его принимать, не бродкаст).
А как это сделать - самому мне не додуматься, Brain.sys требует апгрейда до новой версии.  :-(

Сейчас спрошу максимально тупо и конкретно. Если камера в своём логе сообщает, что к ней подключены 3 клиента - это что значит: что она посылает 3 видеопотока в подключенные адреса или 3 клиента принимают один транслируемый видеопоток? Конкретно осциллом в кабель я не заглядывал, но сдаётся мне почему-то, что видеопотоков она выдаёт три, оттого и испугался. Хотя, допускаю, что я и не прав.
?????????????????????

> [11] ABolnykh ©   (08.10.09 15:59)


> Проблема в том, что сколько подсоединений, столько и копий
> одного видеопотока в разные IP-адреса клиентов. А хотелось
> бы иметь ОДИН видеопоток и чтобы его принимали все, кому
> он нужен (т.е. кому положено его принимать, не бродкаст)
> .

т.е. имеется
камера <==> диспетчер (самописный) <==> клиент
?

так вот
тут ( диспетчер <==> клиент) количество соединений тоже критично?

> так вот  
тут ( диспетчер <==> клиент) количество соединений тоже критично?

Тут некритично.
Хотелось бы иметь один поток между камерой и самописным диспетчером.

> [13] ABolnykh ©   (08.10.09 16:23)


> Тут некритично.

но в этом и состоит основная задача - делать пулл TCP потоков, либо использовать тот же мультикаст для рассылки картики клиентам.

> Хотелось бы иметь один поток между камерой и самописным
> диспетчером.

с этим, как раз, никаких проблем нет.

> но в этом и состоит основная задача - делать пулл TCP потоков,
либо использовать тот же мультикаст для рассылки картики клиентам.

Я понимаю, что дважды два - четыре, а трижды три - девять.
Но вопрос-то был задан

> Теперь непонятно: если делать Multicast-рассылку в локальной сети с помощью TIdIpMCastServer, то как смаппировать две сети? Если две сети уже смаппированы, то как сделать multicast-рассылку? То есть, как соединить MappedPort с MCast-сервером?

и этот вопрос остался...
Теперь уже до завтра.

> ABolnykh ©   (08.10.09 14:05) [9]


> Сразу оговариваюсь, что платить за советы могу только благодарностью,
>  которую, как известно, в карман не положишь.

:)


> Использую Axis 207.

Хорошие камеры, и главное документированные.


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

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

Данные камеры позволяют запбирать видеопоток двумя основными способами:
1) HTTP
2) RTSP

Советую взять HTTP, это МНОГОООО проще. RTSP клиент и тем более сервер в разы сложнее.

Работа ретранслятора грубо говоря выглядит следующим образом.

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

Это наброски так сказать, так как сделано у меня.
В двух словах не расскажешь, т.к. каждый шаг здесь отдельная длинная история.

> ABolnykh ©   (08.10.09 16:59) [15]

Мультикаст использовать не рекомендую, т.к. во-первых это будет реально работоспособно только в локальной сети, да и то при поддержке свитча, во-вторых в данных камерах мультикаст основан на RTSP и намного сложнее в реализации.

Кроме написания ретранслятора, понадобится еще какое то клиентское ПО, которое будет непосредственно обращаться к ретранслятору. Это может быть как отдельное приложение так и JavaScript / Java-апплет / ActiveX Control / Flash Player в веб интерфейсе самого ретранслятора.

> как смаппировать две сети?


см. IGMP-proxy

> DVM ©   (08.10.09 17:03) [16]
>
> Работа ретранслятора грубо говоря выглядит следующим образом.
> ..........................
> Это наброски так сказать, так как сделано у меня.
> В двух словах не расскажешь, т.к. каждый шаг здесь отдельная длинная история.

"Ахренеть, дайте две!!!"

Вам бы книжки писать - "Видеопрограммирование для чайников". Глядишь, через неделю и чайников бы не осталось. :-)

Если, как я уже писал, до сих пор я просто пребывал в прострации, то после такого "хэлпа" у меня вообще опустилось всё, что только было к этому способно.

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