[mantech 42]

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

Обычного восьимбитного

Такой и у меня где-то был, нужно SPI..

[repstosw 18]

Удалось устранить один неприятный баг, связанный с кодированием в H264-видео на V3s.  На некоторых разрешениях появлялись артефакты в виде мешанины розово-синих пикселей в левом верхнем углу кадра, которые нарушали гармоничность картины.

Проблема была зафиксирована на следующих размерах кадра:

    FRAMESIZE_QQVGA,    // 160x120
    FRAMESIZE_CIF,      // 400x296
    FRAMESIZE_HVGA,     // 480x320

В то время, когда на других  разрешениях артефакты не появляются:

    FRAMESIZE_QCIF,     // 176x144
    FRAMESIZE_240X240,  // 240x240
    FRAMESIZE_QVGA,     // 320x240
    FRAMESIZE_VGA,      // 640x480

Проблема оказалась в недостаточном размере на некоторые выделенные буфера: в итоге одна компонента налезала на другую компоненту (я это предположил, и предположение подтвердилось).  Точно неизвестно, сколько нужно, пока я просто увеличил размеры буферов в 2 раза:

h264enc *h264enc_new(const struct h264enc_params *p)
{

 //.........

	/* allocate reference picture memory */
	unsigned int luma_size = ALIGN(c->mb_width * 16, 32) * ALIGN(c->mb_height * 16, 32);
	unsigned int chroma_size = ALIGN(c->mb_width * 16, 32) * ALIGN(c->mb_height * 8, 32);

luma_size  *=2; //добавил
chroma_size*=2;

 //.........
}

Глюк очень неприятный, убил на поиск его причины 2 дня.  С моим фиксом проблема уходит, кадр кодируется без артефактов.

Писал на whycan.cn, никто ничего путного там не написал.

 

Похожая проблема возникала здесь:  https://github.com/jemk/cedrus/issues/5

https://www.dropbox.com/sh/1dw7pdff192j4ha/AAC_v1k9uvTDNZdgfZW4t5VQa/cedar.mkv?dl=0

 

Там предложили фикс, исправляющий проблему: https://github.com/mzakharo/gst-plugin-cedar/commit/eb70fe5a31f8516fde96f67a3a5c262bdffca6cd

 

Но это оказалось не моим случаем,  так как у меня V3s (VE ID 0x1681), а данный фикс нужен для C.H.I.P. R8 (VE ID 0x1625). И это мне не помогло.

https://github.com/mzakharo/gst-plugin-cedar/blob/master/src/h264enc.c

Изменено 17 августа, 2022 пользователем repstosw

[repstosw 18]

On 8/15/2022 at 6:15 PM, repstosw said:

Прерывания  возникают лишь только в том случае, если их разрешить на уровне ядра сразу же перед запуском захвата (как об этом было сказано в предыдущем моём посте).

Нашёл причину сего безобразия:  в одной из функций (между инитом и запуском CSI) был запрет прерываний на уровне ядра. Этим и объяснялось, что перед запуском нужно было их разрешить.  Сейчас работает в любом порядке, как и должно быть со "стандартной точки зрения".

[repstosw 18]

Делаю запись h264-потока в реальном времени на SD-карту.

 

Тут aaarrr писал, что задержка перед записью на SD-карту может быть до 250 мс:

 

Как расчитать общее минимальное/максимальное время для буферизации, с учётом всех задержек и времён операций SD-карты?

 

В качестве вводных величин:  задержка перез записью T_p_r_max=250 мс,  класс скорости C=10,  объём данных в байтах (кратен 512) V.

Пока взят буфер на 640 мс.   Объем данных:  до 32 кБ за 1 раз.

Изменено 18 августа, 2022 пользователем repstosw

[Ozelot 7]

22 minutes ago, repstosw said:

Как расчитать общее минимальное/максимальное время для буферизации, с учётом всех задержек и времён операций SD-карты?

Physical Layer Simplified Specification Version 4.10

4.6 Error Conditions

...

It is strongly recommended for hosts to implement more than 500ms timeout value even if the card indicates the 250ms maximum busy length.

 

[mantech 42]

41 минуту назад, repstosw сказал:

Делаю запись h264-потока в реальном времени

Сколько получили скорость записи с учетом разгона до 100-200МГц при чтении?

[repstosw 18]

50 minutes ago, Ozelot said:

It is strongly recommended for hosts to implement more than 500ms timeout value even if the card indicates the 250ms maximum busy length.

Спасибо!

 

31 minutes ago, mantech said:

Сколько получили скорость записи с учетом разгона до 100-200МГц при чтении?

Вот как раз с записью проблема из-за задержки, которая появляется периодически.  А раз так,  то нет смысла разгонять клок хоста, если SD-карта - трэш.

 

Тестирую пока на формате 160x128  25 FPS.   Даже с древней картой всё записывается вовремя.  Её максимальная задержка (определил программно) 176 мс.

Алгоритм универсален - накапливаю сжатые фреймы в буфере,  как только 16 фреймов  (25 FPS * 16 = 640 мс) готово,  скидываю на карту  часть буфера,  размером кратным 512.  Остаток в начало и дописываю до следующего раза.  Число фреймов уменьшаю на 16. При таком  подходе,  запись в файл может занимать до 640 мс,  а в это время новые фреймы поднакопятся.  Буферизация двойная - одна часть буфера записывается на карту,  а вторая часть - заполняется кодером.   И первичная буферизация тоже двойная - одна часть подаётся на кодер,  а вторая заполняется камерой (CSI).

Изменено 18 августа, 2022 пользователем repstosw

[repstosw 18]

Попутно ещё обнаружил, что режимы камеры с относительно высоким разрешением (от 640 x 480 и выше) на 25/30 FPS  требуют  согласования линий MCLK и PCLK. 

Пришлось феритовые втулки накинуть на макароны.  Иначе кадр режется горизонтальными полосками.

На 12.5 FPS и меньше ферит не нужен.

ЕМНИП связано с целостностью сигналов и переотражением (Signal Integrity) и cлабой помехозащищённостью макарон в воздухе (cross-talk).

По Феншую должны быть короткие трассы с волновым сопротивлением 50-60 Ом (как пример: толщина дорожки 0.2 мм и толщина до внутренней плоскости питания-земли 0.12 мм).

Изменено 19 августа, 2022 пользователем repstosw

[mantech 42]

3 часа назад, repstosw сказал:

Пришлось феритовые втулки накинуть на макароны.  Иначе кадр режется горизонтальными полосками.

А не смотрели в сторону MIPI камер? Там дифпары более помехозащищенные.

[repstosw 18]

6 hours ago, mantech said:

А не смотрели в сторону MIPI камер? Там дифпары более помехозащищенные.

Я бы с удовольствием поковырял MIPI-DSI, но у меня нет ни дисплея , ни камеры с таким интерфейсом.

Что-то делать придётся, потому что одновременно запустить камеру по DVP и дисплей по RGB не получится, из-за общности пинов GPIO.

Возможны такие варианты:

1. Дисплей RGB, камера MIPI

2. Дисплей MIPI, камера DVP

3. Дисплей SPI, камера DVP

4. Дисплей SPI, камера MIPI

 

Благодаря DMA и параллельности действий, SPI уже не будет узким бутылочным горлышком.

 

На V3s открывается возможность сделать беспроводной видео-терминал: связка LoRa + модуль на V3s(кодек H264 + аудиокодек).

В качестве LoRa взять мощный модуль на +30dBm : LoRa1278F30

 

Кадр можно взять какой-нибудь QQVGA (160x128) или QCIF (176x144). Ну или QVGA 320x240

Для видео-терминала Судного Дня (когда будет выведен из строя интернет и сотовая связь) сойдёт

Изменено 19 августа, 2022 пользователем repstosw

[repstosw 18]

4 hours ago, repstosw said:

3. Дисплей SPI, камера DVP

4. Дисплей SPI, камера MIPI

Нельзя, потеряется аппаратная возможность конверсии YUV в RGB и скейлер.

 

Сделал замеры касаемо записи на SD-карты. Исходные кадры для видео: 800x592 (размеры кратны 16) , формат YUV420(1,5 байта на точку), длительность записи 10 минут, 25 кадров в секунду.

В непожатом виде оно бы заняло:  800x592x1,5x25x10x60 = 9,9 GB

В пожатом виде (h264) видео вышло размером: 116 MB

Сжатие вышло в 87 раз.

Средняя скорость сжатого потока:  116*1024/600 = ~ 198 кБ/c.

 

У камеры OV2640  FPS плавает +/-1 FPS  при движении объектов (работает встроенный DSP для масштабирования картинки, зума, пре- и пост- процессингов,...).

 

В эксперимете приняли участие 2 SD-карты:  на 2 GB без класса скорости и на 16 GB с 10-м классом скорости.  Буфер взял 1 секунда.  Это накопление 25 фреймов.  Запись на SD-карту идёт блоками кратными 4096  (8 секторов SD-карты).  Максимальный размер буфера - 2 МБ.   Экспериментально выяснено, что такого размера хватает, чтобы эти 25 сжатых фреймов не вышли за предел буфера (пиковое заполнение буфера в эксперименте - 28%).   На обеих картах  записанное пожатое видео содержит все фреймы, без потерь.

 

В итоге,  общее время задержки при записи блоков на SD карту выходят примерно одинакового порядка.

Карта 2 GB (первое число - размер блока записи кратного 4096,  всегда по 25 фреймов(последний фрейм может усекаться, его остаток пойдёт в запись следующего блока) ):

Quote

. . .

286720 bytes
82.7 ms

290816 bytes
85.1 ms

245760 bytes
340.7 ms

245760 bytes
94.0 ms

258048 bytes
77.9 ms

249856 bytes
70.3 ms

253952 bytes
84.3 ms

274432 bytes
87.2 ms

327680 bytes
91.7 ms

335872 bytes
92.1 ms

352256 bytes
103.7 ms

. . .

Tmax = 340.7 ms

Карта 16 GB 10 класс :

Quote

. . .

118784 bytes
26.3 ms

225280 bytes
53.8 ms

253952 bytes
107.1 ms

196608 bytes
48.2 ms

364544 bytes
103.2 ms

364544 bytes
87.2 ms

294912 bytes
68.8 ms

155648 bytes
40.9 ms

147456 bytes
31.0 ms

184320 bytes
44.3 ms

. . .

Tmax = 107.1 ms

 

 

Изменено 19 августа, 2022 пользователем repstosw

[Ozelot 7]

5 hours ago, repstosw said:

Я бы с удовольствием поковырял MIPI-DSI, но у меня нет ни дисплея , ни камеры с таким интерфейсом.

По моему самый доступный вариант - OV5647. MIPI интерфейс. На этом сенсоре масса камер для Raspberry PI.

[aaarrr 69]

6 hours ago, repstosw said:

Дисплей MIPI, камера DVP

У V3s нет MIPI DSI.

 

28 minutes ago, Ozelot said:

По моему самый доступный вариант - OV5647. MIPI интерфейс. На этом сенсоре масса камер для Raspberry PI.

IMX219 во второй версии камеры RPi дает значительно более качественную картинку.

[mantech 42]

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

У V3s нет MIPI DSI.

Однозначно. По ходу с дисплеем будет одновременно только MIPI камера.

7 часов назад, repstosw сказал:

В качестве LoRa взять мощный модуль на +30dBm : LoRa1278F30

Там же скорость очень низкая, разве, что на фото-терминал сподобиться)))

[repstosw 18]

2 hours ago, aaarrr said:

У V3s нет MIPI DSI.

Да, ошибся. Остаётся тогда вариант:

37 minutes ago, mantech said:

По ходу с дисплеем будет одновременно только MIPI камера.

 

 

37 minutes ago, mantech said:

Там же скорость очень низкая, разве, что на фото-терминал сподобиться)))

Тут всё зависит от того какое разрешение и FPS нужны.

Максимальная скорость LoRa : 37,5 кбит/c

А есть ли что-нибудь лучше чем LoRa в плане интерференций и помехозащищённости со скоростью от 96 кбит/c ?  

Игрался несколько лет назад с LoRa, сделал рации с вокодером MELP. Что понравилось - это отсутствие сбоев при передвижении: встроенный FEC и спред-модуляция делают своё дело.

Нужен цифровой модем/трансивер для наземной подвижной радиосвязи. Желательно в виде готового модуля - аля напаять одну плату  поверх другой.

Изменено 19 августа, 2022 пользователем repstosw