Видео сжатие, на каком проце делать?, H.263, h.264, theora, FFmpeg Опции

[hwdev]

Идет оценка проекта от заказчика..
Требуется сжимать, чтобы сохранить на носитель данные от 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, так они стоили не дорого. Теперь же их сняли с производства и заменили дорогими, а есть ограничение на стоимость прибора

[scum]

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

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

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

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