[AleksBak 0]

Здравствуйте!

Вот решил реализовать и проверить проект 'JPEG_MJPEG_VideoDecoding' на STM32H7 (на своей плате с таким процессором (STM32H743x), SDRAM, LCD (800x480) и т.п.).

В проекте от самой ST он должен работать на 'STM32H743-EVAL' и проигрывать MJPEG файл из микро-СД. Есть еще вариант - когда файл размещен в QSPI.

Я же решил сделать попроще пока что и просто взял первые 100 фреймов от проигрываемого MJPEG видео и просто их разместил во внутренней FLASH контроллера благо оно помещается там (около 1.5МБ в итоге заняло это). Однако, каково же было мое удивление, когда ничего нормально и не заработало. После некоторых небольших правок (!) уже началось хоть что-то нормально показывать (под конец видео). Я тут снял видео на веб-камеру как это выглядит вообще:

https://youtu.be/HHL-QLw5Ihk

На видео видно, что происходит "мешанина" первые 4 секунды примерно. А в конце появляется нормальный кадр (100-й фрейм). Т.е. само аппаратное JPEG декодирование происходит правильно. Также, если отладчиком останавливаться в моменты когда декодирование произошло и фрейм отправлен на видеобуффер LCD, то покадрово все четко видно (каждый фрейм) и нет никакой "мешанины". Т.е. неправильная тут работа с видеобуфером для LCD получается. Тогда я, чуть изменив исходный проект, решил применить двойное буферирование для LCD (2 'layer'-а использовал). И переключаться между ними. И опять, к сожалению, неудача (см. видео) и практически все тоже самое. Возможно "не успевает" проц. или все-таки неправильно организовал работу видеобуфера. В нете что-то абсолютно (!) тихо по этому поводу. Как-будто у всех сразу, и заработало, и работает норм. :) Далее, потом, приведу значимые куски кода отсюда. Спасибо.

[AleksBak 0]

В общем, я понял в чем тут дело. Придется - очень много переделать тут. Непонятно только почему не рабочий пример 'ST'('STM')-шники выкладывают в свой репозиторий. Еще, у них там, в одном из видео семплов вирус сидит (судя по рапорту от анитивируса). Всем нормальным людям всего хорошего.

[x893 33]

Делал на H747. Пример рабочий под Keil. После переделки работал под STM32 IDE

[mantech 33]

6 часов назад, AleksBak сказал:

Еще, у них там, в одном из видео семплов вирус сидит

Как вы себе это представляете? Вирус в массиве картинок)))

[x893 33]

5 hours ago, mantech said:

Как вы себе это представляете? Вирус в массиве картинок

Раз антивирус сказал, что вирус - значит вирус.

[AleksBak 0]

5 часов назад, mantech сказал:

Как вы себе это представляете? Вирус в массиве картинок)))

Win10-овский антивирус упорно указывает на одно и то же видео там. А FFmpeg, кажется, распарсил на фреймы, но их кол-во меньше чем должно быть. Что есть, то и сообщаю. По идее в любой файл с данными можно каким-либо способом внедрить вирус особо не повредив данные. Сам вот в 'wav'-файлы пихал "секретные" данные и помечал так их лет 12 назад. :) На самом деле - это по-моему не важно совсем.

8 часов назад, x893 сказал:

Делал на H747. Пример рабочий под Keil. После переделки работал под STM32 IDE

А можно посмотреть как-то? На почту или как тут? А то у меня что-то DMA2D совсем сдурел от неправильных моих настроек и показывает мягко говоря нескромные результаты пересылки (через DWT их померял) декодированного фрейма в буфер LCD. Вообще-то весь код у меня пока мало отличается от СТМ-овского и значит у них там так все "работало". Спасибо. 

[mantech 33]

1 час назад, x893 сказал:

Раз антивирус сказал, что вирус - значит вирус.

Вот поэтому уже 6 лет не пользуюсь никакими антивирусами, чтобы подобную чушь от них не лицезреть)))

[jcxz 182]

2 часа назад, AleksBak сказал:

Win10-овский антивирус упорно указывает на одно и то же видео там.

Это он в том видео обнаружил и обличает пропаганду путинского режима!  

[AleksBak 0]

10 часов назад, AleksBak сказал:

А можно посмотреть как-то?

Я каа-то слишком обнаглел наверно.

А вот так вот правильно я переключаю "слои" (HAL-овские получается):

#define LCD_FRAME_SIZE_ROUNDED				0x180000		/* 1.5MB */

#define LCD_FRAME_BUFFER_0					(SDRAM_START_ADDR + 0x01000000)
#define LCD_FRAME_BUFFER_1					(SDRAM_START_ADDR + 0x01000000 + LCD_FRAME_SIZE_ROUNDED)

/* Change the buffer address to the next one */
if (frameStartAddress == LCD_FRAME_BUFFER_1)
{
    frameStartAddress = LCD_FRAME_BUFFER_0;

    /* now on the LCD active layer is 'LTDC_LAYER_2'(=1) -> LCD_FRAME_BUFFER_1 */
    __HAL_LTDC_LAYER_DISABLE(&hltdc, LTDC_LAYER_1);
    __HAL_LTDC_LAYER_ENABLE(&hltdc, LTDC_LAYER_2);
}
else
{
    frameStartAddress = LCD_FRAME_BUFFER_1;

    /* now on the LCD active layer is 'LTDC_LAYER_1'(=0) -> LCD_FRAME_BUFFER_0 */
    __HAL_LTDC_LAYER_DISABLE(&hltdc, LTDC_LAYER_2);
    __HAL_LTDC_LAYER_ENABLE(&hltdc, LTDC_LAYER_1);
}
__HAL_LTDC_RELOAD_CONFIG(&hltdc);

Они (слои) вроде переключаются, но как-то не так что-ли. Тут 2 слоя - значит двойное видеобуферирование для LCD. Так получается? Или не так все надо делать.

Сейчас, по самым оптимистическим подсчетам, для ARGB8888 на 800x480 получится максимум 2-3 кадра в сек.

Для SDRAM тут у меня:

SDRAM common clock = 2 HCLK clock cecles

И при частоте тактирования FMC master-а в 180MHz получается, что на 90MHz SDRAM работает? Или на 60MHz все-таки?

Что-то 'callback' по завершению передачи например у DMA2D и не хочет возникать. Хотя прерывания разрешил/настроил указатель на него.

Здесь, изначально, стратегия и алгоритм работы кода - неправильный да? Если по уму все делать, то надо в прерываниях от LTDC master-а организовывать больше работу.

А тут (в примере от СТМ) абсолютно так не делается. Как же оно у них работало то?

[AleksBak 0]

.

Изменено 9 марта, 2022 пользователем AleksBak

[mantech 33]

1 час назад, AleksBak сказал:

А вот что, что Win10 антивирь наговорил про него/обругал как смог

Отключите эту дурь и не мучайтесь, да и комп будет на 10-15% работать быстрее...

6 лет назад для себя сделал так, комп для работы, только ЛВС, без выхода в инет и обязательно отключенный автозапуск с флешек и подобного, и ноут для инета... Не ходить в инете черт те куда и не запускать непонятные экзешники и все правила...

Изменено 9 марта, 2022 пользователем mantech

[AleksBak 0]

2 минуты назад, mantech сказал:

Отключите эту дурь

Хорошо. Возможно попробую как-нибудь. Спасибо Вам большое.

Если посмотреть SDRAM (да это "средневековье", но все-таки) у меня так настроена:

	/* hsdram1.Init */
	hsdram1.Init.SDBank = FMC_SDRAM_BANK2;
	hsdram1.Init.ColumnBitsNumber = FMC_SDRAM_COLUMN_BITS_NUM_9;
	hsdram1.Init.RowBitsNumber = FMC_SDRAM_ROW_BITS_NUM_13;
	hsdram1.Init.MemoryDataWidth = FMC_SDRAM_MEM_BUS_WIDTH_16;
	hsdram1.Init.InternalBankNumber = FMC_SDRAM_INTERN_BANKS_NUM_4;
	hsdram1.Init.CASLatency = FMC_SDRAM_CAS_LATENCY_2;
	hsdram1.Init.WriteProtection = FMC_SDRAM_WRITE_PROTECTION_DISABLE;
	hsdram1.Init.SDClockPeriod = FMC_SDRAM_CLOCK_PERIOD_2;
	hsdram1.Init.ReadBurst = FMC_SDRAM_RBURST_ENABLE;
	hsdram1.Init.ReadPipeDelay = FMC_SDRAM_RPIPE_DELAY_0;

	/* SdramTiming */
	SdramTiming.LoadToActiveDelay = 2;
	SdramTiming.ExitSelfRefreshDelay = 6;
	SdramTiming.SelfRefreshTime = 4;
	SdramTiming.RowCycleDelay = 6;
	SdramTiming.WriteRecoveryTime = 2;
	SdramTiming.RPDelay = 2;
	SdramTiming.RCDDelay = 2;

	if (HAL_SDRAM_Init(&hsdram1, &SdramTiming) != HAL_OK)
	{
		Error_Handler();
	}

Как-то не очень оптимальные настройки да? Тут она (SDRAM) на 16 бит как видим. FMC как писал на 180МГц, а потом:

2 часа назад, AleksBak сказал:

SDRAM common clock = 2 HCLK clock cycles

Можно тут еще больше "разогнать" эту SDRAM? Или уже практически максимум? Подскажите кто в теме - пожалуйста. Буду очень благодарен. Спасибо.