roboforum.ru

Вот чего нарыл:
http://www.alibaba.com/product-gs/51198 ... video.html?
http://www.grandtec.ru/Grand_IP_Video_Server_4.htm

А кто чего еще знает из этой оперы?

Добавлено спустя 18 минут 53 секунды:
Первая штука меня реально заинтересовала, вот более подробное описание:
http://www.shixin-china.com/en/product_ ... sp?id=2766

Если коротко - можно подцепить к этому точку доступа, пару вебкамер, на ней же есть порт RS-232 для управления всяким добром (т.е. например, модулями Open Robotics )

Или вообще подцепить не точку доступа, а WiFi USB Dongle, обещают что будет беспроводной доступ тогда.

Добавлено спустя 12 минут 44 секунды:
Вышел на еще более детальное описание и похоже сайт реально авторов

http://www.icamview.com/icv32.htm

Короче можно к этому девайсу подцепить USB-Hub, в него впихнуть пару веб-камер, wireless-usb-dongle и получить WiFi-шлюз на 2 вебкамеры и UART (там еще RS-232 порт есть).

Правда осталось понять насколько всё это легко потом будет заполучить с ПК

основной вопрос сколько девайс стоит, потому что то что я вижу ничем не отличается от прекрасно изученной и массово выпускаемой
wifi точки доступа ASUS WL500gp
там внутри ARM , полноценный линукс , ну и пара портов USB
работает с любыми USB девайсами - хочешь флешку пихай хочешь видео , хочешь WimMax модем (у меня кстати так дома)

Добавлено спустя 4 минуты 41 секунду:
ага, цену увидел - asus WL500gp дешевле и доступнее

идеи по использованию одной из точек доступа с линухом на форуме достаточно давно. пока только все заканчивалось вопросом "а зачем это нужно?". Как говорит Snable в соседней теме вполне можно использовать ffmpeg и кодировать программно видео на стороне робота, паковать его и слать по сети (это все умеет тот самый vlc, который на ffmpeg построен и работает и есть и под винду и под линукс), а на виндовой стороне тем же vlc можно как кодировать так и писать так и куча других вариантов есть. вопрос только в цене, имхо. ну и производительность камня в точке, конечно

В общем я о том же , только с уточнением что для кодирования vlc не нужен (несмотря на то что он это умеет это всё же плеер и достаточно тяжеловесное для ARM приложение)

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

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

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

Добавлено спустя 19 минут 29 секунд:

Правда осталось понять насколько всё это легко потом будет заполучить с ПК

там Motion-JPEG судя по описанию, а VLC с ним дружит.

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

В топку "китай просто", будем использоваться "китай ASUS WL500gp"

>хочешь WimMax модем (у меня кстати так дома)
А мы скайлинк модем к нему через USB подключали. Отлично работал Роутер просто чудо(благодаря альтернативным linux прошивкам), его единственный минус низкая скорость. У нас на сети он успевает через ВПН канал(не шифрованный) маршрутизировать только 6мбит. Не понятно успеет ли он обработать поток в 25 кадров на разрешении 640х480(не говоря про два таких потока).

Без сжатия 640х480, 24 бита и 25 кадров - это 184.32Мбита
Нефиговый поток одна надежда - что веб-камеры его гонят уже сжатый
Раз через USB1.1 как-то проходил он (12Мбит)

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

Добавлено спустя 1 минуту 34 секунды:

одна надежда - что веб-камеры его гонят уже сжатый

ну если через 12 Мбит USB его прогоняли, то определенно был сжат. Хотя 12 мбит это все равно много. надо сильнее жать.

2frig: Там процик 266Мгц вроде всего, какая еще предобработка, да и нафиг не надо разработчику СТЗ иметь проблемы с программированием предобработки для своей задачи еще и на ARM'е.

Даже ч/б в 320x240 это уже 15мбит. Веб камеры ес-но умееют сжимать. Там обычно есть даже несколько вариантов кодеков, этим действительно грех не воспользоваться.

Добавлено спустя 5 минут 16 секунд:
Правда нужно понимать, чем сильнее сжатие, тем больше информации мы несомненно теряем. Но я согласен, без сжатия это вообще не целесообразно. Поэтому лично я буду придерживаться стратегии обработки видео прямо на борту нетбука. И буду надеятся, что Intel сдержит своё обещание по поводу их стратегии "тик-так" в отношении Atom'a и каждые два года, будет увеличивать их мощность(число транзисторов) в два раза. Тогда лет через 10 у меня всё будет замечательно.