Still looking for a solution

[Gary Thomas]

I'm struggling to find a solution (in gstreamer 0.10) for my problem.
What I need to do is take a streaming video (from a camera) which can't
explicitly be shared and share it amongst 3 different applications.
These applications come and go but the camera stream is always present.
What I'd like to be able to do is start up one (or more) of these
applications at any arbitrary point in time, run them for a while
then close down.  I need to be able to repeat this process on demand
for as long as the video stream is active.

Sounds simple enough and I thought something like the attached
diagram would work.  The big box is a single gstreamer application
which splits the video stream into three bits, possibly manipulating
the data along the way.  These stream "copies" are then available
via some transport mechanism to be used by the various applications
(the transports are represented by the ellipses at the right edge).

The physical transport is only part of this problem.  I've had the
best luck with shmsink/shmsrc.  The real problem past that is how
to keep the data packetized the same way as if there was no transport
involved.  For this I've tried rtpvrawpay/rtpvrawdepay and gdppay/gdpdepay.
As seen by other email threads this week, the RTP packing seems to
have issues - programs that happily run in a native pipeline just don't
any more with no obvious reason.  The GDP packing seems to work much
better, but it has no tolerance for reusing connections (only a
single source->application connection will ever work).  Looking at
the code/design, this is obvious as this is just how the GDP tools
are built - the internal packets only pass CAPS information when
needed and if the connection is broken (which is invisible to the
gdppay provider) then the gdpdepay element will be lost when first
connecting.

Since I'm only interested in the actual video data passing to
the applications, I even tried no packetizing at all, i.e. no
gdppay/gdpdepay or rtpvrawpay/rtpvrawdepay.  Sadly, this breaks
things downstream in the applications as they expect to see video
packets, not arbitrary chunks of data.  I think if I could solve
this problem, perhaps by inserting some element which only delivers
exactly one video frame at a time, my model would work.

Am I barking up the wrong tree here?  Will this application model
ever work?  What can I do to get there?

Thanks for any ideas/help with this vexing issue

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gstreamer.png
Type: image/png
Size: 20608 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130308/d53f6212/attachment-0001.png>