repstosw

Чтоб не быть голословным: сделал и закачал архив(ссылка ниже), в котором результаты сжатия трёх кодеков: - VP9: 18.1 МБ - Lagarith: 12.8 МБ -PackMan v.2 (мульти-стратегический): 12.6 МБ Исходное видео: 52.3 МБ что при пересчёте с 8 на 6 бит на компоненту - в эквиваленте 39.23 МБ (младшие 2 бита каждой цветовой компоненты оригинального видео =0). Там же бат-скрипты, утилита для воспроизведения ffplay и новая версия кодера/декодера PackMan (мультистратегический). На более длинных видео - результат будет ещё лучше в пользу PackMan Архив: https://dropfiles.org/2Sn пароль к архиву 13169

У вас есть опыт работы с этим камнем без пингвина и ведра? Внешней шины для подключения дополнительной периферии, наподобие как FSMC у STM32 у V3s как я понял нет? Если так - прощай дисплеи с контроллерами и своей памятью .. Тот что в QFP OMAPL137-HT недоступен для заказа из-за политики США по отношению к РФ. В БГА мне неинтересно.

Всё-же уделил время на VP9 и затестил его в режиме лосслесс через ffmmpeg: rem VP9 кодек Lossless конфа ffmpeg -i 0.avi -c:v libvpx-vp9 -lossless 1 output.webm Результат обнадёжил : 390 МБ против моих: Packman rev.0: 234 МБ rev. 1: 228 МБ Мультистратегический: 224 МБ Лагариф и МСУ также лучше: 242 и 247 МБ соответственно. Так что хвалёный VP9 на лосслесс оказался хуже "старых" добрых MSU и Lagarith. И жмёт ещё долго, по сравнению с PackMan и Lagarith. Выводы я сделал.

Вам осталось сделать ещё один небольшой рывок - доказать, что AV1 и VP9 битэкзактны. Есть сомнения по поводу. Ну и глупо искать по нарицательным именам конкретные видеоролики, тем более версии, заточенные под 160x128. Но ваш намёк понял - вот вам моё встречное напутствие: встречного ветра и якорь вам в... :)

AV1 и VP9 - не lossless. MSU - не древний, живёт и процветает до сих пор. http://www.compression.ru/video/ls-codec/ Lagarith я бы не сказал что древний

Здравствуйте. Ищу процессор в QFP корпусе, который будет производительнее, чем ADSP BlackFin BF532. Цель: запуск обильного кода с 2D графикой (bitblt, colorkey, alfablending) + немножко 3D (поворот, перенос, масштабирование), тригонометрия. + эмуляция процессоров -8 и 16 бит: Z80, 6502, M68000. + декодирование видео (H264, MJPEG,...) аудио (MP3, FLAC) Пробовал собирать эмуляторы на BF532, разогнал до 700 МГц. Иногда эмуляция всей системы не достигает 60 FPS из-за отсутствия floating point, медленной производительности. В качестве кандидата на замену рассматриваю : TMS320C6745 - доступен, корпус QFP, 475 МГц, шина SDRAM 32 бита, есть floating point, VLIW до 6 команд одновременно. Вроде как лучше чем BF532 ? Или даст выигрыш по сравнению с 532-м незначительно?

Что за шланг? GCC arm-noeabi ? Насколько хуже будет код GCC по скорости по сравнению с ARMCC ? Да, подвисает зараза, когда много сорцов проекта открыто. По этой причине редактирую код в Блокноте, а фишки компиляции со сборкой в проект - в Кейле. Насколько оправдан и затратен переход на GNU ToolChain? Файлы линкера и мейк-файлы писать умею.

А разве не порвёт C6745 BF532 хотя-бы из-за: 1) VLIW до 6 команд одновременно - против 2 команд у BF532 //выигрыш в 3 раза 2) SDRAM 32 бит - против 16 бит у 532-го // выигрыш в 2 раза 3) Hardware floating point - против софтварных целочисленных рядов Тейлора на 532-м //выигрыш в специфических местах 4) 475 МГц - против 400 // несущественно, но приятно 5) У BF532 - скудный малооперандный ассемблер, в отличие от того же ARM. У C6745 вроде как по-лучше? В целом вижу оправданным переход на C6745. Поправьте, если ошибаюсь.

Рассматривал JPEG2000 Lossless, его программная реализация (которая есть в открытом виде) - очень громоздка для переноса на МК STM32F407 и алгоритм просто не пошёл (из-за применения менеджера кучи для данных и кода). К тому же, кодек MJPEG2000 Lossless проигрывает по степени сжатия даже тому же Lagrith. Dirac - тоже жмет хуже Lagarith и требует много вычислительных ресурсов. HuffYUV - прост, но хуже всех жал. MSU - нет исходников Lagarith - хотел вначале портировать его, но мой кодек его обскакал по сжатию (в анимешных мультфильмах) Остался 1 путь - написать свой, взяв всё лучшее со всех. Я - человек науки, поэтому тут ещё дополнительно академический интерес. Жал много фильмов, мультфильмов, коэффициент сжатия был не ниже 2. Обычно от 2.8 - 3. Конечно, если жать белый шум, то выигрыша не даст :) Пробовал применить ZLIB, слишком затратно по времени на декодирование. LZH тоже. Так что только энтропийное кодирование. ---------------------------------- Я вот тут подумал и сообразил новый Мульти-Стратегический кодек. Суть его в том, что пробуются все возможные сочетания блоков конвеера на предмет сжатия. И выбирается лучшая стратегия. Если исходный сигнал у нас - это RGB, то блоков конвеера у нас 5: 1) преобразование YCbCr 2) WaveLet преобразование 3) Difference преобразование (межкадровое вычитание) 4) Huffman 5) RLE Просчитал, возможно 64 комбинации, они на рисунке ниже. Написал кодер, прогнал вариант 3): "Space Cobra": 1034.24 МБ С учётом 6 бит из 8: 775.68 МБ PackMan rev.0: 225 МБ PackMan rev.1: 211 МБ получилось 187 МБ против 211, что неплохо! Причем задача декодирования нисколько не усложняется, а наоборот даже - в некоторых случаях конвейер декода будет короче, номер стратегии пишется в хедер - каждый номер определяет жестко заданный порядок декодирования . Это немаловажно для STM32F407. Восклицательным знаком помечены те варианты, которые были распознаны как оптимальные по сжатию. (подсчитал статистику по стратегиям )

В SNES-эмуляторе графическая система на floating point. Эмулятор Snes9x. Потому что : поворот, растяжение, текстурирование :) Особо упоротые реализации в CPS1/2 - синтез звука на floating point. Вот я и хочу понять, насколько осчастливят меня ARM Kinetis, или всё-же лучше взять C6745, который будет по-лучше прошлого варианта эмулятора с ADSP BF532? Если оно того не стоит, то насколько будет удачен выбор Allwinner A13, v3s для эмуляторов? (без линукса правда, в стиле баре-метал)

-HT - в QFP Это хотел сказать, что нужна плавучка, а то как она реализована - в виде юнита или в составе команд основного АЛУ - уже не интересует :) В смысле, что экзамплы входят в неё или нет? Наподобие как у Visual DSP: в папке есть примеры работы с периферией Блекфина (наподобие SDK). А почему бы и нет? Ха! Эмуляция только одного графического чипа Capcom Play System-2 и его звуковой части Q-Sound + FM- синтез чего только стоят. Быстрая числодробилка напрашивается!

В разработанном устройстве "nanoPlayer" и на ПК ошибок нет и быть не может (при условии, если настройка режимов ядра и периферии выполнены корректно). Если же говорить о линии связи или промежуточном агенте переноса информации (радиоволны, оптоволокно и прочее...), то в данном кодеке используется форсированная вставка ключевого фрейма - каждый 12-й кадр, что даёт время восстановления 1 секунду при 12 FPS. В новой ревизии 1 кодека, ключевой кадр может идти чаще, но не реже, чем 1 раз на 12 кадров. Ok, спасибо! Я перепробовал 4 версии кодера Хаффмана (качал с гитхаба) и все они жали по-разному. Был даже один вариант, который декодировался с ошибкой. Я выбрал тот, который при проверке не даёт ошибок и с лучшим сжатием.

Хороший вопрос! :) Честно, я не смог определить - адаптивный или нет, прилагаю сорец реализации Хаффмана, пожалуйста гляньте если нетрудно, тоже интересно - адаптивный или нет? huffman.txt Иногда, когда много пустоты в кадре из-за пустой таблицы частот приходится дожимать с помощью RLE поверх Хаффмана.

