Trying to understand how Pipe works in this situation
I'm using ffmpeg to pull in an input rtmp stream and then push that out to a destination. In case the main input fails, I would like my ffmpeg process to switch to a backup input.
Unfortunately, ffmpeg CLI does not seem to have this ability built in. So I came across a solution which uses pipes to manage this. The input rtmp is pushed to a pipe file first. Code:
PIPE_FILE= /path/to/pipe/file Code:
ffmpeg -re -i $PIPE_FILE -c:v libx264 -preset veryfast -r 25 -g 50 -f flv $RTMP_ENDPOINT Also, if it is an actual file, will it's size keep increasing as the stream continues. Also, what are mkfifo and the exec 7 commands actually doing? Thanks |
For starters, see Named pipe in Wikipedia. Here is an introduction to named pipes that may be easier to understand.
The <> is a redirection operator present in Bash, meaning both input and output get redirected to/from $PIPE_FILE on file descriptor 7. As for exec used for redirections, see this chapter in the Advanced Bash-Scripting Guide. I should add that using redirections in this way is rarely needed in Bash, because it has process substitution. But when writing a POSIX-conform shell script they often come very handy. |
Quote:
|
Quote:
|
Quote:
And does it exist once the source starts "inputting" into the pipe, or only after the "sink" starts reading out of the pipe? |
Quote:
Quote:
|
Quote:
|
You mean "newer"? No, this is not possible. The pipe is not a black hole, no data get lost.
|
you can imagine that pipe as a "real" pipe (or tube). From one side you put data into it and on the other side you will take that out.
the pipe [may] exists without any data pushed/pulled. fifo means First In First Out, so the order of the data cannot be changed inside the pipe. https://www.softprayog.in/programmin...fifos-in-linux |
I've been trying to picture this and I think I know now how pipes originated. They're just a small wrinkle on normal disk I/O.
The kernel maintains huge buffers whenever it has enough free memory for them. When it has to read from a disk, it reads much more than was requested and stores the rest in a buffer. That way it can satisfy subsequent read commands from the process without having to do any further mechanical disk access. And similarly output from a process goes into a buffer and gets written to disk at a convenient time, when the cpu is less busy. A sync function synchronises the disk with the buffers when required. When a process wants to do I/O, the kernel assigns a file descriptor (just a number) and links it to the appropriate internal buffer. Now to create a pipe, all the kernel has to do is assign two file descriptors to such a buffer, one in read mode and one in write mode. That way the buffer needn't be linked to the disk surface in any way. Instead one program simply reads out of the buffer what the other program has written into it. |
All times are GMT -5. The time now is 10:12 AM. |