Кошка на именованную трубу вызывает зависание
Я пытаюсь выполнить потоковую передачу с помощью FFMpeg, и я думаю, что наконец-то нашел решение, которое мне нужно для гашения экрана. Это требует записи PNG в именованный канал, а затем FFMpeg читает их как наложение. Однако, у меня, кажется, странная проблема.
#!/bin/bash
mkfifo /tmp/stream_pipe
cat /path/to/transparent/or/splash/screen.png > stream_pipe
echo "done!"
В этом примере, echo "done!" на самом деле никогда не работает.
Итак, я перешел к терминалу и попробовал то же самое, и, безусловно, команда cat зависает бесконечно.
Я не помню, чтобы когда-либо возникали проблемы с привязкой к именованным каналам, и, действительно, я видел много ссылок на именованные каналы, которые используют именно это. Что здесь может пойти не так? Разве cat не должен завершиться после завершения записи файла в канал? Записываемый файл - просто обычный файл PNG, так что это действительно озадачило меня.
Или, может быть, cat пытается закрыть трубу при записи? Это имело бы смысл, почему оно зависало, так как это недопустимый файл, но я бы предположил, что cat будет знать разницу или не будет заботиться.
РЕДАКТИРОВАТЬ: cat $file | echo -n > /tmp/stream_pipe демонстрирует то же поведение
2 ответа
У Вас должно быть что-то читающее из FIFO
Попытка это:
#!/bin/bash
mkfifo /tmp/stream_pipe
cat /path/to/transparent/or/splash/screen.png > stream_pipe &
cat stream_pipe
echo "done!"
необходимо получить содержание файла, распечатанного на экран (то же, как будто Вы делаете cat /path/to/transparent/or/splash/screen.png).
cat $file >/tmp/stream_pipe не работал, но я смог заставить его работать (до некоторой степени) путем присвоения канала дескриптору файла как так:
#!/bin/bash
exec 3<>/tmp/stream_pipe
cat /path/to/file.png >&3
я сказал, что это работает до некоторой степени, потому что выполнение его автономные помехи канал и сценарий, кажется, зависает. Это - то, вследствие того, что каналы в Ubuntu имеют 1M ограничение буфера, как замечено через команду systcl fs.pipe-max-size. К сожалению, настройки это значение через sysctl, кажется, не изменяют его. Однако, пока данные канала используются другим процессом, не должно быть проблемы. Любые записи к полному каналу заблокируются (он похож на подвешивание, но это не), пока данные не используются, в которой точке продолжится запись.