Question regarding use of interleaved and deinterleaved elements in processing chain

[Sebastian Dröge]

On Tue, 2016-08-23 at 15:23 +0200, Hauke Krüger wrote:
> 
> On 08/23/2016 10:24 AM, Sebastian Dröge wrote:
> > 
> > On Mon, 2016-08-22 at 21:15 +0200, Hauke Krüger wrote:
> > > 
> > > > 
> > > > You'll have to connect to the "pad-added" signal of it, and from there
> > > > link the pads further. See also the first part in chapter 8 of the
> > > > manual (application developer's manual).
> > > Yes, that worked out as you said. However, it seems to be impossible to
> > > set the pipeline into the
> > > PLAYING state afterwards: Whenever trying to set the state of the
> > > pipeline to PLAYING, the pipeline element
> > > is blocked since it expects an ASYNC state change which unfortunately
> > > never really is solved.
> > > 
> > > How is that part supposed to work? Is there any way to somehow observe
> > > the ASYNC state change by catching
> > > a message in the main loop?
> > That all depends on your actual pipeline. How does it look like?
> > 
> > Most commonly this means that you have one or more sinks in your
> > pipeline that never receive any buffer and are async=true (which is the
> > default). You should check where data flows in your pipeline and why it
> > doesn't reach all sinks. Also check if you get any error messages.
> > 
> > 
> 
> My pipeline is rather simple:
> 
> alsasrc -> capsfilter -> deinterleaver -<channel0>-> interleaver -> 
> capsfilter -> alsasink
> -<channel1>->
> 
> alsasrc and alsasink are configured to allow 2 channels, no rate 
> conversion must be
> done.
> 
> I tracked the problem by means of my debugger: once all pads are 
> connected, I can see
> the deinterleaver working: It has 2 output sources and I can see the 
> code in which the deinterleaver
> loops over all sources here: deinterleave.c, line 896 (current master 
> release of gstreamer 1.0 project).
> I see that the function "gst_pad_push" is used within the loop to pass 
> the single buffers to the connected
> interleaver sink.
> 
> When debugging into this function call of "gst_pad_push" for the first 
> single buffer to be transferred, I end
> up in "gstcollectpad.c" since the interleaver seems to use this 
> collector block. The buffers seem to arrive
> in  function "gst_collect_pads_chain" to wait for all buffers before 
> interleaving takes place.
> 
> Debugger shows that the first buffer is accepted but the program flow 
> ends in a non-returning wait condition
> in line 2257 in "gstcollectpad.c",
> 
> /* wait to be collected, this must happen from another thread triggered
>       * by the _chain function of another pad. We release the lock so we
>       * can get stopped or flushed as well. We can however not get EOS
>       * because we still hold the STREAM_LOCK.
>       */
>      GST_COLLECT_PADS_STREAM_UNLOCK (pads);
>      GST_COLLECT_PADS_EVT_WAIT (pads, cookie); <---- HERE
>      GST_COLLECT_PADS_STREAM_LOCK (pads);
> 
> It seems that the wait will persist locked until the chain function is 
> called from within the context of another thread.
> 
> This behavior would make sense if the deinterleaver would decompose the 
> single buffers to be
> processed within different thread contexts. This, however, seems not to 
> be the case.

That's exactly the problem: you have to put a queue element after each
deinterleave pad for adding this new thread.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160823/2ae56c1a/attachment.sig>