Идет оценка проекта от заказчика..
Требуется сжимать, чтобы сохранить на носитель данные от 2-х (4-х) видеокамер. Картинка 640х480 30fps.

Камера поддерживает форматы: Raw RGB, RGB (GRB 4:2:2, RGB565/555), YUV (4:2:2) and YCbCr (4:2:2). Какой выбирать?

Теперь по алгоритмам. Сразу скажу, что аппаратура будет на DSP или ARM9, не х86, об этом позже.
Из постановки задачи требуется записывать в кольцевой буфер 10-15мин от всех камер. Каким кодеком предпочтительнее сжимать видео поток, чтобы сохранить хорошее качество видео и не потерять кадры при захвате? Я так понимаю, от скорости кодека зависят требования к производительности процессора, Core Duo ставить возможности нет . Где хранить этот поток еще не решили, в зависимости от объема может поставим SDRAM большой, чтобы не парится с флешами из-за их низкой скорости записи и ограниченного ресурса. Ресурс записи также важен, т.к. прибор будет работать до 14ч в день и постоянно писать в кольцефой буфер..
Теперь конкретные вопросы:
1) какую библиотеку взять (пока смотрю в сторону ffmpeg, кросс-компиляция есть)?
2) каким конкретно кодеком жать?
3) какой процессор использовать?
На счет процессора: можно взять TI DSP + какой-нибудь МК или АРМ7. Можно взять DM355, у этого явного DSP нет, зато аппаратный MPEG сопроцессор стоит. C64x не подходят из-за цены. 5л назад работал с C6713, так они стоили не дорого. Теперь же их сняли с производства и заменили дорогими, а есть ограничение на стоимость прибора

chto-to mne podskazyvaet, chto programno na dsp ty tochno ne uspeesh v realnom vremeni szhmat s neskolkih kamer. da i tseny na programnye encoder $10k+

На сегодняшний день максимальное качество должен давать h264. При этом по вычислительной сложности он тоже уверенно лидирует. Реальность кодирования четырех каналов в хорошее качество на одном дспшнике вызывает сомнения. Если говорить именно про техасы, то интересно посмотреть в сторону DM6467, но там цена достаточно высокая. Если даже 64x не подходят (которые стоят 30-50 долларов, если я правильно помню), то 6467 не подойдет и подавно. Так что, похоже, надо смотреть на менее затратные кодеки, либо дспшники других фирм.

Вообще, наверное, имеет смысл попробовать покодировать разными енкодерами то видео, которое ожидается получать с камеры, и оценить для каждого енкодера битрейт, на котором получается приемлемое качество. Ну и исходя из этого думать дальше. Понятно же, что для того, чтобы различить номер машины на пожатом видео, нужен битрейт сильно выше того, который необходим чтобы увидеть просто наличие машины, и её цвет, например.

Формат входного видео, наверное, лучше выбрать что-нибудь вроде YV12, т.е. из 4:2:2 сконвертить в 4:2:0. Это хоть немного, но облегчит жизнь енкодеру, а для камеры слежения в 4:2:2 большого смысла вроде как и нет.

В ffmpeg насколько я знаю, нет примитивов для техасных камней, так что если выбраны будут именно они, то придется примитивы писать самостоятельно. Впрочем, в техасной dsplib уже есть кое-что готовое.

Последний Digital Signal Processing Selection Guide, стр.56. Там написано, какие кодеки реализованы для каких 64-х. ssdv004v.pdf (5 Mб)
h264 там есть.

http://focus.ti.com/apps/docs/selsolnguides.tsp?appId=79

Есть-то он есть, но там наверняка реализованы далеко не все фичи стандарта, так что надо смотреть на выходной стрим. Только его редко кто даёт.
Дема енкодера х264, которая идет с DM6446, например, умеет только три интра моды 16*16 и нулевые вектора в интер-моде. Ну то есть, стрим стандарта х264, да, но пользы от такого х264 — ноль.
Ещё 640*480*4 это почти полтора 1280*720, а это довольно много, обычно на дспях 64х речь идет про разрешения в районе 720*576.

800р в розницу за проц с индексом Б с 2 гигафлопами - имхо, очень недорого! данные с _efind.ru
И с производства они, насколько мне известно, не сняты! Мы как раз запускаем проект в серию на них...

Извиняюсь, но не могу опять не влезть :-)
67я серия это же плавучка, а видео кодирование всё сплошь на целочисленке. Можно, конечно, и 67 приспособить к видео, но смысл?

Поясните пожалуйста, что такое нулевые вектора? Компенсация движения не работает чтоли?

Да. То есть предсказание из предыдущих кадров как-бы есть, но только из тех же координат, где находится текущий макроблок. Не, на самом-то деле целопиксельный поиск движения не слишком сложен в вычислительном смысле, я думаю тут просто у техасов времени\желания не хватило.

поглядите на http://www.freescale.com/webapp/sps/site/p...p?code=MSC8144E
скорее всего производительности этого проца вполне хватит.

если же цена имеет значение то возможно это подойдет http://www.freescale.com/webapp/sps/site/p...X27&fsrch=1
все зависит от интерфейса...

Есть спорная(на мой взгляд) статья-обзор М.В. Руцкова на эту тему.
Ознакомится с ней можно здесь.

весьма спорная, ни слова по Analog Devices ни про Freescale, хотя у них тоже есть решения в этой области...

1. Не совсем ясно что должен делать этот прибор. Какой по времени объем данных надо хранить?
2. Сколько вам выделено времени на разработку?

Предположим заказчик хочет увидеть демо через пол года, предположим сохранять надо всего 15 минут с каждого канала. (...здается мне это очередной девайс для автомобилей...).
Для H264 (считаем что реализация енкодера качественная) хорошее качество картинки для заданного разрешения и заданного фрэймрэйта будет около 1.5 мегабит для Main Profile и около 3 мегабит для бэйзлана. Это примерно (1.5...3) * 60 * 15 =170...340 мегабайт на канал. Соответственно 700...1400 мбайт на все четыре канала. Т.е. все видео войдет в 2х гигабайтную флэшку. При этом поток данных будет около 2 мбайт/сек (== 16 мбит/сек) (все округляю в большую сторону).
Написать енкодер х264 (пусть даже только бэйзлайн) - год. Вы хотите год делать устройство? Четыре канала х264 нужно еще постараться запихнуть в один дсп (не важно какой, наличие ускорителей на борту скорости разработке не прибавит особо...) "один микросхем - один канал" - наверняка вам такое решение не очень понравится ибо "есть ограничение на стоимость прибора"...
Рекомендация: MJPEG. TI + DM642. Либа енкодера идет с edk. Если она не устраивает - пишите своё - жипег на порядок проще 264го. JPEG 640x480 30 fps приемлемого качества это около 6..8 мегабит, хорошего качества - около 12..16. Объем хранилища: 16 * 60 * 15 = 1.8 Гбайта, 1.8 * 4 = 8 гигабайт на 4 канала. (поправте если обсчитался) Не так уж и много. Поток в хранилище: 16 * 4 = 64 мбита/сек.

P.S. Скорость флэшей - приличная, так что не бойтесь их.

Итого получаем: 4х канальная видео ацп (TI, Techwell) + DM642 (600MHz, а если немножко не хватит роизводительность ставте 720 - не на много дороже) + 8ГБ флэш (CF, на пример или рассыпуха).
За пол года должны будете уложиться.