Спасибо.
А можно пример использования? Для сжатия картинки?

ЗЫ: "гнутые" - имеется ввиду GCC? А под ИАР долго затачивать, интересно?

Да там просто все - вызвать encode(), указав откуда, куда, в каком формате и какого размера. С decode() аналогично.


Пардон, хотел сказать GPL'ные. Обычный plain C, без каких-либо специфических фишек, даже не 99.

Это вот такие поддерживаются форматы на входе?

Ну вот в каком формате, например, должна быть исходная картинка для функции: rgb24trPyuv420?
Что значит Y00 Y01 Y10 Y11 Cb Cr?

Тут понятно только, что 24 бита на пиксель, а дальше все эти Yxx...

Я бы понял, к примеру, такое описание: 24 бита на пиксель, сначала идёт красный (R, 8 бит), затем зелёный (G, 8 бит) и голубой (B, 8 бит).

зы: а, наверное, там задаётся как входной, так и аыходной формат?
Тогда всё понятно.
Можно попробовать взять маленькую фотку размером, скажем, 150х150 пикселей в RGB24 и...

RGB24. Где что по компонентам - не помню, но вариантов всего два.


Y - яркостная составляющая, Cx - цветоразностные.


Пример:

Вернет длину получившегося jpg.

Спасибо, всё понял, кроме параметра quality из Вашего примера. Думал, что это целое число в диапазоне от 1 до 100, но в примере получаются огромные цифры вплоть до 51000...
Это нормально?

Нормально. Это как раз приведение диапазона 1..100 к тому, который требует на входе энкодер. Почему именно так - не помню, хоть убейте.

с клоком все ок. почему так мало я уже писал.

Провел тест на mp3 декодере (от helix). В цикле 10 раз декодировал mp3-файл.
Библиотечные функции не использовались. inline assembler в декодере не использовался (только intrinsics).
Код на 3х компиллерах одинаков

gcc -Werror -Wall -Wextra -mcpu=cortex-m3 -mthumb -O3 -fomit-frame-pointer -ffreestanding -fno-common -fwide-exec-charset=UTF-16LE -fshort-wchar -g
39 сек
общий размер кода 196907

armcc --thumb -O3 -Otime --cpu=Cortex-M3 --bss_threshold=0 --c99 --strict --wchar16 --diag_error=Warning
39 сек
общий размер кода 181675

iccarm -thumb --cpu Cortex-M3 --aapcs std --aeabi -Ohs -r -e
44 сек
общий размер кода 166795

самый красивый код судя по бегло просмотренным листингам инересных функций у RVCT.
на размер кода особо не смотрите, линкеры rvct и iar повырезали некоторые неиспользуемые функции (mp3 это не касается)
Стек GCC жрет больше, чем rvct. Скажем вся самая большая ветка от main к самой глубокой функции у gcc 650 байт, у rvct 624 байт. IAR прочесать не смог, какой-то не стандартный у него elf или я что-то протупил

исходник,бинарки и пример использования (main.c) прилагаю.
Если будете собирать - на всякие непонятные вам функции (типа svcCreateThread) забейте(убейте), интересно только то, что в цикле.
Код пахал под моей осью, но системный таймер остановлен, других тредов не запущено,прерывания никакие не дергаются, тобышь весь алгоритм выполнялся линейно
Будет возможность, проверьте плиз на NXP, или я позже проверю

Блин, с энкодером облом вышел, функции преобразования цвета подобные rgb24trPyuv422 перезаписывают исходную картинку, то есть если она лежит во флеш сразу получаем исключение
И так с трудом влез в 20к оперативки STM32f103RBT6, а теперь ещё такое

Преобразуйте картинку заранее на PC.

LPC1768, 100 MHz, IAR 6.20.3, High Optimization, Speed: 28,5 секунд, 311 фреймов * 10 циклов.
Размер кода ~ 158022 байта.

свершилось...... LPC1830-LPC1850 уже в продаже
http://search.digikey.com/scripts/DkSearch...ame=568-6683-ND
http://search.digikey.com/scripts/DkSearch...ame=568-6682-ND

Сообщение отредактировал pofikus - Jul 15 2011, 18:11

Да, для не PRO версий они его уродуют . Для PRO, все совместимо.

А вот кстати, в посте где-то на две страницы ранее увидел, что, якобы декодирование MP3 320kbps занимает на NXP 30%, SAM3U 50%, а STM32F - 100%.
Хотелось бы стросить sonycman, проценты относительно к чему? То есть, как понимать, скажем, 100% загрузки?

Я сделал тут WAV/MP3 плейер на SAM3U (96MHz) и померял осциллографом, сколько надо на декодирование одного фрейма MP3 320kbps (то есть, один вызов MP3Decode). Получалось от 9 до 11.5мс (чем "басее" звук, тем дольше). Как известно, результат вылетает в DAC за 26мс. То есть, с этой точки зрения загрузка менее 50% (проц. мог бы декодировать два полных фрейма, пока один проигрывается). Неужели STM32F нужно полные 26мс, чтобы сделать то же самое?!

Сообщение отредактировал KnightIgor - Jul 15 2011, 21:58

Я приводил обобщённые данные загрузки для 320 kbps MP3, то, что видел на форумах.
100% для STM32 получилось со слов некоторых форумчан, сказали, что есть подтормаживания. Это говорит о 100% загрузке процессора.

Но сам на практике STM32 в роли декодера не испытывал.

Предполагаю, что тот, кто писал о подтормаживании, что-то неправильно в программе сделал.
Перекину проект на STM32F103RC, расскажу. Пусть не в тему тут. Хотя упомянутый мной SAM3U4E на SAM3U-EDK я взял, чтобы разобраться как раз с HS USB.