Event "state change" handling from element to element?
Locked
Event "state change" handling from element to element?
 
|
Hello, can someone give or point me to some info, how event handling is working internally between two element? E.g. end of pipeline contains of a queue and an appsink. … -> queue -> appsink Appsink does not want to go to PLAYING state, other elements in this pipeline do it without problems. In result the pipeline itself does not go into PLAYING state. How are states exchanged between elements? How are the neighbor elements connected?
Is it all going via some common code inside gstreamer?
So queue is sending state to Gstreamer code and Gstreamer code gives state event to appsink? Or is the queue element directly connected to the appsink element? So queue is sending state directly to appsink element? Is there some debugging possibility to see why state event is not running through till the end? I have a bushandler which logs state changes for each element and I see my queue is going to PLAYING, but appsink remains in READY, even when pending state is PLAYING. cameraBusFunc State changed: MyAppSink, oldState=NULL, newState=READY, pendingState=PLAYING cameraBusFunc State changed: MyQueue, oldState=NULL, newState=READY, pendingState=PLAYING cameraBusFunc State changed: MyQueue, oldState=READY, newState=PAUSED, pendingState=PLAYING cameraBusFunc State changed: MyQueue, oldState=PAUSED, newState=PLAYING, pendingState=VOID_PENDING After this nothing more happens… Any idea or hint? Many thanks! Best regards, Marie _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Hi, There is a lot of information here : https://gstreamer.freedesktop.org/documentation/design/index.html Most of them are a must read if you are new to GStreamer. There's a page about Event handling. Cheers, Philippe. Le Vendredi 19 octobre 2018 17h51, "Maurer, Marie" <[hidden email]> a écrit : Hello,
can someone give or point me to some info, how event handling is working internally between two element?
E.g. end of pipeline contains of a queue and an appsink.
… -> queue -> appsink
Appsink does not want to go to PLAYING state, other elements in this pipeline do it without problems.
In result the pipeline itself does not go into PLAYING state.
How are states exchanged between elements? How are the neighbor elements connected?
Is it all going via some common code inside gstreamer?
So queue is sending state to Gstreamer code and Gstreamer code gives state event to appsink?
Or is the queue element directly connected to the appsink element?
So queue is sending state directly to appsink element?
Is there some debugging possibility to see why state event is not running through till the end?
I have a bushandler which logs state changes for each element and I see my queue is going to PLAYING,
but appsink remains in READY, even when pending state is PLAYING.
cameraBusFunc State changed: MyAppSink, oldState=NULL, newState=READY, pendingState=PLAYING
cameraBusFunc State changed: MyQueue, oldState=NULL, newState=READY, pendingState=PLAYING
cameraBusFunc State changed: MyQueue, oldState=READY, newState=PAUSED, pendingState=PLAYING
cameraBusFunc State changed: MyQueue, oldState=PAUSED, newState=PLAYING, pendingState=VOID_PENDING
After this nothing more happens…
Any idea or hint?
Many thanks!
Best regards,
Marie
gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Event "state change" handling from element to element?
|
|
In reply to this post by Maurer, Marie
Hi,
Can you post more details about your pipeline? You gotta remember that sink elements like AppSink will go from READY to PAUSED only when they receive a buffer pushed by the source element. For example, consider a simple pipeline like this: fakesrc ! queue ! fakesink. This is how the states are changed for each element when you set the state of pipeline to PLAYING: 1. All elements, from the most downstream element (fakesink) to the most upstream element (fakesrc), go from NULL to READY state: fakesink: NULL -> READY queue: NULL -> READY fakesrc: NULL -> READY pipeline: NULL -> READY 2. Now all elements *EXCEPT* the sink elements (fakesink in this case), will go from READY to PAUSED. The sink element will stay in the READY state for now (while the other elements returned GST_STATE_CHANGE_SUCCESS when changing from READY to PAUSED, the sink will return GST_STATE_CHANGE_ASYNC, because it will change its state later when it receives a buffer). queue: creates its streaming thread queue: READY -> PAUSED fakesrc: creates its streaming thread fakesrc: READY -> PAUSED queue: enter its streaming thread fakesrc: enter its streaming thread 3. Now fakesrc will start pushing buffers. Yes, in the PAUSED state. The PAUSED state and PLAYING state are the "same thing" for non-sink elements. When the sink, that still is the READY state, receives the first buffer, it will block its sink pad and proceed to (finally) change its state to PAUSED. fakesrc: push buffers fakesink: receives first buffer then blocks fakesink: READY -> PAUSED pipeline: READY -> PAUSED 4. Now the pipeline is ready to go to the PLAYING state. The pipeline will choose a clock from the most upstream element available and it each element will change its state. fakesink: unblocks its sink pad fakesink: PAUSED -> PLAYING queue: PAUSED -> PLAYING fakesrc: PAUSED -> PLAYING pipeline: PAUSED -> PLAYING You can read more about states here: https://gstreamer.freedesktop.org/documentation/design/states.html There's also another case to consider when the source element is a live element. In this case, the sink element will go from READY to PAUSED then to PLAYING only when the pipeline is already in the PLAYING state, because it's only in this state that live source can produce data (while non-live sources can produce data in the PAUSED state). You can read more about live sources here: https://gstreamer.freedesktop.org/documentation/design/live-source.html -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
| Free forum by Nabble | Edit this page |