На Терралаб'е интересная статья: здесь
Вопрос к обсуждению: какой подход к видеостримингу лучше — 1. содание сервера на самой камере или 2. создание драйвера для камеры на машине, куда будет отсылаться видео?

Здравствуйте, Edge, Вы писали:

E> На Терралаб'е интересная статья: здесь
E> Вопрос к обсуждению: какой подход к видеостримингу лучше — 1. содание сервера на самой камере или 2. создание драйвера для камеры на машине, куда будет отсылаться видео?

Я, как разработчик железа, уверен в верности своего подхода — иметь сервер в камере (1). Мне понятны желания программистов иметь данные на входе в максимально "сыром" виде, чтобы потом делать с ними что душа пожелает. Но специфика камер Elphel — в полной открытости их внутренностей, включая алгоритмы в fpga, которые можно перекомпиллировать, используя софт для разработки, бесплатно загружаемый с сайта производителей fpga — Xilinx (к сожалению, пока бесплатна толька версия для Windows, для Linux, которую я использую, мне подарили — вообще-то она стоит $700).
И я предпочитаю, чтобы физические интерфейсы (как кабель локальной сети, например) совпадали со стандартами более высокого уровня (как видеопотоки).

Здравствуйте, elphel, Вы писали:


E>Я, как разработчик железа, уверен в верности своего подхода — иметь сервер в камере (1).
Мне это тоже очень нравится, но такой сервер может гораздо больше, чем простой стриминг через веб.

E>Мне понятны желания программистов иметь данные на входе в максимально "сыром" виде, чтобы потом делать с ними что душа пожелает.
Так в том-то и дело, что не в сыром, а в самом что ни на есть стандартизированом. DirectShow совершенно четко описывает все видеоданные, проходящие через него. так же как и v4l.
А нужнен такой драйвер на клиентской машине для минимизации задержек. Вот есть в камере возможность захвата с 240 fps. У меня сразу возникает желание использовать камеру в системе управления. Но какая от фпс польза будет, если задержки по веб будут 3 сек? Вообще, твоя камера сейяас хорошо для регистрации/охранных систем подходит, но для прочих применений — увы.

E>И я предпочитаю, чтобы физические интерфейсы (как кабель локальной сети, например) совпадали со стандартами более высокого уровня (как видеопотоки).
имхо, это слишком узкий подход . По одному кабелю можно много видеопотоков передавать. Отсюда следует расширение функциональности — к камере подключаем много клиентов и раздаем им части картинок. Ну а далее все они обрабатывают каждый свой кусочек.

Здравствуйте, Edge, Вы писали:

E>Так в том-то и дело, что не в сыром, а в самом что ни на есть стандартизированом. DirectShow совершенно четко описывает все видеоданные, проходящие через него. так же как и v4l.
А они совпадают?
E>А нужнен такой драйвер на клиентской машине для минимизации задержек. Вот есть в камере возможность захвата с 240 fps. У меня сразу возникает желание использовать камеру в системе управления.
Какой, например?
E> Но какая от фпс польза будет, если задержки по веб будут 3 сек? Вообще, твоя камера сейяас хорошо для регистрации/охранных систем подходит, но для прочих применений — увы.
Когда мы пробовали server push (с 4-м netscape), то задержка была гораздо меньше.
E>...к камере подключаем много клиентов и раздаем им части картинок. Ну а далее все они обрабатывают каждый свой кусочек.
И какого рода "обработка по кусочкам" предполагается? Нельзя ли и ее тоже в fpga засунуть?

Здравствуйте, elphel, Вы писали:

E>Здравствуйте, Edge, Вы писали:

E>>Так в том-то и дело, что не в сыром, а в самом что ни на есть стандартизированом. DirectShow совершенно четко описывает все видеоданные, проходящие через него. так же как и v4l.
E>А они совпадают?
Не знаю, надо смотреть.

