Elsystems 0 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба Прошу помощи профессионалов с опытом обработки видео. Стоит задача создания модуля, который в режиме реального времени осуществляет обработку видеопотока FillHD. Требуется реализация 2-х режимов работы: 1) определение смещения картинки по осям x, y (что то на подобии алгоритма в оптической мыши); 2) захват и сопровождение движимых и недвижимых целей. Видеопоток приходит по Ethernet в упакованном виде H.264. Есть еще ряд функций - сохранение видео на HDD, пользовательский интерфейс, наложение на видеопоток надписей и рамок захваченных объектов и т.д. Мы ранее с подобной тематикой не работали, но есть возможность и желание заняться. Пока стоит основной вопрос к профессионалам в данной области, что лучше выбрать - FPGA или DSP? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gorby 6 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба Прошу помощи профессионалов с опытом обработки видео.... что лучше выбрать - FPGA или DSP? Не в обиду. Выберите сначала грамотного руководителя. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
WitFed 1 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба Ну не надо так категорично ! Может, это руководитель и щупает почву... Хотя для руководителя прямота -- признак невысокого полёта сейчас и вообще ;) ...Тут много можно найти баталий на эти темы, только по всем признакам однозначно будет выбор -- DSP. Сейчас можно 8 ядер с плавучкой за 15 Вт купить 1 ГГц, они обжуют что угодно в рилтайме, цены на порядок легче ПЛИСовых, а скорость и качество разработки, возможности отладки -- на 2 порядка лучше. ПЛИС можно ставить рядом, только если какой-то вычурный ввод-вывод ещё не реализовали производители процов, чтобы подносила снаряды и уносила пустые гильзы. Если есть в наличии гении -- а их сильно вывозят последние 25 лет, -- то можно и на винт скинуть из ПЛИС, только гениям нужно подкидывать менее противоестественные задачи, ибо прямота и борьба с трансректалом -- основа их сознания. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба Мне кажется, что тут выбор будет между ПЛИС с АРМ-ом внутри (Cyclone V SoC, Arria V SoC например), и DSP с хардварным ускорением H.264 (какой нибудь DaVinci) - и, я практически уверен, в этой задачи DaVinci по цене и скорости разработки обойдет ПЛИС в разы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Elsystems 0 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба WitFed, SM спасибо, примерно так я и рассуждал, и хочется больше склониться в сторону DSP+ARM (типа TMS320DM). Заставляет колебаться такой факт: Белорусская фирма RIFTEK реализовала алгоритм захвата и сопровождения целей на FPGA в довольно маленьком объеме: для Spartan-6 - 5206 Slice reg, 13 DSP, 31 Block memory. Но мне наверное сейчас больше важна уверенность, что DSP справится с задачей. Gorby, я являюсь Подрядчиком, в то же время у меня есть свои Подрядчики, которые специализируются в разных областях. Я лично выполняю определенный объем работ, т.е. не передаю тупо все своим субподрядчикам. Один заказчик, который уже меня знает, предлагает заняться данной задачей. Обмана тут нет, он знает что у меня отсутствует опыт в этой области. Я конечно могу и отказаться, но хочу освоить это направление. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alexPec 3 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба Мне кажется, что тут выбор будет между ПЛИС с АРМ-ом внутри (Cyclone V SoC, Arria V SoC например), и DSP с хардварным ускорением H.264 (какой нибудь DaVinci) - и, я практически уверен, в этой задачи DaVinci по цене и скорости разработки обойдет ПЛИС в разы. Я бы на ПЛИС с армом смотрел. Пробовал DM3730, была задача в реал-тайме кодировать в JPEG D1, писать его на флешку + отправлять по Ethernet. Так вот на 25 к/с хватало, а на 30 к/с - уже нет. Сложилось впечатление, что TI по оптимизации кодека не заморачивались вообще. Конечно все было топорно, кодеки готовые от TI, операционка linux, но FullHD+ обработку которую Вы говорите - незнаааааааай. Там в алгоритмах аппаратного ускорения не будет, попиксельная обработка. Если только действительно монстра какого ставить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 6 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба выбрали FPGA возможно, потому что они умеют делать это на FPGA если находитесь (или исполнитель) в такой ситуации, что не знаете с чего начать, то DSP+ARM проще, и соответственно разработка дешевле но так как вычислительная часть достаточно простая и параллелится, то может на FPGA будет дешевле (себестоимость прибора), там, имхо, основная проблема будет в ширине шины (ее пропускной способности) к памяти, то есть совсем уж дешевую FPGA в маленьком корпусе не получится самое правильное, имхо, искать эксперта, который похожие задачи уже решал :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба Там в алгоритмах аппаратного ускорения не будет Будет. H.264 же - он полностью ляжет на аппаратное ускорение. Оно там заточено именно под этот стандарт. А остальное - да, попиксельная обработка, но она легкая, это Вам не JPEG. Более того, анализ смещения, скорее всего, тоже ляжет на аппаратный ускоритель для кодера H.264 - motion estimation (IME/IME2) - но тут бы посоветоваться с производителем этого чуда, вещь в себе. Кстати, не забываем о том, сколько места в FPGA это самое h.264 занимает. Особенно, если для сохранения видеопотока с наложенной графикой его обратно в h.264 кодировать придется! И смотрим на DM81xx, наверное... Там все интерфейсы сразу есть, включая и SATA, и HDVICP до трех штук для H.264 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба Видеопоток приходит по Ethernet в упакованном виде H.264. Судя по всему вам нужно будет, для начала работы, картинку развернуть в кадр, а это в стандарте h264 может быть сделано кучкой способов, особенно при компенсации движения (например ссылка на 2-3 кадра назад). ИМХО DSP only. UPD. декодер всегда делать сложнее чем энкодер, т.к. декодер должен поддерживать профайл стандарта полностью, а вот кодер может забить на очень многое. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Elsystems 0 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба Есть мысль (если склонюсь к DSP, что скорее всего) попробовать сначала (пусть не все) на таком ките http://www.starterkit.ru/html/index.php?na...=view&id=85 Кто нибудь использовал, что можете сказать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 28 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба Приветствую! Вы не стой стороны вагона подходите к задаче! Если у вас нет готовых алгоритмов обработки - то первое что надо делать - брать хороший комп. Вот когда на компе будет понятно последовательность, объем и тип вычислений, тогда и можно будет думать как и на чем эти алгоритмы реализовывать и на какую ножку микросхемы цеплять светодиод LOCK :) Успехов! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gorby 6 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба Приветствую! Вы не стой стороны вагона подходите к задаче! Если у вас нет готовых алгоритмов обработки - то первое что надо делать - брать хороший комп. Вот когда на компе будет понятно последовательность, объем и тип вычислений, тогда и можно будет думать как и на чем эти алгоритмы реализовывать и на какую ножку микросхемы цеплять светодиод LOCK :) Успехов! Rob. О! Вот и появился долгожданный кандидат в руководители. Задачу решают не на ДСП и не на ФПГА. А на адекватных задаче аппаратно-программных средствах. Аплодирую! к Elsystems: видите, как надо? А то "я - подрядчик..." Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HardJoker 12 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба Прошу помощи профессионалов с опытом обработки видео. Стоит задача создания модуля, который в режиме реального времени осуществляет обработку видеопотока FillHD. Требуется реализация 2-х режимов работы: 1) iMX6Quad - http://www.freescale.com/webapp/sps/site/p...jsp?code=i.MX6Q, поставщик и тех.поддержка - Симметрон, www.symmetron.ru Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба Если у вас нет готовых алгоритмов обработки - то первое что надо делать - брать хороший комп. Ну, как бы.... По умолчанию подразумевается, что математика уже сделана, когда речь о выборе платформы стоит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Elsystems 0 27 ноября, 2014 Опубликовано 27 ноября, 2014 · Жалоба О! Вот и появился долгожданный кандидат в руководители. Задачу решают не на ДСП и не на ФПГА. А на адекватных задаче аппаратно-программных средствах. Аплодирую! к Elsystems: видите, как надо? А то "я - подрядчик..." ДА я с вами полностью согласен, и были такие мысли на ПК сначала попробовать, но с другой стороны эти алгоритмы уже реализованы довольно многими фирмами на западе и некоторыми у нас, т.е речь не идет о создании чего то принципиально нового. Собственно я и хочу выяснить, какие аппаратно-программные средства более адекватны этой задаче. Алгоритм захвата и сопровождения целей кстати в Матлабе в примерах есть реализованный. Пока еще не ковырял, руки не дошли. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
