Постоянна ли скорость потока между между программами.

Размер пайпа в линуксе 4КБ, как только пишущий процесс превысит этот размер, его write() будет заблокирован. И наоборот, когда пайп пустой, читающий процесс будет заблокирован. Если у вас есть какие-то узкие места в читающем или передающем процессах, то будет наблюдаться задержки.

Есть еще вариант, что в сеть после send() данные попадают не сразу, или есть какие-то дополнительные задержки в сетевом оборудовании.

А вообще без буферизации будет туго ;) Хотя бы пару кадров было бы неплохо буферизировать. Это же все таки сеть...

man 7 pipe говорит, что с since Linux 2.6.11, the pipe capacity is 65536 bytes. Так, на заметку.

Спасибо! Не знал, что его увеличили!

1. посмотри скорость исходящего трафика (udp)
2. посмотри загрузку процессора
3. попробуй заменить "./prog1 -output -" на "./prog1 -output file1" и затем «cat file1 | ./prog2 ...»

очень сомневаюсь что именно пайп тормозит, а не баги в твоих программах

просто нужно на получающей стороне делать кэш на несколько секунд. Либо юзать UDP для стриминга сразу из ПО, которое снимает данные с камеры. Задержки могут быть из-за чего угодно, в т.ч. из-за сети/TCP, и из-за кривой prog2

На приемном конце наблюдаю джиттер (иногда спонтанно большие задержки).

Это плохой показатель, сохраняйте время отправки каждого пакета.

Как пишете и читаете пайп, системные вызовы или FILE? Синхронно, асинхронно, в отдельном потоке? По какому условию отправляете пакет?

Лучше всего код покажите.

PS. Собственно у меня есть в точности такая же связка: genarete-packets | send-packets только передается звук, а не видео (то есть, объем данных видимо меньше).

В send-packets использую буферизацию в несколько десятков миллисекунд. Джиттер при отправлении пакетов на порядок меньше длительности пакета.

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

Засунь между ними в конвейер pv -L <битрейт>. Другие опции pv помогут посмотреть, как меняется скорость передачи данных в конвейере.

может ли так быть, что передача stdin->stdout между программами идет с непостоянной скоростью?

Конечно может, а Вы откуда взяли, что есть какая-то гарантия? Вам уже правильно сказали, что во-первых пайп буферизируется и если читающий процесс читает слишком быстро, то он будет периодически останавливаться. Во-вторых, у Вас же, я думаю, не RT ядро, никто не гарантирует, что процессы вообще будут работать равномерно. В-третьих, никто не гарантирует, что пакеты будут идти с одинаковой скоростью, т.к. на других системах см. пункт 2.

Передаю видео, БЕЗ буферизации надо: пришел кадр - показываем.

Хреновая идея, но можно попробовать пропускать кадры которые не пришли вовремя.

Согласен. Я бы ко всему этому добавил еще перенос с пайпов и файлов на сокеты

без сорцов prog1,prog2 сложно диагностировать..

но вполне вероятно что prog1 может использовать буферизованный вывод (юзает FILE*) и забывает про fflush.

передавать видео через обычный пайп нехорошая затея, разве что на поотлаживать. Хочешь более-менее реального времени - или крути свой (несложный) велик с разделяемой памятью или бери готовый gstreamer.

В настоящий момент я выяснил что задержка возникает в prog1. Сейчас узнаю - это из-за записи в stdout или просто данные неравномерно от кодека приходят...

Добавил: оказалось кодер выплёвывает данные таким страннейшим образом... Убрал вообще вывод куда-либо а проблема осталась. Печально, самая сложная часть в плане исправлений и оказалась прблемной.

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

Так что... Детективное расследование кто портит малину продолжается.