multiple source pads in one thread

[Sergey Mironov]

2011/4/6 Sergey Mironov <ierton at gmail.com>:
>> Hello! I'm writing a dvb-source element capabale of working with
>> specific hardware DVB demuxer (PES filter). In it's basic mode, the
>> element has to open 2 devices, read them repeatedly and pass the data
>> to video and audio srcpads. In general, I use guidelines from [1].
>>
>> Algorithm is following:
>>
>> 1. start one GstTask to poll both devices
>> 2. wait for the data to arrive
>> 3. if it's a first data pack, send NEWSEGMENT to both pads
>> 4. send the data to corresponding pad
>> 5. goto 2
>>
>> To try this out, I wrote simple test
>>
>> gst-launch <.debug flags>\
>>     mdemuxsrc adapter=0 name=s \
>>     s.vsrc ! filesink location=$OUT1 name=vsink \
>>     s.asrc ! filesink location=$OUT2 name=asink \
>>     2>&1 | tee $LOG
>>
>> hoping to get two PES streams in separate files. As it turns out (seel
>> log [2]), first filesink is blocking the pipeline and stopping the
>> task. And if I comment out, say, second filesink, test will succeed.
>> As I understand, thats because of some kind of synchronization applied
>> by the core. Is it possible to turn it out? Basically, I want 2
>> independent data streams for now. Or maybe gstreamer doesn't support
>> threads driving more than 1 pad?
>>
>> Thanks in advance.
>> Sergey.
>>
>> [1] - http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-live-source.txt
>> [2] - http://pastebin.com/raw.php?i=PpPnPWaj
>> it is a tail of log, starting at the moment of first data arrival.
>>

Johns Victor wrote the letter, I move it to this thread:

> Sergey, I have been following this thread closely( I assume that this is related
> trying to drive multiple source pads from a single thread) I am Johns
> Victortrying to implement something very similar i.e. I have multiple section
> filters from a demux and would like all to be processed in the same thread. I
> ran into the exact same problem that you did. Did you ever resolve your issue

Well, I lurked inside gstreamer and now think that it doesn't support
threads driving several pads at once. Gstreamer actively uses locks so it is
hard to predict whether gst_pad_push will block or not. The solution is to use
one task per pad. gst_pad_set_task() makes it easy.

The goal I tried to achieve by using 1 thread for all pads was to win some
performance. I hoped to avoid thread context switching - our ARM SoC doesn't
have lots of resources. If it is still possible, please let me know, but now it
looks like one should fight for low CPU usage in some over place :)

Sergey