[gst-devel] New DXR3 components and scheduling problem
wim.taymans at chello.be
Mon Mar 31 11:38:09 CEST 2003
On Mon, 2003-03-31 at 15:49, Martin Soto wrote:
> Hi all:
> 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
- 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
- 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,
> M. S.
Wim Taymans <wim.taymans at chello.be>
More information about the gstreamer-devel