[gst-devel] New DXR3 components and scheduling problem

[Wim Taymans]

On Mon, 2003-03-31 at 15:49, Martin Soto wrote:
> Hi all:

Hi,

> However, in order to be able to play video and subtitles simultaneously,
> I need to put the dxr3audiosink in a separate thread.  As far as I know,
> a reasonable structure would be:
> 
>                         +-----------------------------------+
>                         | Thread                            |
>                         |                                   |
>   +-------+ac3_stream   |  +-------+ ac3_sink +-----------+ |
>   |       |-----o   o---+--| Queue |----------|           | |
>   | MPEG  |             |  +-------+          | DXR3Audio | |
>   | Demux |             |                     |  Sink     | |
>   |       |pcm_stream   |  +-------+  pcm_sink|           | |
>   |       |-------------+--| Queue |----------|           | |
>   +-------+             |  +-------+          +-----------+ |
>                         |                                   |
>                         +-----------------------------------+
> 
> However, as soon as I do that, no more sound buffers are delivered to
> the dxr3audiosink element.  The pipeline seams to run however, in that I
> can see the video running, but no flow of data seems to happen inside
> the thread.  By fiddling with the structure, I have seen that the sole
> fact of having two queues in the thread is enough to stop the flow of
> data, even if only one of them is connected. Putting the queues outside
> the thread seems not to have an effect, i. e. the problem persists.
> 
> Any ideas of what may be happening?  I did my last tests using CVS from
> yesterday (Sunday).  In general I tested with the opt scheduler, but the
> use of other schedulers doesn't seem to improve the situation.

I see 2 problems:

 - the optimal scheduler (opt/optomega/...) will not correctly schedule 
   the above pipeline as it contains two entry points (the queues) in
   a group of elements (provided DX3AudioSink is not loop based).
 - The other schedulers cause a deadlock as one of the queues sinkpad is
   left unconnected.

Some observations:

 - correct behaviour in this pipeline is to (dead)lock until the queue's
   sinkpad is connected.
 - The scheduler has no way of knowing that the queue will be
   permanently disconnected or that it will be connected at some later
   stage.

The solution:

 - Assuming the app is in control of linking the ac3/pcm stream, it
   should deactivate DXR3sinks sinkpad that is not currently active
   (with gst_pad_set_active() or by PAUSING the queue). This will make
   sure that the schedulers do not try to schedule the unconnected queue
   and DXR3sink will not try to pull data on the disabled pad.
 - Since the queue is not connected, changing the state of the thread
   will fail. This can be solved by setting the LOCKED_STATE flag on the
   queue (with the CVS version) so that a state change is not attempted 
   on that element.

There are other options to implement this pipeline, dynamically
reconnecting the queue for example.

Hope this helps, please ask more if needed,

Wim

> 
> Cheers,
> 
> M. S.
-- 
Wim Taymans <wim.taymans at chello.be>