[_Евген_ 0]

19 часов назад, _Евген_ сказал:

Знатоки,

кто подскажет почему при попытке прочитать состояние из регистра 0x01C0E000 (VE_BASE+VE_CTRL) в F1C100s, да собственно и любого регистра группы VE_BASE - программа зависает?С доступом к регистрам других блоков (TVE,TVD...) проблем нет! Отладчика нет - что-то считать после этого не знаю как (загружаю через sunxi-fel exec).

Начальная настройка следующая(запуск все в том же проекте F1C100s_projects/projects/tv_in_test/main.c😞

ve_init(){ 
 clk_pll_init(PLL_VE, 99, 8); // 24*99/8 = 297MHz <- copy-past от TVD
 clk_pll_enable(PLL_VE);

 clk_enable(CCU_BUS_CLK_GATE1, 0); // VE bus clock
 clk_enable(CCU_DRAM_CLK_GATE, 0); // DRAM access clock

 intc_disable_irq(IRQ_VE);
 clk_reset_clear(CCU_BUS_SOFT_RST1, 0);

 u32 ctrl=readl(VE_BASE + VE_CTRL); <- тут виснет

Помог код(рабочий) из проекта jpgdec (автор ozelot):

 /* Hardware JPEG Decoding */
    CCU->PLL_VE_CTRL = (1u << 31) | (1 << 24) | (12 << 8); // 312MHz
    while(!(CCU->PLL_VE_CTRL & (1 << 28)));
    CCU->VE_CLK |= (1u << 31);
    CCU->BUS_CLK_GATING1 |= 1;
    CCU->BUS_SOFT_RST1 &= ~1;
    CCU->BUS_SOFT_RST1 |= 1;
    CCU->DRAM_GATING |= 1;
    SYS->CTRL[0] &= 0x80000000;
    SYS->CTRL[0] |= 0x7fffffff;
    SYS->CTRL[1] &= 0xefffffff;
    printf("VE Version 0x%X 0x%X\r\n", VE->VERSION >> 16, VE->CTRL);

По итогу для считывания версии:

// Configure video engine clocks
    clk_pll_init(PLL_VE, 99, 8); // 24*99/8 = 297MHz <- работает и с 312МГц от ozelot
    clk_pll_enable(PLL_VE);

    CCU->VE_CLK |= (1u << 31); // вставлено из jpgdec!TODO: -> clk_ve_config in f1c100s_clock!

    clk_enable(CCU_BUS_CLK_GATE1, 0); // VE bus clock
    clk_enable(CCU_DRAM_CLK_GATE, 0); // DRAM access clock

    clk_reset_set(CCU_BUS_SOFT_RST1, 0);
    clk_reset_clear(CCU_BUS_SOFT_RST1, 0);


    u32 version=readl(VE_BASE + VE_VERSION) >> 16;

 

Изменено Пятница в 05:38 пользователем _Евген_

[_Евген_ 0]

В 17.07.2024 в 21:16, Ozelot сказал:

В F1C есть только jpeg-кодер. Разобраться с ним у меня ушло пару дней. Свои исходники по этой теме выкладывать не буду

Если не исходным кодом, то советом можете подсказать, какие регистры (https://linux-sunxi.org/VE_Register_guide: 0x0xx, 0x1xx, 0xaxx) отвечают за

• задание параметров входного(yuv\nv) кадра: размер, адрес буфера;
• задание параметров сжатия (выходного кадра): адрес буфера
• запуск сжатия JPEG: выбор режима VE на сжатие и запуск(аналог DEC_TRIG в Вашем проекте)

Заранее благодарен за помощь!

Смотрел исходники cedar/cedrus: декодеры на любой цвет и вкус, а кодеры только для h26x ... =(

[sasamy 3]

On 7/20/2024 at 11:16 AM, _Евген_ said:

Смотрел исходники cedar/cedrus: декодеры на любой цвет и вкус, а кодеры только для h26x

я это использовал

https://github.com/milosladni/jepoc

в аттаче мои изменения для майнстримного драйвера Linux относительно этого форка

https://github.com/smaeul/linux/tree/d1/all

он не требует libjpeg но мне кажется вас только запутает - POC легко читается и лёгкий для понимания, но вопросы и подводные камни были

 

linux-d1-all-jpeg-enc.patch

Изменено Суббота в 09:09 пользователем sasamy

[_Евген_ 0]

17 минут назад, sasamy сказал:

я это использовал

https://github.com/milosladni/jepoc

 

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

Теперь все встает на свои места 😃 Меня смущало в коде(повторюсь, что у меня чип F1C без H264):

main.c:

char *outjpeg = "/tmp/poc.jpeg";
...
veavc_launch_encoding(); -> veavc.c:  S(trigger, VE_AVC_TRIGGER); -> ve.h : #define VE_AVC_TRIGGER			0xb18

что данный регистр относится к группе кодека h264(oxbxx)! А раз кодека нет, то и блока регистров такого нет ... думал я =( 

Но судя по комментарию "JPEG/H264 Different Settings" - в F1C без H264 этот блок есть, но работает только в режиме JPEG.

Жаль , что понял я это поздно! Сейчас уже уезжаю на дачу. Пока решил ограничить частоту кадров(надеюсь 64Gb хватит отловить момент, кто у Тещи цветы выкапывает 😃 . Вернусь, набросаю код(без платы) и уже через неделю проверю "теорию".

[repstosw 18]

41 minutes ago, sasamy said:

он не требует libjpeg но мне кажется вас только запутает - POC легко читается и лёгкий для понимания, но вопросы и подводные камни были

Собирать нужно с libjpeg8, а не libjpeg.  Тогда всё собирается очень легко. Оно нужно только для создания/распарсивания хедера + создание таблиц квантования. 

Можно заранее просчитать все нужные хедеры, иначе возможна утечка памяти при циклическом вызове функций.

[sasamy 3]

On 7/20/2024 at 12:40 PM, repstosw said:

Собирать нужно с libjpeg8, а не libjpeg.  Тогда всё собирается очень легко. Оно нужно только для создания/распарсивания хедера + создание таблиц квантования.

я в курсе, для драйвера в ядре всё должно быть своё и естественно вопросы были не о том с какой из библиотек libjpeg собирать POС

On 7/20/2024 at 12:30 PM, _Евген_ said:

повторюсь, что у меня чип F1C без H264

в t113 его тоже нет

[mantech 42]

3 часа назад, _Евген_ сказал:

надеюсь 64Gb хватит отловить момент

Нужно делать детектор изменения в кадре, тогда точно хватит

Изменено Суббота в 13:04 пользователем mantech

[_Евген_ 0]

В 20.07.2024 в 16:01, mantech сказал:

Нужно делать детектор изменения в кадре, тогда точно хватит

 

О, машинное обучение 😉 я не силен в данной теме, но мне кажется одного ядра f1c будет маловато для таких целей.  

Камера у меня 576p. Сохраняю я только яркостный канал(ч.б. фото). Т.к. драйвер sd в данном примере не шибко расторопный,  то и 25 к/с он не успевал сохранять- кадры прореживаются =( 

В итоге, одно событие занимает ~50Мбайт( экспериментальные данные). У нас все же не проходной двор - 1000 срабатываний на неделю должно хватить.

Упустил момент с "размытиями" движений. Здесь о них писали. Я их фиксировал в начале экспериментов. Но так и не понял их причину. А после добавления  всех костылей(прореживания, сохранения ч.б. и т.п.) не проверил, т.к. была статика =( 

 

[mantech 42]

38 минут назад, _Евген_ сказал:

О, машинное обучение

Детектор изменения содержания кадра был придуман давным давно, когда еще никаких нейросетей никто не использовал))

Не путайте с распознаванием образов...

Раньше для подобного еще такой "финт ушами" делал, ставил к пленочной камере объемный охранный датчик, видео писалось при срабатывании его и еще пару минут после, эт такой аппаратный декодер изменения картинки)))))))

38 минут назад, _Евген_ сказал:

то и 25 к/с он не успевал сохранять

При вашей задаче зачем вам такой битрейт? Тут 10к\с вполне хватит, при 576р картинке жпег может и программно жаться наверно, хотя у вас же не кортекс А и НЕОНа нет, так что может и не успеть...

Изменено Понедельник в 06:13 пользователем mantech