E>>А нужнен такой драйвер на клиентской машине для минимизации задержек. Вот есть в камере возможность захвата с 240 fps. У меня сразу возникает желание использовать камеру в системе управления.
E>Какой, например?
Например, автосопровождения. Камера смотрит на участок сцены и следит за ним. Т.к. фпс очень высокий, то между кадрами сюжет меняется незначительно и можно не придумывать сложных алгоритмов. Ну а дальше ставим камеру на управляемую платформу и крутим ее как надо. В общем случае за счет большой частоты можно повысить скорость движения этой платформы.
Еще можно использовать камеру для слежения за роботами-манипуляторами — управление захватом по визуальной информации. Та же фигня — при большей скорости камеры можно шустрее двигать манипулятором.

E>>...к камере подключаем много клиентов и раздаем им части картинок. Ну а далее все они обрабатывают каждый свой кусочек.
E>И какого рода "обработка по кусочкам" предполагается?
Свертка (convolution) с ядрами от 5х5 + работа с гистограммами + преобразование цветов. Это самое простое. А вообще вот здесь есть описание многих методов, используемых при обработке. Также стоит глянуть сюда. И учесть, что все это на практике применяется не по отдельности, а вперемешку.

E>Нельзя ли и ее тоже в fpga засунуть?
Э-э-э... Вот здесь я уже не спец. Я слабо себе представляю, что может fpga.

Здравствуйте, Edge, Вы писали:

E>Свертка (convolution) с ядрами от 5х5 + работа с гистограммами + преобразование цветов. Это самое простое. А вообще вот здесь есть описание многих методов, используемых при обработке. Также стоит глянуть сюда. И учесть, что все это на практике применяется не по отдельности, а вперемешку.
E>>Нельзя ли и ее тоже в fpga засунуть?
E>Э-э-э... Вот здесь я уже не спец. Я слабо себе представляю, что может fpga.
С 5х5 можно, если постараться, даже в ту fpga запихнуть, которая сейчас — дополнительно к тому, что есть. Сейчас для Bayer->YCbCr 4:2:0->JPEG я считываю в fpga из sdram квадраты 18х18 (с перекрытием в 1 пиксель). При текущих ресурсах плитки легко увеличить до 22ж22...
А с апгрейдом Spartan2e(300K gates)->Spartan3(1000K gates) — вообще будет раздолье (на некоторое время по кр. мере)

Здравствуйте, elphel, Вы писали:

E>Здравствуйте, Edge, Вы писали:
E>А с апгрейдом Spartan2e(300K gates)->Spartan3(1000K gates) — вообще будет раздолье (на некоторое время по кр. мере)

а это не твоя статья на мембране.ру лежит? с конкурсом?

Здравствуйте, elphel, Вы писали:

E>Здравствуйте, Edge, Вы писали:

E>> На Терралаб'е интересная статья: здесь
E>> Вопрос к обсуждению: какой подход к видеостримингу лучше — 1. содание сервера на самой камере или 2. создание драйвера для камеры на машине, куда будет отсылаться видео?

E>Я, как разработчик железа, уверен в верности своего подхода — иметь сервер в камере (1). Мне понятны желания программистов иметь данные на входе в максимально "сыром" виде, чтобы потом делать с ними что душа пожелает. Но специфика камер Elphel — в полной открытости их внутренностей, включая алгоритмы в fpga, которые можно перекомпиллировать, используя софт для разработки, бесплатно загружаемый с сайта производителей fpga — Xilinx (к сожалению, пока бесплатна толька версия для Windows, для Linux, которую я использую, мне подарили — вообще-то она стоит $700).
E>И я предпочитаю, чтобы физические интерфейсы (как кабель локальной сети, например) совпадали со стандартами более высокого уровня (как видеопотоки).

1. Как я понял из твоей статьи, у тебя в камере есть аппаратное сжатие и буфер, в который достаточно быстро по кругу записываются сжатые кадры. Тебе нужно со скоростью сжатия (быстрей все равно не получится) эти кадры передавать как видео поток, который может понимать QuickTime. То есть тебе нужен миксер видео потока. У тебя, как я понял, пример миксера есть, но он почему-то работает медленно. Вопрос — почему? Тебе наверное лучше всех известна причина. Попробуй объяснить. Как я понимаю по скорости выдачи данных по сетевому протокулу ограничений нет? По крайней мере в контексте задачи.