Reduce the scope of set_state?

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

Reduce the scope of set_state?

Lautaro Woites
Hi all,
          I Have a pipeline with multiple inputs to a videmomixer:

filesrc location=test.mp4 ! decodebin2 ! queue2 ! videomixer name=mix
filesrc location=test2.mp4 ! decodebin2 ! queue2 ! mix.
....
filesrc location=testN.mp4 ! decodebin2 ! queue2 ! mix.

Then I encode and mux the stream:

mix. !  x264enc ! matroskamux ! filesink location=test.mkv


Later in a python program I change the filesrc and decoder on run-time.
The probem occurs when I change the state of one filesrc/decoder from NULL to PLAYING
I've seen the logs and the state changes  are propagated to all the elements in the pipeline.

This is a problem for me because sometimes I've had a filesrc/decoder on NULL state and
I dont want to set it to PLAYING state when  I've changed the state of another filesrc/decoder.
(This happens for example when I want to change two inputs at the same time)

I've tried using a bin with the filesrc and decoder, but the state propagates the same way.

How can I limit the scope of a state change?


Thanks.

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

Re: Reduce the scope of set_state?

Adrian Pardini
On 6 November 2013 12:31, Lautaro Woites <[hidden email]> wrote:

> I've seen the logs and the state changes  are propagated to all the elements
> in the pipeline.
>
> This is a problem for me because sometimes I've had a filesrc/decoder on
> NULL state and
> I dont want to set it to PLAYING state when  I've changed the state of
> another filesrc/decoder.
> (This happens for example when I want to change two inputs at the same time)
>
> I've tried using a bin with the filesrc and decoder, but the state
> propagates the same way.
>
> How can I limit the scope of a state change?


Hi Lautaro,

normally you would block the pads, unlink the element and then put it
on another pipeline (or just remove it from the main until it's needed
again) so it is not affected by the state changes on the main pipeline
of your program. Something like what is shown here:
http://groakat.wordpress.com/2012/12/05/gstreamer-stream-h264-webcam-data-to-series-of-files/
(but that use case is a bit different). Keep in mind that some
elements don't really like to be reused so perhaps removing and adding
a fresh one is the way to go. Let me know if you need a hand.

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

Re: Reduce the scope of set_state?

Sebastian Dröge-3
On Mi, 2013-11-06 at 13:56 -0200, Adrian Pardini wrote:

> On 6 November 2013 12:31, Lautaro Woites <[hidden email]> wrote:
> > I've seen the logs and the state changes  are propagated to all the elements
> > in the pipeline.
> >
> > This is a problem for me because sometimes I've had a filesrc/decoder on
> > NULL state and
> > I dont want to set it to PLAYING state when  I've changed the state of
> > another filesrc/decoder.
> > (This happens for example when I want to change two inputs at the same time)
> >
> > I've tried using a bin with the filesrc and decoder, but the state
> > propagates the same way.
> >
> > How can I limit the scope of a state change?
>
>
> Hi Lautaro,
>
> normally you would block the pads, unlink the element and then put it
> on another pipeline (or just remove it from the main until it's needed
> again) so it is not affected by the state changes on the main pipeline
> of your program. Something like what is shown here:
> http://groakat.wordpress.com/2012/12/05/gstreamer-stream-h264-webcam-data-to-series-of-files/
> (but that use case is a bit different). Keep in mind that some
> elements don't really like to be reused so perhaps removing and adding
> a fresh one is the way to go. Let me know if you need a hand.
Or you could use gst_element_set_locked_state(). Then the element's
state is not changed by the parent bin.

--
Sebastian Dröge <[hidden email]>
Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source

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

signature.asc (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reduce the scope of set_state?

Adrian Pardini
On 7 November 2013 05:06, Sebastian Dröge <[hidden email]> wrote:
> Or you could use gst_element_set_locked_state(). Then the element's
> state is not changed by the parent bin.

Aw, I totally missed that. Thanks Sebastian.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reduce the scope of set_state?

Lautaro Woites
In reply to this post by Adrian Pardini
Hi Adrian,
      I think your example is different from mine because you are not changing the state of  the src elements.
  I' ve followed this to achieve my pipeline =>http://gstreamer-devel.966125.n4.nabble.com/change-quot-location-quot-of-filesrc-element-without-breaking-tcpserversink-connection-tt4661248.html#a4661273.
And it works fine! But my program has crashed from time to time. (When i've tried to change two src at aprox the same time, apparently one state change
affects the others, so I need a mutex I Suppose)

Sebastian, I've Tried using gst_element_set_locked_state, but seeing the logs I am still viewing that my the elements post messages like:

child 'img_src_bkg_src' changed state to 3(PAUSED) successfully

I will keep trying.

Thanks a lot for your answers!




normally you would block the pads, unlink the element and then put it
on another pipeline (or just remove it from the main until it's needed
again) so it is not affected by the state changes on the main pipeline
of your program. Something like what is shown here:
http://groakat.wordpress.com/2012/12/05/gstreamer-stream-h264-webcam-data-to-series-of-files/
(but that use case is a bit different). Keep in mind that some
elements don't really like to be reused so perhaps removing and adding
a fresh one is the way to go. Let me know if you need a hand.

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


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