Evgeny_CD 0 18 января, 2005 Опубликовано 18 января, 2005 · Жалоба Исходная постановка задачи: необходимо делать снимки с видеокамеры, и сжимать их в JPEG. Описание планируемого железа. Видеосигнал подается на специализированный АЦП от филипса, например на SAA7113. Выход ITU 656 YUV 4 : 2 : 2 format (8-bit), разрешение 696*560 (PAL/SECAM). АЦП на плисину. К плисине SDRAM в качестве буферного ОЗУ. Все это подключается к микроконтроллеру. Алгоритм работы. Контроллер дает команду - "снять кадр". Плисина сама все делает, и кладет JPEG файл из этого кадра в буферное ОЗУ. Есть вариант реализации JPEG кодера Кодер на ПЛИС Влазит в недорогую XC3S400-4PQ208, насколько я понял. Вот только, боюсь, денег он стоит :) Что самое главное, есть отличная отладочная плата, как раз с нужной плисиной, чтобы потихоньку начать творить Отладочная плата на Ксиле Цена вполне разумная - 200 баксов. ВОПРОСЫ: 1. Есть ли у кого опыт (а еще лучше, реализация) создания JPEG кодера (декодер в этом проекте не нужен)? 2. Есть ли у кого "прихватизированная" библиотека с таким кодером или его элементами? 3. Взялся ли бы кто (не бесплатно) помочь мне сотворить это чудо? Я как-то не силен во всех эти *ХДЛ, я больше по контроллерам :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NickS 0 18 января, 2005 Опубликовано 18 января, 2005 · Жалоба Я бы вам предложил решать вашу задачу на DSP , например, на Blackfine. Имеет прямой порт для подключения кодека, ресурса хватит, с учетом того, что вам даже Real Time не нужно. Стоит дешевле чем Spartan. Найти реализацию на "С" так же проще. Помоему даже в application что-то есть. Отлаживать - для вас понятнее. Реализовать вашу задачу на ПЛИС - я думаю оптимистично от 3 до 6 человеко месяцев, с учетом отладки. Отлаженную реализацию с учетом таких затрат вам дешевле $10000 не продадут. Найти "на халяву" - так кто отвечать будет за работоспособность, а разобраться, проверить, отладить - так это те же самые 3-6 месяцев. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 18 января, 2005 Опубликовано 18 января, 2005 · Жалоба Вот, нашлось что-то готовое. Непонятно только качество. http://opencores.nnytech.net/projects.cgi/web/video_systems/ http://opencores.nnytech.net/projects.cgi/web/jpeg/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dmtl 0 19 января, 2005 Опубликовано 19 января, 2005 · Жалоба {посмотрите тему http://forum.electronix.ru/index.php?showtopic=2352 из ветки ищу работу} 1. Ищу (почти нашел) постоянную работу, а не одноразовую. 2. В данном случае плясать нужно от требуемого разрешения, если это охранка, с низким качеством, то можно поставить за ТВ декодером Pilips blackfin от ADI с портом PPI, и на внутренней памяти (64к) хранить картинку. При более высоком качестве blackfin+память. В аналоговом девайсе есть открытый код JPEG200 под этот процессор, наверняка конкуренты от TI тоже не отстают в данной проблеме. 3. ADI выпускает специализированный чип, который кодирует видео в JPEG2000. 4. Вы хотите просто держать данные в буфере или куда-нибудь передать? Это также может повлиять на выбор микросхем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 25 января, 2005 Опубликовано 25 января, 2005 · Жалоба {посмотрите тему http://forum.electronix.ru/index.php?showtopic=2352 из ветки ищу работу} 1. Ищу (почти нашел) постоянную работу, а не одноразовую. 2. В данном случае плясать нужно от требуемого разрешения, если это охранка, с низким качеством, то можно поставить за ТВ декодером Pilips blackfin от ADI с портом PPI, и на внутренней памяти (64к) хранить картинку. При более высоком качестве blackfin+память. В аналоговом девайсе есть открытый код JPEG200 под этот процессор, наверняка конкуренты от TI тоже не отстают в данной проблеме. 3. ADI выпускает специализированный чип, который кодирует видео в JPEG2000. 4. Вы хотите просто держать данные в буфере или куда-нибудь передать? Это также может повлиять на выбор микросхем. <{POST_SNAPBACK}> 1. - понятно. 2. разрешение 696*560, качетсво должно вариьроваться - это и 64 к картинка, и выше. 3. Изучается. Но eval кит больно дорого стоит. И поставка чуть ли не 14 недель. 4. В буфере держать. Его дальнейшей обработкой CPU займется. Как будет буфер организован - пока не понятно. Спасибо за ответ - я потихоньку продвигаюсь к пониманию того, можно ли так решить задачу и нужно ли. http://elphel.com/downloads/313_rus.html -есть исходники JPEG сжимателя. Там решена похожая задача, но мне надо несколько по другому. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andrey Filippov 0 27 января, 2005 Опубликовано 27 января, 2005 · Жалоба http://elphel.com/downloads/313_rus.html -есть исходники JPEG сжимателя. Там решена похожая задача, но мне надо несколько по другому. Тому проекту уже больше двух лет - JPEG уже давно у всех есть - можно и настоящий видеокомпрессор в плиску впихнуть - еще и место остается - 1280х1024 - 30к/сек http://cvs.sourceforge.net/viewcvs.py/elphel/fpga/theora/ Loading device database for application Par from file "x333_map.ncd". "x333" is an NCD, version 2.38, device xc3s1000, package ft256, speed -4 x333.par: ... Device utilization summary: Number of External DIFFMs 1 out of 78 1% Number of External DIFFSs 1 out of 79 1% Number of External IOBs 116 out of 173 67% Number of LOCed External IOBs 116 out of 116 100% Number of MULT18X18s 13 out of 24 54% Number of RAMB16s 20 out of 24 83% Number of Slices 4789 out of 7680 62% Number of SLICEMs 454 out of 3840 11% Number of BUFGMUXs 7 out of 8 87% Number of DCMs 2 out of 4 50% ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Decan 0 15 февраля, 2006 Опубликовано 15 февраля, 2006 · Жалоба Andrey Filippov: JPEG уже давно у всех есть Будьте добры ткните меня носом в ссылку, где это добро находится... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 15 февраля, 2006 Опубликовано 15 февраля, 2006 · Жалоба По поводу Theora: интересно, а какова его эффективность по сравнению с тем же MPEG4? Дока по самому алгоритму качественная и обстоятельная, но на сайте не сильно много инфы. http://www.theora.org/ На сайте, кстати, прикол - вверху стоит новость от 2005 January 13, что меня опечалило, но присмотревшись, я понял, что это "ачепятка" Я своими глазами видел работу MPEG4 на разрешении CIF / 25 fps получалось что-то типа 1мбит/сек при качестве как у среднего VHS видика. Что тут получается? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andrey Filippov 0 23 февраля, 2006 Опубликовано 23 февраля, 2006 · Жалоба Andrey Filippov: JPEG уже давно у всех есть Будьте добры ткните меня носом в ссылку, где это добро находится... Так в любой сетевой камере. На ПЛИС - хоть www.iqinvision.com, хоть http://www.mobotix.com/ (из тех. про которые я точно знаю). Но исходников там, конечно нет. Нужны GPL-ные (не freeware) - берите у нас. Хотите разрабатывать/дорабатывать - пишите, для хорошего дело железок бывает не очень жалко. Andrey Filippov andrey . filippov <at> elphel . com Что тут получается? http://www.elphel.com -> Developers -> первый абзац - там два клипа. Современные дистрибутивы GNU/Linux открывают сходу (например, Kaffeine), говорят и под виндами тоже работает. Andery Filippov Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 24 февраля, 2006 Опубликовано 24 февраля, 2006 · Жалоба Спасибо за то, что откликнулись! Andrey Filippov, интересно, сообщество Theora Вам еще не поставило прижизненный памятник? Посмотрел. страница http://www.elphel.com/3fhlo/index.html Смотрел плеером http://www.videolan.org/ Файл m021_300_1_70.ogg не открылся - "серый квадрат". Может, у меня машина слабая - AMD Barton 1.6? j0011_5.ogg проигрался нормально. Загрузка проца - 50% (точно, для предыдущего файла проца не хватит - вероятно, декодер пока не оптимизировали на все эти SSE и пр.). Вообще внушает! 2 минуты ролик, 6fps. 1280x1024, 16мбайт размер ролика - получается что-то типа 136 кбит (кило=1024)/сек. Качество - на мой взгляд, хрошее, с бытовой камерой не сравнить. Если идти в сторону "видеоохранного" качества, и поставить планку CIF 6fps, битрейт, вероятно, упадет не менее чем в два раза. Получим видео вполне достаточного качества при потоке 64 кбит/сек. Если повезет, и упадет в 3 раза, то получим 45кбит на видео, и на аудио 19 кбит останется - получим полноценную систему мониторинга с потоком 64 кбит :tort: 1Гбайт памяти - это 4.5 часа такой записи. С учетом того, что 4 Гбайт SD карточка стоит в Москве <300$ получим 18 часов записи на девайс размером со "спичечную коробку" - ну или "пачку от сигарет" - если еще и аккумулятор подрубить. Лично для моих проектов GPL лицензия на видеочасть даже полезна - хорошо, что все открыто, и есть шанс, что завтра оно не сдохнет. В качестве кодера в проекте выступает XC3S1000-4FT256C. Терпимо. В общем, Andrey Filippov - :a14: "адназначна". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andrey Filippov 0 24 февраля, 2006 Опубликовано 24 февраля, 2006 · Жалоба Файл m021_300_1_70.ogg не открылся - "серый квадрат". Может, у меня машина слабая - AMD Barton 1.6? j0011_5.ogg проигрался нормально. Загрузка проца - 50% (точно, для предыдущего файла проца не хватит - вероятно, декодер пока не оптимизировали на все эти SSE и пр.). Да, именно. Я тогда себе под это дело dual Xeon 3.6 купил все равно - недотягивал. Хотя софт с тех пор подчистили. Вообще внушает! 2 минуты ролик, 6fps. 1280x1024, 16мбайт размер ролика - получается что-то типа 136 кбит (кило=1024)/сек. Качество - на мой взгляд, хрошее, с бытовой камерой не сравнить. Честно говоря - там еще работать и работать - можно во многих "охранных" применениях сжать и посильнее. Дело в том, что у меня не использована возможность - на ходу решать - кодировать ли блок или считать, что он слабо изменился и пропускать (неподвижный фон). Сейчас этоне реализовано, т,к, заголовки у меня генерируются программно (зыранее), запихнуть их тоже в ПЛИС-ину уже напряга не хватило (а заголовок кадра сожержит, в частности, таблицу кодированных блоков) Если идти в сторону "видеоохранного" качества, и поставить планку CIF 6fps, А вот здеь я не согласен - считаю, что именно в этой области планку нужно поднимать. Иметь возможность записывать высокое разрешение с широкоугольными объективами, а не с повроротными камерами, которые легко пропускают важные события. Низкое качество охранных систем - может быть это сила привычки? Лично для моих проектов GPL лицензия на видеочасть даже полезна - хорошо, что все открыто, и есть шанс, что завтра оно не сдохнет. Именно на этом и бизнес :-) Мне удалось взять (и выполнить, конечно) большой заказ на разработку еще тогда, когда фирма-то была из одного человека. И со мной не испугались иметь дело именно поэтому - с исчезновением фирмы не пропадет возможность продолжать работать с ее продукцией - специалистов ведь можно и нанять себе. Андрей Филиппов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 24 февраля, 2006 Опубликовано 24 февраля, 2006 · Жалоба ...Честно говоря - там еще работать и работать - можно во многих "охранных" применениях сжать и посильнее. Дело в том, что у меня не использована возможность - на ходу решать - кодировать ли блок или считать, что он слабо изменился и пропускать (неподвижный фон). Сейчас этоне реализовано, т,к, заголовки у меня генерируются программно (зыранее), запихнуть их тоже в ПЛИС-ину уже напряга не хватило (а заголовок кадра сожержит, в частности, таблицу кодированных блоков)...Я понимаю, что Вы спец по FPGA, но интересно, можно ли эту Theor'у в AD BF561 засунуть? Там все-таки софтом многие вещи было проще решать......А вот здеь я не согласен - считаю, что именно в этой области планку нужно поднимать. Иметь возможность записывать высокое разрешение с широкоугольными объективами, а не с повроротными камерами, которые легко пропускают важные события. Низкое качество охранных систем - может быть это сила привычки?Да нет. Я как раз сторонник большого количества простых камер. Тогда точно ничего не пропустится. И, главное, камеры должны быть _аналоговыми_, т.к. пока выбор среди CMOS сенсоров ни в какое сравнение не идет с обычными аналоговыми охранными камерами (парадокс - там внутри стоит тот же CMOS, иногда CCD цифровой сенсор + DSP, но опытный фаакт, что получать такое же качество изображения в "стремных" условиях (темнота, большой диапазон по яркости) при помощи обычного CMOS сернсора замаешься!) А GPL - Это сила! Тут спорить не о чем. И деньги это ничуть не мешает зарабытывать - даже наоборот (при грамотном подходе). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alexr22b 0 24 февраля, 2006 Опубликовано 24 февраля, 2006 · Жалоба ...Честно говоря - там еще работать и работать - можно во многих "охранных" применениях сжать и посильнее. Дело в том, что у меня не использована возможность - на ходу решать - кодировать ли блок или считать, что он слабо изменился и пропускать (неподвижный фон). Сейчас этоне реализовано, т,к, заголовки у меня генерируются программно (зыранее), запихнуть их тоже в ПЛИС-ину уже напряга не хватило (а заголовок кадра сожержит, в частности, таблицу кодированных блоков)...Я понимаю, что Вы спец по FPGA, но интересно, можно ли эту Theor'у в AD BF561 засунуть? Там все-таки софтом многие вещи было проще решать......А вот здеь я не согласен - считаю, что именно в этой области планку нужно поднимать. Иметь возможность записывать высокое разрешение с широкоугольными объективами, а не с повроротными камерами, которые легко пропускают важные события. Низкое качество охранных систем - может быть это сила привычки?Да нет. Я как раз сторонник большого количества простых камер. Тогда точно ничего не пропустится. И, главное, камеры должны быть _аналоговыми_, т.к. пока выбор среди CMOS сенсоров ни в какое сравнение не идет с обычными аналоговыми охранными камерами (парадокс - там внутри стоит тот же CMOS, иногда CCD цифровой сенсор + DSP, но опытный фаакт, что получать такое же качество изображения в "стремных" условиях (темнота, большой диапазон по яркости) при помощи обычного CMOS сернсора замаешься!) А GPL - Это сила! Тут спорить не о чем. И деньги это ничуть не мешает зарабытывать - даже наоборот (при грамотном подходе). Именно, в БФ или ДМ642 или ещё луче в Davinchi (TI). Там и CABAC можно написать (или в Теоре они не его не используют?) -попроще будет чем в ФПГА. Да и motion search сделать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andrey Filippov 0 26 февраля, 2006 Опубликовано 26 февраля, 2006 · Жалоба но опытный фаакт, что получать такое же качество изображения в "стремных" условиях (темнота, большой диапазон по яркости) при помощи обычного CMOS сернсора замаешься!) опять-таки не согласен - аналоговым камерам сложно делать несколько-секундные выдержки точью. А ночные съемки у нас есть - webcams . elphel.com Андрей Филиппов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 26 февраля, 2006 Опубликовано 26 февраля, 2006 · Жалоба Именно, в БФ или ДМ642 или ещё луче в Davinchi (TI). Там и CABAC можно написать (или в Теоре они не его не используют?) -попроще будет чем в ФПГА. Да и motion search сделать. CABAC это же в MPEG-4, Theora на хафмане вроде сидит (возможно адаптивном), но вот кабак на ДСП ИМХО не сильно переспективное занятие :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться