Dynamic pipelines & gst_element_sync_state_with_parent() usage

[Stirling Westrup]

Hmm. I still don't know why caps weren't being automatically
propagated down the video processing pipe, but I removed the pad probe
and instead did a gst_pad_query_caps on that pad, and I got the fixed
caps I was looking for.


On Tue, Jan 8, 2013 at 3:28 PM, Stirling Westrup <swestrup at gmail.com> wrote:
> I'm currently struggling with a very similar issue. I have a dynamic
> pipeline that is built during the pipeline transition from READY to
> PAUSED state. During the transition decodebin produces output pad
> depending on the input streams it finds. I have a callback that
> attaches a video output bin to any video pads that appear, and an
> audio output bin to any audio pads.
>
> The trouble I have is that I need to pick up the video caps from the
> end of the video processing bin, as it can have any number of video
> rotating or resizing elements, depending on what the user put on the
> command line.
>
> Simply put, a probe I put on the video bin's output pad never sees any
> fixed caps before the pipeline completes its transition to the PAUSED
> state. However, when I tested this with a non-dynamic pipeline, it
> worked.
>
> So, how do I ensure that adding a bin to the pipeline during a state
> transition will have it get fully synced with the rest of the
> pipeline?  I've tried requesting the video bin to sync with parent
> both before and after linking it to the decoder, and have had no luck
> at all.
>
> I'm beginning to think I'll need to capture a caps event from before
> I've added the video processing bin, and then manually feed it through
> the bin once I've put it in the pipeline.
>
>
>
>
> On Tue, Jan 8, 2013 at 4:55 AM, Paddy <pat.blanchon at gmail.com> wrote:
>> Hi All,
>>
>> I'm using gstreamer-0.10.
>>
>> I'm debugging some strange behaviour in my audio/video recording pipeline
>> which saves to files in 30sec chunks & I've come across something that I
>> need clearing up.
>>
>> When I create the new mux/filesink to record to I follow the accepted wisdom
>> of:
>> 1) create bin
>> 2) add bin to parent
>> 3) sync bin with parent using gst_element_sync_state_with_parent()
>> 4) link bin to parent
>> 5) unblock blocked pads
>>
>> The manual for  gst_element_sync_state_with_parent()
>> <http://gstreamer.freedesktop.org/data/doc/gstreamer/0.10.36/gstreamer/html/GstElement.html#gst-element-sync-state-with-parent>
>> states:
>> "Returns : TRUE, if the element's state could be synced to the parent's
>> state. MT safe."
>>
>> however looking at the code, it returns TRUE if the call to
>> gst_element_set_state() does not return GST_STATE_CHANGE_FAILURE; AFAIK
>> should the state change be asynchronous then there is no guarantee that the
>> element is synced when TRUE is returned.
>>
>> So my question is:
>> Do I need to wait for the state change to complete before linking (by
>> creating a gst_element_really_sync_state_with_parent() function, say) ?
>> or
>> Is there some unwritten rule deep down in the code that makes the above a
>> non-issue, & the child is synced with the parent before the link ?
>>
>> Cheers,
>>
>> Paddy
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Dynamic-pipelines-gst-element-sync-state-with-parent-usage-tp4657809.html
>> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> --
> Stirling Westrup
> Programmer, Entrepreneur.
> https://www.linkedin.com/e/fpf/77228
> http://www.linkedin.com/in/swestrup
> http://technaut.livejournal.com
> http://sourceforge.net/users/stirlingwestrup



-- 
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup