Issues with valves
hectorcanto at gmail.com
Wed Mar 16 07:19:38 PDT 2011
Thanks a lot for the answer. I'll take your advise into account.
To follow up the issue I have to say that I have improved my recording by
changing the valves
the moment the pipeline is on pause, these way I don't stop the
initialization and I don't have to
take measures such as unblocking, flushing or whatever. The only problem I
have left it's that some
data is able to pass the valve before the dropping is on. Further the valves
will work properly.
I've been thinking on using the output-selector element - along with a
fakesink as one of the
selections -, but I couldn't make it work, neither findany suitable example
around the web.
About changing elements dynamically, I agree, it would bring new problems
but I may use it on
future improvements of the pipeline. I was able to get it work following the
instructions on this link
Anyway, I have learnt that many of the problems related to the states can be
solved forcing flushing
events but I need to know where - and if- a blockade has happened, so I will
have to research on how
gstreamer messages works.
2011/3/16 4ernov <4ernov at gmail.com>
> 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
> > regulate the record (stop/pause/cut...).
> > The problem is that the pipeline won't pass Prerolling when the valves
> > 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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel