[gst-devel] decodebin problem (gst 0.8.9; gentoo linux)

[Stefan Bambach]

Hi,

I took the decodebin example code, but want to have another queueing.

I thought of 3 bins.
- bin pipeline
- thread decoding (decodebin)
- thread sink

bin_main = gst_pipeline_new("bin_main");
main_src = gst_element_factory_make("filesrc", "main_src");
g_object_set(G_OBJECT(main_src), "location", filename, NULL);
main_queue = gst_element_factory_make("queue", "main_queue");

bin_decoder = gst_thread_new("bin_decoder");
decoder_dec = gst_element_factory_make("decodebin", "decoder_dec");
g_signal_connect(G_OBJECT(decoder_dec), "new-decoded-pad",
G_CALLBACK(decoder_newpad), NULL);
decoder_queue = gst_element_factory_make("queue", "decoder_queue");

bin_sink = gst_thread_new("bin_sink");
sink_conv = gst_element_factory_make("audioconvert", "sink_conv");
sink_pad = gst_element_get_pad(sink_conv, "sink");
sink_scale = gst_element_factory_make("audioscale", "sink_scale");
sink_out = gst_element_factory_make("alsasink", "sink_out");
g_signal_connect(G_OBJECT(sink_out), "eos",
G_CALLBACK(sink_eos), pma);


I tried many combinations for "gst_bin_add_many" and
"gst_element_link_many" but none worked... Sometimes it won't even start
to play and sometimes the state changed from PAUSED to PLAYING and
direktly back to PAUSED (and I do not change this state!).

Why I want this:
The call to gst_bin_iterate() is too slow! When I want to shutdown my
own thread (which do the iterate() call), I set a variable
"thread_cancel=1" and loop in the thread code with
"while(thread_cancel==0) {...iterate...}". But the iterate() method can
need much time (~2sec) for iterating, and so my thread shutdown needs
this time, too. And setting the state to NULL/READY/PAUSE before
thread_cancel ends in core dumps at "..._get_state".

My app configuration:
- main app
- starts pipeline, and other gst stuff
- my own pthread iterates over elements (gst_bin_iterate())
-> not blocking main app
- other commands from main app (seek, pause, getposition, gettotal)


Can I break the gst_bin_iterate() method ? (states?)

Howto link and add elements for my example ?

What state should be set and when ?

To which element should I send seek, getposition, pause "events" ?


ciao. Stefan

[Ronald S. Bultje]

Hi,

Post by Stefan Bambach
I took the decodebin example code, but want to have another queueing.
I thought of 3 bins.
- bin pipeline
- thread decoding (decodebin)
- thread sink

Mistake 1. This won't work. You cannot have a queue between decodebin
and filesrc. It just doesn't work. In all examples, you will always find
decodebin and filesrc in the same thread, I recommend you continue doing
that.

Post by Stefan Bambach
- main app
- starts pipeline, and other gst stuff
- my own pthread iterates over elements (gst_bin_iterate())
-> not blocking main app

This is *way* worse. You hereby remove all threadsafety, for as far as
it exists, by manually threading one pipeline. Do not ever do that. :).
You can make the main pipeline a thread to get the same effect, and that
may actually work. However, your own pthread iterating a pipeline will
not work, it will cause random thread failures.

Post by Stefan Bambach
Can I break the gst_bin_iterate() method ? (states?)

No. 2 seconds is too much, but implies a pipeline that can be optimized
(scheduling-wise). Are all your bins/threads separate entities? Or does
one bin own the others? What's the exact setup of your pipeline?

Post by Stefan Bambach
What state should be set and when ?

READY when nothing goes on, PAUSED for pause and PLAYING to play.

Post by Stefan Bambach
To which element should I send seek, getposition, pause "events" ?

To the (audio)sinks. This is explained in more detail in the application
development manual on our website. Pause events are not events, so you
just set a state on the all-containing pipeline.

Ronald

[Stefan Bambach]

Hi Ronald,

Post by Ronald S. Bultje
Mistake 1. This won't work. You cannot have a queue between decodebin
and filesrc. It just doesn't work. In all examples, you will always find
decodebin and filesrc in the same thread, I recommend you continue doing
that.

Post by Stefan Bambach
- main app
- starts pipeline, and other gst stuff
- my own pthread iterates over elements (gst_bin_iterate())
-> not blocking main app

This is *way* worse. You hereby remove all threadsafety, for as far as
it exists, by manually threading one pipeline. Do not ever do that. :).
You can make the main pipeline a thread to get the same effect, and that
may actually work. However, your own pthread iterating a pipeline will
not work, it will cause random thread failures.

Ok.

1. I will use "gst_thread_new" instead of "gst_pipeline_new"
2. and ... link decodebin to this thread

Do I need to iterate this new main thread ?

Post by Ronald S. Bultje

Post by Stefan Bambach
Can I break the gst_bin_iterate() method ? (states?)

No. 2 seconds is too much, but implies a pipeline that can be optimized
(scheduling-wise). Are all your bins/threads separate entities? Or does
one bin own the others? What's the exact setup of your pipeline?

main pipeline was the master, linked all elements together and added the
threads to the pipeline. I think this is wrong !

FUTURE plans:
gst_bin_add_many(GST_BIN(bin_sink), sink_queue, sink_conv, sink_scale, sink_out, NULL);
gst_element_link_many(sink_queue, sink_conv, sink_scale, sink_out, NULL);

gst_bin_add_many(GST_BIN(bin_main), main_src, decoderbin, NULL);
gst_element_link_many(main_src, decoderbin, NULL);

gst_element_set_state(bin_sink, GST_STATE_PAUSED);
gst_element_set_state(bin_main, GST_STATE_PLAYING);

"new_decoded_pad" callback will add "sink" to "main" later.

Right ?

Post by Ronald S. Bultje

Post by Stefan Bambach
To which element should I send seek, getposition, pause "events" ?

To the (audio)sinks. This is explained in more detail in the application
development manual on our website. Pause events are not events, so you
just set a state on the all-containing pipeline.

Ok. So "seek" + "getposition" calls use "sink" element. So that's right... :-)
And "pause" state use main thread. Fine.


ciao. Stefan

[Ronald S. Bultje]

Hi,

Post by Stefan Bambach
Do I need to iterate this new main thread ?

No. It'll do that by itself.

Post by Stefan Bambach
gst_bin_add_many(GST_BIN(bin_sink), sink_queue, sink_conv, sink_scale, sink_out, NULL);
gst_element_link_many(sink_queue, sink_conv, sink_scale, sink_out, NULL);
gst_bin_add_many(GST_BIN(bin_main), main_src, decoderbin, NULL);
gst_element_link_many(main_src, decoderbin, NULL);
gst_element_set_state(bin_sink, GST_STATE_PAUSED);
gst_element_set_state(bin_main, GST_STATE_PLAYING);
"new_decoded_pad" callback will add "sink" to "main" later.
Right ?

Yes, that should be fine.

Cheers,
Ronald