Question regarding use of interleaved and deinterleaved elements in processing chain

Hauke Krüger public-hk at ind.rwth-aachen.de
Mon Aug 22 19:15:18 UTC 2016


Hi,

thank you for your response.

On 08/22/2016 08:05 AM, Sebastian Dröge wrote:
> On Sun, 2016-08-21 at 18:45 +0200, Hauke Krüger wrote:
>>   
>>
>> Here is the question: is that really the way it is supposed to work or
>> may I somehow trigger interleaver and deinterleaver
>> to produce source and sink pads before actually switching to PLAYING
>> state? And if that is the way, how may I achieve the
>> generation of the interleaver sink pads? The creation of the processing
>> chain is aways from src to sink which implies that the
>> interleaver must have the sink pads connected first which are not available.
> That's all intended, yes. deinterleave does not know about the number
> of channels before it receives data.
>
> 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?

Thank you and best regards

Hauke




More information about the gstreamer-devel mailing list