[gst-devel] Newbie Q: Connecting Pipelines

rahul at reno.cis.upenn.edu rahul at reno.cis.upenn.edu
Thu Feb 28 14:03:40 CET 2002


(I am not sure if this got through so I am resending. My apologies if this is a repost)

Hi Folks,
I am presently prototyping with gstreamer to use it in an astronomical
data pipeline from a telescope. Its an unusual use, but there is a
continuous flow of data in buffers, and gstreamer offers much pluggable
capability to let researchers prototype data analysis pipelines on their
laptops and then move them to production.

Each such pipeline consists of multiple gstreamer executables, presently
communicating using written files (I will need to use sockets soon, are
there any socket modules in development?). Now, to co-ordinate two
different processes, I need to be able to do something like:
Process A tells Process B:
Hey, I finished writing file 1(buffer1), come pick it up. Then the
input pad in process b will do the read, but not until then..

This means that I need to run each pipeline again for a new data file
coming in.

So ought I to use the normal scheduler and set the pipeline stage to
paused and playing depending upon whether there is input, and restart
the pipeline once eos has been obtained, again starting it paused?

I need to be able to catch external events coming in on another thread,
say using xmlrpc from a python control server, and also to be able to
send a signal up that stream when something finished. Internally, I
could use handoff and eos signals to tickle the other thread. For
finegrained control, do I need gstevents?

Or should I be writing a custom scheduler? Are there other benefits I
get from writing a custom scheduler?

Sorry for all the questions. I have read the docs and know the different
API elemnts out there, but I do nat have a completely clear global
picture of what fits in there. Upto now I have implemented single
process pipelines by playing with the identity plugin to take an
arbitrary void function as an algorithm, and have written an API which
will hide the nitty gritty stuff from the users who are physicists, but
now comes the part of getting different processes to talk, After that I
will want to support the different dataflow idioms supported by
gstreamer, presently its always src-queue-algorithm-sink..but we will
need output buffering and multicast..should be fun!

Rahul





More information about the gstreamer-devel mailing list