[gst-devel] Viable strategy?

[Kulecz, Walter (JSC-SK)[WYLE LABORATORIES]]

I'd like some advice about how viable this pipeline layout would be and if I'm missing anything:

pipeline1: vrl2src->tee->queue->myImageProcessingPlugin->xvimagesink
                pipeline2:    \queue->mjpegencode->filesink

Pipeline1 would run continuously from program startup till termination for real-time monitoring and analysis.  Pipeline2 would be started and stopped as needed to record various epochs of interest.

The main reason I ask is, if you add audio to it, you have a Linux video capture application, of which I've yet to find a good one (other than perhaps systems like MythTV which I've not actually used) so if gstreamer would make it this "easy" I have to ask why not one or more already?.


Any issues I need to be aware of starting and stopping pipeline2?  Glitch free operation is pretty important.
The reason for pipeline2 is because I would eventually write an "off-line" application for attempting to handle segments where the real-time tracking failed due to transient lighting changes, etc. that perhaps could be fixed with changes to the analysis parameters.  Pipeline3: filesrc->myImageProcessingPlugin ->xvimagesink.  What we do now is split the video and run it into my version1 image processing application and record to standalone S-VHS or DVD recorders in parallel. For the off-line step my version1 app uses the output of the recorder instead of live video.  This does ok,  but the workflow is tedious.

Any advice as to ximagesink vs. xvimagesink?  I'd like to display the video output within a gtk window, I've found a sample code that sort of works and uses ximagesink.


The long term goal would be to add analog data to the stream captured along with the video.  One obvious possibility would be to abuse the audio subsystems of gstreamer since things like alsasrc with audio/x-raw-int  claim to support sample rates and number of channels from 1-2^31, I'd be happy with a max 16-20 channels at 2000Hz which would only be about 80K bytes/sec aggregate rate for 16-bit data which is a bit lower than "normal" CD quality stereo.