OpenMAX AL и DL

[proxy3d]

[realizator]

[proxy3d]

Да я понимаю, что повторяюсь. Просто наконец-то руки дошли до виртурилки (до этого занимался разработкой на других платах).
Нет, ни в коем случае я не пиарю 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... мне приходилось разрабатывать на всех, поэтому опыт разработки у меня большой. Поэтому по возможности хочется помочь и другим, облегчить процесс программирование под виртурилку (в конце концов вы у нас в россии одни... кто подходит для робо-проектов).

[realizator]

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

[proxy3d]

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

[Gol]

[proxy3d]

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

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

[Gol]

[proxy3d]

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

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

[Gol]

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