A question about multiple players

[Ian Davidson]

This is a guess.

I suspect that step 8 (setting the state to NULL) may take some time to 
complete.  Does it raise a signal when the state changes? If you set the 
state to NULL and then blindly go ahead and unref things you are hoping 
that the state change will have completed quickly.  So, sometimes, you 
will 'get away with it' and sometimes you will crash.

Ian


On 06/09/19 23:45, Olivier Crête wrote:
> Hi,
>
> You don't need a separate gmainloop per pipeline, you can use the same one for all of them. They'll all use the default main context. So you do steps 3 & 6 only once.
>
> Olivier
>
> On September 6, 2019 4:32:41 p.m. EDT, Ben Rush <ben at ben-rush.net> wrote:
>> I have a need to put multiple video windows in a single application.
>> This
>> means multiple pipelines. For example, the RTSP URL is different for
>> each
>> player, and so I get a new pipeline for each invocation
>> of gst_parse_launch.
>>
>> I can share code, but in general: what is the best way to do this? The
>> way
>> I'm doing this now (for EACH player I've instantiated in the SAME app):
>>
>> 1) gst_parse_launch, get back the pipeline,
>> 2) gst_pipeline_get_bus, to create a bus on this pipeline.
>> 3) g_main_loop_new(NULL, FALSE) to create a new loop (this is where my
>> main
>> question is at)
>> 4) gst_bus_add_watch to create an add watch on this pipeline,
>> 5) gst_element_set_state to set my pipeline state to GST_STATE_PLAYING
>> 6) g_main_loop_run on the loop returned from #3
>> 7) Then I play until a stop is issued....
>> 8) gst_element_set_state(pipeline, GST_STATE_NULL)
>> 9) unref the bus,
>> 10) unref the pipeline
>> 11) unref the loop
>>
>> I ask about this order, and the fact I'm creating a new loop without an
>> independent context because I'm getting some random crashes in my app
>> hosting multiple players, and it appears to be during tear down. In
>> general, is this pattern acceptable, or have I committed a sin
>> somewhere?