virt2real.ru

Да я понимаю, что повторяюсь. Просто наконец-то руки дошли до виртурилки (до этого занимался разработкой на других платах).
Нет, ни в коем случае я не пиарю OpenMAX, более того сейчас я пробую GStreamer. Я просто пытаюсь разобраться в этом вопросе, чтобы потом не прыгать на граблях. Дайте четкий ответ и все будет понятно.
На данный момент пробую кодить с использованием GStreamer, но прежде всего для меня важна кросс-платформенность как в плане ОС так и языковая. Скажу более того, я начал адаптировать модули GStreamer под Lazarus (бесплатный кросс-платформенный Delphi). Так как с OpenMAX возникли проблемы, я просто не нашел где скачать необходимые библиотеки для тестирования, а сидеть кропотливо ковырять модули и искать их связи с ."so" желания 0.. не зная работает это или нет.
В плане GStreamer пока проблем с переносом нет, практически закончил и на днях надеюсь протестировать.

Поэтому не поймите меня не правильно, вопрос об OpenMAX интересует меня как разработчика. Я так же поясню почему сейчас мой интерес к OpenMAX пропадает и растет к GStreamer. Дело в том что, как я понимаю OpenMAX адаптирован не подо все платформы. А зацикливаться только на Linux, я считаю просто поставить большой крест на аудитории которая мало знакома с Linux и программированием, но при этом хочет начать. Я не нашел OpenMAX под Windows например. Это я к тому, что школьник-студент-начинающий_экспериментатор-преподаватель хотели бы например протестировать программу под виндоус и потом просто выбрав опции запустить ее под Virt2Reаl.
Не просто так у малины поддержка многих языков, и более того тот же Lazarus там предустановлен.

Я не заставляю и не прошу вас переносить или адаптировать модули GStreamer, это я уже практически сделал (пусть и частично, лишь то что необходимо для видео и звука). Но я хочу понять, почему выбор пал на GStreamer, а не OpenMAX (может то что я переношу окажется не нужным). Возможно я в чем то не прав, и тогда вы меня поправьте. Наоборот, я пытаюсь помочь, ведь доступность простых языков которые изучают в школе сделает Virt2Reаl привлекательной и в образовательных целях.

Поэтому мой вопрос простой.. для программирования под Virt2Reаl, что на ваш взгляд лучше OpenMAX или GStreamer и почему? хотя бы почему мы выбрали GStreamer, а не OpenMAX? помогите с этим разобраться, а то выходит что вы молчите и я снова сталкиваюсь с этим вопросом.
Так же замечу, что лично для меня разницы нет на каком языке программировать: ява, php, си... хоть clipper... мне приходилось разрабатывать на всех, поэтому опыт разработки у меня большой. Поэтому по возможности хочется помочь и другим, облегчить процесс программирование под виртурилку (в конце концов вы у нас в россии одни... кто подходит для робо-проектов).

На самом деле все просто. Gstreamer гораздо более распространен и он существенно старше OpenMAX. Уже в 2006 году активно использовался, а родился в 1999 году - см. вики. Под него много примеров и работающих вещей. Поэтому мы сделали ставку на то, что уже известно и работает, а не стали закладываться на относительно новое решение в виде OpenMax.

Спасибо за ответ, теперь выбор стал понятен. Буду тогда доделывать GStreamer. Просто до этого ваш выбор был не очевиден и поэтому причины были не ясны.

Да я уже понял, что цепочка. Заменить то можно... другое дело в чем. Сейчас пока переношу GStreаmer, проблем особых не испытываю. С OpenMАX, только одна иницализация это геморой.
Под переносом я имею компоненты-фреймверки. То есть по принципу.. настроил визуально (или даже по умолчанию использувал настройки), скомпилировал и используй. При чем не важно.. скопилировал в виндоус и посмотрел, на маке или надроид, линукс. Чтобы для тех кто не хочет думать о тех. особеностях, вдаваться в подроности (это ни кому и не нужно), а хочет например открыть пример, написать свои обработчики на разные события и использовать (человек коптер делает.. ему до фени, что такое линукс, версии библиотек, конфигурация и прочие). Ведь например одна из проблем - это различие в АPI у GStreаmer разных версий (конечного пользователя внутреность не должна волновать), а так же некоторые другие детали (например параметры вывода зависят от платформы). все это ни как не должно касаться пользователя веритурилки.

