Нужно наверное использовать raspivid , выводить видео в stdout и как-то организвать пипу для энкодера. Но за отсутвием опыта с Gstteamer (нужен ли он?) обращаюсь за советом. Нужно захватывать эти видеокадры и каждый перекодировать в png на лету. Если работать с камерой как с /dev/video0 то получается через pngenc , но с /dev/video0 засада он не понимает параметров, которые понимает raspivid интерфейс

Насколько велика частота кадров и разрешение? А то я что-то не припомню в камнях аппаратного PNG кодека

да это 4-ядерник 1.2ГГц и софтом то сможет влегкую, даже без GPU. 75 кадров 800*480/ Ну собсно png это от балды, так- то надо простой YUV в памяти для мат обработки поиметь. Если уж так туго то можно 320*240 хотя бы. Реально не хочется софтом делать своим, стример это явно умеет, только не пойму как пипу нарисовать

На счет линукса и гпу не подскажу, но одноядерный МХ6, 1024х768х32 в png упаковывал несколько кадров в сек, без линукса, с кэшем и оптимизацией. 4х ядерник конечно покруче, но...

У меня есть опыт с gstreamer.
stdout это для текстового вывода. У gstreamer есть видео sink.
Что говорит команда gst-inspect | grep sink ?
gst-inspect может быть в разных написаниях (часто номер версии добавляют в конце). Нажмите после ввода два раза табуляцию -- он покажет варианты.

png для видео использовать нерационально. Используют DIVX, XVID, MPEG2, h263, h264, h265. Вам следует хорошо подумать о формате. с png вы будете иметь проблемы. Оно для статических картин хорошо, а не для видео.

Добавлю, что JPEG (MJPEG) тоже успешно и часто используется.

Те что я перечислил как раз основаны на том, чтобы избежать использовать JPEG для всех кадров. Там JPEG используется один раз на много кадров, а последующие кадры только разницаа между новым и JPEG плюс ошибки, что гораздо экономнее чем одни JPEG посылать. Использование одних JPEG кадров это непрофессионально сегодня. Оно много информации требует. Но конечно если очень хочется, то можно и вообще не сжимать.
i-frames это и есть JPEG:
https://en.wikipedia.org/wiki/Video_compres...n_picture_types

Насчет «непрофессионально сегодня» — это не так. Для широкого класса задач MJPEG намного удобнее, чем использование стандартов кодирования, предусматривающих межкадровое сжатие. За м/к сжатие приходится щедро платить сложностью кодера-декодера, задержками, дороговизной. Поэтому MJPEG вполне себе используется на самом профессиональном уровне.
Непрофессионально использовать MJPEG там, где более эффективным кодекам нет альтернативы, а так бывает не всегда.

Ну если вы делаете систему без передачи видео по линиям связи и без записи на носитель, то разумется пофиг. Если вам не важно сколько каналов видео вы сможете передать по линии связи и сколько часов записи поместится на ваш диск.
"Для широкого класса задач MJPEG намного удобнее"
Я бы сказал понятнее и с меньшими усилиями. Что могу сказать? Не надо лениться, а делать над собой усилие и двигаться вперед. Я работал в последнее время над видео в некоторых системах. Обеспечивать в них MJPEG даже в голову никому не приходило.

Тем более, что в процессорах уже стоит кодек на отдельном DSP. iMX53, iMX6x например. Там они сделаны с Gstreamer интерфейсом. Пользоваться легко и без дополнительных знаний о методах несомненно очень непростого кодирования.

Насчет дорого.
Вот здесь бесплатно, но возможно придется поработать:
https://opencores.org/projects