Цитата

tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch0 NOBUF seq=1054 dcount=4453

это отладочное сообщение, напрямую с tw6869 не связано - оно гворит о том что в очереди v4l2 нет свободного буфера для следующего кадра, поэтому готовые кадры не отправляются системе на обработку а используются заново - полученный кадр теряется. Суть в том что даунстрим не успевает возвращать буферы и это может быть связано с чем угодно в плагинах которые следую дальше в конвеере.

1. отключил в в ядре SMP (многопроцессорность) (buildroot-2016.11 процессор IMX6S)
при загрузке выдает galcore: disagrees about version of symbol module_layout
перестает работать вывод видео
Setting pipeline to PAUSED ...
g2d_alloc: alloc memory fail with size 16!
ERROR: Pipeline doesn't want to pause.

2. Имеет ли значение при обработке видео gst сообщение
[WARN] VPU iram is less than needed, some parts don't use iram

3. Нормально ли такое сообщение при загрузке
imx-sdma 20ec000.sdma: no iram assigned, using external mem

1 В buildroot собирается внешний модуль для GPU поэтому после пересборки ядра нужно пересобрать и модуль для GPU

rm -r output/build/kernel-module-imx-gpu*
make

2,3 нормальные сообщения и не влияют на ситуацию.

Вполне возможно у вас перегревается процессор судя по этому

Цитата

Если ошибка появилась, то ребут как правило не помогает.

https://www.starterkit.ru/html/index.php?name=forum&op=view&id=22847&num=1#24695

Основная проблема с которой я столкнулся - низкая производительность IPU если точнее, модуля преобразования цвета. VPU не поддерживает напрямую форматы с которыми работает tw6869 и требуется преобразование формата "на лету". Например у i.mx6 Dual два IPU и там заметно меньше подобных ошибок - они могут параллельно обрабатывать разные видео-потоки.

Спасибо.
1. С температурой завязка какая-то есть но точно не от перегрева, потому-что ошибки могут возникать на холодном 10-20С процессоре сразу (из холодильника ). Температуру ядра контролируем постоянно с внутреннего датчика.
Сама по себе ошибка
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch0 NOBUF seq=1054 dcount=4453
когда возникает в единичных экземплярах - не приводит к фатальным последствиям. Но при каких то условиях работы (опять же может быть при легком прогреве 40-50С)наступает ситуация , когда после некоторого времени работы выдается
последовательность типа
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch1 NOBUF seq=3541 dcount=2
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch5 NOBUF seq=3527 dcount=2
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch6 NOBUF seq=3527 dcount=3
imx-ipuv3 2400000.ipu: ERR:[0x88d23600]-no:0x36e30 "wait_for_comp_timeout" ret:0,line:2963
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch0 NOBUF seq=3539 dcount=3
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch1 NOBUF seq=3541 dcount=3
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch5 NOBUF seq=3527 dcount=3
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch6 NOBUF seq=3527 dcount=4
mxc_ipu mxc_ipu: ERR[0x88d23800,no-0x36e40] wait_res timeout:980ms!
mxc_ipu mxc_ipu: ERR:[0x88d23800] no-0x36e40 can not get res
mxc_ipu mxc_ipu: ERR: [0x88d23800] no-0x36e40,state 5: wait resource timeout
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch0 NOBUF seq=3539 dcount=4
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch1 NOBUF seq=3541 dcount=4
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch5 NOBUF seq=3527 dcount=4
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch6 NOBUF seq=3527 dcount=5
imx-ipuv3 2400000.ipu: ERR: [0x88d23000] no-0x36e60, timeout:1000ms!
imx-ipuv3 2400000.ipu: ERR: no-0x36e60,ipu_queue_task err:-110
mxc_ipu mxc_ipu: ERR: no-0x36e40,ipu_queue_task err:-125
tw6869 0000:01:00.0: tw6869_dma_reset: DMA 0
tw6869 0000:01:00.0: tw6869_dma_reset: DMA 1
tw6869 0000:01:00.0: tw6869_dma_reset: DMA 5
tw6869 0000:01:00.0: tw6869_dma_reset: DMA 6
tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch0 NOBUF seq=3540 dcount=5



Я так понимаю с ключевыми сообщениями mxc-ipu .. и TW dma_reset
После этого ошибки валятся потоком. После ребута как-правило такая ситуация повторяется сразу либо после очень небольшого времени работы, что наводит на мысль о влиянии какого-то определенного температурного режима. Также может заработать после дальнейшего повышения температуры в некотором диапазоне. При этом все остальное работает нормально. Попытки калибровки DDR пока не привели ни к чему.
2. Такая же ситуация с ошибками может возникнуть после нескольких перезапусков скрипта с убиванием потоков в промежутке между запусками. Но в отличие от первой ситуации эта после ребута исправляется. Может быть это какая-то дефрагментация памяти с последующими проблемами при выделении DMA. Вообще при работе потока gst постоянно сильно меняются показатели распределения свободной / буферной памяти считываемых например top в сторону уменьшения свободной до 4-5 мбайт
Замечено что при работе с тремя видеопотоками все работает более стабильно.

3. Настройки памяти DDR применяются только в u-boot ?

Цитата

Я так понимаю с ключевыми сообщениями mxc-ipu .. и TW dma_reset
После этого ошибки валятся потоком.

повторюcь - это ошибки не tw6869, когда валятся потоком

Цитата

tw6869 0000:01:00.0: tw6869_vch_dma_frame_isr: vch0 NOBUF seq=1054 dcount=4453

с неизменным seq=1054 и при этом увеличичвающемся dcount=4453, видно что конвеер остановился - даунстрим вообще перестал возвращать буферы

Цитата

2. Такая же ситуация с ошибками может возникнуть после нескольких перезапусков скрипта с убиванием потоков в промежутке между запусками.

это скорей всего баги в драйверах freescale

Цитата

tw6869 0000:01:00.0: tw6869_dma_reset: DMA 0

Сброс tw6869 dma происходит в данном случае по причине аппаратной нагруженности процессора/памяти.

Цитата

наводит на мысль о влиянии какого-то определенного температурного режима

у вас установлен радиатор ? перегрев можно исключить элементпрно временно посадив радиатор на термопасту

Цитата

Вообще при работе потока gst постоянно сильно меняются показатели распределения свободной / буферной памяти

возможно есть утечки памяти в драйверах VPU - он постонно запрашивает/освобождает память. В целом на работающей и загруженной системе с постоянной записью на носитель уменьшение свобоной памяти - нормальное явление, система полностью использует имеющиеся ресурсы. Для tw6869 утечка памяти нереальна - при старте захвата резервируется определенный лимит

Цитата

3. Настройки памяти DDR применяются только в u-boot ?

да

Добрый день!

1.Имеется такой скрипт для gst.
(video8 - крайний драйвер adv7180 с настройками 1024x768 для adv7181 )

gst-launch-1.0 -e imxv4l2videosrc device=/dev/video8 queue-size=48 fps-n=25 ! queue2 ! imxipuvideotransform \
deinterlace=true ! queue2 ! imxvpuenc_h264 bitrate=2000 ! queue2 ! h264parse ! queue2 ! splitmuxsink \
location=/media/usb0/1/stream6_[1]_%04u.mp4 max-size-time=60000000000 &

При запуске выдает
ERROR: v4l2 capture: VIDIOC_REQBUFS: not enough buffers

Процесс записи при этом таки идет. Что за ошибка ?

2. Имеется ли возможность задавать кол-во кадров/сек обрабатываемых процессором с конкретного канала. Параметр fps-n в imxv4l2videosrc похоже не работает или как-то непонятно работает. Куда этот параметр передается ?
В процессоре вроде как есть регистр IPU_CSIx_SKIP. Он как то может участвовать в процессе прореживания?

3. Нашел упоминание о такой проблеме https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233
Может ли это иметь отношение к проблеме которая упоминалась в предыдущих постах по поводу сваливания записи видео c 4-х каналов.

1)

Цитата

При запуске выдает
ERROR: v4l2 capture: VIDIOC_REQBUFS: not enough buffers

Процесс записи при этом таки идет. Что за ошибка ?

там же написана причина - не хватает буферов. Уменьшите очередь с 48 хотя бы до 24

Цитата

queue-size=48

2)

Цитата

2. Имеется ли возможность задавать кол-во кадров/сек обрабатываемых процессором с конкретного канала. Параметр fps-n в imxv4l2videosrc похоже не работает или как-то непонятно работает.

это должен еще драйвер поддерживать, драйвер tw6869 точно поддерживает

3)

Цитата

Может ли это иметь отношение к проблеме которая упоминалась в предыдущих постах по поводу сваливания записи видео c 4-х каналов.

мало вероятно - насколько помню в свежих ядрах проблема фрагментации не возникала. Попробуйте без деинтерлейсинга

Цитата

deinterlace=true

если с tw6869 его использовали. Нормальный деинтерлейсинг на solo возможен только на одном канале, потому что IPU нужно хранить несколько кадров для детектора движения и это невозможно на одном устройстве VDI и нескольких каналах. На нескольких каналах возможно только отбрасывание пол кадра (одного поля) и интерполяция - mode 2 насколько помню у IPU, грубо говоря 1 поле растягивается на полный кадр.

https://community.nxp.com/docs/DOC-173003

Этот режим помоему по умолчанию в плагинах https://github.com/Freescale/gstreamer-imx. По крайней мере mode 0,1 не будут правильно работать в текущем варианте плагинов потому что там не передается информация о типе буфера INTERLACED_TB/ INTERLACED_BT которая зависит от стандарта видео, т.е. после плагина imxv4l2videosrc она теряется.

Цитата

это должен еще драйвер поддерживать, драйвер tw6869 точно поддерживает

И как это задать для 6869 . fps-n= не влияет. точнее не влияет на размер файла, хотя в проигрывателе показывает выставленный fps

Цитата

не влияет на размер файла, хотя в проигрывателе показывает выставленный fps

скорей всего у вас просто картинка статическая.

Попробуйте процессор Dual с радиатором если нужнен захват с нескольких каналов и бОльшая часть вопросов отпадет.