Issues with valves

[Hector Canto]

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've also try to change sinks on-the-move (Playing) but it didn't work as I expected.

Any tips?

Hector C.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Alexey Chernov]

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.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Hector Canto]

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
from GST: http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-block.txt

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.

Cheers
Hector

2011/3/16 4ernov <[hidden email]>

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.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Alexey Chernov]

On Wednesday 16 March 2011 17:19:08 Hector Canto wrote:

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

Yes, I've also been experimenting with valves and in some cases it's the right
way to reduce the code size without any complex blocking logic.

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

I think use of fakesink in some kind of relay is quite common practise, I did
the exact this way. The problem seems to be in the fact that output-selector
as also tee don't generate anything on activating or deactivating outputs so
the user should take care of it by himself.

> 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
> from GST:
> http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-block
> .txt

I think it's some kind of base guideline to write such pipelines, I used it
intensively, too. In terms of video capture to file I have a couple more links,
maybe you find it interesting for your projects:

http://bugzilla.gnome.org/show_bug.cgi?id=561224 - report about the resettime
plugin which can help to keep proper segment stuff on turning some branch on
and off (it can be used to create correct seekable file with correct timestamps)

http://gstreamer-devel.966125.n4.nabble.com/Handling-EOS-in-a-branched-
pipeline-td2965563.html - about sending EOS event at the end of recording. I
should add that one should pay extra attention to prevent any data after EOS
events as some elements (theoraenc, for instance) don't expect it and they
simply crash. And it seems that there's no rule saying they won't.

Anyway, there's always a working method: to stop pipeline, change it and start
with changed structure again. In many cases it helps.

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

It's very interesting. Many times I wanted to try flush events to solve
blockade and starvations but never could use it right. Could you describe the
way you use flush events? Do you send flush-begin and flush-end in a row or wait
some time?

>
> Cheers
> Hector
>
>
> 2011/3/16 4ernov <[hidden email]>
>
> > 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.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[wally_bkg]

---------- Forwarded message ----------
From: 4ernov <[hidden email]>
To: [hidden email]
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);

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nathanael D. Noblet]

On 03/16/2011 04:10 PM, wally bkg wrote:

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

Search the archives of November 24, 2010 for an email with subject:

"[SOLVED] Dynamically Recording From a Live Stream & EOS Handling"... it
has the answer for this problem for you. If after reading that and using
the source attached in that email it still doesn't work I may be able to
help... But I am in no way an expert.
--
Nathanael d. Noblet
t 403.875.4613
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel