Decoding h264 streamed through a named pipe

[Benjamin Rapaport]

I am trying to decode a raw h264 video stream via a named pipe (created via `mkfifo -m 0660 in_pipe`), and output decoded RGB images to another named pipe. My command looks something like:

gst-launch-1.0 filesrc location=in_pipe ! h264parse ! vpudec ! glupload ! glcolorconvert ! gldownload ! video/x-raw,format=RGB ! filesink location=out_pipe.

I need the input pipe to remain open indefinitely, as I will continue to write video frame bytes to the pipe as they become available, and want them decoded as soon as possible. However, it appears that as soon as gstreamer completes the pipeline on the first input written to in_pipe, gstreamer gets an EOS signal, shuts down, and closes the input and output pipes.

I have tried to do this with fdsrc as well, but see similar behavior.

Any ideas what I can do to make something like this work?

br

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Arjen Veenhuizen]

On the OS level, the pipe will be closed when the sending process is
finished. This will inevitably result in an EOF on the named pipe, causing
your second pipeline to go into EOS and stop.

I once had the same problem and ended up writing a small named pipe proxy
script in python which basically kept the second fifo open if the first one
closed. After the first one closed, the named pipe proxy script would
immediately restart reading on the named pipe again.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Benjamin Rapaport]

Neither the process writing to the input pipe nor the process reading from the output pipe are finishing. They both write/read as long as the pipe is open on the other end - the other end being gstreamer. For instance, using named pipes for input and output via this same routine with ffmpeg works, and ffmpeg does not complete until I close the pipes. It waits for more data and continues to decode.

On Tue, Sep 11, 2018 at 7:48 AM Arjen Veenhuizen <[hidden email]> wrote:

On the OS level, the pipe will be closed when the sending process is
finished. This will inevitably result in an EOF on the named pipe, causing
your second pipeline to go into EOS and stop.

I once had the same problem and ended up writing a small named pipe proxy
script in python which basically kept the second fifo open if the first one
closed. After the first one closed, the named pipe proxy script would
immediately restart reading on the named pipe again.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel