подача на вход ffmpeg разжатых фреймов

У «raw фреймов» есть как правило свой конкретный формат. Моя вебка работает. Когда надо было странный сырой bayer пожать в mp4 пришлось немного покостылить.

Разрешаю.

Чего ты прицепился к этой шаред мемори? Обычные пайпы нормально работают:

sleid0r -i flowers.lst -s -S -d 1 -t 1 -g 512x288 -r 25 -o - | \
ffmpeg -f rawvideo -video_size 512x288 -r 25 -pix_fmt rgba -i pipe: -codec:v libvpx -qmin 16 -qmax 16 flowers.webm

подавать потоковое сырое видео через shared memory?

В общую память можно писать, можно из неё читать, но нужны ещё механизмы синхронизации. Обе стороны должны согласовать взаимодействие, чтобы не случилось так, что записывающая сторона испортит кадр, пока его принимает читающая.

Так что подавать можно, но нужен ещё сигнальный канал.

Так что подавать можно, но нужен ещё сигнальный канал

ну это если использовать ffmpeg как исходники и писать код синхронизации... я имел ввиду можно ли через shared memory общаться с ffmpeg через командную строку без каких-то сложностей? походу, это нереально

Обычные пайпы нормально работают

хм, неплохой вариант

Ты себе это как представляешь? В виде магии?

ну флажками в ffmpeg задаем какую-нибудь область под shared memory, и он в эту очередь принимает от внешнего приложения(с каким-то форматом, который тоже задается) сырые фреймы

В принципе, такое возможно, но опять-таки, возникает проблема сигнального канала. При передаче через трубу всё проще — там сигналом является сам факт передачи данных. И невозможно напортачить с очерёдностью чтения и записи.

через пайп возможно передать, например, сырой фрейм 4к видео?

через пайп возможно передать, например, сырой фрейм 4к видео?

Да. Странный вопрос.

Я могу, конечно, посчитать нужную ширину потока и прикинуть производительность трубы/fifo у себя на системе. Но не представляю, зачем тебе числа с моей системы.

прикинуть производительность трубы/fifo

а подскажите куда копнуть чтобы у себя это узнать

я просто считал, что пайп эт так, малопроизводительное что-то... для производительности/cкорости передачи нужно использовать shared memory

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

куда копнуть чтобы у себя это узнать

3840x2160 это 8294400 точек. Цвет может быть 8- или 10-битным, поэтому можно считать, что на каждую точку — 4 байта. Это примерно 31,64 МиБ. Если в видео 60 кадров в секунду, нужна пропускная способность в 1898 МиБ в секунду. Примерно 2000.

Скорость чтения из файла:

pv /dev/zero > /dev/null

Скорость при передаче через трубу:

cat /dev/zero | pv > /dev/null

Скорость при передаче через fifo:

mkfifo testfifo; cat /dev/zero > testfifo & pv testfifo > /dev/null

для производительности/cкорости передачи нужно использовать shared memory

Для прозводительности нужно делать меньше работы. В каждом конкретном случае способы могут быть разными; нужно искать подходящие.

Передача данных через пайп предполагает копирование данных в пространство ядра во время write() и копирование обратно, во время read(). Плюч переключения контекста туда-сюда на каждые 64 килобайта (или сколько там размер буфера). Очевидно, использование общей памяти экономит кучу переключений и уменьшает объём копируемых данных.

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

хм, спасибо

да я, в общем-то, хотел на c++ писать прилагу одну чтобы в итоге сырой фрейм возвращался... вот думал куда бы сделать вывод чтобы посмотреть правильность фреймов...

ffmpeg из коробки читать из shared memory не умеет, насколько мне известно

но умеет читать с вебкамер, а так же умеет читать raw video из файлов

есть у меня поток с веб-камеры(он ведь вроде raw-фреймами является)

не обязательно, многие умеют в MJPEG, а некоторые ещё и в H.264

Для отладки скорость не важна, потому можно тупо const auto im=xcb_image_create_native(co,pn.width,pn.height,XCB_IMAGE_FORMAT_Z_PIXMAP,se->root_depth,0,0,0); xcb_flush(co); пишем в im->data xcb_image_put(co,se->root,gc,im,0,0,0);