How to operate "valve" element

classic Classic list List threaded Threaded
3 messages Options
bb
Reply | Threaded
Open this post in threaded view
|

How to operate "valve" element

bb
Greetings,

I find the 'valve' element confusing in spite its seemingly simple
interface.
I got a simple filesrc -> valve -> appsink pipeline and am trying to use the
valve to control the flow. Initially the valve is open and all is good. When
the "drop" property is set to TRUE the new samples stop arriving as
expected. Now if the "drop" is set to FALSE again I don't get any new
samples; i find it counterintuitive.

In an attempt to get this working (e.g. getting samples flowing each time
the valve is open, regardless of the previous state) I was setting the
appsink state to GST_STATE_PAUSED whenever valve "drop" is TRUE and to
GST_STATE_PLAYING when valve "drop" is FALSE. That worked better as appsink
is getting new samples whenever the valve is open, however the samples
received on the valve reopen are those that were meant to to be dropped
while the valve was closed as if they were buffered up and are now being
pushed to appsink as nothing happened. Is that how it's meant to work? I was
expecting the samples dropped during valve "drop" == true to be lost
forever, never reaching the appsink.

Searching on the web i noticed people suggest setting the sink's "async"
property to FALSE but that didn't do anything for me.

Clearly in this simple pipeline I could be controlling the samples within
appsink "new-sample" callback but i'm intending to use valve elsewhere and
would like to know how to operate it correctly - as it is looks like i'm
missing something.




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to operate "valve" element

Olivier Crête-3
Hi,

The filesrc element will read from the file as fast as possible and it
is only being slowed down by the application's speed reading from the
appsink. If you set drop=true on the valve, then there is nothing
stopping the filesrc from reading the whole file and promptly dropping
the results. If you want to have something like this, you need to fake
a live source with something like "filesrc ! parsebin ! identity
sync=true ! valve ! appsink". You use parsebin (or the specific element
to parser your file) to put appropriate timestamps on the buffers, then
"identity sync=1" to block the buffers until the timestamp is reached.

Olivier

On Mon, 2020-02-24 at 16:50 -0600, bb wrote:

> Greetings,
>
> I find the 'valve' element confusing in spite its seemingly simple
> interface.
> I got a simple filesrc -> valve -> appsink pipeline and am trying to use the
> valve to control the flow. Initially the valve is open and all is good. When
> the "drop" property is set to TRUE the new samples stop arriving as
> expected. Now if the "drop" is set to FALSE again I don't get any new
> samples; i find it counterintuitive.
>
> In an attempt to get this working (e.g. getting samples flowing each time
> the valve is open, regardless of the previous state) I was setting the
> appsink state to GST_STATE_PAUSED whenever valve "drop" is TRUE and to
> GST_STATE_PLAYING when valve "drop" is FALSE. That worked better as appsink
> is getting new samples whenever the valve is open, however the samples
> received on the valve reopen are those that were meant to to be dropped
> while the valve was closed as if they were buffered up and are now being
> pushed to appsink as nothing happened. Is that how it's meant to work? I was
> expecting the samples dropped during valve "drop" == true to be lost
> forever, never reaching the appsink.
>
> Searching on the web i noticed people suggest setting the sink's "async"
> property to FALSE but that didn't do anything for me.
>
> Clearly in this simple pipeline I could be controlling the samples within
> appsink "new-sample" callback but i'm intending to use valve elsewhere and
> would like to know how to operate it correctly - as it is looks like i'm
> missing something.
>
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
--
Olivier Crête
[hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
bb
Reply | Threaded
Open this post in threaded view
|

Re: How to operate "valve" element

bb
> The filesrc element will read from the file as fast as possible and it
> is only being slowed down by the application's speed reading from the
> appsink. If you set drop=true on the valve, then there is nothing
> stopping the filesrc from reading the whole file and promptly dropping
> the results. If you want to have something like this, you need to fake
> a live source with something like "filesrc ! parsebin ! identity
> sync=true ! valve ! appsink". You use parsebin (or the specific element
> to parser your file) to put appropriate timestamps on the buffers, then
> "identity sync=1" to block the buffers until the timestamp is reached.


oh, i see; my mental model how it all works was too simplistic;

ended up using:
    filesrc ! waveparse ! identity sync=true ! valve ! appsink

as was having problems with creating parsebin src pad - am guessing that
needs to be done in a callback;
the above pipeline appears to be doing what i wanted;

thanks for the explanation

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