OMAPL137-HT в QFP корпусе. В свете сегодняшних политических событий его вряд-ли возможно из США в Россию передать. Так сказал mouser.com. Порылся в ТиШных DSP, нашёл ещё красавца - TMS320C6745 - тоже в QFP, версия 456 МГц. Если его сравнить с BF532 на 400 МГц, то очевидно , что TMS лучше ? Заинтересовал VLIW и наличие FPU, чего нет у Блекфина. А также подключение SDRAM с шириной ШД аж 32 бита! Ну и доставаем. На счёт Code Composer Studio, поддержка TMS там на уровне? Или всё спрятано в линуксах? С БГА пичаль, мне надо чтоб без ухищрений распаять. Или всё-же долбить Allwinner? Я очень часто работаю с чужим исходным кодом и не могу позволить себе роскошь потратить время на тотальное переписывание исходных кодов эмуляторов (это не только процессор, но и периферия). Это к вопросу "Либо вы точно знаете свои алгоритмы и что в них хотите улучшить, либо не знаете" Ну и ZX эмулировать совсем неинтересно. GameBoy Color или NES куда интереснее будут! :)

Я конечно могу привести таблицу, но поверят ли? Проще проверить было самому. Тесты: 1) "Винни-Пух": 211 МБ С учётом 6 бит из 8: 158.25 МБ PackMan rev.0: 59.6 МБ PackMan rev.1: 56.9 МБ Lagarith: 69.4 МБ MSU: 46 МБ 2) "Yurizan Beltran": 406 МБ С учётом 6 бит из 8: 304.5 МБ PackMan rev.0: 106 МБ PackMan rev.1: 102 МБ Lagarith: 98.5 МБ MSU: 97.7 МБ 3) "Space Cobra": 1034.24 МБ С учётом 6 бит из 8: 775.68 МБ PackMan rev.0: 225 МБ PackMan rev.1: 211 МБ Lagarith: 240 МБ MSU: 178 МБ 4) "Ashton Pierce": 877 МБ С учётом 6 бит из 8: 657.75 МБ PackMan rev.0: 234 МБ PackMan rev.1: 228 МБ Lagarith: 242 МБ MSU: 247 МБ Во втором случае кодек проиграл всем остальным по сжатию. В четвертом случае - победил всех. В большинстве случаев разработанный кодек между Lagarith и MSU по степени сжатия, при этом не уступающий в скорости кодирования-декодирования (про MSU лучше вообще не вспоминать, там где нужна скорость декодирования) Реализовал улучшенный вариант кодера: PackMan rev.1, декодер остался тем же. Когда отлажу, выложу. Я смотрел на ней[железке] весь сериал "Space Cobra" все 31 эпизодов по 25 минут каждый.

Для BF532, BF533 я абстракцию писал сам :) На выходе получилось что-то вроде своего SDK (или API), делающий всю необходимые функции: установка клоков CPU, SDRAM, SPI, настройка периферии, стека , кучи... Повезло что Блекфины линуксоеды и прочие ОСо-любы не испортили :)

Под этот же плеер исходники с прошивками, декодирующие: ADPCM, MP3, FLAC, MJPEG, MP4(H264): nanoPlay_IMA_MP3_FLAC_MJPEG_H264.zip

Нет, GUI не нужен. Нужно просто быстрое ядро под универсальные алгоритмические задачи (эмуляция 8- и 16- битных процессоров) + обработка графики (копирование из одной области памяти в другую, копирование массива в регистр данных дисплея). DDR я как понимаю будет лучше смотреться, чем обычная PC133 SDRAM. Приобрёл 2 платы на A13: Olinuxino и SOM-модуль. И-за текущих работ не могу пока до них добраться, поэтому в режиме сбора информации. Есть ещё v3s, к счастью там не надо DDR разводить. Ничё, время лечит, думаю за пол-года-год будет SDK "чистый поток сознания", наподобие как китайцы перелопатили SPL-говнокод на "регистры" для STM32. Если нет, то сам займусь. Под железным подходом имел ввиду - не использовать HAL, OS; только хедеры регистров и их бит. Ну может ещё что-то типа SPL допускается. Не более! Никаких абстракций, только имена регистров и их биты! Ну писать только C/C++, Asm , никаких питонов, сишарпов и прочих джав. Вы как человек с опвытом можете сказать, OMAP-L137 отвечает моим хотелкам или там тоже абстракция с пингвинами?

Фото плеера: Принципиальная схема (элементы, помеченные как NC - отсутствуют): Видео в действии (на мерцание экрана не обращать внимание, это из-за фотоаппарата): video1.zip и video2.zip

Есть ли достойная замена STM32F... на частоте от 400 МГц, QFP корпус, внутренняя память не менее 512 кБ с железным подходом программирования?

делал, жмёт лучше (пример: 205 вместо 240 МБ), но на ПК (3 ГГц) скорость воспроизведения декодированного видео в 2 раза медленее. Реализация: "Д. Мастрюков, "Монитор", N1, 1994. Алгоритмы сжатия информации. Адаптивное арифметическое кодирование. Демонстративная программа." Встроенной РАМы STM32F407 не хватит. Изначально планировал Lossy :) Но потом понял, что это слишком легко, часть коэффициентов - особенно сильно ВЧ можно обнулить, те что более НЧ проквантовать, Low оставить без изменений. Да, была фантастика - сжатие в несколько десятков раз, но c артефактами вокруг чётких контуров. У меня есть пара идей как усовершенствовать кодек. Первая идея даже не требует изменения алгоритма декодера. Вторая - с пересмотром алгоритмов обоих. Интернет. Без шуток... 0) http://compression.ru/ 1) описание JPEG, JPEG2000 - трудностей с поиском не должно возникнуть 2) Хабр: https://habrahabr.ru/post/168517/ https://habrahabr.ru/post/169615/ и https://habrahabr.ru/post/142242/ https://habrahabr.ru/post/142492/ и https://github.com/VadimKirilchuk/jawelet/w...velet-Transform https://github.com/VadimKirilchuk/jawelet/w...velet-Transform 3) всякие научные статьи учёных деятелей (индусских в основном), чьи перлы просочились через интернет 4) github.com , pudn.com - исходные тексты кодеров Хаффмана, RLE, арифметик-кодера. Много нерабочего говнокода!!! Надо проверять на правильность работы и фильтровать! 5) Ну и конечно, сам Бог велел: https://hightech.in.ua/content/art-c-cpp-co...ler-for-windows или http://pmg.org.ru/gamedev/djgpp.htm - на выбор. 6) Ну и без этого не достичь большой скорости декодирования: http://infocenter.arm.com/help/index.jsp http://www.keil.com/support/man/docs/armasm/ или хотя-бы для начала: https://www.compel.ru/lib/ne/2012/6/3-bogat...yadre-cortex-m4 7) И смотреть чё делается в критических местах: ASM-листинги компилируемой программы

Тут беда была не из-за прагм. Прагмы как раз работали. И компилятор свежий (версии тоже писал выше). Скачал ARM Compiler V6. Попробую его к Кейлу прикрутить (если будет клянчить лицензию - тогда fail)

Здравствуйте! :) Решил поделиться с общественностью своими наработками в области сжатия видео без потери качества. :yeah: Разработан битэкзактный 4,5 ступенчатый Lossless Bitexact кодек видео под названием "PackMan" rev.0. Кодек соперничает с MSU и Lagarith, исходники открыты и доступны для платформ: - ПК (ДОС, все Винды) - ARM Cortex-M4 (STM32F407), только декодер Конвейер кодера: Декодер - обратим. Подробное описание здесь: http://vrtp.ru/index.php?act=categories&am...mp;article=3713 Про nanoPlayer здесь: http://vrtp.ru/index.php?showtopic=29688&st=90 и здесь: http://vrtp.ru/index.php?act=categories&am...mp;article=3712 Макет плеера: Релиз будет скоро спаян, печатные платы есть: Принципиальная схема плеера: http://vrtp.ru/index.php?act=Attach&ty...t&id=769410 Исходники кодера и декодера + билды под форточки, ДОС, скрипт, тестовый образец: PackMan_Codec.zip Исходники декодера для STM32F407, вывод оптимизирован, параллельно играет FLAC с asm-оптимизацией: nanoPlay_PackMan.zip Кодек зарелижен, оттестирован. Битэкзактный на уровне 6 бит (специфика железа) Замечания, пожелания, эксперименты и предложения по улучшению сжатия кодера и/или скорости декодера приветствуются!

А по первому пункту вопроса, в ходе копаний стало ясно почему программа не работала с -O3. Не стартовал ЦАП и не происходило прерывание от него, которое синхронизировало внутренний цикл программы. Программа просто зависала и ждала снятия флага по прерыванию. А ЦАП не стартовал из-за некорректной отработки функции инициализации ЦАП+ДМА+Таймер. Заменил обычную память под выделяемые структуры на динамическую. Всё сразу заработало! Вполне возможно, что SPL-ный говнокод приводит к большому потреблению памяти на структуры инициализации и переполнению стека, что при разных оптимизациях вполне возможно. Ну и как проинитил часть железа - сразу осовобожать память. Вот фрагмент кода в котором происходила проблема: static void DAC_DMA_IRQ_Config() { DMA_DeInit(DMA1_Stream5); DMA_InitTypeDef *DMA_InitStructure=malloc(sizeof(DMA_InitTypeDef)); DMA_InitStructure->DMA_Channel =DMA_Channel_7; DMA_InitStructure->DMA_PeripheralBaseAddr=DAC_DHR12R1; DMA_InitStructure->DMA_Memory0BaseAddr =(u32)&AudioBuffer; DMA_InitStructure->DMA_DIR =DMA_DIR_MemoryToPeripheral; DMA_InitStructure->DMA_BufferSize =L<<1; DMA_InitStructure->DMA_PeripheralInc =DMA_PeripheralInc_Disable; DMA_InitStructure->DMA_MemoryInc =DMA_MemoryInc_Enable; DMA_InitStructure->DMA_PeripheralDataSize=DMA_PeripheralDataSize_HalfWord; DMA_InitStructure->DMA_MemoryDataSize =DMA_MemoryDataSize_HalfWord; DMA_InitStructure->DMA_Mode =DMA_Mode_Circular; DMA_InitStructure->DMA_Priority =DMA_Priority_VeryHigh; DMA_InitStructure->DMA_FIFOMode =DMA_FIFOMode_Disable; DMA_InitStructure->DMA_FIFOThreshold =DMA_FIFOThreshold_HalfFull; DMA_InitStructure->DMA_MemoryBurst =DMA_MemoryBurst_Single; DMA_InitStructure->DMA_PeripheralBurst =DMA_PeripheralBurst_Single; DMA_Init(DMA1_Stream5,DMA_InitStructure); free(DMA_InitStructure); DMA_ITConfig(DMA1_Stream5,DMA_IT_HT|DMA_IT_TC,ENABLE); NVIC_InitTypeDef *NVIC_InitStructure=malloc(sizeof(NVIC_InitStructure)); NVIC_InitStructure->NVIC_IRQChannel=DMA1_Stream5_IRQn; NVIC_InitStructure->NVIC_IRQChannelPreemptionPriority=0; NVIC_InitStructure->NVIC_IRQChannelSubPriority=0; NVIC_InitStructure->NVIC_IRQChannelCmd=ENABLE; NVIC_Init(NVIC_InitStructure); free(NVIC_InitStructure); DAC_InitTypeDef *DAC_InitStructure=malloc(sizeof(DAC_InitTypeDef)); DAC_InitStructure->DAC_Trigger =DAC_Trigger_T6_TRGO; DAC_InitStructure->DAC_WaveGeneration=DAC_WaveGeneration_None; DAC_InitStructure->DAC_OutputBuffer =DAC_OutputBuffer_Enable; DAC_Init(DAC_Channel_1,DAC_InitStructure); free(DAC_InitStructure); } Но стоит только выделить под структуры статическую память (а она будет будет взята из секции стека, так как идёт из вызова процедуры), работать при -O3 перестанет. Код работает и со статической памятью, если его вызвать не как функцию, а в main() написать всё что внутри void DAC_DMA_IRQ_Config(). Потому что память на структуры берется уже не из секции стека, а из секции DATA, которая больше. К сожалению говнокод, который в SPL приводит к таким вот неприятным вещам ... Проблема решена. :)

Старый добрый ДОС мне много счастья подарил :) С сектором да, разобрался - 512 байт и не меняется. Скачал SDFormatter, форматнул карточку им, произошло чудо - медленные карты теперь идут без заиканий. Теперь вопрос: какой смысл использовать DMA для карт памяти через SDIO при использовании FatFs ? Допустим надо считать порцию с файла. Вызывается чтение секторов, но ведь пока DMA не передаст все данные - прийдётся ждать! И сделать ничего не могу дальше, пока файл не считан. Оперативы - сколько в штатном STM32F407, так что спроецировать файловую систему в память не смогу (хотя в другом проекте такое успешно делал, но там памяти 64 МБ было). Есть ли шанс реорганизовать работу Fatfs без ожидания завершения чтения секторов? Мне кажется, что нет. Остаётся толко низкоуровневое чтение секторов одного за другим (причем блочное). Пробовал переводить карту в High Speed Mode, тактовая частота 36 - 52 МГц ( менял делитель PLL_Q для USB, так как согласно эррате на STM32F407 Bypass там не работает) - выигрыша с медленными картами не дало. Медленная карта - без обозначения класса скорости вообще на 2 ГБ. С классом скорости 4 - работает отлично. Я так понял, что разгон тактовой для карты памяти не имеет смысл, когда читаешь 1-секторный блок, так как задержки перед чтением у карты могут быть более длинными по времени. Так ли это, как я тут изложил свои думалки?