LINUX.ORG.RU

Как лучше организовать обмен видео данными между процессами?


0

0

Делаю распределённую систему камер видео наблюдения. Каждая камера подключена к компьютеру на котором бежит демон выполняющий захват видео и возможно обработку этого самого видео. Демон предоставляет клиентам "сервисы", такие например как цветное видео, ч/б видео, детектор движения и т.д.. Теперь собственно вопросы:

1) Как лучше организовать обмен видео данными между демоном и клиентами. На локальном компьютере, как мне кажется, наилучшим вариантом является shared memory, хотя хотелось бы прозрачности в плане подключения к локальному и к удалённому компьютеру.

2) Как организовать обмен вспомогательными данными: как рассказать клиенту какие "сервисы" предоставляет данный сервер, какие параметры видео (размер, цветовое пространство и т.д. и т.п.) ?

Пишу на линуксе, перенос на другие платформы не важен, но не помешает писать более менее портабельно.

П.С. скорость очень важна.

anonymous

1. Делай через сокеты TCP/IP и не парься.

2. Продумай вразумительные запросы от клиента к серверу и ответы сервера.

anonymous
()
Ответ на: комментарий от anonymous

TCP/IP можно и нужно для удаленных клиентов, но для локальных это ИМХО перебор, к тому же TCP сервер тоже будет общаться с демоном.

anonymous
()
Ответ на: комментарий от anonymous

Да, архитектура Видеолана похожа на то, что я делаю.

anonymous
()
Ответ на: комментарий от no1sm

По-сути это и был мой вопрос стоит ли использовать сокеты или пайпы или что-либо другое вместо шаред мемори?

anonymous
()
Ответ на: комментарий от anonymous

если тебе нужен ремотный коннект и быстродействие то скорее всего тебе надо UDP/IP сервер общающийся с твоим демоном через шаред мемори.

TCP - это тормоз.

ещё можеш попробовать T/TCP

cvv ★★★★★
()
Ответ на: комментарий от cvv

10x.

про Sun Door никогда не слышал, сейчас поищу что это такое.

anonymous
()
Ответ на: комментарий от cvv

>кстати тебе ещё может помочь sun rpc или sun door. один из них и будет самым быстрым ремотным решением

посмотрел бенчмарки. sun rpc - тормоз. не рекомендую к использованию

sun door - это фишка солярки которая добавляется к линуксу налаживаним патчей. по имеющимся у меня бенчмаркам она наиболе быстрая при ремотных коммуникациях

cvv ★★★★★
()

Довольно давно подобная задача была мной реализована примерно так: в системе есть 4 основных компонента:

а) Client-side на Java Applet( хотя можно и на Flash если с Action Script знаком ) -коннектимся из браузера, берем с сервера через HTTP картинку, запрос на картинку/кадр в твоём случае будет иметь примерно такой вид:

http://my_camera_server.com/cgi-bin/getimage.pl?Session_id=1234567891234567890&a mp;camera_ID=2&image_format=jpg&compression=5 Скрипт возврашает одну картинку. При первом запросе клиент сам себе выбирает псевдослучайный Session_id, он нужен для того чтобы сервер его узнавал и запомнил.

б) Server-side: скрипт на Perl (mod_perl) - обрабатывает запросы клиентов, организует очередь запросов на управление камерами (если управление камерой монопольное- например- зум и паннинг),делает статистику и архив изображений для загона например в формат MJPEG, обрубает личеров которые неактивны уже давно и только трафик с другого конца интернета берут, etc.

в) Server-side: програмка на C вызываемая из б), которая делает низкоуровневые запросы - пишет в порты ввода/вывода, в моём случае управляла шаговыми двигателями камеры; я не заморачивался с написанием драйвера сделал простой Suid Exec.

г) скрипт на баше который при старте Linux подгружет все необходиые дрова , делает инициализацую какую надо.

подробнее по- пункту а)

как ты понял уже, это не стрим а серия картинок, в этом и плюсы и минусы, из плюсов- нам пох какой клиент сколько времени по диалапу кадр тянет- это будет нефатально ни для него ни для нас, изображение не прервётся, для изменения качества/размера картинка есть стандартный либжепеговский параметр компрессии, при локальном просмотре рекомендую в клиенте запрашивать формат PNG с выключенной компрессией как не так напрягаюший мозги компа и соответственно лучше будет плавность. Клиент сделан так чтоб задержек между кадрами искуственно не вносилось. На клиенте сделаны всякие рюшечки типа ползунки и переключатели которые в конечном итоге попадают в параметры HTTP запроса.

по- пункту б) тут тебе простор фантазии , после базового функционала систему можно улучшать до бесконечности. Подсказка куда можно копать: разграничение уровней пользователей на демо, пользователь и начальник, работа с логами запросов, хранение архива , удобная скачка архива по кускам через вебинтерфейс, хранение альбома мошендетекченных случаев и так далее :)

теперь за скорость: если камеры/драйвер не левые, то они не должны сильно вносить задержку.

Делал давно,применял Апач а не чего-то более быстрое, для кодирования Jpeg применял стандартный cjpeg ,на каждом кадре красовался служебный текст типа время etc засовываемый через программку ppmcaption, на сервере помню был П4 1200 скорость была в районе 12 jpeg кадров в секунду - клиент это умел мерять, правда, и камера была одна.

NarcaNoID
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.