[gst-devel] blocked glib idle/timeout

[Dan Taylor]

Arnout Vandecappelle wrote:
> On Wednesday 25 March 2009 01:18:10 Dan Taylor wrote:
>   
>> My simplest test pipeline has dvbsrc, mpegtsdemux (tried flutsdemux,
>> too), and
>> two filesinks (location is /dev/null).  There's a new pad callback to
>> connect
>> the demuxer to the filesinks, which works when the specified program
>> number
>> is in the stream.
>>
>> When I use a program number that exists in the stream, the functions
>> called with g_idle_add_full() and g_timeout_add_full(), and the shorter
>> forms, are called.  When the program number doesn't exist in the stream,
>> the timeout is never called, and the idle function stops within a
>> second.
>>     
>
>  This may be a very stupid remark, but do you use queues in your pipeline?  If 
> not, the two sinks will deadlock the main thread...
>
>  Regards,
>  Arnout
>
>   
Not  a stupid question.

I didn't mention them, since they don't look like the source of the 
problem, but there are queues between the source (dvbsrc or filesrc) and 
the demultiplexer and between the sink pads for the demuxed audio and 
video elementary streams and the filesinks.  In the real application, 
the queues from the sink pads feed decodebin in each downstream branch 
and there's another queue between each of those and the final processing 
steps and sinks.  I have tried fewer and more queues, but it doesn't 
change the symptom.  In the queues, "max-size-buffers" and 
"max-size-bytes" are both set to 0.

I may be overstressing this point, but the ONLY difference between a 
trial run that works, including the callbacks being run, and one in 
which the timeout is NEVER called (and the idle stops after a second) is 
that the program number given to the demultiplexer  exists in the stream 
or it doesn't.  It is even the same transport stream in the case of filesrc.