Я наверное не правильно выразился на счет языков. Я имел ввиду набор готовых компонентов/фрейворков для работы с виртурилкой. Пока для меня приоритетным является Gstreаmer, так как на виртурилке собираюсь протестировать аппратную поддержку кодирования. А там можно будет сделать обертку и под GPS и другие модули.
Насчет питона, NodeJS и других сркиптовых.. то на них можно чтото протестировать.. но увы что-то серъезное не сделать. Си отлично, но начинающим или не имеющим опыта это темный лес и может легко отбить энтузиазм что-то сделать.
Скрипотовые я воспринимаю только для не высоконагрузочных решений, где время отклика не решающее. Из плюсов - простота и кросс-платформенность. Когда речь идет о много-потоковых приложениях, про все скриптовые языки можно смело забыть. А если мы говорим о переферии, значит потоков на обработку будет несколько. Хотя конечно все зависит от задачи. В любом случае, надеюсь, что в ближайшее 1-2 неделю закончу и выложу.

Я даже не спорю, что это отлично работает. Я о высоко-нагруженных моментах. Когда кол-во запросов будет к примеру 300 в секунду. Я поясню откуда у меня такое суждение. Подготавливал софn для олимпиады в Сочи, там был один из серверов который только перераспределял данные на других и сохранял их. Протокол был http. Первым делом я сделал реализацию на скриптах (ведь это так просто и удобно) реализовав веб сервер, не справился он... повисал постоянно при больших потоках данных (так как нельзя было сделать так что какие то данные пропали). В итоге переписал на си, и эта часть прекрасно работала ни разу не повиснув с большими объемами ни пропустив ни одного (крутила у себя более тысячи перенаправляющих потоков).
Поэтому если речь идет о том, что данные от периферии приходят не интенсивно и потери допустимы, то скрипт подойдет. Но если потеря данных критична (например новые опираются на старые) и интенсивность отправки высока, то о скриптах можно забыть. Это ни сколько не говорит, о том что скриптовый это плохо, но нужно всегда помнить где он может применяться, какие ограничения он накладывает. Тем более виртурилка слабее, и тысяча потоков на скриптах для нее будет смертельно (впрочем думаю и 200-300 потоков на скриптах).
Я ни в коем случае не говорю что не нужно использовать скриптовые языки) наоборот, очень удобно порой и у них много плюсов. Просто я предупреждаю сразу о тех проблемах с которыми могут столкнуться другие. Если же человек собирается интенсивно обмениваться данными с виртурилкой, с кол-вом разных (разные потоки) запросов например 20 в секунду и объемом данных в них выше 100-300 кб (которые нужно обрабатывать параллельно), то боюсь что тут про скрипты можно забыть. Да и в любом случае (при меньших объемах данных) это скажется на времени отклика, возникнут лаги.

Мое дело из личного опыта предупредить о возможных проблемах, прислушаться к этому или нет дело личное. Хотите проверить, сделайте на скриптах тест, который
1) создает поток (когда приходят новые данные от сервера) и обрабатывает их и генерирует новый поток
2) новый поток что-то шлет обратно серверу (нужно чтобы обработка не мешала поступлению новых данных) и при этом сам что-то делает (опрашивают какие то порты).
3) Сгенерируйте на компьютере 200 запросов в секунду, и посмотрите что будет с виртурилкой.
И нужно не забывать, что чаще всего нужно еще и передача видео и звука.
Ну и последнее, как я понимаю вы не обрабатываете ни чего на сркиптах. Они нужны только для запуска си-шных модулей. Это совсем другое дело. Хотя не сов сем ясно как это происходит, один раз запустили забыл или постоянно при каких то действиях они запускают модули?

А, ну эт само собой, я ж не спорю. Просто для большинства обычного применения Виртурилки (управление чем либо одним клиентом, или несколькими, но поочерёдно) хватает описанной мною схемы. Там где нужна производительность - само собой, только скомпилированные приложения. Но там и гстример уже излишество, нужно приложение которое видео жмёт/транслирует. Примеры в DVSDK даже есть, правда, мы их ещё ни разу не пробовали. Но такая схема обычно делается когда железка предназначается для конкретной задачи, под это всё и пишется. А когда она в качестве "конструктора" - скрипты и гстример удобнее