Cortex-M4F и сжатие видео на ходу, Вомзожно ли Опции

[Forger]

Подскажите, плиз, кто имел опыт сжатия видео на ходу на Cortex-M4F, в частности на STM32F4 или другом проце на таком ядре.
Возможно ли сжать на этих МК на ходу видео 320x240, 2 байта на пиксель, 25 fps и выше?
Скажем, в формат MJPEG. Исходные данные идут в формате YCbCr 4:2:2 или RGB565.
Если это анреал, то что посоветуете дешевое, без линуксов и с нормальным (IDE).

[_pv]

для оценки можно взять циферки от блэкфина
http://www.analog.com/en/dsp-software/bf_j...on-jpeg/sw.html
и на 2, а то и на 3 помножить.
jpeg - 50 блэкфиновских тактов на пиксель.
320*240*25 = 2МПикс/сек. то есть по хорошему кортексу надо бы 200-300МГц.
с видео енкодерами с межкадровым сжатием (mpeg) всё еще хуже.
можно конечно попробовать что-нибудь своё сгородить, тупо дельта кодирование или даже какой-нибудь простейший вэйвлет хаара (полусумма/полуразность, да еще и трехмерный, чтоб по времени) + энтропийное кодирование, но, имхо, если оно и влезет по быстродействию, сжатие будет не большое.
да и с внешней памятью у STM32F4 через FSMC общение не самое быстрое, сколько там максимум, на 56МГц цикл шины?
хотя у F429 есть и sdram контроллер и некие ухищрения в дма для графики, но не сильно это поможет.

[Forger]

да и с внешней памятью у STM32F4 через FSMC общение не самое быстрое, сколько там максимум, на 56МГц цикл шины?

На 25fps поток выходит почти 4Мбайт/сек, а для 16-битной внешней SRAM выйдет почти 2Мслова в сек.
При использовании DMA перегон данных туда-сюда не сильно грузит проц.
Я как-то сравнивал: DMA2 гнал данные из DCMI (камера OV7725) в ЖК по FSMC.
Так вот нагрузка на проц на 168Мгц вырастала всего лишь на 0.2% (под TNKernel).

Межкадровое кодирование необязательно, хватит обычного MJPEG.

Т.е. вы считаете, что не потянет?
На каком проце лучше это поднять?
Нужен аппаратный интерфейс для работы с камерой и ЖК, USB device и нормальная среда и библиотеки для сжатия видео по возможности.

[_pv]

На 25fps поток выходит почти 4Мбайт/сек, а для 16-битной внешней SRAM выйдет почти 2Мслова в сек.
При использовании DMA перегон данных туда-сюда не сильно грузит проц.
Межкадровое кодирование необязательно, хватит обычного MJPEG.
Т.е. вы считаете, что не потянет?

вопрос в том сколько раз туда-сюда данные надо будет гонять для сжатия видео в какой-нибудь mpeg.
для jpegа да, только один раз прочитать надо в буфер на 8 строк,
ну а 50 тактов на пиксель для блэкфина говорят о том что не потянет, кадров 10 в секунду, наверное, получится.

[Forger]

вопрос в том сколько раз туда-сюда данные надо будет гонять для сжатия видео в какой-нибудь mpeg.
для jpegа да, только один раз прочитать надо в буфер на 8 строк,
ну а 50 тактов на пиксель для блэкфина говорят о том что не потянет, кадров 10 в секунду, наверное, получится.

Ради интереса я взял вот это довольно просто написанный JPEG-кодек: Jpegant.
Убрал оттуда преобразование RGB->YCrCb (к счастью, хотя бы это камера OV7725 умеет делать сама).
Осталось только DCT преобразование и huffman сжатие.
Проц STM32F407VG на 168МГц, кроме как кодирование картинки он ничего не делает (ну крутится еще RTOS, но я ее тут не считаю).
Изображение берется из внутренней ОЗУ, благо для хранения картинки 320x240x2байта его хватает.
Оптимизация файлов кодека -O3 -Otime (Keil 4.72.10).

Так вот. в пределе выходит 25fps.

Ради интереса попробовал включить RGB->YCrCb преобразование, то fps резко упало до 15.
Если покопаться в исходниках кодека и оптимизировать его под Cortex-M4F, то, я уверен, что fps можно еще поднять на несколько кадров.

В принципе, вот весь код сжатия картинки:

CODE

huffman_start(240, 320);
for (unsigned y = 0; y < (240-15); y += 16)
{
for (unsigned x = 0; x < (320-15); x += 16)
{
getBlock(x, y, 16, 16, (BGR*)RGB16x16)); // take picture block from IRAM
/*
// geting four 8x8 Y-blocks
for (unsigned i = 0; i < 2; i++)
for (unsigned j = 0; j < 2; j++)
{
for (unsigned r = 0; r < 8; r++)
for (unsigned c = 0; c < 8; c++)
{
const unsigned rr = (i<<3) + r;
const unsigned cc = (j<<3) + c;

Color red = RGB16x16[rr][cc].red;
Color green = RGB16x16[rr][cc].green;
Color blue = RGB16x16[rr][cc].blue;

// converting RGB into Y (luminance)
Y8x8[i][j][r][c] = RGB2Y(red, green, blue)-128;
}
}
// getting subsampled Cb and Cr
subsample(RGB16x16, Cb8x8, Cr8x8);
*/
// 1 Y-compression
dct(Y8x8[0][0], Y8x8[0][0]);
huffman_encode(HUFFMAN_CTX_Y, (short*)Y8x8[0][0]);

// 2 Y-compression
dct(Y8x8[0][1], Y8x8[0][1]);
huffman_encode(HUFFMAN_CTX_Y, (short*)Y8x8[0][1]);

// 3 Y-compression
dct(Y8x8[1][0], Y8x8[1][0]);
huffman_encode(HUFFMAN_CTX_Y, (short*)Y8x8[1][0]);

// 4 Y-compression
dct(Y8x8[1][1], Y8x8[1][1]);
huffman_encode(HUFFMAN_CTX_Y, (short*)Y8x8[1][1]);

// Cb-compression
dct(Cb8x8, Cb8x8);
huffman_encode(HUFFMAN_CTX_Cb, (short*)Cb8x8);

// Cr-compression
dct(Cr8x8, Cr8x8);
huffman_encode(HUFFMAN_CTX_Cr, (short*)Cr8x8);

}
}
huffman_stop();

Сообщение отредактировал IgorKossak - Nov 28 2013, 14:48

Причина редактирования: [codebox] для длинного кода, [code] - для короткого!!!

[_pv]

Ради интереса я взял вот это довольно просто написанный JPEG-кодек: Jpegant.
Так вот. в пределе выходит 25fps.
Ради интереса попробовал включить RGB->YCrCb преобразование, то fps резко упало до 15.
Если покопаться в исходниках кодека и оптимизировать его под Cortex-M4F, то, я уверен, что fps можно еще поднять на несколько кадров.

отличный результат,
значит для блэкфина jpeg, что дают AD, действительно довольно индусский и там, наверное, тоже есть что улучшить.