Issues with valves

[wally bkg]

> ---------- Forwarded message ----------
> From: 4ernov <4ernov at gmail.com>
> To: gstreamer-devel at lists.freedesktop.org
> Date: Wed, 16 Mar 2011 14:38:15 +0300
> Subject: Re: Issues with valves
> Hello, Hector,
>
> > Hi everybody,
> >
> > I'm new in GStreamer but trying to move faster through it.
> >
> > I'm recording video with basic pipelines and now I'm trying to use valves
> to
> > regulate the record (stop/pause/cut...).
> > The problem is that the pipeline won't pass Prerolling when the valves
> are
> > initialised dropping.
>
> I'd say using valves is not the best way for your case as it's very
> easy to drop some useful data (e.g. events or buffers) with them.
> Dynamic changes in pipeline is better but they also have a bunch of
> problems you need to solve.
>
> >
> > I've also try to change sinks on-the-move (Playing) but it didn't work as
> I
> > expected.
> >
> > Any tips?
>
> If I get it right what you're trying to do is to change the pipeline
> dynamically. Well, it's not the easiest part of work with GStreamer, I
> should say. There're several posts in the list about it here and
> there, but to sum everything гз here're the problems one need to solve
> to change the pipeline dynamically in proper way:
> 1. Branch synchronization if some of the sinks is in sync (e.g.
> streaming video to ximagesink and capturing it to file
> simultaneously): it's necessary to use queue for each branch.
> 2. To reconnect elements on the fly one need to look after the
> remaining pipeline. It's done by either blocking pads of changing
> branch or using valves (so dangerous).
> Besides that you should take into account that with every problem the
> pipeline is stalled hard without any messages even on DEBUG log level.
> It make the debugging difficult very much. Also these instructions
> work quite stable only for PLAYING state and have many issues for
> others. For example, if you block pads in PAUSED state, it will stall
> the pipeline forever as no buffers are streamed through the pipeline
> in this state. And finally, remember that elements are not guaranteed
> to be reusable i.e. if you create pipeline from scratch, set it to
> PLAYING state, then set it to READY and again to PLAYING, it's not
> guaranteed that the behavior is the same as if you create a new one
> instead of setting the existing pipeline to READY and then to PLAYING.
>
> So, there's some hope that it would be changed in the future releases,
> but now it's not easy at all to change the pipeline dynamically.
>
> Hope it helps


I'm trying to do similar, but my app is using three pipelines
(oversimplified):

v4l2src ! appsink   (data source)

(There is some image processing in between)

appsrc ! encoder ! muxer ! filesink  (data recorder)
appsrc ! xvimagesink  (live data monitor)


The xvimagesink always runs, my problem is I need to send EOS to the
filesink pipeline, stop it, change file location and restart at the next
recording epoch.

Is this not  a viable approach?

My current stumbling block is sending the EOS.  It seems to work well if I
just start and stop everything all at once by closing the xvimagesink window
but my encoded files only play back on Linux, not Windows presumably because
they are not getting the EOS before exiting.

Also I'm a bit fuzzy on what exactly the GST_FORMAT_TIME from the appsrc
examples is doing as opposed to other or default options
g_object_set(G_OBJECT appsrc, "format", GST_FORMAT_TIME, NULL);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110316/e35738b1/attachment.htm>