[gstreamer-bugs] [Bug 500447] New: EOS and EOF across a named pipe is .... difficult

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=500447

  GStreamer | gstreamer (core) | Ver: HEAD CVS
           Summary: EOS and EOF across a named pipe is .... difficult
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: peter at maersk-moller.net
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Hi.

Im trying to make gstreamer to work with an external application through named
pipes. Named pipes are like files in many aspects, but opening a named pipe
reading is blocked until it is also opened somhow for writing. And likewise
when openeing for writing.

This is how I set it up using CVS from yesterday (in this example 'cat' is the
external application) 

$ ls -l >myfile1
$ mkfifo raw_pipe encoded_pipe
$ cat <raw_pipe >encoded_pipe &
$ gst-launch -v filesrc location=myfile1 \
    ! queue \
    ! filesink location=raw_pipe \
    filesrc location=encoded_pipe \
    ! queue \
    ! filesink  location=myfile2
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock

What you can observer is that a) not all data is copied from myfile1 to myfile2
and b) gst-launch never exits.

This is what I conclude :

When the first filesrc detects EOF, it sends an EOS downstream but thats all.
The first filsink receives the EOS event and probably flushes its buffers, but
keeps its fd to raw_pipe open so far.

The 'cat' process reading from raw_pipe never gets an EOF because Gstreamer
keeps its fd on raw_pipe open. Subsequently 'cat' never closes its fd to
encoded_pipe and since it is opened in a BLOCKING rather than a NONBLOCKING
mode, 'cat' probably even keeps some data back in its internal buffers.

Now since cat never closes encoded_pipe for writing, Gstreamer never receives
an EOF on it second filesrc reading encoded_pipe. Subsequently Gstreamer can
not close its open fd's and it can not terminate. 

You can't exactly say it is a bug in filesink, but it limits the usability of
Gstreamer together with named pipes.

If the event handling of EOS in gstfilesink.c line xxx is changed from
----------------------
  case GST_EVENT_EOS:
        if (fflush (filesink->file))
          goto flush_failed;
        break;
----------------------
to
----------------------
  case GST_EVENT_EOS:
        if (fflush (filesink->file))
          goto flush_failed;
        if (!filesink->seekable) gst_file_sink_close_file (filesink);
      break;
----------------------
then non seekable files (like named pipes) are closed upon EOS and subsequently
signalling EOF to external sources reading the named pipes.

Closing a fd is the only way to signal EOF across a named pipe.

Kind regards

Peter Maersk-Moller


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=500447.