Viable strategy?

[Kulecz, Walter (JSC-SK)[WYLE INTEG. SCI. & ENG.]]

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.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Fri, 2009-09-04 at 08:47 -0500, Kulecz, Walter wrote:

> 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.

Looks ok. The main problem with such setups is usually that if you link
in the second part mid-stream you won't get a newsegment event and
timestamps starting at a non-zero value, which often causes problem when
saving to a container format. If you're just dumping video frames as
MJPEG, that shouldn't be an issue though.

You might also want to have a look at camerabin from gst-plugins-bad.

> 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.

Both should behave pretty much the same with regard to GstXOverlay.
ximagesink usually requires RGB input and doesn't do scaling, whereas
xvimagesink accepts YUV and does scale. The downside with xvimagesink is
that you can usually only have one at a time (depending on
hardware/drivers), or can't even use it at all on some systems (if the
driver doesn't support it). ximagesink should always work as long as
you're using X11.

Cheers
 -Tim


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel